Building your design system and your design culture
How being open and inclusive will improve your design system and your design culture
Over the past few years, I’ve had the opportunity to help build design systems and felt it was time to share some of things that I’ve learned. I plan to do this in a few parts. My hope is that this helps me organize my own thoughts and in doing so I’m able to help others along the way.
Building a design system from the ground up can be a very exciting challenge! At this point the benefits of design systems are well documented. Not only can they dramatically improve an organization’s ability to deliver products faster, more consistently, and more efficiently, they also free up designers and product teams to focus on more important work — like improving products and solving user problems.
At this point, the question isn’t, “Should we build a design system?”. Instead it’s, “How do we build our design system?”. In other words, how do we establish how our organization builds digital products and experiences.
This is a much bigger, trickier question. The answer likely depends on the size of the organization, how it’s structured, and how many products and platforms the design system needs to support.
For the purposes of what I’d like to share here, I’ll focus on building design systems for organizations that have multiple squads working on various products. More specifically, I’ll share how building an open and inclusionary culture around your design system can expand capacity, accelerate output, elevate quality, and build buy-in.
Planning and Strategy
In the beginning, there’s so much to do it can be hard to know where to start. As with any big undertaking, creating a plan is a good first step. To get started you’ll want to answer some fundamental questions and determine a strategy for scaling and evolving the design system over time.
You’ll want to consider:
- Conducting a UI audit
- Deciding what platforms to support
- Determining team structure and a contribution model
- Planning how tiering might work
- Establish governance around the system
- And mapping out workflows
Of course, some of this will come with time but planning as much as possible up front will pay off later. A good plan can help mitigate design debt and tech debt by preventing teams from going rogue.
Tip: As part of your plan, you might want to consider publishing a high-level roadmap so squads can plan when and how they’ll adopt the system and how they might be able to contribute.
Getting Started
Once you have a plan in place, it’s time to get to work. To get going you’ll have to decide how the work will get done and who will do it. Fortunately, it’s become more common for larger organizations to have a fully dedicated Design System Team. This is great news! Fully dedicated teams can help to operationalize design by standardizing workflows and continuously building and improving the design system.
Treating the system like a product is a smart, user-centered approach, but if a design system is a product, it’s a really big one. Even with a fully dedicated squad, I think it’s fair to say that each platform could be considered a product, at least in the beginning.
Let’s look at some of the platforms that might be supported.
- Documentation Website
- Front-end Style Guide
- Sketch Libraries
- React Style Guide
- iOS
- Android
- etc…
Building up the assets for each of these platforms is a pretty big undertaking especially if these are meant to be built concurrently or published in the same timeframe.
Take building a React style guide for example. To build this, we’ll need Designers designing components and the UI of the style guide, a team of Developers building, testing, and releasing components and along the way we’ll need to write documentation. In addition to this, a backlog will need to be managed and beyond the first release issues will need to be tracked and managed.
Now multiply this by the number of platforms the design system will support and consider all of the work and management that needs to be done. It’s a lot, especially if the dedicated team is your average size squad.
There’s a better way!
The design system can be used as a hub for building an inclusionary culture where everyone is encouraged to contribute and be involved. Remember that many of the people using a design system are creators themselves. If users are brought into the process to co-create, their needs, concerns and desires are being built into the product from the ground up (user-centered).
Since a design system is meant to empower teams to solve a very broad and varied set of problems, bringing people together is also an important part of ensuring the system is effective for all who rely on it. Encouraging and empowering people to be involved can be a powerful concept for building an inclusive culture too.
Need a POC? Try this design system workshop
Invite a cross-product group of Designers to a workshop where they can share their latest work. The goal of this exercise is to improve the design system, it’s not intended to be a critique but… good luck avoiding this in a room full of Designers 😉. Hang everything up on the wall and give each participant an opportunity to quickly share their work. Five minutes should suffice. After everyone has shared, have the group do a museum walk taking note of inconsistencies, opportunities to converge, components not officially in the system yet, etc.This is an opportunity to identify “What good looks like”, to spot do’s and don‘ts, and to uncover shared problems that could potentially lead to the formation of Chapters. This is also a great venue for collecting feedback and to celebrate the great work that’s being done.
Having participated in a few of these myself, I’ve found that people were really excited to be involved. It gives Individual Contributors an opportunity to share their work and their point of view. More importantly though, it’s an opportunity to be user-centered, inclusionary, and to make people feel like they’re part of the solution.
Governing the Design System
You might be thinking, “Okay great, sounds good but how can everyone be involved?”. Here’s one model I’ve found to be really effective. It includes a centralized Design System Team, a Design System Guild, Chapters, and Individual Contributors. Each of these groups plays an important role in designing, building, and managing the design system.
Roles and Responsibilities
Design System Team
The core Design System Team helps operationalize an organization’s design workflow. They’re charged with amplifying designs impact by arming product teams with the assets they need to improve products and solve user problems. They determine how the design system is structured, designed, managed, distributed, evolved and maintained. This team relies on the support of the Design System Guild and Individual Contributors to constantly evolve and improve the system.
Some of the core team’s responsibilities:
- Structuring the design system
- Designing each of the platforms
- Delegating work and overseeing each platform
- Ensuring quality and consistency
- Managing release schedules
- Ensuring each platform is solving user needs
Design System Guild
A Design System Guild is comprised of experts from around the organization. Guild members serve as representatives of various platforms and problem spaces. They help build, govern and manage the design system.
This team is comprised of a combination of Product Designers, Front-end Developers, Illustrators, Visual Designers, Accessibility Experts, Subject Matter Experts, and more. Since Guild Members are spread throughout the organization, they represent a diverse set of concerns and perspectives. As such, they can ensure that the design system is working to solve a broad range problems.
What the Design System Guild does:
- Helps create contribution guidelines for each platform
- Manages contributions ensuring quality, consistency and standards
- Identifies opportunities for forming Chapters
- Facilitates workshops and collaborative working sessions to identify “what good looks like”, identify inconsistencies, surface do’s and don’ts, etc
- Advocates for changes to the system when necessary
- Helps determine and manage design system tiers
Individual Contributors
Individual Contributors are your forward deployed teammates who are in the weeds everyday. These are the subject matter experts of their respective problem spaces and can offer invaluable insights about the efficacy of the design system. Individual Contributors should be encouraged and empowered to offer feedback and contributions to the design system.
They can do this in multiple ways:
- Offer feedback and propose changes
- Report bugs and issues
- Submit contributions to the Design System Guild
- Be part of a Design System Chapter
- Contribute expertise on a particular topic
Chapters
Chapters are a team of Individual Contributors formed to solve shared problems. They‘re like a special forces team comprised of experts in a particular area. Their job in the Chapter is to fulfill a certain mission and return back to their respective squads when the job is done. This isn’t a full time gig though, at least in my experience.
Typically when a Chapter is formed, the team will create a charter and agree to dedicate a certain amount time to accomplish the goals of the Chapter.
It’s important to note that this should not be considered an extracurricular activity. The work done in a Chapter is valuable and will impact each contributor’s team as well as the broader organization. To that end, each contributor will need to dedicate a certain percentage of their time to contribute.
Formation of Chapters
Everyone benefits from this approach
The Design System Team is able to output design system assets and improvements much faster.
The Design System Guild ensures the system is solving a broad range of problems while enforcing quality and consistency.
Chapters can substantially improve efficiency by helping prevent teams from working on the same problems.
Individual Contributors can contribute feedback and contributions to make sure the design system is working for their specific needs.
A design system can be the heart of your design culture when everyone is involved.
How your organization makes digital products is more than the assets that are published. It’s the processes and people involved that determine how successful your design system will be over time.
