For a long time, design pattern documentation was an after-thought, tacked on at the end of projects as a nice-to-have, or abandoned altogether because of a looming deadline. Clients and stakeholders just didn’t see the value of meticulously explaining your thought processes and the decisions behind your design work, once the work had already been completed and shipped. Onto the next project. In most cases, they were right. Without a design system underpinning a product, creating pretty documentation after-the-fact is a waste of time and resources. By the time the next iteration comes along, the product has moved on, and the documentation is no longer relevant. But design systems change everything. Design system documentation sites like the ones you can create with zeroheight are no longer just aesthetic artefacts—they’re a foundational part of how design gets communicated and delivered at a company. A style guide is no longer an afterthought, but the cornerstone of a successful design system workflow. It’s the very thing that enables a design system to progress through the three crucial stages that are necessary for it to succeed:
- Birth — convincing stakeholders and getting the design system funded
- Adoption — getting people to use and contribute to the system
- Maintenance — making sure that the system lasts
Birth
A compelling representation
One of the key milestones at the beginning of the journey is getting top-down business approval to unlock the time and budget required to build a design system. Getting approval and funding is one of the biggest challenges of creating a design system. A strategy that many teams adopt in order to get buy-in from stakeholders is to build a proof-of-concept, or “guerrilla design system”, that hints at what their team would be capable of if they were granted a proper budget. In building this guerilla system, teams typically focus on color, typography and a few core components such as buttons in order to get the proof-of-concept up and running quickly. Documentation plays a critical role at this proof-of-concept stage, by enabling early advocates to show something. That’s not to say that the accompanying powerpoint presentation isn’t equally useful or important—arguing a well-thought-out case is necessary to unlock funding for anything. But a proof-of-concept style guide provides a compelling teaser for stakeholders trying to visualize what you are promising to build.
Persuasive comparisons
Luckily, style guides are one of the facets of a design system that companies tend to release publicly—particularly design-driven companies who are at the cutting edge of design systems. This means that there are some fantastic examples of successful, polished design systems in the wild. Naturally, in the early days, your style guide will be much simpler than those, but leveraging the comparison during your pitch will provide additional context and credibility, helping you secure the budget required to get to the next stage.
Programmer and UX UI designer working in a software development and coding technologies. Mobile and website design and programing development technology.Adoption
Once a team has unlocked financing for a design system and their leadership team is on board, the next make-or-break milestone for a design system is adoption. The only thing that is more fundamental than documentation for a design system is users—a design system simply isn’t a design system if no one uses it! The adoption stage requires the design system advocates to communicate the benefits of their work to colleagues and get them involved. One of the best ways to achieve this is by creating a great style guide.
Removing friction
An important way that documentation helps with adoption is by providing an unambiguous reference for people who want to get started with the design system. It provides a single, natural place for the design system team to add setup guidelines and resources. The key here is single. Whenever there are multiple places where such rules and resources exist, it creates ambiguity, and ambiguity slows people down. Should I follow the rule about color naming that is in the Confluence doc? Or the way layers are named in XD? Questions like that create friction for design system adoption. Before they can use the system, users have to hunt down the answers. Having somewhere obvious like a style guide that people can easily look things up makes the process of getting started a lot simpler, and fosters adoption.
Providing the why and the how
Without the why and the how, design and code components are like lego blocks without instructions. In the same way that you can’t build an awesome spaceship without knowing how to attach the lego pieces together, you can’t build a product without knowing how your design system components work—what is the rationale behind a component? How does it fit into the system? How and when do I use it? When should I avoid it? Traditionally, this information—if it even exists—is scattered across design files, CSS comments, project management tools, and online docs. A style guide is an opportunity to bring it all together and create a shared understanding of components’ usage and purpose.
Getting people excited
A well-crafted documentation site is also a great way for design system evangelists to encourage teammates to contribute components. The meticulous collection of best design practices and tools in a neat, coherent package makes contributors proud, and inspires others. Despite most of the design system work happening behind the scenes, the styleguide is the sexy showreel that allows the design system to grow by getting people excited, generating momentum and spurring on collaboration.
Maintenance
Once a design system gains traction and is successfully adopted, the next stage on its journey is maintenance. This is the stage where it becomes self-sufficient and robust enough to withstand change—technology change, people change and process change. Here, documentation plays a critical role by establishing the rules of how the system should evolve.
Governance and contribution
There are many stories of companies that build a successful design system, only to see it unravel due to incoherent contributions that bloat the system and grind it to a halt. Design systems are complex beasts. In order for them to stand the test of time, they need to be looked after by experts. Embedding the contribution and governance model into your design system documentation provides a safeguarding mechanism against that. And by codifying these processes into your styleguide, you future-proof the system by allowing it to grow organically without breaking, removing any dependency on the original design system team.
Recruiting
Another way that public style guides contribute to success at the maintenance stage is by providing design system teams with a powerful recruiting tool. They’re a great opportunity for companies to show how good they are at design, and there’s no better way to hire great talent than by making it clear that you operate at the cutting edge of your industry. Not only does showcasing your design system communicate that you really care about design, it tells future hires that they will be able to focus on doing meaningful work, as the nitty gritty details will be taken care of by the system.
But what’s more important than hiring great people is keeping them. In the same way that having an industry-leading design system is exciting for potential hires, it can make existing employees more enthusiastic about their day-to-day work. This retains the best people and makes sure that the experts stick around to mentor and train others as the system grows.
Programmer and UX UI designer working in a software development and coding technologies. Mobile and website design and programing development technology.It’s worth saying again—without a functioning design system made up of people, processes, resources and tools, a style guide is just a throwaway artefact. Having a style guide doesn’t guarantee design system success by any means, as there are many other challenges involved in delivering products efficiently using a modular design approach. But when a company is looking to establish a lasting design legacy, having a sturdy, comprehensive and appealing documentation site for their design language has many benefits. It allows their design system to successfully progress through birth, adoption, maintenance, and stand the test of time.