Governance by design: Building successful design systems | Rangle.io

By: Rick Poulin, Director of Digital Innovation

Your design system is a living artifact. Like a spoken language, it will evolve over time as it is used by new groups-retaining its basic structure, but with new additions spurred by the speakers themselves.

At least, this is the ideal scenario. Your design system should be a living language, not a dead one, like Ancient Greek or Latin. Once built, it has to change and adapt to be useful to the widest possible number of teams. This is the goal, not only to ensure that teams within your organization are using the design system, but also to achieve the underlying objective of keeping your brand and experiences consistent across all end user touchpoints.

Once built, the design system team must let their baby go into the world and make its own way.

However, like good parents, the team can establish a solid foundation that ensures the stability and cohesion of the design system as it grows and changes. Governance by design means that the governance model and its rules are built into the design system itself. Like guardrails, building good governance practices at its inception ensures that the rules for use and enhancement are not just stale artifacts-they’ll be adhered to as part of the process of the system’s lifecycle.

What is a governance model?

Governance for a design system comprises the processes that control decision-making, contribution, enhancements and workflows for the design system. It’s the control center of the design system, including agreement on roles, responsibilities and process for its evolution.

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.

Far from being a restriction on the use of the design system, governance by design is about enabling adoption, in an intentional and intuitive way. Traditional governance aims to provide guidance for expected usage. Governance by design aims to expect non-standard use cases as a normal occurrence. When a user finds an edge case that the current design system components don’t cover, for example, a governance by design model will allow them to, and provide guidance to: a) give feedback to the design system team; b) decide how to address the edge case with a decision tree; c) automatically communicate the issue and its resolution to the rest of the consuming teams so that the learnings can be shared.

This is in contrast to a design system without a healthy governance process in place-one where individual teams or users might deal with edge cases in their own way, without reporting how they solved it to other teams. This may lead to repeated re-work, where each team solves parallel problems in their own way. Over time, you’ll have a mishmash of processes for dealing with situations the design system doesn’t cover, and a variety of different end user experiences to match. This also makes it difficult to release otherwise non-breaking changes to design system elements, and predict the impact on its consumers. As these cases multiply, the design system itself loses its original purpose, and becomes a hindrance rather than an accelerator.

As your design system becomes increasingly adopted by product teams, maintaining the delivery velocity is critical. Its owners can accelerate development by taking advantage of contributions from product teams, if there is an established and intuitive process. To ease developer contributions to the design system, it’s helpful to set up a review and approval process for your design system repository. For instance, the developers can submit code via pull requests (to address potential edge cases or suggested enhancements, for example) to the design system’s engineers for addition to the design system. Using a method that the developers already employ makes the process natural for these practitioners, but still allows for approvals that keep the system coherent and contained.

Taken together, processes like these become the foundations of a compliance by design practice-where the consumers of the design system are following its rules as a matter of course when using the system, rather than relying on handshake agreements that they’ve read the documentation where the rules are outlined. By adopting these principles for governing your design system, you can build organizational guardrails into your processes.

Enabling adoption

To gain traction for the design system in your organization, you will need a mechanism for contribution-for feedback about current state flexibility and product coverage, and for evaluating proposed modifications to components. Other teams’ feedback should be welcome. They can see the forest, and the team who build the design system has spent months looking at the trees. New teams can answer two critical questions that the build team cannot: Where do you get stuck? What’s not obvious?

New teams can answer two critical questions that the build team cannot: Where do you get stuck? What’s not obvious?

When it comes to design systems, the ability to measure and learn is often delayed for too long by organizations eager to define and create. A governance by design model can also include a built-in mechanism for gathering data such as component usage statistics, and relaying it to the design system team. In this way, you can ensure that the design system evolves in a way that’s appropriately prioritized for its consumers.

Consider this: After the initial build, how do you know where to put your effort to actually add value to the design system in support of the teams who use it? You need data to structure these decisions, and to prove their investment value to stakeholders. Building data collection into the design system will not only help make these decisions, but will also prove the value and ROI of the system itself. Gathering success metrics will also help evangelize the design system to teams who have not adopted it yet.

How do you operationalize success metrics?

Success metrics for a design system can be as individual as the companies who build their own proprietary design system. However, there are some general success metrics that you may consider adopting or adding to your current list:

• Increased development velocity for product teams
• Improvement in product quality (as measured by time spent in rework, results of regression testing, etc.)
• Frequency of external contributions (this measures adoption and engagement)
• Attendance of community contributors at system team planning and demos
• Satisfaction rating received from contributors and product teams leveraging the system
• Number of active users on Slack or other channels where discussion happens
• Time to launch or release, for both initial adoption and new features
• Satisfaction score (net promoter score or similar)
• Coverage of the design system component library against product features
• Changes in the amount of design time required for a feature
• Changes in the amount of time required to perform QA (specifically visual QA) for a feature
• Changes in accessibility rating

It’s important to remember that direction from the top-down won’t convince other teams in your organization to use the design system. To increase real adoption, teams need to see how the design system provides a relatively straightforward way to significantly improve their work, in both speed and quality. Knowing that they can provide feedback, and more importantly, get their feedback actioned, will help convince the skeptical of the value of your work. This means creating mechanisms for collecting feedback that are easy to use, intuitive, and automated where possible. Most of all, it means actioning that feedback once collected, so that your design system is not abandoned, stale, or unsuitable for new products and experiences.

Originally published at https://rangle.io on September 30, 2020.