Explicit constraints define what is allowed, what is discouraged,
and what is intentionally unsupported.
Without constraints, flexibility turns into inconsistency
and the system loses its ability to guide decisions.
Make constraints visible and intentional
Constraints must be explicit to be effective.
Documented constraints
EmailButton with icon and label
✓ Supported
Primary use case, fully documentedButton with only icon
✓ Supported
Icon-only variant documentedEmailCustom button styling
✗ Not allowed
Explicitly stated: use design tokens instead
Document allowed variations and supported use cases.Assume constraints will be inferred from examples.State unsupported patterns clearly.Leave teams guessing what is "out of bounds".
A list of tools and services related to this argument.Documentation platforms
Good constraints enable faster and safer decisions.
Safe defaults
mds-buttonvariant="primary", size="md"85% of use casesmds-input-fieldtype="text", size="md"90% of use casesmds-cardelevation="1", padding="md"80% of use cases
Provide safe defaults that cover most use cases.
Expose unlimited configuration for the sake of flexibility.
Limit variation through tokens and composition.Allow arbitrary overrides at the component level.
A list of tools and services related to this argument.Tokens tools
Constraints should be enforced by the system, not by guidelines alone.
Type-safe constraints
variant
primarysuccesserror
type Variant = 'primary' | 'success' | 'error'size
smmdlg
type Size = 'sm' | 'md' | 'lg'disabled
truefalse
booleaninvalid'custom'
Type error
Restrict props and APIs to supported options.Rely on documentation to prevent misuse.Use type systems and validation to enforce rules.Allow invalid combinations to fail silently.
A list of tools and services related to this argument.Type systems
Constraints are not static and must adapt with the system.
Constraint evolution
v2.0.0
Added size="xl" option
High demand from 15+ teams for larger buttons
v1.8.0
Removed variant="custom"Caused inconsistency, only used by 1 team
v1.5.0
Added disabled state constraint
Standardize disabled behavior across components
v1.0.0
Initial constraint: variant limited to 3 values
Reduce decision complexity for common use cases
Revisit constraints based on real usage and feedback.Remove constraints to solve isolated edge cases.Document rationale behind constraints.Treat constraints as arbitrary rules.
A list of tools and services related to this argument.Version control