Design System 101: What no one tells you

This article is not about “what a design system is” or “how to create one” — there are already countless resources, experts, and books available on those topics. Instead, I’ll focus on the unique challenges faced by small teams and first-time design system builders, along with practical lessons learned along the way.

During my time at Renegade Insurance, I had the opportunity to develop a design system from scratch—a challenging yet rewarding experience that taught me lessons I wish I had known beforehand. In hindsight, there are several “not-so-obvious” insights that could have helped us move faster and more efficiently through the complexities of this process.

Modified from HiTu Illustration Components

1. Research — It’s All About the “Why”

Before diving into the process, take a step back and analyze why your team needs a design system. For us, it started with a couple of designers in the product design team pitching the idea to our design manager. After gaining hesitant approval to begin research, we carefully examined the problem space.

Understanding and articulating the “why” is critical because it keeps you grounded when management or other teams question the need for a design system — especially when it becomes time-consuming or expensive.

Here were our key reasons for building a custom design system:

Fragmentation across pods: Multiple sticker sheets, style guides, and frameworks (Material Design, OS design guidelines) led to inconsistencies, impacting the product’s aesthetic.
Highly customized components: The existing frameworks are not tailored for fintech (and specifically insurtech) space. It lacks comprehensive components and adaptable design systems that fit product needs.
B2B and B2C Integration: Our products serve both businesses and consumers, who often interact with each other. This required a unified design language to ensure seamless visual communication across features like campaign and proposal tools.
Rebranding efforts: The company’s transition from Sage Innovation to Renegade Insurance in 2021 made it essential to establish a consistent and scalable design identity.

2. Involve Engineering Early

One of the most crucial lessons we learned was the importance of involving the engineering team from the start. Somewhere between research and onset of creating elements, we aligned with product, management, and engineering teams to ensure everyone understood the need for the design system and its long-term value.

Without collaboration, the design system would have remained a Figma exercise

rather than a scalable, functional system.

In our case, as part of the company’s rebranding efforts, we also collaborated with the branding and marketing teams to create a unified foundation. This cross-functional collaboration ensured smoother implementation and adoption across the organization.

3. Understand the Investment

Building a design system is resource-intensive— it’s an ongoing commitment that requires dedicated time, effort, and buy-in from multiple stakeholders. At first, we thought we could balance it alongside our regular design work, but we soon realized it needed focused attention. The biggest challenge? Making sure it’s continuously maintained — something that’s easy to overlook.

The reality is that a design system isn’t

just about making things look cohesive —

it’s about long-term efficiency, and that requires ongoing investment.

As products change, new patterns emerge, and old ones become obsolete. We found ourselves revisiting decisions, tweaking components, and updating documentation more often than expected.

4. Design Principles Over Components

One of our biggest takeaways was to focus on design principles rather than just components. This approach ensures scalability and consistency.

For example, when introducing a new card component, decisions were driven by principles like accessibility and intuitiveness rather than fleeting trends like glassmorphism. This principle-first approach made the system more robust and adaptable.

5. Prepare to Iterate (and Discard)

One of the toughest lessons we learned was that our first few versions wouldn’t survive. We spent weeks refining early drafts, only to realize that we had either missed something crucial or overcomplicated things. It was frustrating at times, but also necessary.

A design system isn’t built in a single attempt—it’s a constantly evolving process.

Along the way, our frontend engineers played a vital role, offering feedback that helped us make the system more practical and implementation-friendly. Their insights shaped everything from component structures to naming conventions. Speaking of which, establishing clear, semantic naming for tokens took much longer than expected. We eventually found that brainstorming sessions with both design and development teams helped align everyone on a shared vocabulary.

6. Keep Documentation Simple

Documentation was another area where we learned through trial and error. Taking inspiration from Material Design and Lightning Design System, we initially wrote detailed documentation for every component. However, we quickly realized that overly detailed notes were difficult for teams to absorb.

We shifted to using visual aids and examples to illustrate how and what components should be used.

It’s essential to document not just the components but also their purpose and usage. This makes onboarding new team members faster and significantly improved adoption rates across teams.

What I’d Do Differently

If I were to build another design system from scratch, here’s what I’d do:

Engage with peers who've built design systems

Connecting with designers outside your organization who have built and shipped similar design systems can provide invaluable insights. Learning from their experiences—and mistakes—can save you a tremendous amount of time and effort. These conversations often uncover practical insights that aren’t found in standard guides or case studies.

Set realistic expectations

Attempting to build a system as extensive as Material or Lightning from the start isn’t feasible. A successful design system requires time, resources, and organizational buy-in. Instead of aiming for perfection from the start, focus on building a practical, usable system that can scale alongside your product’s growth. We structured our rollout in phases: Phase 1: Design principles, foundational elements

Phase 2: Atoms, molecules

Phase 3: Organisms, templates

Phase 4: Pages Other evolving patterns, such as features and product-specific components, were intentionally left for later stages. We decided to introduce them once the product reached 5,000 active agents, ensuring that the system adapted to real-world usage rather than premature assumptions.

Adapt to limitations

Every team has constraints—whether it's time, resources, or capacity—and it's crucial to work within them rather than against them. In our case, we were a remote team of three designers managing the design system alongside our regular work. To stay productive, we blocked 1.5 to 2 hours each day to collaborate over a video call (or in a meeting room if you're working in-person). This dedicated time helped us brainstorm, align, and iterate much faster than working in isolation. To make it work, we ensured the rest of the team and product pods were aware of this schedule, giving us the flexibility to avoid interruptions or opt out of other non-essential meetings.

Building a design system is a complex but rewarding journey — one that requires collaboration, iteration, and a willingness to adapt. Throughout this process, I’ve learned that staying grounded and working closely with cross-functional teams is key to creating a system that not only solves immediate challenges but also scales with your organization’s future needs.

References

Books: Design Systems by Alla Kholmatova, Atomic Design by Brad Frost
Inspiration: Material Design, Human Interface guidelines, Carbon Design System, Lightning design systems, Atlassian design system, Intuit Quickbooks
Articles: NN Group’s Design System 101 (which inspired the title of this blog!), Design systems in IDF website, Accessibility and principles at Pulse

Special Mention

A huge shoutout to Renegade Insurance design team folks for being the best collaborators and the engineering team for consistent feedback and quick adaptation to the new design system.

That’s a wrap on my design system journey — filled with learning, tweaking, and plenty of coffee! I hope this article helps answer some of the questions that come up when building a design system for the first time. If you’ve worked on one or are just starting out, I’d love to hear your thoughts — always happy to chat and exchange ideas!

Is this your first time building a DS?