Article Summary
Most companies think they have a design system because they have a brand guide and a Figma library. They don't. A design system is the infrastructure that connects how your brand looks to how your product actually gets built, maintained, and scaled. In the second part of our design system series, we sat down with Avi Debnath, a senior product designer at Intuit, to unpack what a design system actually contains, how teams use one in practice, and what mid-market companies should know before building their own, and how experienced partners can help with sustainable design systems and broader design services.
Key Takeaways
- A design system is a structured collection of foundations (colors, typography, spacing), reusable components, design patterns, and documentation that product teams build from. Think of it like Lego: everyone gets the same bricks, with instructions for how to use them.
- A brand style guide tells you what the brand looks like. A design system tells you how to implement it in a product. One is a reference; the other is infrastructure.
- Design systems serve designers, developers, product managers, and content teams simultaneously. When they work, changes to a single component propagate everywhere.
- Governance is what separates a living system from a forgotten Figma file. Someone has to own what gets added, what gets changed, and how teams contribute.
- Adoption is cultural, not technical. The system has to be easier to use than the alternative, or people will route around it.
- Mid-market companies are in the highest-risk zone: big enough to have multiple teams shipping simultaneously, small enough that nobody owns the system.
- You don't need an enterprise-scale operation to get started. A small set of design tokens, a core component library, and one person who owns decisions is enough to begin.
Related Video
Full Article
The Lego analogy (and why it works)
We recently brought Avi Debnath onto the podcast to talk about what a design system actually is. Avi is a senior product designer at Intuit, where he works on a design platform that serves business units across TurboTax, Mailchimp, and QuickBooks. We asked him to explain a design system to someone who has never heard the term.
His answer was immediate: Lego.
"Think of a design system like a box of Lego. You have standardized bricks that snap together in predictable ways. Anyone can build with them, and what they build looks and feels like it belongs together. The system is the bricks, the instructions, and the rules for how to combine them." — Avi Debnath, Senior Product Designer, Intuit
That analogy does a lot of heavy lifting. A design system is a structured collection of foundational elements, reusable components, documented design patterns, and the rules that govern how they all get used. It is a single source of truth for how your product gets designed and built. The Figma library is part of it. The coded component library is part of it. The documentation, the naming conventions, the governance model: all of it.
If you read part one of this series, you already know what happens when teams don't have a system: brand drift, design debt, and a ball of yarn that gets more expensive to untangle every quarter. This piece is about what the system itself looks like and how teams actually use one.
What's actually inside a design system
Most people picture a color palette and some button styles. A mature design system goes quite a bit deeper.
Foundations are the base layer: design tokens that define color, typography, spacing, elevation, and motion as variables. Instead of hardcoding a hex value in twelve places, you define it once as a token and reference it everywhere. When the brand color changes, you update the token and the change propagates. Foundations are the plumbing.
Components are the reusable UI elements that product teams build with. Buttons, form fields, navigation patterns, modals, cards, tables. Each component has defined states, accessibility specs, and corresponding code. A component library in Figma and a matching coded component library (often React, published via npm) should point to the same source of truth.
Patterns sit above components. They're repeatable solutions to common problems: how authentication flows work, how search behaves, how error states are handled. Patterns combine multiple components into documented workflows that teams reference instead of solving the same problem differently every time.
Documentation is the layer most teams skip. Usage guidelines, do-and-don't examples, accessibility considerations, code snippets. Documentation is what separates a design system from a UI kit. Without it, you have parts but no instructions. A new developer joining the team should be able to open the documentation site and understand how the company builds interfaces within an hour. If they can't, the system isn't documented well enough.
These layers, foundations, components, patterns, and documentation, live together in a central repository, usually a dedicated documentation website that both design and development teams can reference. The specific tools matter less than the principle: one place where everyone goes for the truth about how the product is built.
How teams actually use one
A design system serves designers, developers, product managers, and content teams across products and platforms. That breadth is what makes it valuable and what makes it difficult to get right, which is why pairing it with a holistic, systems-thinking UX framework for digital transformation can be so powerful.
Designers pull from the component library and documented patterns in Figma to assemble screens, rather than designing from scratch. Developers consume the same system through coded component libraries. When a core component gets updated, say a new focus state gets added to the primary button for accessibility, that change propagates to every product using it. You fix something once and it's fixed everywhere.
Product managers benefit from the shared language. When everyone on a cross functional team references the same components and patterns, conversations about scope get faster. "Use the existing search pattern" is a much shorter conversation than "let's design search from scratch."
The day-to-day impact shows up in design reviews that get shorter, handoff errors that drop, and new team members who onboard faster because the system itself documents how the company builds things. Reports from firms that have implemented design systems suggest efficiency gains of 30 to 40 percent in developer time. Those numbers compound the bigger your team gets and the more products you ship, especially when you invest in end-to-end product design and development services that know how to operationalize those systems.
There's also an accessibility angle that doesn't get talked about enough. If you don't have a dedicated accessibility specialist on staff (and most companies with 50 to 200 people don't), the design system is your guardrail. When components include contrast-checked color tokens, keyboard focus states, and proper ARIA attributes by default, teams meet standards like WCAG 2.1 without scrambling at the end of a sprint. The system does the compliance work so individual designers and developers don't have to reinvent it.
It's not a brand guide (but it needs one)
This is the most common confusion we hear from clients. They have a brand guide. They assume that means they have a system.
A brand style guide tells you what the brand looks like and sounds like: logo usage, color palette, typography, tone of voice. It applies across everything, from print to social to digital. A design system defines how those rules get implemented in digital products. It translates brand decisions into usable components, patterns, and code that product teams build with.
A UI kit is a third thing. A collection of pre-made visual elements in Figma or Sketch. UI kits help teams move quickly, but they stop at design assets. No production-ready code, no documentation, no governance.
The three work together. Marketers reference the brand style guide. Product teams rely on the design system. The UI kit provides building blocks inside the design tool. When these are aligned, stakeholders see consistent execution across every surface, which speeds up approvals and builds trust with clients and prospects.
Where it gets interesting: as a design system matures, it can start influencing brand decisions. If the brand's primary blue doesn't meet contrast requirements for accessibility, the design system team surfaces that problem and works with the brand team to adjust. The feedback loop runs both ways.
Governance: the part nobody wants to talk about
Governance is the difference between a system that gets used and one that gets ignored.
Design system governance is the set of rules, roles, and processes that determine how the system changes over time. Who owns each component? How are new components proposed? What criteria must be met before something gets added? How are breaking changes communicated?
Without governance, you get design drift: the gradual gap between what the system documents and what actually ships. Teams hardcode values instead of using tokens. Someone creates a local override that never makes it back to the main library. Six months later, the system is a fiction.
Avi's perspective from Intuit was useful here. At their scale, they handle governance through a contribution model: product teams build what they need, and the design system team reviews it, smooths out the rough edges, and decides whether it belongs in the core system or stays product-specific.
"We're pretty opinionated about some things and flexible about others. The key is being clear about which is which. If teams know where they have freedom and where they don't, adoption gets a lot easier." — Avi Debnath, Senior Product Designer, Intuit
For a mid-market company, that level of formality isn't necessary. But the principle holds. Define who owns decisions. Set up a lightweight review process. Make the rules transparent. And track basic metrics: how many products are using system components, how many overrides exist, how often the library gets updated.
The goal is to make using the system the path of least resistance. If the system is harder to use than going around it, people will go around it.
And because someone always asks: yes, design systems have to justify their existence. Avi brought this up unprompted during our conversation, and we hear it from every client. The ROI conversation is unavoidable. Frame the system as infrastructure, not a project. The first six months might feel like overhead. After a year, the teams using it are shipping faster, the brand is more consistent, and the cost of maintaining the system is a fraction of the cost of not having one.
Do you actually need one?
There are signals. Multiple products sharing similar UI patterns. Multiple teams working in parallel. Recurring inconsistencies. New hires taking too long to get productive. If any of those sound familiar, you're already paying the cost of not having a system.
The trade-off is real: building a design system requires investment. For very early stage products, single-developer teams, or one-off campaigns, a full system is overkill. A shared set of tokens and a small component library is a better starting point, especially as new tools and workflows continue to blur the line between design and development in modern, process-focused design practice.
The moment more than one team is touching your product or brand materials, the cost calculus shifts. We covered this in part one: the cost of fixing inconsistency downstream is dramatically higher than building the system upstream.
In the next episode, we'll get into the practical side: how to know if you're ready to invest, and a framework for actually scoping and building a design system at your scale.
Frequently Asked Questions (FAQ)
Is a design system just a fancier name for a style guide?
No, and the distinction matters. A style guide covers visual rules: logo usage, colors, typography, imagery. A design system includes those visual foundations plus reusable coded components, documented patterns, accessibility specs, and a governance process for how the system evolves. The style guide is one layer inside the larger system.
How do I know if my company is big enough to need a design system?
Size is less relevant than complexity. If you have more than one product, more than one team building UI, or you're onboarding new people regularly, you're likely already experiencing the symptoms: inconsistent interfaces, duplicated components, slow handoffs between design and development. Even a small team can benefit from a lightweight system if they're maintaining multiple digital products.
What's the difference between a design system and a UI kit?
A UI kit is a collection of pre-made visual elements and templates inside a design tool like Figma. It helps designers move quickly, but it stops at design assets. A design system extends into production-ready code, documented patterns, usage guidelines, and governance. Many mature design systems include a UI kit as one piece of a larger infrastructure.
How long does it take to build a design system from scratch?
A useful starting point (core tokens, five to ten components, basic documentation) can come together in a few sprints. A mature system with broad coverage, contribution models, and multi-product adoption is an ongoing investment measured in months and years. The mistake most teams make is waiting until the system is "complete" before releasing it. Ship early, get feedback, iterate.
Can a design system support multiple brands?
Yes. Multi-brand systems use shared core tokens and patterns with brand-specific theming layers on top. You keep the structural patterns and component logic consistent, then swap out the visual layer per brand. Plan for it early if it's on your roadmap; retrofitting multi-brand support after the system is built is considerably more work.
What does design system governance actually mean in practice?
Governance is the process for deciding how the system changes. At minimum, it means someone owns the system, there's a way to propose new components or changes, and there are clear criteria for what gets approved. For small teams, this can be a weekly 30-minute review and a shared decision log. The point is to prevent drift: the gap between what the system documents and what actually ships.
Do I need to build a custom design system, or can I use an existing one?
Both paths work. Adopting an existing open-source system (like Google's Material Design) reduces setup time but still requires customization to match your brand. Building custom gives you full control but demands more resources and ownership. Most teams land somewhere in between: they start with an existing system's structural patterns and customize the visual layer and documentation to fit their needs.
