What starts the process?
Design system work begins with an audit of every existing screen, component, and style rule a product already carries. Teams catalogue what exists before creating anything new, because scattered inconsistencies discovered here shape the entire build plan.
Auditors screenshot every interface state, group similar elements side by side, and count how many button styles, colour values, and text sizes currently exist across the live product. Numbers from this stage frequently exceed product owner expectations, since a mature application commonly holds thirty button variants where four would serve. A UX agency running this phase also interviews engineers about which components cause repeated build friction, because developer pain points reveal where a system delivers value fastest. Findings then get sorted into elements worth keeping, elements that can join together, and elements ready for removal. This inventory becomes the contract for everything that follows, and audits skipped or rushed at this stage resurface later as gaps the finished system cannot cover.
How do foundations form?
Colour, typography, spacing, and grid rules come first because every later component inherits from them. Agencies call these decisions tokens, and each token carries a name, a value, and a usage rule.
- Colour tokens pair each value against contrast checks so accessibility holds across every future screen.
- Type scales fix a small set of sizes and weights that cover headings through captions.
- Spacing units follow one base number, keeping margins and padding mathematically related.
- Grid rules state how layouts respond across phone, tablet, and desktop widths.
Token decisions lock early because changing a foundation after fifty components exist forces fifty revisions.
Assembling component libraries
Components build upward from simple to complex. Buttons, inputs, and labels arrive first, then combinations like search bars and cards, then full patterns such as checkout flows or dashboard layouts. Each component arrives complete with every state it can show, covering hover, focus, error, disabled, and loading, because missing states get defined inconsistently by whichever team encounters them first.
Documentation grows beside each piece. A component without written usage rules spreads misuse as fast as the component itself spreads, so agencies write clear notes into the library explaining where each component fits and where it does not belong. Engineers receive coded versions matched exactly against design files, and mismatches between the two get resolved before release rather than after.
Sustaining system adoption
Handover decides whether a system stays in active use or falls out of use entirely. Agencies run training sessions with internal designers and engineers, walk through contribution rules, and set up a request path for new components discovered during real product work.
Governance follows the launch. Someone inside the client organisation takes ownership of approving additions, retiring old patterns, and keeping documentation current, with the agency often reviewing quarterly during the first year. Systems tracked through usage measurement show which components teams actually adopt, and low adoption signals either a training gap or a component that solves nothing. Living systems change monthly, while abandoned ones freeze within a quarter.
A design system emerges through audit, foundations, components, and sustained governance in that order. Each stage depends on the one before it, and the finished library succeeds only when internal teams treat it as their own working tool rather than a delivered artefact left unused.
