You’re staring at your Figma file.
Spacing feels off. Typography doesn’t quite capture your brand. The components from the framework you're using feel... fine, but not you.
You start to wonder:
“Is it time to build our own design system?”
It’s a tempting thought. But before you dive into building from scratch, it’s worth understanding what that really means — and whether it’s the right move for your team, your product, and your future.
Why build a design system from scratch?
Building your own system gives you complete creative and functional control. Here's why some design teams take the leap:
You have specialized industry requirements
Some industries require more than just good looks. Healthcare, education, and finance often bring accessibility, compliance, and workflow challenges that off-the-shelf components weren't built for.
You want to scale across a large team
When you're supporting a larger team of designers (and roles), you need consistency and flexibility. Building your own system lets you tailor foundational rules, naming conventions, and component logic that your entire team can grow with. You might have multiple brands that need to be built off of the foundations your setting here.
You want brand identity to be strategic advantage
If your brand experience is the product — then pixel-perfect control over your interface matters. Building from scratch lets you craft a system that reflects your brand's voice in every component.
But first: what needs to be true before you build
Building a design system from scratch isn't just a design decision.
It's a product team decision.
Here are a few signs you might be ready:
- Your design team is repeatedly hacking or overriding your current framework.
- There's strong internal support from engineering to invest in a system.
- You've outgrown the limitations of what you're using today (Think UI kits like Material Design, Tailwind UI (now Tailwind Plus), etc.).
- Your product roadmap supports a long-term investment in design consistency and scalability.
- You've already started documenting components and patterns organically — now you need to formalize it.
If these don't resonate yet, you might benefit more from a hybrid or customized framework approach instead of starting from zero. We'll cover that approach soon in another article. But if you feel ready, consider checking out our Design System Course to prepare yourself for the entire process and help lead your team.
What expectations should you set with your team?
If you're going to build from scratch, alignment matters. It's not just about getting stakeholder buy-in — it's about setting clear, shared expectations for what the work looks like over time, and who's responsible for what.
A simple way to think about it is:
- What are we building? Components, documentation, tools
- When will things be delivered? Milestone dates and sprints
- Who will have access to those things? Team adoption timelines
I talk about those three themes here in my recent article on how to use Design System Roadmaps to communicate with stakeholders.
Here are some themes your team needs to consider that can keep any design system effort running smoothly.
Get aligned on:
1. It's a long-term investment
Design systems don't happen in a sprint. This is foundational work — not a feature release.
You're building tooling that supports every feature that comes after it. That takes time. Expect multiple phases of design, documentation, engineering, feedback, and iteration.
What to align on:
- Don't expect pixel-perfection on Day 1.
- Budget time for foundational work like token definitions and accessibility standards.
- Prioritize long-term scalability over short-term aesthetics.
- It's not a project, it's a product and it's going to need support and investment as long as it's around.
2. Design and engineering should build together
A beautiful Figma file means nothing without dev implementation. A robust component library in code means little without clear usage guidance from design.
Designers and developers need to be working side-by-side — not in separate silos with handoffs in between.
What this looks like:
- Engineers are involved early in component design discussions & foundational meetings about properties and naming.
- Designers who understand technical constraints and performance tradeoffs.
- Shared documentation tools like Storybook or Zeroheight that bridge design and code.
- Weekly syncs or design-dev crits to spot gaps before they grow.
This isn't just about collaboration. it's about co-ownership.
Understand and document the needs of the team
Our Design System Interview Template is a great resource to talk to the entire team to better understand the needs of each role, expectations, and getting the feedback you need. This helps you discover blind spots and reduce issues later on in the design system build.
3. Governance is critical
Without a plan, your design system won't be nurtured like it should be.
Governance isn't about gatekeeping. It's about setting up a framework to keep things scalable, consistent, and trustworthy across teams.
What to define early:
- Who owns the system? Is there a design systems team, or a cross-functional working group?
- What's the process for contributing new components?
- How are decisions made about deprecations, updates, or naming conventions?
- How is documentation reviewed and updated over time?
Governance brings clarity. And clarity creates adoption.
Check out our free design system governance template for Figma.
4. Visual changes will happen gradually
When you build from scratch, there won't be a single moment where the new design system "launches." You'll likely introduce changes in phases.
One flow, feature, or product at a time. And that's okay.
What to communicate:
- Legacy UIs may exist for a while during the transition.
- Developers may implement dual systems temporarily.
- Not every product or brand touchpoint will update simultaneously.
- This is a great time to talk to your teams about contributing to your system.
Setting this expectation helps avoid frustration. Especially from stakeholders expecting a full rebrand overnight.
How to build in phases (even with a small team)
You don't need a team of 12 to start. Here's how smaller teams can approach a phased rollout:
Phase 1: Audit what exists
- Review current UI patterns, spacing, and typography.
- Look for inconsistencies and duplication.
- Identify high-traffic or high-visibility areas as starting points.
- Check out our free design system component capture template and tutorial
Phase 2: Start with foundations
- Define your design tokens (color, spacing, typography).
- Build your first set of core components (buttons, inputs, cards).
- Document usage guidelines as you go.
Phase 3: Pilot with a key product area
- Choose a single product or flow to apply the system to.
- Partner closely with engineers to implement it.
- Use real feedback to improve your components and process.
Phase 4: Scale and refine
- Start migrating other products or features over.
- Introduce documentation hubs and usage standards.
- Consider tools like Storybook and token management systems to help bridge design and code.
It's okay to have an evolving system. Start small. Learn fast. Scale intentionally.
Measuring your design system's success
Once you dive into building a custom design system, you'll want ways to track if it's actually making an impact. After all, your team invested real time and energy into this thing – so how do you know if it's working?
What to measure and why
Your metrics should connect back to why you built the system in the first place. Think about tracking:
Business impact
Time saved (because who doesn't want more of that?), brand consistency improvements (fewer "that doesn't look like us" moments), and ultimately, return on investment. Also consider scalability, can other teams in your organization (like marketing) now use this too? Who will benefit and be able to work faster, without sacrificing brand consistency?
Product quality
Are teams actually using your components? Are there fewer UI inconsistencies? Has accessibility improved? These are wins worth tracking.
Team efficiency
Is the design-to-development handoff smoother? Are you spending less time in meetings just to align on design decisions? Can you prototype faster now? Can the marketing team mock up landing pages faster? Is the same size team able to get more done with less mistakes?
Setting up your tracking system
Start small – really.
Begin with just a few metrics that directly connect to your team's goals. You're not building a data science project; you're just proving your design system is pulling its weight.
A simple way to begin:
- Know your starting point — Before rolling out your system, jot down how long key workflows take now
- Pick 3-5 metrics that matter — Choose ones your boss or stakeholders actually care about
- Check in regularly — Monthly check-ins help keep everyone honest about progress
Remember: Nobody wants metrics for metrics' sake. Choose things you can actually act on, and that help show the value to people who need to keep supporting your work.
Component Tracking Matrix
One tool we've found super helpful is creating a Component Tracking Matrix – basically a visual dashboard showing how all your components are progressing. It's like a status board that both detail-oriented designers and big-picture stakeholders can get something from.
Your matrix might show:
- Where each component stands in its journey from idea to fully implemented
- If design and code versions match up (they should!)
- Whether documentation exists (and is actually helpful)
- Which platforms each component supports
- Who's approved what
This gives everyone that satisfying visual sense of progress while still providing the details for anyone who needs to dig deeper.
From decision to design reality
Designers often feel the pull to build — and sometimes, it's absolutely the right call.
Just make sure:
- You're solving a real problem, not just chasing perfection.
- Your team and partners understand the commitment.
- You build with purpose, not just polish.
Have questions about this process?
If you're unsure whether your org is ready to build from scratch, we'd be happy to help you evaluate the decision. Sometimes the best system is the one you don't have to build alone.
Feel free to reach out to chat with our team.
