5 pain points of not having a design system

Nobody decides to skip having a design system. It just happens. You’re busy shipping. The team grows. Someone starts a Figma library “for now”. Someone else spins up a Storybook “when we get time”. Three years later you’re paying for the absence of a system every single sprint. You’ve just stopped noticing, because the cost never shows up as one line item. It shows up as friction, everywhere, all the time.

Here’s what that friction actually looks like. If you recognise three or more of these, you don’t have a design system. You have a collection of good intentions.

1. Figma-to-code is a bottleneck, not a workflow

Your designers hand off pixel-perfect files. Your developers rebuild them from scratch. Every feature cycle restarts the same translation work.

Think about what’s actually happening there. A designer spends a week getting a screen exactly right. Then a developer spends another week (sometimes two) recreating that same screen in code. Same buttons, same spacing, same cards, same tables. Work that was already done, done again, by a more expensive person, with more ways to get it wrong.

And here’s the part that stings: most of that screen already existed. The button existed. The form field existed. The modal existed. But because nothing connects the design file to the codebase, every handoff is a full rebuild. Your team isn’t slow. Your workflow makes them slow.

The tell is in your estimates. If “build the UI” is a meaningful chunk of every feature estimate (for screens made of parts you’ve built ten times before), you’re not estimating new work. You’re estimating translation. And translation is eating your velocity.

2. Your component library exists in name only

There’s a Figma library. There might even be a Storybook. But they don’t match, nobody governs them, and developers default to custom code because trusting the system is slower than building from scratch.

This is the most common state we find teams in, and it’s worse than having nothing. Because on paper, the box is ticked. “We have a design system.” Leadership believes it. New hires are pointed at it. And then everyone quietly routes around it.

Watch what a developer does when they need a dropdown. Do they import one? Or do they check the existing component, discover it doesn’t handle their case, can’t tell if it’s safe to change, and write their own? Every time that happens, you get one more dropdown. We’ve audited codebases with a dozen button implementations. Nobody planned that. It’s just what happens when using the system is riskier than ignoring it.

A component library isn’t a folder of components. It’s a promise: use this, and it will work. When the promise breaks once, people stop believing it. And a library nobody trusts is just documentation of what you wish were true.

Figma Config 2026

Me at Figma, happy to be around design system enthusiasts.

3. Design tokens are missing or hardcoded

Colours, spacing, and typography are scattered across stylesheets. Theming is painful. Multi-brand or multi-platform support feels years away because the foundations were never abstracted properly.

Here’s a quick test. Ask your team to change your primary brand colour. Not redesign anything. Just change one colour, everywhere. If the answer involves a find-and-replace across the codebase and a prayer, your foundations are hardcoded.

That sounds cosmetic. It isn’t. Hardcoded foundations are the reason “can we do a dark mode?” gets laughed out of the room. The reason white-labelling for that big enterprise deal became a six-month project. The reason your marketing site, your app, and your emails look like three different companies. Every one of those is a business opportunity blocked by a technical decision nobody remembers making.

Tokens are boring. That’s the point. They’re the plumbing that makes everything above them cheap to change. Skip them, and every visual decision your team ever made is welded in place.

4. Design and engineering speak different languages

Designers spec interactions that don’t map to real constraints. Engineers interpret specs differently every time. The gap between “designed” and “shipped” keeps growing, and neither team knows who owns it.

You’ve seen this meeting. The designer pulls up the Figma file next to the live product and points out everything that’s off. The spacing is wrong. The hover state is missing. The empty state was never built. The engineer, reasonably, says none of that was in the ticket. Both of them are right. Both of them are frustrated. And the product your customers actually touch is the casualty.

The usual fix is process: more detailed specs, more handoff meetings, more QA passes. That treats the symptom. The disease is that your designers and engineers have no shared vocabulary. When a designer says “card” and there’s no Card component with defined behaviour, “card” means whatever each engineer decides it means that day.

A real design system is that shared vocabulary. Designed and built once, agreed by both sides, named the same thing in Figma and in code. Then a spec stops being an interpretation exercise and starts being an assembly instruction.

5. You’re hiring designers when you need design infrastructure

Adding more designers doesn’t fix any of the above. It makes it worse.

This one costs the most money, so it deserves the most honesty. When UI output feels slow and inconsistent, the instinct is to add capacity. But if your workflow is translation-heavy, your library is untrusted, and your teams share no vocabulary, a new designer just produces more screens to translate, more variants to rebuild, more inconsistency to reconcile. You’re scaling the problem, not the output.

You don’t need more screens. You almost certainly have too many screens. What you need is a system that lets the team you already have ship consistent UI without reinventing it every sprint, so your senior people stop redrawing button states and start working on the problems you actually hired them for.

Infrastructure is a harder sell than headcount. A hire feels like progress; plumbing doesn’t. But one is a recurring cost that grows your problem, and the other is an investment that shrinks it.

San Francisco

Infrastructure is crucial.

The common thread

None of these five are design problems. They’re not engineering problems either. They’re the gap between the two. That gap doesn’t show up on anyone’s org chart, so nobody owns it, so it never gets fixed. It just quietly taxes every feature you ship.

The good news: this is solvable, and it’s been solved before. Not with a tool, not with a Figma template, but with foundations: tokens, components that match in design and code, and clear ownership of the layer in between.

That layer is what we build. If you recognised your team anywhere above, that’s what our design systems service is for. Or just reply and tell me which of the five hurts most (I read every message).