Insights for those trying to figure out where to start
“Where do I start?”
That’s the question I get asked the most these days by other designers. Smart, talented product designers who are struggling to build a design system within their team. We see Salesforce’s Lightning Design, Google’s Material, IBM’s Design Language, or BBC’s Global Experience Language and thought, ‘Oh wow. I would love to have that for my team.’
These are the golden standards of design systems: Salesforce’s Lightning Design System, Google’s Material Design, IBM’s Living Language, and the BBC’s GEL.
And we understand why: a systematic approach to design not only ensures a better, more cohesive experience for our users, but it helps keep our internal teams in sync as well. As design pushes out from being a simple, beautiful veneer to an integral guiding force, it’s important that design teams proactively communicate and work with other teams.
But again—you get this. The question still remains, “Where do I start?”
It’s the same question I had for a long time. Many articles and sessions I’ve attended on the subject tend to assume you’re starting from scratch—or would even recommend this approach. It’s far easier to wipe the slate clean and start over. For many people though, starting over isn’t an option. It wasn’t at Stack Overflow.
So we had to figure this out on our own. In the process we’ve had our fair share of false starts, mistakes, and backtracking. But we’ve also had successes too as we learned the best way for us to build a design system. And I stress “for us” because crafting a design system is unique to your team. What’s worked for us, or Google, or Airbnb—that may not work for you. Like a workout regimen, you need to figure out what fits your team best and build from there.
Get buy-in first, patiently and broadly.
Getting buy-in from other designers, co-workers, and decision-makers will be your biggest challenge. That’s not to say there aren’t other challenges, but almost any challenge you’ll face after this can be overcome. If you don’t overcome this hurdle, either your system won’t ever get off the ground or it will be thought of as some side-project which never gains widespread adoption.
Some will understand the value of a design system right away—especially if you’re a growing design team struggling with inconsistent outputs across multiple product teams. In those instances, it’s worth the company’s resources to create a team which manages design consistency. Many of us though don’t work at companies which are aggressively hiring dozens of designers and experiencing severe growing pains that comes with that. Or–if you are aggressively growing–the company isn’t always able to allocate people because of more pressing business priorities.
Moving the conversation from the merits of a design system to implementing one can be a long one, but be patient. Changing minds takes time. Build support not only within your own team, but reach out to other teams as well. Listen to their hesitations and note the problems they are facing. Figure out how a design system could help solve some of their issues. Gather feedback from user research, usability tests, and traffic data to show how inconsistent designs across different teams is costing your company money and opportunity by creating subpar experiences for your users. To have a design system you first must be its advocate.
Settle the “Big Four” first.
When you look at finished systems, it’s inspiring. You want to jump right into designing the “things” within the system. Yet if you don’t work out the foundational pieces of your system, you’re not providing the necessary tools your team members need to continue building on the system. At Stack, we refer to these foundational items as our “Big Four”.
- Typography
- Spacing / Grids
- Colors
- Forms
Those are listed in the rough order I would recommend teams exploring them in. At Stack Overflow we tackled colors first, then forms, and finally typography and spacing together. In retrospect, we probably should have address typography first since it’s integral to everything you’ll build.
When working on colors, we pulled all the colors found within our minified CSS. We then plotted them, noting their usage, to develop a new set of colors.
We chose to tackle color first because it was the best place to get started for us at that time. Stack Overflow was in the midst of a rebrand, which had made the marketing and product teams acutely aware of our inconsistent use of colors throughout the product. Addressing this issue provided us our first major opportunity to show the larger product team of a design system’s value.
We addressed forms next, again, because it became the most pressing issue for us at the time. Here was another chance to show the product team the design system’s value. The process also helped us to learn how to review large design changes as a team and communicate those out to the rest of the company. Since we aren’t able to redesign everything at once, we needed to learn how to roll out changes while maintaining current features and layouts.
The important thing to remember is a design system needs “just enough” rules.
Coming to agreement on these items makes all future decisions easier. Establishing type, spacing, and color patterns limits your choices, but frees your team to explore experience and product design ideas without needing to worry about the visuals every time. You can move into implementation questions instead of having another “discussion” over the use of particular color, font-size, or layout.
The important thing to remember is a design system needs “just enough” rules. It needs to be rigid enough to provide strong guidance, but flexible enough to allow for unforeseen scenarios.
Document everything.
As you gain buy-in and settle the foundational design elements, it’s important you document your decisions. Presentations and talks are great ways of introducing things to your team, but it’s important team members have easy access to information without having to talk to someone.
Your documentation doesn’t need to be slick at first. It can something as easier as a README file, Google Docs, a Trello board, or even a simple static website—it doesn’t matter. What’s most important is that you start documenting things.
Some teams start by creating a “design war room”, which works great if you’re in one location. However this doesn’t work for all teams. Especially for remote teams like the Stack Overflow Design team. Spread across 12 locations, 6 countries, and 6 time zones, we need to be able to communicate topics, decisions, and guidelines asynchronously.
Start with the tools your team is already using to start organizing and documenting things.
Using tools like Trello, we gather guidelines, needs, and examples. Then we attach Google Docs to cards to document suggested rules and proposed layouts. This allows others to learn, comment, and discuss items in their own time. Once we have agreement, then we start adding the documentation to a simple static HTML website. This website is easier to access (and can be bookmarked). We use all of these tools regularly for our other projects. In the same way, work within the tools your team is already using and start there.
At Stack Overflow, we documented items, providing code snippets and HTML previews. We also label where these components are currently available.
As you’re writing and collecting documentation, it’s also important you agree on the documentation’s purpose. Should the documentation only contain what you have available right now or should it include what could be as well?
This may seem like common sense, but unless you explicitly state the purpose, people will assume their purpose is the same as everyone else’s. I know because that’s what happened at Stack. Because we didn’t have that agreement, we had a number of discussions over what we should document, how we should document it, and what we should work on next.
In the end we realized it’s not a binary decision. Your documentation can be both. This might make your documentation messier, but we felt it was important people understand not only what’s available to them now, but what’s going to be possible soon.
Create “North Star” projects.
As your establishing your design system, it’s important you take time and create “North Star” projects. It’s hard for people to get excited about tools. And a design system is that: a tool. There’s beauty in it, of course. But the beauty comes with how people use it.
When you see a hammer, you’re excited about what you can do with a hammer–not about the hammer itself. It’s the same way with a design system. To get people excited about a system, you have to show them what you could build with it.
Now there’s a caution here, though: be wary of “the redesign.” Designers love to wipe that slate clean and start over. It’s easier in some ways to not have to worry about legacy code. Despite the excitement though, we shouldn’t forget how expensive a redesign is. And expensive not just in the time and effort for the product team, but also for everyone who sells, supports, and uses the product. The institutional knowledge gained will now be altered, changed, or even made irrelevant with a redesign.
That caution aside, it’s good to excite people about the potential available with a cohesive design system. One way we’ve done this at Stack Overflow is holding “5% Fun” meetings. These are 2-hour meetings held at our discretion. Beforehand someone presents a challenge. We’re given 60 minutes to design a solution, encouraging each other to think outside of what we do today. We then spend the next 60 minutes presenting our work and discussing it.
A sample output from one of our “5% Fun” activities exploring Stack Overflow Jobs.
Some of those projects went nowhere. But some have become seeds for larger projects. In those instances, gaining internal support was much easier since we can show a number of potential ideas to other team members.
We’re still learning at Stack
We’ve made a lot of progress over the last year, but we aren’t finished. Far from it in fact. Despite the work in front of us, we’re excited about our progress so far. We’re still learning how to balance this as a support project amongst other business concerns. We’re getting better informing the product team of our next steps, allowing for feedback, and holding each other accountable to the new standards.
In the end, we’re pushing ourselves every week to do one more thing then we did last week; and that’s the same wish I have for you as you start your design system.