A design system keeps UX designers, product teams, and engineers on the same page. They can build interfaces faster while maintaining a high degree of consistency.
As the product evolves, designers must follow design system governance procedures to maintain integrity and consistency. The goal is to reach a stage where designers and engineers can launch a product with little or no coding because the design system offers the building blocks to scale.
Achieving that goal means organizations must follow a design system maturity model that promotes the flexibility to grow!
📚 This is an abridged version of the article about design system maturity. Read the full article on UXPin’s blog: https://www.uxpin.com/studio/blog/design-system-maturity-how-to-improve-your-design-system/
4 Stages of Design System Maturity
Organizations worldwide have used several design system maturity models, but we’ve found the one from Iress is easy to digest, replicate, and scale.
Design System Product Owner and Regional Head of Product Design at Iress, Nick Elliot, got the inspiration for this model from TJ Harrop, Design System Product Manager at the NSW Government. It’s a four-stage process that outlines the steps it takes to achieve design system maturity.
- Stage one — Style guides
- Stage two — HTML & CSS
- Stage three — Design & coded components
- Stage four — Fully integrated
It’s important to note that it took Iress eight years to get from stage one to four. Which goes back to the point we made at the beginning of this article–“developing a design system is a marathon, not a sprint!”
Stage One — Style Guides
If you’re at stage one, your organization doesn’t have a design system but might have a few common assets defined. Most startups will find themselves here, but many established organizations live in stage one too!
During this early stage of design system maturity, teams design product assets and develop brand consistency. The assets live in PDF style guides that designers use to create assets.
While these style guides provide some consistency, designers often have their own version of the design system saved in their design tool. Design handoffs are often chaotic because there’s drift and inconsistency due to multiple interpretations of the design system.
Another problem with stage one is that PDF style guides aren’t scalable–at least not with any accuracy or consistency. If you release a new version of your style guide, designers must note the changes and update their assets manually. Creating more work and increasing time to market!
If your organization is suffering from these design issues, it’s time to implement a strategy to develop a scalable design system.
Stage Two — HTML & CSS
At stage two, your design system components are defined in snippets of HTML and CSS. While this is an improvement, the design system is still a guideline rather than building blocks designers and engineers can grab to build an interface. It’s open for interpretation which means design drift and errors still occur regularly.
HTML and CSS snippets also need regular updates, which means DesignOps and DevOps need to communicate constantly to sync design systems manually.
Stage Three — Design & Coded Components
Many companies linger in stage three indefinitely. The organization has a design system and follows governance procedures before updating pattern libraries and components.
The design system is fully documented, which streamlines onboarding and reduces errors.