How to build and maintain an equitable design system in Abstract

The other day I stumbled upon a GitHub repo containing the United States Constitution, complete with a history of edits. As a former CS/History double major, I can’t describe how satisfying it is to see the history of U.S. law expressed so clearly. To be able to see who amended the document, exactly when they amended it, and why they did it — it’s empowering. Imagine the possibilities if, instead of Thomas Jefferson (one of those designers), the designers of the Constitution had parallel thoughts, distributed work, and transparency!

Lately, when consulting on design systems with teams using Abstract, I think back to that Constitution repo. If you think of the U.S. Constitution as the "design system" upon which the entirety of U.S. law is based, you’ll see that teams looking to design systems for cohesion of identity, systematic and efficient means of scaling, and organized methods of presenting knowledge are actually looking for a system of design governance.

• Do I need a new component to provide this experience?
• What colors can I use to properly express our idea and our brand while still being accessible? 
• When is it acceptable to override this style? 
• Has this been done before?

While many designers love the direction and clarity design systems provide, those benefits are diminished when building that design system isn’t an equitable process. Healthy governance isn’t built in a vacuum. An effective governance model requires emotional and intellectual buy-in from the rest of the team. Using Abstract to distribute the work and maintenance of a design system reduces the workload on everyone while cultivating buy-in as each designer or developer participates.

Open up your decision-making process

Think of your team’s design system like the Constitution: It’s your manual for lawfulness as a design citizen of your team. Something so powerful should never be stagnant or neglected. But, keeping a design system up-to-date in our highly dynamic design environment can feel like a losing battle. Even adopting a design system at all is an expensive act that many design teams can’t afford.

Abstract distributes the hard work of design system management across everyone who touches the design system. The magic starts with Abstract’s Branch-based version control. Branching allows teams to consider the many parallel timelines and possible directions a project could take. 

Take, for instance, when our principal designer Tim Van Damme designed the icon for our Inspect tool in Abstract. What started off as a speculative, non-roadmap Branch titled “🏝 Inspect Icon” ended up having some options that Tim felt were shippable. To gather feedback on this icon that would be added to our design system at Abstract, he used a Collection to capture all of his ideas and turned off auto-update on the Artboards to freeze each iteration. He shared a link to the Inspect Icon Ideas Collection in Slack. Designers and developers alike weighed in, using comments and reactions as a means of voting on which icon fit best. 

Using Abstract for this process documented the history of icon explorations as well as our conversations and decision-making process within comments and Commits.

‍

Protect design system integrity with version control

Chaos isn’t an option for design systems, the foundational blocks on which all other projects are based. Because of their foundational nature, design systems often serve as the common touchpoint between many different teams, and should reflect all stakeholders’ goals and priorities. In short, the stakes are high. 

Abstract has built-in protection against the mess and lack of accountability that most other ways of working leave room for. Today, you can track every change made to your design system with our Branch-based version control. Whether you need to revisit an old exploration or pivot to a different design direction, you can always restore your design system to a previous version. Over the next quarter, we’ll be rolling out Merge restrictions as an additional tool your team can use to establish accountability and attribution to every design change made within Abstract. At their most basic, Merge restrictions mean that, before any changes to Main proposed in your Branch can be merged, a Project Admin must approve your changes.

Whether your team uses Merge restrictions or reviews Branches in design review before merging, you’ll need to work together to define the acceptance criteria for your design system. Merging Branches in your design system project provides a mechanism for regular check-ins for your team to reconnect and determine whether the current iteration of your design system satisfies your design needs.

Don’t trade in the exponential benefits collaboration offers design system improvements due to fear of unwanted changes. With Abstract’s Branch-based version control, you can have your creativity, and integrity too.

Improve your design system, bit by bit

In addition to safely distributing the workload of design systems between many people, Branches also let you spread out improvements over time.

Let’s say you’re working and you realize a button in your design system needs to be updated. Short term, you need to update the button. So, you open a Branch on your design system project to begin editing. The file takes a long time to load. And, once it finally opens, it takes you several minutes to locate the button you need to update. Your design system Main file has gotten way too big. Now, you have a long term task: breaking down your large design file into multiple smaller ones.

In the past, re-architecting design ideas from one pattern of organization to another was a very expensive and intensive task. But, Abstract’s built on Git, which is an inherently iterative process. Rather than re-architecting a massive file all at once, you can pull buttons into their own new Buttons.xd or Buttons.sketch file and re-organize the rest later. 

When you request a review before merging your Branch with the button file updates, you’re actually proposing a new pattern for organizing design system components that the rest of your team can follow on their subsequent updates. As time passes and your design system is collaboratively re-architected according to the pattern you proposed, you’ll end up with a project structure that mirrors healthy coding practices: lightweight files (e.g. buttons, colors, forms, typography, etc.) that scale effectively and surface concise descriptions of a file’s dependencies.

Abstract not only helps you keep your design system files tidy, it also allows you to take small steps toward improving how your team works together.

Maintain flexible and integrated documentation

As long as your product exists, your design system isn't done. Design systems grow and evolve right alongside your product and your team. A healthy design system includes living, breathing documentation that’s more like an ongoing conversation than a decree from on high. 

Abstract is open-ended in where and how you share documentation. For some teams, it makes the most sense to document the usage and variants of components directly in the design file. If you're working with granular files in Sketch, a useful practice is to designate different Pages for usage, instructions, examples, explorations, and for the actual components. This approach leverages how Abstract surfaces pages to allow for quick visual browsing without opening the actual file. When documentation lives right inside the design file, the rationale behind the components becomes equally important to the design of the components themselves. Thus, approving a Merge in a design systems project becomes more than accepting visual changes. You’re forging  an agreement on the usage of what has been designed, its proposed implementation, and the ideas behind them. 

Other teams use Collections to store documentation. It’s easy to get Collections in front of lots of stakeholders — especially non-designers — to gather their feedback. With just one share link, Collections provide access to Artboards (and their version history), decision-making made in comments & annotations, and all the code specs engineers need to deliver designs. Designers can use Collections to present their work and to fully document the intent of their designs. At their core, Collections are a vehicle to share your specific designs (the Artboards) and the thought process behind them (the Collection descriptions, plus comments & annotations). 

Collaborate with care, not control

Once you streamline the process of safely collaborating on design systems, your team’s energy is free to consider how you might design together, rather than despite one another. Abstract’s hope is that teams can use our technology to build design systems that feel less like control and more like care. With our Git-based platform, there’s no need to limit the number of voices in order to prevent chaos. Abstract’s Branch-based version control makes space for everyone to be heard. Design decisions can belong to all of us.

‍