Amey-Thakur Design systems
A design system earns its cost when a new screen is faster to build and looks like it belongs. It fails when it becomes a museum nobody uses or a cage nobody can work in. Aim for the useful middle: shared decisions, room to move.
Method
- Start from tokens, not components. The primitives come first: a color scale, a type scale, a spacing scale, radii, shadows, motion durations. Everything else references these, so a change to the brand is a change in one place. Name tokens by role (surface, text-muted, accent), not by value (gray-200), so the meaning survives a repaint and themes are possible.
- Build components on the tokens, in layers. Primitives (button, input, text) compose into patterns (form field, card) compose into layouts. A component that hardcodes a color or a pixel value instead of a token is a future inconsistency.
- Design the states, not just the default. Every interactive component specifies hover, focus (visible, always), active, disabled, loading, and error. The default state is the easy 20%; the states are where consistency and accessibility actually live.
- Make the accessible path the default path. Components ship with correct semantics, keyboard behavior, focus management, and contrast built in, so a product team gets accessibility by using the system, not by remembering to. An inaccessible component in a design system multiplies the failure across every screen.
- Document usage, not just appearance. Each component says when to use it, when to use a different one, and the props that matter, with a live example. A gallery of components with no guidance produces creative misuse.
- Version and change with care. The system is a dependency for every product using it, so treat changes like an API: additive freely, breaking changes with a version and a migration note. A silent restyle is a production incident distributed across teams.
Judgment calls
- Consistency versus flexibility: enforce the decisions that carry the brand and the accessibility floor; leave room for product-specific layout. A system that forbids everything gets forked and abandoned.
- When to add a component: the third time a pattern is rebuilt by hand is the signal, not the first. Premature components ossify a shape before it is understood.
- Tokens versus one-offs: a value used in three places is a token; a value used once may stay local until it repeats.
Litmus tests
- Can a new screen be built mostly from existing components, and does it look native without extra effort?
- Does a single token change repaint the product correctly?
- Is every component usable by keyboard and screen reader out of the box?
- Could a product team learn a component from its docs without reading its source?