By the people, for the people: Keeping your design system evergreen

This post is the third in a series about HubSpot Canvas, our new Design Language. Read the first here and the second here.

Every January, millions of people decide that this is the year their lives will be different. You’ll read more books. You’ll put more money into savings. You’ll eat fewer Cool Ranch Doritos and pints of Ben & Jerry’s. And you will gym. Every. Day.

But more often than not, as soon as February rolls around, there’s a stack of unread books on your nightstand. Your savings is routinely going to fund your Taco Tuesday habit. And there’s a fine layer of Dorito dust covering your couch. 

Why? Because good intentions aren’t enough. Unless you make a lifestyle change, even the best-intentioned resolution just won’t stick.

The same is true with design systems. When you redesign your product, the systems that caused your product’s style guide to stagnate (or led to your team creating 6 different primary buttons) is probably still around. And without a true lifestyle change, you’re likely to end up right where you started.

That’s why the most important part of your new design system isn’t your beautiful new color palette, or even the tools you put in place to make using your design system effortless — it’s the way your team interacts with the system on an ongoing basis.

We didn’t want our new design system, HubSpot Canvas, to follow in the footsteps of our old style guide, which ended up stale and ignored. We wanted it to be a growing, changing, living thing. We needed a lifestyle change. And we were only going to get there by overhauling our design process.

By the people - your system should be owned by all

Process sometimes gets a bad reputation. And it’s true — process for the sake of process can be inefficient at best and frustrating at worst. 

But the right process removes friction. It speeds up decision-making, makes roles and responsibilities crystal clear, and gets everyone on the same page. In figuring out how to govern HubSpot Canvas, our design language, we wanted to create a process that achieves all these things. We knew that if our new process was going to succeed, it would need to be lightweight and co-owned by the people who were using it every day.

There’s no question that building and maintaining a design system can be a full-time job. But we’ve found that spreading that job across a rotating group of designers works best. It stands to reason that the designers who work on our product every day, who understand our users, and who are trained in how to prioritize work and iterate on solutions make for the best shepherds of this process.

Every 6 months, a group of four designers rotate in and assume specific roles and responsibilities on the Canvas team. The benefits are twofold — not only will they directly improve the system while they’re on the team, but they’ll have a deep understanding of how to contribute to it after their rotation is over. Our goal is to have every product designer at HubSpot eventually do a tour of duty on the Canvas team.

The designers who work on our design language do so in addition to their “day jobs.” We’ve found this works well, because now that all the major pieces of Canvas have been created, the task of maintaining the design language is much less demanding. 

Still, the designers on this team must:

• Champion the HubSpot Canvas design language
• Be well versed in the existing documentation and decisions to date so they can easily answer questions and identify inconsistencies
• Continue identifying ways to improve the process and documentation
• Update the Sketch UI Kit weekly and send out an email detailing the updates to designers and front-end developers
• Triage incoming issues and facilitate discussion and decisions in our weekly review meetings
• Proactively reach out to designers across the team to help document use cases, variants, and patterns
• Work with our Frontend-as-a-Service team to answer questions and help ensure components are correctly changed or built.

How a bill becomes a law

Keeping a design system evergreen requires close collaboration between designers and developers. So in order to facilitate effective collaboration, we decided to build our process where the conversations and decisions about our design system were already happening — in Github.

This makes Github our single source of truth for Canvas. So…

• If an engineer needs to know whether a component has been approved by the design team? It’s in Github. 
• If a designer needs to know whether a component has been built yet? It’s in Github. 
• If the team needs to debate whether a component should exist at all? You guessed it — we do that in Github.

Step 1: We need a new component, or an edit to an existing component.

From our UI Library, anyone can submit a Github issue to the team for review. These issues are how a designer gets the ball rolling with the Canvas team.

We ask for a number of details in the initial Github issue. We’ve learned over time (and communicated broadly) that things move more smoothly when the submitter has considered the details and use cases for a component thoroughly. This isn’t the place for general ideas or future improvements (those conversations often happen over Slack or offline between designers) — it’s for a component that’s ready to be reviewed and built.

It then gets added to our queue:

Step 2: The issues get triaged by the Canvas team.

This process has evolved over time, but our goal has remained the same. In order to make sure that nothing slips through the cracks, we realized that each issue needs someone responsible for shepherding it through this process. 

Instead of devising a sophisticated model for how to divide or evenly distribute the work, we ended up with a simple volunteer triage system each week. We settled on this for a couple of reasons. First, some people just have more interest or expertise in certain topics. And second, workloads outside of this team fluctuate — sometimes certain people on the team are busy and sometimes they aren’t. This way, the team can react to work in an elastic way, trusting each other to pick up the slack. It’s not perfect; sometimes we need to reassign issues or make small changes. But it fits our general style of working at HubSpot, and it hasn’t failed us yet.

Step 3: The issues go through review.

At a high level, the review process mirrors our overall design process (but at a smaller scale):

1. Understand the problem
2. Determine who is affected by the issue
3. Chat and collaborate with teams who are affected
4. Craft, modify, and hone the component design
5. Review with the Canvas team

We aim for this process to take a week, but some issues take minutes and some can take weeks depending on the scope of the component and its dependencies.

Step 4+: It depends.

There are a couple of scenarios that can come out of the component review:

• Design 👍 for components with wide use. It makes the most sense for our Frontend-as-a-Service team to build and implement these components, since they’ll be used across the product.
• Design 👍 for components with more narrow use. Often, if it’s a single team that needs a component most, they’ll build it in a reusable way, then add it to our UI Library.
• Design 👍 for components that don’t need to be reusable. Sometimes, components are so narrow in scope that there’s no reason another team would need to use it. In this case, the component is reviewed to ensure that it fits with the rest of the system, and then the team will build it into their app. If it needs to become a reusable component at some point in the future, teams can then add it to the UI Library.

If these issues result in something needing to be changed or added in our Sketch UI Kit, it receives a special tag with the name of the upcoming release. This makes it easier for the designers who curate the UI Kit to see everything that needs to be addressed.

There are also a few reasons why the team might reject a component request:

• Design 👎 for components that we deem unnecessary. The team will always include a thoughtful reason for why a component shouldn’t become a standard or why it doesn’t fit our guidelines. If applicable, other solutions or considerations are offered.
• Design 👎 for components that need more information. Sometimes, designers need to go back to the drawing board to figure out additional details before a component is ready for prime time.

For the people - your system should help you

We wanted Canvas to be so easy to use that our designers would never dream of using anything else. So, for example, instead of using just numbers to label our UI Kit versions, we started naming each version alphabetically after famous rappers. Not only did we get fun facts and great playlists, but it also made remembering and talking about the different versions a lot easier (unsurprisingly, Jam Master Jay and Kris Kross is a lot easier to remember than v1, v22, or v100). Once we made it through the alphabet, we started working our way through As Seen on TV products.

We care a lot about continuously evaluating and improving our process to make life easier for everyone on the design team. Some examples of the challenges we’ve solved over time are:

Visibility into what’s changing. 

In the early days, designers on the team had trouble knowing what was changing unless they were on the Canvas team. So we started sending out email every time we release a new Sketch UI Kit. These emails help us clearly and consistently update the team on what’s new and different in each version, and provides an easy place for designers to download the new Kit. Each UI Kit also includes a changelog on the first page of the Sketch file. 

Matching code in the UI Library to design assets in the Sketch UI Kit. 

In the beginning, we had a bare-bones Sketch kit cataloging the different components we might need and a front-end component library for developers to reference and use, but they didn’t always match up. This divide led to mismatched language between designers and developers. So in order to cultivate co-ownership between designers and developers, we undertook a big project to match the navigation and naming conventions in our UI Library and our Sketch UI Kit.

Thinking beyond traditional components.

Illustrations, page layouts, empty states, error states — you name it. If reusing an object creates leverage, it’s worth making it into a component or an add-on. Our Frontend-as-a-Service team has also made it extremely easy for engineers on product teams to submit components or add-ons to the system themselves. We’ve also started documenting UX patterns (not just “which component should I use?” but “how should I use it?”).

But we certainly haven’t fixed everything. Some challenges we’re still trying to solve and have been iterating on include:

Effectively assigning and displaying priority.

When we started moving our process into Github, we provided tags that let users choose the priority of their request on a scale from P1 to P3 (a P1 meant “we need this done yesterday” and a P3 meant “we’ll get to this someday”). But because our team moves so fast, almost everything ended up being a P1. 

But we also can’t do everything — we need to balance the priorities of 40+ teams, and we’ve had some issues slip through the cracks. We’re rethinking how we prioritize issues today so we can both solve for the team that builds our components and for the teams who are waiting on them.

Not having a dedicated design resource. 

While we’d like for all designers on the team to do a rotation, their main responsibilities still lie with their product teams. This means we need to be scrappy and resourceful when it comes to getting the work done in a timely manner. We may consider supplementing the rotational team with designer who’s focused on the system full-time in the future.

In our system we trust

We have a golden rule here at HubSpot as part of our Culture Code: Use good judgement. It stems from a culture of trust and accountability to others. We built our principles, guidelines, and processes on a bedrock of trust to ensure that our design system lasts, because a system only works if people trust it.

We created that trust by making it easy to understand how decisions are made and how to contribute if someone wants to help or disagrees with a decision. We gather feedback periodically and make plans to address improvements. We find ways for people who care about it or use it a lot to get involved. And we document as much as we can about why decisions were made so that anyone can see and refer back to them. 

At the end of the day, making the maintenance of our design language a breeze wasn’t just good for our designers and developers — it was good for our users. Redesigning our product with Canvas was a big change, but our goal was to build a system and process so strong that we’d never need to redesign our product again. 

With the foundation we’ve created with this entire system we have the capability to make smaller changes across our product over time. New primary color? Done. Rounded corners not cool anymore? Gone. Users have trouble figuring out how to proceed in a wizard flow? We’ll research and fix it without a whole UI audit across the app.

By creating a strong design system and a strong process to support it, we can support a thoughtful process of product evolution — without the burden of wholesale revolution. It’s a system that works.