01 / Design Systems
June, 2023Approaching Design Systems in a Scale-up
Most scale-up teams invest in a design system to improve UX. In reality, the decision is a business one: running the engineering function more effectively.
Throughout my career, the main pattern I have seen is design leaders hiring specialists to build a design system for the sake of having one, without engineering alignment. Like any major investment, this requires a scalable approach and a clear plan first. A design system is not only about better UX. It is about unlocking critical business and engineering advantages.
From a business perspective, a well-implemented design system leads to faster time to market and lower development costs. It removes redundant work and streamlines maintenance. It also improves collaboration, which reduces burn rate. These are CFO-level arguments. They are the ones that secure budget and gain traction with engineering.
From an engineering perspective, a design system means a clear path to code reusability through centralized component libraries. It accelerates development and raises code quality: fewer bugs, less technical debt. This way, sprint time gets spent on real product and architecture thinking.
That sentence describes the graveyard of design systems. Beautifully documented, meticulously color-tokenized, and completely ignored by the engineers who were never part of the conversation. A design system without engineering buy-in is a very expensive style guide.
Like any meaningful investment, building a design system requires a scalable approach and a plan. Which means you need to understand where you are before you can plan where to go.
The Three Stages of Design System Maturity
Every company that builds products across multiple teams goes through a predictable progression. Understanding which stage you're in changes what you should do next. The diagram below maps this trajectory: products and features sprawl horizontally over time, complexity grows downward, and there is a single inflection point where everything changes.
The design system maturity arc, from ad-hoc chaos to strategic infrastructure
The red vertical line is the hinge of the entire argument.
Everything before it reflects one mode of operating in a company moving from MVP stage toward maturity. The need for a design system becomes clear when product complexity reaches a threshold. Missing this moment, or misreading it, is an expensive mistake for a growing product organization.
At this stage, priorities are rightly set around achieving product-market fit. Design and engineering operate more ad hoc, and that flexibility allows rapid direction changes. UI libraries are a strong starting point and a cost-effective way for different teams to solve similar interface problems. The cost tradeoff is relatively low, and the accumulated UX debt is manageable.
Business-wise, this can be considered a smart approach.
Ad-hoc methods become unsustainable. Engineering faces technical debt. Maintaining a consistent UI becomes a drag on velocity. This is the strategic moment to invest in a design system, and the stage where most execution mistakes happen.
- Work with agencies or externals first
- Don't hire UI wizards as Product Designers
- Delegate ownership to skilled, interested designers
- Empower them through accountability
The design system is a mature, integral part of development. Initial investment yields faster development cycles, improved product quality, and faster time to market. The organization scales effectively with less burn rate.
- AI-first approach as technology advances
- Dedicated DS and Code Library team
- Extend DS based on product needs, not system needs
- DS designers are not siloed to only building the DS
Why Stage 2 Is Where Teams Go Wrong
The critical mass moment is obvious in retrospect and invisible in the present. Teams notice the symptoms (slower sprints, inconsistent UIs, design-engineer handoff friction, onboarding that takes weeks longer than it should) but misattribute them. They hire more designers. They adopt a new design tool. They run a workshop.
What they should do is treat the design system as a product with a roadmap, not a project with a deadline. That distinction changes everything: who owns it, how it gets funded, how it evolves, and whether it will still be used in two years.
The pattern I have seen consistently, in both large and small organizations, is that Stage 2 investments are often made without grounding them in business realities.
Design leaders tend to hire a dedicated "design system team" before the system has real users. The focus shifts to building exhaustive token taxonomies before understanding actual component needs in the product. "UI guru" designers are hired to build quickly, without first building product understanding or experiencing pain points firsthand.
Stage 3 looks deceptively simple from the outside. The system just works. New products spin up faster. Engineers reach for components instead of building from scratch. Designers spend less time in review cycles and more time on actual product thinking. But that simplicity is the accumulated result of hundreds of small, deliberate decisions made in Stages 1 and 2.
The Organizational Principle That Actually Matters
Beyond strategy and timelines, there is one organizational principle that predicts whether a design system lives or dies: integration without isolation.
Design system designers should not be siloed into only building the design system. They need to be embedded enough in product work that they feel the friction directly, so they know which components are painful to use, which tokens are missing, which patterns keep getting reinvented. The moment the DS team loses that connection to real product problems, they start optimizing for the system's own internal consistency rather than for the people trying to ship with it.
Similarly, engineering alignment is not optional. A design system that engineers didn't help shape is a design system that engineers will quietly route around. The component API, the naming conventions, the build pipeline integration: all of these require engineering to be in the room from the start, not handed documentation after the fact.
The business and engineering advantages are real. The investment compounds over time. But the only way to capture those advantages is to build the system for the right reasons, at the right moment, with the right team, and to resist the temptation to hire your way into something that actually requires clarity of purpose to exist.
