UI Design Create a Design System Create a design system by documenting the small decisions that repeat: colours, type, spacing, radius, shadows, buttons, cards and reusable section patterns.
Problem statement What this workflow solves Target outcome A lightweight design system that helps developers and designers build consistently without inventing styles on every page.
Use this when You need a repeatable workflow, not a one-off article. You want tools, references and UI guidance in one place. You want a short implementation plan you can copy. Collect repeated interface values and existing components. Identify the smallest product surface that will adopt the system first. Agree who can change shared tokens and patterns. :root {
--colour-blue-600: #2563eb;
--colour-surface: #ffffff;
--colour-text: #0f172a;
--colour-action: var(--colour-blue-600);
--space-2: 0.5rem;
--space-4: 1rem;
--radius-control: 0.5rem;
--shadow-card: 0 12px 30px rgb(15 23 42 / 0.08);
}Define colour roles instead of only colour names.
Choose heading, body and small text sizes.
Document buttons, badges, cards, forms and navbars first.
Adding sections because they look impressive instead of helping a decision.
Using inconsistent spacing, button styles or card treatments.
Treating mobile layout as a smaller desktop layout.
1 Start with core tokens Tokens make repeated decisions explicit before they become inconsistent CSS values.
Define colour roles instead of only colour names. Choose spacing steps used by sections, cards and controls. Document radius, shadow and border rules. 2 Standardise typography Readable type scale and consistent heading rhythm make the interface feel calmer.
Choose heading, body and small text sizes. Set line-height rules for dense and long-form text. Avoid viewport-based font scaling that becomes unpredictable. 3 Define reusable components Start with components that appear everywhere before documenting rare patterns.
Document buttons, badges, cards, forms and navbars first. Include empty, hover, focus, disabled and error states where relevant. Keep examples realistic enough to copy into product work. Verification Check every semantic token resolves to a defined primitive. Apply tokens to one real component before expanding the system. Test text, focus and control contrast in light and dark themes. Search product CSS for values that should use shared tokens. Edge cases Not every one-off value deserves a token. Theme tokens should describe roles, not duplicate raw palette names. Breaking token changes need the same review as component API changes. ElementYard CTA Prototype system components in ElementYard Use ElementYard to visually test component patterns before turning them into system guidelines.
Open ElementYard Does a small project need a design system? It may only need a lightweight one. Documenting colours, type, spacing and common components can still prevent visual drift.
Should tokens come before components? Usually yes. Tokens give components a shared foundation, but you can refine tokens as real components reveal gaps.
More guides Build a Landing Page A practical landing page workflow for planning sections, writing copy, checking accessibility and preparing reusable UI components. Launch a Website A practical website launch checklist covering content, metadata, accessibility, sitemap, robots, performance and final link checks. Flexbox vs Grid Learn when to use CSS flexbox or grid for practical responsive layouts, navigation, cards, page sections and interface alignment.