10 signs your product needs a design system (and what it's costing you now)
In 2016, Airbnb engineers described their codebase as suffering from three compounding problems: fragmentation, complexity, and performance issues. The fragmentation alone – engineers using different frameworks, CSS hardcoded and overridden across multiple files – had grown to the point where the team printed out their screens and laid them side by side on a board just to see where the experience was breaking. That exercise became the starting point for Airbnb’s Design Language System.
The decision to build a design system is rarely proactive. It usually happens when the cost of not having one becomes impossible to ignore. The question isn’t whether your product needs one. It’s whether you’ve already crossed the threshold where the absence of a system is slowing you down more than building it would.
These are the ten signs that threshold has been crossed.
Table of contents
10 signs your product needs a design system
1. Your team uses AI tools, but every output looks slightly different
Cursor, Claude Code, and Figma Make generate UI from whatever visual logic is available in the codebase. Without a shared token architecture, each tool infers spacing, colour, and typography independently – from whatever it finds in the code. The inferences are close, but not identical, and they compound across every session and every team member using them. The result isn’t obviously broken. It’s subtly inconsistent – and subtle inconsistency is harder to fix than obvious breakage, because it never creates a single moment of urgency.
A design system gives AI tools a shared reference. Instead of inferring, they read from your token architecture. The output stays within the visual boundaries your product was built on.
2. You have more than one version of the same component in production
This is the most diagnostic sign of all. Three button variants, two modal styles, four card layouts – none of them wrong enough to block a release, all of them different enough to signal that decisions are being made locally rather than systemically.
Airbnb’s engineers described exactly this pattern in their 2016 codebase: when pressed with incoming deadlines, engineers would write their own components rather than use the design system’s components, defeating the point of having a system in the first place. The component count grows faster than the product does, and the only way to stop it is to make the shared component the path of least resistance.
3. A new designer or developer spends their first two weeks asking which component to use
Onboarding time is a direct measure of documentation quality. If the answer to “which component do I use here” exists only in the memory of the person who built the system, every new hire starts from zero. The knowledge doesn’t compound – it resets.
Tuomas Artman, co-founder and CTO of Linear, describes the inverse of this problem: engineers who have trained their eye for quality through consistent practice start noticing problems while building new features, not just when reviewing existing ones. That kind of compounding attention only develops when there’s a shared standard to measure against.
4. Changing a colour or spacing value requires touching dozens of files
This is the absence of design tokens made visible. One decision – update the primary button colour – becomes a multi-sprint engineering task instead of a single token change that propagates automatically across your design tool and your codebase.
Shopify’s Polaris design system, launched in 2017 to solve fragmented user experiences across Shopify’s growing app marketplace, was built specifically around this problem: before Polaris, developers building apps for Shopify struggled to match Shopify’s interface standards, resulting in jarring transitions between native features and third-party apps. The system made consistency the path of least resistance.
5. Design and production look different, and nobody is sure why
Your design tool says one thing. The codebase does another. The gap widens with every sprint because there’s no defined process for keeping them in sync – and no single source of truth either side is working from.
Design-to-code parity isn’t a tooling problem. It’s a governance problem. The tools exist to keep design and code aligned – Token Studio in Figma, Style Dictionary in the codebase – but without a defined process for who updates what and when, the gap reopens faster than it gets closed.
6. Your team is preparing for AI-assisted development but has no token architecture
If design tokens aren’t named, documented, and shared before your team starts using AI tools at scale, those tools will infer their own visual logic from the existing codebase. That logic will be inconsistent, because the codebase is inconsistent. The design system needs to exist before the AI tools are deployed at scale – not after, when the fragmentation has already accumulated.
7. Three or more teams are building the same product simultaneously
Parallel development without shared infrastructure is the fastest path to visual fragmentation. Each team makes locally reasonable decisions – a slightly different card component, a slightly different spacing scale – that are globally incompatible. The product begins to feel assembled rather than designed.
Google’s Material Design, announced in 2014, was built in part to solve this problem at a scale most companies will never face: unifying Gmail, Chrome, Android, and every other Google product so they felt like they existed in the same family. The internal description at Google was that they needed to “clean out the cruft – the unnecessary bubbles and bumps that had been part of Google’s UI story for a long time.”
8. A full redesign feels inevitable, but you can’t justify the cost
Design debt compounds silently. The moment a team starts discussing whether it’s easier to rebuild than to fix, the absence of a design system has already become the most expensive line item in the product budget – it just hasn’t been named yet.
Airbnb’s own design system had to be rebuilt in 2018 – not because the original was badly built, but because the product had expanded so significantly that the system couldn’t accommodate the new scope without a structural rethink. Building the system earlier doesn’t prevent evolution. It makes evolution cheaper.
9. Your product feels like it was built by several different companies
Users rarely articulate inconsistency directly. They don’t say “your spacing scale is off” or “this component doesn’t match the one two screens back.” They say the product feels off, or they stop trusting it, or they churn. The feeling precedes the diagnosis.
Tuomas Artman described this dynamic at Linear: quality doesn’t affect revenue, until it does. And by then it’s a slow drain, not a sudden drop – hard to attribute, hard to reverse. The 150-millisecond fade-out on a hover state that Linear spent time getting right isn’t a detail for its own sake. It’s the accumulated effect of hundreds of such decisions on how the product feels.
10. You’re scaling the team but not the system
Hiring more designers and developers into a product without shared infrastructure doesn’t accelerate delivery – it accelerates divergence. Every new team member is another vector for visual inconsistency without a system to constrain it.
Shopify’s Polaris was built not just for Shopify’s internal teams, but for the thousands of third-party developers building apps in the Shopify ecosystem. The design system became the mechanism through which Shopify could maintain consistent quality across a product surface no single team could directly control. Scale made the system necessary. The system made scale possible.
What it’s actually costing you
The cost of not having a design system rarely appears as a single line item. It accumulates across three categories:
Time. Rebuilding components that already exist. Debugging visual inconsistencies introduced by parallel teams. Onboarding new hires into a system that lives in people’s heads rather than documentation. These hours are real, but they’re distributed across sprints and teams in ways that make them invisible in any single planning cycle.
Speed. The gap between a feature request and a shipped feature widens as the component inventory grows without governance. Engineers spend time deciding which component to use, creating new ones when they can’t find the right one, and resolving conflicts when two teams built the same thing differently.
Quality. The product gradually stops feeling like a single thing. Users don’t need to be able to name design inconsistency to feel it. The feeling compounds into trust – or its absence.
The threshold question
Every team that has built a design system describes the same pattern: they waited longer than they should have, the cost of starting was lower than they feared, and the compounding returns came faster than they expected.
The ten signs above are not a checklist to complete before you act. They’re a map of where you already are. If three or more of them describe your product today, the threshold has been crossed.
Share this article:
