3 min read
A design system's job in a five-person team
A design system isn't a layer of bureaucracy. For lean teams, it is how you stop re-solving the same UI problems every sprint.
Furkan ÇolakDeveloper
“Design system” sounds like something a 200-person product org needs and a five-person team doesn’t have time for. That reasoning is backwards. Big companies build systems to coordinate hundreds of people who will never meet. Small teams need them for a cheaper reason: to stop relitigating the same spacing argument in every sprint.
Nielsen Norman Group’s research on lean design-system teams found something counter-intuitive: small, close-knit teams often produce better-adopted systems than large, centralized ones, because the people using the components are the same people who built them (NN/g, “Small by Design”). There’s no translation layer between “what the system says” and “what the product actually needs.”
The performance case is concrete, too. Teams working with a well-adopted design system complete comparable UI tasks roughly 34% faster than teams without one (Figr, “Driving Design System Adoption That Works”). The decision about how a button, a card, or an empty state should look was already made once, correctly, instead of being re-argued in every PR review.
Fewer decisions before a component library
Start by documenting the patterns you’re already repeating: forms, cards, navigation, empty states. That’s the beginning of a system. Not a 200-component Figma library assembled before a single screen ships.
The goal on day one isn’t coverage. It’s removing the handful of decisions that get re-made, slightly differently, every week: What’s our spacing scale? What does a disabled button look like? How do we phrase an error?
Constraints are a quality mechanism
Limits force consistency, and consistency reads as professionalism; especially for a small team shipping fast enough that nobody has time for a full visual QA pass before every release.
When a component is shared, a fix propagates everywhere it’s used. When every screen is bespoke, the same bug gets fixed three times in three slightly different ways, and a fourth instance nobody noticed keeps shipping broken.
Adoption beats mandate
One recurring finding across case studies, including a rollout at Storyblok that had no dedicated design or development headcount assigned to it, is that systems succeed when they’re adopted by the people who need them rather than imposed from above (Sparkbox, design system case studies). A system that requires a mandate to survive is a system that will quietly stop being followed the first time a deadline gets tight.
Grow the system with the pain
Add tokens and components when a specific inconsistency starts costing you real time. Not preemptively, in a burst of tidiness before a launch nobody asked you to prepare for.
A living system that three people actually reach for beats a comprehensive spec that lives in a Figma file nobody opens. For a small team, that’s not a nice-to-have. It’s the difference between shipping and re-deciding.
Recommended articles
Custom software or off-the-shelf
The decision is not made by comparing features. It is made by where the part of the work that sets you apart from competitors sits.
What an MVP is and how to scope it
Scope comes from the assumption being tested, not from a feature list. Anything that does not serve that assumption waits for the second version.
Which pages a company website needs
A separate page per service does more work than a single 'Our services' page, because people search for the service, not the company.