Design system

A design system is the single source of truth for how a product looks and behaves. It typically has four layers:

• Foundations: design tokens for colour, typography, spacing, radius, shadows and motion.
• Components: buttons, inputs, menus, tables and cards, each with its variants and states. This is the component library.
• Patterns: recurring combinations such as forms, empty states, onboarding steps and settings pages.
• Documentation and governance: when to use what, and who approves changes.

It lives in two places at once: a design library in Figma and coded components in the product. The value comes from those two staying in sync. Brad Frost’s atomic design model, which builds interfaces from atoms up through molecules, organisms, templates and pages, is a common way to structure one.

Why it matters for a SaaS product

SaaS products grow by adding features, and every new feature is a chance for the UI to drift. A design system keeps the tenth settings page consistent with the first, lets engineers assemble screens from approved parts instead of rebuilding them, and makes theming such as dark mode a change of tokens rather than a redesign. It also shortens reviews, because spacing, colour and button styles are already decided.

The cost is upkeep. A system nobody owns goes stale, and an early-stage team can spend weeks documenting components the product will throw away.

How DesignMe handles it

On product design work we create design system foundations: reusable components, patterns, states and rules. Handoff includes organised Figma files, state documentation, and components with variants and variables. If you already have a system, we use it, clean it up or extend it, and only rebuild when it is slowing the team down. When the project includes build, we carry the same components into code.

For N3XT we built a full design system with design tokens, a complete component library, and light and dark theming, structured to atomic-design principles. That system is what let a small team design 300+ screens across web and mobile consistently.

Example

Say a fintech product has four slightly different date pickers and three shades of “primary” blue, each added by a different engineer. A design system pass replaces them with one date picker component, with defined default, focus, error and disabled states, and one semantic colour token. New features use those parts by default, and changing the brand blue later is a single token edit.

Common mistakes

• Building the system before the product. Systematise patterns you have repeated, not ones you are guessing at.
• Figma and code drifting apart. If the coded button differs from the Figma button, the system is two systems.
• Designing only the default state. Hover, focus, loading, error and empty states are where consistency breaks.
• No owner. Without someone approving changes, one-off variants pile up until the system stops being used.