Building Sustainable Design Systems
Over the years, I’ve built design systems in completely different contexts – from organically growing one at a legacy SaaS company, to adapting existing systems for startups, creating educational tools for students, and managing external vendors. Each experience taught me something different about what actually makes design systems succeed or fail.
This is the story of that journey, and the practical lessons I’ve learned about the real challenges and opportunities in design system work.
Learning to start with problems
My first design system work wasn’t planned at all. I had joined a SaaS company and inherited 17 years of product development where talented developers, sales teams, and senior leadership had built a solid business without any design input. The product worked well for users and had found strong market fit.
But as I began working on improvements, I noticed something interesting. A developer asked me which shade of yellow to use for a particular element – a perfectly reasonable question. When we investigated further, we discovered the product was using over 130 different colours. These weren’t carefully considered brand variations, but dozens of slightly different shades that looked almost identical but were coded as separate values.
Working together, we decided to tackle this systematically. The developer exported a complete list of colours from the codebase, and I worked in Figma to consolidate similar shades, align them with brand standards, and define clear usage rules – particularly for success and error states, ensuring they met accessibility standards.
This small change had immediate benefits. For developers, it made code cleaner and future updates much simpler – instead of replacing dozens of similar shades, they could update just one. For me, it eliminated constant colour decisions and made designs more consistent. Most importantly, users didn’t notice the change at all, which taught me that the real value of design systems lies in team efficiency and code quality, not user-facing improvements.
Next came icons, which presented a different challenge. We had inconsistent icons throughout the product – five or six different libraries, various stroke weights and styles, and sometimes completely illogical choices (error messages that used clock icons instead of warning triangles).
Unlike colours, icons needed context to address properly. So we went section by section through the product, documenting each icon’s purpose, replacing them with consistent alternatives from one well-designed library that worked technically for our developers. We also established naming conventions – “error,” “warning,” “success” – creating a shared vocabulary between design and development.
When we finished our systematic review, the developer found a few more icons in edge-case scenarios I’d missed. This collaborative detective work became the foundation for how I approached design systems going forward: always work with your technical partners, and always audit what exists before building what you think you need.
Key lesson: The best design systems start with genuine friction points, not aspirational completeness. Look for the repeated questions and decisions that slow your team down.
Building systems within larger changes
Design system continued to grow after changes to colours and icons. All the work evolved naturally as we faced a technical transition. The product was being rebuilt from an old tech stack to a new one, feature by feature. This presented a perfect opportunity to systematise our approach without asking for dedicated resources.
As each section was rebuilt, I created Figma components for common elements – buttons, tabs, checkboxes, form inputs. This wasn’t official design system work; it was simply making the necessary rebuild more efficient and consistent. The new sections looked cohesive, development was faster, and old sections would eventually be updated as they were rebuilt.
I prioritised components based on frequency and impact. Tables were everywhere in our data-heavy product, so I invested time in creating robust table components and guidelines. Charts appeared rarely, so I focused only on ensuring they used consistent typography and colours rather than building complex chart systems.
This experience taught me that timing matters enormously in design system work. Sometimes the best approach is embedding systematic thinking within existing priorities rather than treating it as a separate initiative. It also reinforced that not everything needs to be systematised – focus on what creates the most repeated work or decisions.
Adapting existing solutions
Later, I worked with an early-stage financial sector startup as a freelancer. They were preparing to launch their MVP and had already implemented a comprehensive free design system. While robust, it had significant problems: the aesthetic was boxy and outdated, components took up excessive screen space, and there were accessibility issues with the visual design.
Rather than starting from scratch – which would have consumed months of time and budget they couldn’t spare – we adapted what they had. I focused on making elements more visually refined and space-efficient, building better form feedback systems, and replacing text with more universal icons where appropriate.
The existing system, however imperfect, had given them the foundation to move quickly when speed mattered most. We could then evolve it as we better understood their product needs and brand requirements.
Key lesson: Starting with something that’s 80% suitable and adapting it is almost always more effective than building from zero. Your energy is better spent on the 20% that makes it uniquely yours and solves your specific problems.
Understanding purpose first
Teaching an intensive 8-week UX course to career changers revealed another dimension of design system thinking. Students consistently struggled when creating interfaces, spending hours on button shapes and colour decisions while producing poor results. This time pressure highlighted that they needed to focus on user experience logic, not visual craft.
I created a design system specifically for educational use – components that looked professional enough for portfolios but, more importantly, freed students to concentrate on research, user journeys, and problem-solving. The system taught them to think in components and patterns rather than individual elements.
This wasn’t about creating the most elegant design system; it was about solving a specific problem: helping students learn experience design principles within severe time constraints.
Key lesson: Different contexts require different approaches. Always start by understanding what problem your design system needs to solve, and for whom.
Pitfalls of outsourcing
In a later role, I managed the creation of a design system through an external vendor. The organisation chose outsourcing because the internal design team was overwhelmed with other priorities. The vendor delivered comprehensive, well-crafted work that initially made a positive impact.
However, the fundamental challenge wasn’t the quality of what was built – it was what happened afterward. To the vendor, this was simply another project for another client. To our team, it was a tool that would affect our daily work. After delivery, the organisation treated it as complete rather than ongoing.
Without budget for iterations or processes for updates, I watched the system slowly decline over two years. Designers began detaching components as the system no longer served evolving needs. Developers built more custom solutions. The gap between system and reality grew until usage nearly disappeared.
This wasn’t a dramatic failure but a gradual withering – like a plant nobody remembers to water.
Red Flags: Spotting Systems in Decline
Based on my experience, here are warning signs that a design system is failing:
- Increasing numbers of detached or heavily modified components in design files
- Developers building more custom solutions instead of using system components
- “Just this once” exceptions becoming routine
- Leadership stops referencing or asking about the system
- Growing gap between system documentation and actual implementation
Key lesson: Design systems are products, not projects. They need ongoing care, iteration, and evolution. The creation phase is actually the easy part; building organisational understanding of why systems need sustained investment is the real challenge.
The essential principles
Looking across my past experiences, several core principles emerge:
Start with problems, not solutions
The most successful design system work I've done started with genuine friction points - repeated questions, inconsistent decisions, or time-consuming manual work. These pain points give you clear success criteria and natural adoption drivers.
Collaborate from day 1
Design systems succeed when they make everyone's work easier. Involve developers, stakeholders, and users in identifying problems and validating solutions. The best systems emerge from partnership, not prescription.
Focus on frequency and impact
Not everything needs systematising. Prioritise what creates the most repeated work, generates the most questions, or would save the most time if standardised. A few well-designed, frequently-used components beat comprehensive coverage that nobody needs.
Don't reinvent the wheel
Building from scratch is rarely necessary. Look for existing solutions that get you 80% of the way there, then invest your energy in the 20% that makes it serve your specific context and problems.
Design for your context
Different situations require different approaches. A startup preparing for launch has different needs than an educational environment or an enterprise rebuilding legacy systems. Always understand your specific constraints, goals, and success criteria.
Plan for evolution
Design systems must be able to evolve with changing needs. This doesn't require formal processes or dedicated teams, but there must be some mechanism for iteration and improvement. Systems that can't adapt will gradually become irrelevant.
Measure team efficiency, not user delight
The primary value of design systems is usually internal: faster development, fewer design decisions, cleaner code, and more consistent experiences. These benefits enable better user outcomes but are rarely directly visible to users.
Final thoughts
The best design system is one that gets used, addresses real problems your team faces, and can evolve with changing needs. Success isn’t measured by comprehensiveness or aesthetic perfection, but by sustained adoption and the problems it continues to solve.
Don’t build a design system because you think you should have one. Build it because you have specific friction points that systematic thinking will address, and ensure you have mechanisms for ongoing iteration as new challenges emerge.
Building the components is the straightforward part. The real work is change management: helping teams understand why systematic approaches matter, securing support for ongoing evolution, and creating processes that enable adaptation without bureaucracy.
That’s how you create something that lasts and truly serves your team’s needs.