Breaking the chains of chaos through the power of design system governance
Unlocking innovation, consistency, and user delight through strategic design system governance and collective creativity"
Here's what you'll learn:
Design system governance is crucial
The types of governance models
Measurement and data collection are essential
and much more…
Let’s dive in…
So, you have sold the idea of a design system to the different stakeholders, built some components, and guidelines, and created the other necessary artifacts.
Congrats.
But what about contribution?
What about your design system governance?
😱
Yes, I know. The funny thing is that your design system will never be done. It is a continuous improvement cycle. Designers will need changes and ask for new components and patterns.
Governance model
Many will consider the term governance as a roadblock to rapid growth, creativity, and flexibility. However, design system governance can foster scalability and creativity if properly implemented while maintaining design and usability consistency. Good design system governance prioritizes users before growth and profits.
Remember: A design system is built by designers, for designers.
Once your design system is in motion and starts to generate some attention, phew things can start to happen. Some designers and developers may start to contribute or add to it without seeking approval or seeing if that “part” is actually needed.
And without any doubt, others will express their opinions on components. Designers all have an opinion 🤓.
The how and the what of your design system are important pieces in this phase. The absence of your governance model can swiftly diminish people's trust in the design system.
No matter where you are in your design system’s maturity, make sure you have some governance model. But which one to choose and why?
Regardless of who ultimately owns the decision-making authority, each user should be allowed to (and encouraged to) propose enhancements to the design system. Whether in code or comments, this should also allow feedback about the governance model itself. It should be an evolving set of processes that changes over time as the needs of the business and the teams change.
What the heck is that?
Design system governance is the process and protocols for maintaining and updating a product’s design system.
Maintain’s design and brand consistency
Prevents poor design decisions—leading to usability issues
Encourages team members to think creatively and try to solve problems with the tools on hand before attempting to make changes
Ensures updates consider accessibility
Keeps the entire organization informed of changes
Updates digital product and design documentation
Potential difficulties
I’m not going to lie and say it’s a clear road ahead with unicorns and rainbows. Having a governance modal can have some difficulties:
Company Political Forces
Managing Input From Multiple Teams and Departments
Design Systems are Often an Afterthought or Side Project
Poor Communication
Reluctance from Team Members
Reluctance to Change
The Single Source of Truth Dilemma
But just like building your home, if you have a solid foundation, everything else will be built correctly.
Types of governance model
Federated: A team is formed consisting of representatives from your product portfolio who collaborate to contribute to and maintain a design system. Any changes made are distributed to all product teams. To guide this process, a Design System Manager can take the lead, facilitate discussions, and ensure accountability.
Centralized: In a centralized model, a dedicated "core" team is responsible for creating and maintaining design system components. Subsequently, they distribute these components to all the product teams.
Hybrid: A hybrid approach combines elements of both the federated and centralized models. In this approach, a federated committee offers guidance and feedback, while a centralized team takes charge of creating UI libraries, coded components, and updating documentation. Subsequently, these changes are shared with all the product teams.
Although we desire straightforward solutions, the choice depends on various factors such as the size of your organization, product portfolio, stakeholder expectations, and available resources. Selecting a model requires considering your long-term goals while being content with the model you can currently implement.
My two cents
What has worked for you in the past?
Well, I’m glad you asked.
My approach is to use Governance by design… a mix and match I could say. If we want our design system to be used by designers, we must include designers in the process. And please don’t forget our developer friends… they have great ideas to add to the mix.
When designers of your system encounter an edge case that is not addressed by the existing design system components, the governance by design model enables them to take the following actions and receive guidance:
provide feedback to the design system team;
determine how to handle the edge case using a decision tree;
automatically communicate the problem and its resolution to other consuming teams, facilitating the sharing of insights.
The number one goal is to avoid one-off solutions where individual teams or users might deal with edge cases in their own way, without reporting how they solved it to other teams.
Design system adoption guild
Creating design guilds is what has worked for me the most through my design system experiences. These guild members become your biggest allies.
A design guild is a group of people who come from different Products or verticals but have common interests. In other words, any member of the organization can be a part of the Guild. These experts can help each other and exchange some information with each other by meeting in Guilds.
Guilds raise awareness for Design system needs and create advocates throughout their organizations. Promote the exchange of technical Ideas & best practices within your company.
Equip everyone with an elevated design-aware mindset and become a better craftsman. This can be done by discussing new technologies, sharing experiences, and inviting people from outside.
DST = Design System Team
DSG = Design System Guild
IC = Individual Contributors
The goal of these guilds is to create collaborative sessions aimed to build relationships, drive systems thinking, and improve overall system quality.
Members of this group spend 10 to 15% of their time a week reviewing component work for other designers.
Design system team
The core Design System Team helps operationalize an organization’s design workflow
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.
Helps create contribution guidelines for each platform
Manages contributions ensuring quality, consistency, and standards
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
Individual contributors
Individual Contributors are your forward-deployed teammates who are in the weeds every day.
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 & Sub-groups
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.
Designers no longer just design the component itself, they design policies that govern a system of components
Developer contributions
The goal of a design system is to be more efficient and increase speed to market. Ensuring the delivery velocity remains high is vital as your design system garners greater adoption among product teams. The owners of the design system can enhance development speed by capitalizing on contributions from product teams, given the presence of a well-established and user-friendly process.
If another team got to a component first, why now allow them to contribute the design & code back to your system? Everyone wins.
To ease developer contributions to the design system, it’s helpful to set up a review and approval process for your design system repository.
When combined, these processes form the basis of a compliance-by-design approach. This basically means that consumers of your design system naturally adhere to its rules while using the system, instead of relying on informal agreements or assuming they have read the documentation where the rules are explained.
They can no longer just make things up as they go.
In reality, we all know designers like to be creative and break components.
Make sure you are flexible in your approach, other teams’ feedback should be welcome and actually encouraged.
Monitor and report your progress
With individual products as well as reporting organization-wide, we need a structure to monitor and report on adoption.
Let’s face it, your leadership team will be asking for progress. Time = Money.
Your governance-by-design model has the ability to incorporate a built-in mechanism to collect data, including component usage statistics, and share it with the design system team. This approach ensures that the design system evolves in a manner that aligns with the needs and priorities of its consumers.
Flexibility and adaptability are key in today’s market.
You are all happy and proud that you’ve launched your design system but how can you determine where to focus your efforts in order to truly enhance the value of the design system for supporting teams?
Data. Feedback. User input.
These are essential for making informed decisions and demonstrating the value of these investments to stakeholders. You can capture data directly within Figma, Jira, or in code.
How do you measure?
Here are some ideas for you to measure the impact of your design system.
Subjective Measurement: This might come in the form of surveying end-users or internal teams to get a pulse on how people’s opinions might change. To gauge end-user satisfaction, one approach could involve conducting an NPS survey with the aim of obtaining higher ratings, and positive feedback, and fostering increased trust in the product.
Objective Measurement: Sometimes the impact can be measured in a very objective way. The impact of the design system can be assessed through the tracking of specific metrics. For end-users, this may involve examining factors such as page load times, accessibility, and more.
What to measure
User Impact
Creates trust and consistency
Amount of bugs and errors
Business Impact
How much money is saved by the company?
Does it reduces tech and design debt?
Team Impact
Communication and knowledge sharing. Measure this by looking at team adoption
Speed and efficiency of designers & developers (great example here)
Reduces the time needed for quality assurance
Final thoughts
Your users (designers and developers) play a great role in shaping your design system. A well-crafted design system serves as a North Star to your product development. It becomes part of an organization’s DNA that helps product teams produce more consistent user experiences and amplifies a design-driven culture.
Remember to have fun building this journey. There is no one-size-fits-all solution out there but hopefully, we have shed some light on design systems from our own personal experiences.
Mitchell & Pascal
Hey, Mitchell & Pascal here! Thanks for checking out this week’s free edition of the Shaping Design newsletter. We strive to send you the best tips and our very own unique perspective each week. Subscribe to get each article!
If you enjoy this newsletter, we’d love to know!
Awesome read!