Design systems, without the marketing
The term "design system" has been worn out by two years of LinkedIn posts. So let's reset the definition.
A design system is the executable, versioned, single source of truth for how your product looks and behaves. "Executable" because designers work from the same components engineers ship. "Versioned" because the system evolves over time and old versions need to keep working. "Single source of truth" because if there's still ambiguity, the system isn't doing its job.
A Figma file with some buttons in it is not a design system. A Storybook with 40 components and no design tokens is not a design system. The system is the bridge between them.
What changes when you have one
Three things, measurably:
Speed of new feature work. On projects where we introduce a real design system mid-engagement, feature delivery accelerates 30–50% within two sprints. Designers stop reinventing form patterns. Engineers stop reimplementing buttons. PRs shrink.
Consistency across surfaces. Multi-product companies are the obvious case, but even single-product teams benefit. The marketing site, the app, the admin dashboard, the email templates — if they share tokens, they look like they came from the same company. Without shared tokens, they always drift.
Onboarding cost. A new designer or engineer can ship their first PR in their first week instead of their first month. The system answers most "how do we do X" questions before anyone asks.
What goes inside
A working design system has roughly four layers. Skip any of them and the system gets brittle.
1. Tokens. Colors, typography, spacing, radii, shadows, motion durations, easing curves. These are JSON, not images. They feed both Figma (via tools like Tokens Studio) and code (via Style Dictionary or similar). The token layer is the most important and the most often skipped.
2. Primitives. Buttons, inputs, selects, checkboxes, radios, toggles, badges, tooltips, modals. The atomic UI elements that show up on every screen. These should be implemented once, with proper accessibility (focus rings, ARIA, keyboard support), and documented with prop tables.
3. Patterns. Forms, navigation, empty states, loading states, error states, data tables. These are compositions of primitives. They encode opinions: "this is how we handle a multi-step form," not "here's a form library."
4. Guidelines. Voice and tone, accessibility standards, content rules ("we use sentence case in buttons"), animation principles. The non-component parts that keep the work coherent.
A common failure mode: shipping the system, abandoning it
Half the design systems we see in client codebases were built two years ago, used for six months, and then quietly bypassed. Symptoms: a Storybook that no one updates, components in the codebase that shadow design system components, color hex values hardcoded in 30 places.
This usually happens when the system is treated as a one-time deliverable instead of a living product. The fix is structural:
- Assign an owner. Even part-time. Without an owner, no one decides when a new component graduates into the system.
- Make the system easier to use than to bypass. If adding a new component to the system takes longer than copy-pasting one, you've lost.
- Run a quarterly audit. Walk every screen, count drift, fix it. We use a simple metric: "percent of screens using only system components." Anything below 80% is a problem.
Starting small (and not stopping)
You don't need a 200-component library to call it a design system. A working v1 fits in a single Figma library and a single npm package, and contains roughly:
- 8 color tokens
- 4 type scales
- A spacing scale (4 / 8 / 12 / 16 / 24 / 32 / 48)
- 6 components: button, input, select, modal, card, table
- 3 patterns: form layout, page header, empty state
That's a real design system. Ship it on Friday, use it on Monday, grow it over the next year.
When you don't need one
A team of two building a single product for six months will ship faster without the overhead of a formal system. The break-even point is roughly: three or more designers/engineers, multiple surfaces, or a product expected to live more than 18 months. Below that, just write down the conventions and move on.
Above that, the question isn't "should we build a design system?" — it's "how much have we already paid for not having one?" If you want a second opinion on where your team's system stands, our UI/UX design team runs a lightweight audit as a starting point.
