Design system governance: bugs, design discrepancies, features, and recipes
When design system users run into issues designing and developing with the system, they often have a hard time distinguishing between a bug, a missing feature, an intentional design deviation, a new pattern they need to create, or something else. Often, all they know is the design system isn’t working for them. They need help!
Turns out there’s one weird trick for helping those people and mastering design system governance: TALK!
When in doubt, have a conversation.
Master design system governance with this one weird trick
Design system teams need to be proactive and obnoxiously clear about how to connect with them. Product teams don’t need to understand the details, lingo, and nuances of a thorough design system governance processes; all they need to know is get in touch with their friendly neighborhood design system team.
Once connected, the design system team can lean in to better understand what the team is wrestling with. This right here, my friends, is a freaking art form and has everything to do with vibes. No one wants to brace for a thorough scolding by the Pattern Police; people want to be heard, understood, and helped. This is why kindness, empathy, and curiosity are such important qualities of design system teams.
It’s through this conversation that everyone can collaborate and unpack the nature of the issue.
Difference between a bug, visual discrepancy, gap, and pattern
Often design system issues arrive with a label of “bug”, simply because that’s the only button people — especially developers who are often the unfortunate downstream recipients of design work — know to push. But the issues rarely are actual bugs; that’s why we’ve found it helpful to distinguish between the the types of “issues” people encounter when working with the design system. Let’s break ’em down!
- Bugs are defects in existing design system components (e.g. the accordion doesn’t open when the user selects it, the primary button foreground and background colors don’t have sufficient color contrast).
- Visual discrepancies are designs that don’t match the available coded UI components. Visual discrepancies can be a design system visual bug (the DS library and code library are out of sync) or it could be a product designer doing their own thing (detaching DS components or creating their own custom UIs)
- A design system feature is a new component or variant that isn’t currently in the design system but maybe ought to be.
- A pattern — or recipe — is a composition of design system components that is owned and assembled by the product team
An more nuanced governance process
We’ve dug into these details with a number of clients, and I’ve updated our design system governance diagram to detail how to handle these different scenarios.
One the teams are chatting, they can unpack the scenario and figure out what — if anything — needs to be done. One of best outcomes is that no new work needs to happen and the DS team can guide the product team to existing solutions and save hours, days, or weeks of unnecessary work. Hooray!
But if the teams agree that new work needs to happen, the next question to ask is “What’s the nature of the new work to be done?”
Handling bugs
If the issue is truly a bug, the design system team should address it with extreme urgency and release a patch as soon as possible. Addressing true defects in the live system should be the highest priority for the design system team; teams won’t trust or use a busted system.
Handling visual discrepancies
In the case of a visual discrepancy, the first question to ask is: “is this an issue with the design system?” If it’s a misalignment between the design system’s design and code libraries, it should be treated as a bug and addressed immediately.
But often it’s a product-level discrepancy where a product designer has either deviated from the system or invented new design patterns. In those situations, it’s important to ask: are these changes deliberate and intentional?
Perhaps a product designer created some purple buttons simply because they like the color purple. Through conversation the teams can determine that deviation isn’t justifiable, so the course of action should be for them to update the design to better align with the design system.
But! Perhaps the purple buttons were created to run and A/B test or to support a specific campaign. In that situation, the teams may agree that’s deliberate and justifiable, so the product team can carry on implementing that custom UI solution. The design system team should make a note to follow-up with the team to hear how things turned out.
Handling features
Often product teams have needs that aren’t handled by the current design system library. For these situations, the first question becomes: Does the feature belong in the design system?
Many times, product teams need to create and own their own recipes — compositions of core design system components and/or custom UI elements. Those recipes should be used consistently within a product, but may not be universal enough to include in the core design system team. The design system team can help guide the product teams to create and own their own recipes that work with the grain of the design system.
In other situations, a new feature should indeed belong in the core design system. In these cases, the question becomes: can that work happen to meet the product team’s timeline without sacrificing the high standards of the design system? If the answer is yes, then great! The work can be built into the system. However if there’s not enough time, the product team should own that work in order to meet their deadline, and the DS team should add it to their backlog to address it when they can.
Design systems die in the darkness
We’ve trained the design system teams we work with to be extremely skeptical when they don’t hear from consuming teams. When you don’t hear from them, it’s typically not a sign of “everything is going great” and is more likely “something is going very wrong.” So be proactive and reach out. When in doubt, have a conversation.
Design system governance involves coming together and collaborating on the best way to handle fuzzy situations. It’s critical for teams to collaborate, communicate, and dig into the nuance of a situation to determine the best course of action. Hopefully this framing can help your team be effective.
We help organizations of all shapes and sizes establish and evolve their entire design system practice: from assets and architecture to people, process, and culture. If you could use help taking your design system to the next level, feel free to reach out!