Overview
As you can see from the image above, Goldstar’s Design System covers a lot of ground. There are entire sections dedicated to documentation and process; a design system is pretty useless if no one on the team bothers to use it. But I’m going to focus on the Component Library in this post because it does a good job showcasing the ideas that I think are important in a Design System.
Goldstar’s Design System contains four separate component libraries, each of which focuses on a different side of the user experience. We can then connect as many libraries as we need to each new project, ensuring that designers are pulling symbols and patterns that are always up to date.
Our libraries are:
- AMP (B2B application for event suppliers)
- Goldstar (B2C web, iOS, and Android products–we call it “Refresh” internally)
- Wireframing
The Start
When we went about starting to build our component libraries, we had some difficulties to overcome. For one, even today there aren’t a lot of great resources on how to build and maintain a usable library. There’s a ton being written about them, but most are so surface-level that they just ended up wasting our time when we tried to implement them. So for the most part, we were figuring it out by trial and error, constantly questioning what was right for our team.
Another issue we dealt with (and will continue to deal with for the foreseeable future) is that the tools for component libraries are changing rapidly. Finding the right balance of best tool for the job vs how often we ask a team to adjust their process is something that isn’t changing anytime soon.
Audit
We had two main issues to contend with at the very start. The first was that our product had 15 years of history, which translated to designs that weren’t consistent. There was a point where we realized that we had 40 different buttons styles! The second issue is that we were working through the Design System as part of our rebrand, so all the parts were in motion at once.
That said, the first step in putting a Design System together is an exhaustive audit of what already exists. It’s impossible to know how to architect a system until you know what it needs to include. The audit also helps us find places to streamline. In the end, those 40 button styles were whittled down to four.
It’s a Product, Give it a Roadmap
One of the more important aspects of a component library to realize is that it must evolve. Every new feature, or even every new promotion, has potential ramifications for the library. It’s critical to get everyone, from designers all the way up to C-Level folks, onboard with the idea that libraries need continual maintenance.
Libraries tend to be massive, and therefore feel very daunting. But since we’ve been cleared to treat it as a product that needs time allocated, we can make it seem less intimidating by breaking it down into smaller releases. It didn’t need to be detailed, it just needed to make everyone feel like they weren’t going to be crushed by the workload.
Architecture
All of our libraries’ components work like building blocks; each level builds upon the level that precedes it. It borrows heavily from Atomic Design principles.
Our component libraries are arranged in levels like this:
- Helpers
- Level 1
- Level 2
- Level 3
- Typography
Helpers are things like colors, spacing blocks, sticky notes–things a designer might need often. Level one covers things like icons, logos, and other symbols that can’t be broken down any farther. By the time you get to level three, we’re dealing with whole UI patterns that can be dropped into place.
Setting Up the Sheets
One of the more enlightening parts of building a pattern library is realizing that the part that everyone thinks is important is actually pretty worthless. Sheets (often called sticker sheets) do a good job of showing what lives in the library, but it isn’t where the real magic happens.
We did, however, make some important choices regarding our sheets. We set them up to be printable, and to translate well to HTML should we decide to take them out of Sketch.
Each sheet gives a little information about how certain symbols should be used within our system. Ideally, these could serve as a crash course when a new designer joins the team.
Designing for Everyday Use
Even though we set up the component library to be easily scannable on each page of the library file, it’s important to remember that the actual use of the library doesn’t happen within the file itself. The usefulness of our library comes down to how easy it is to use when we have it connected to other projects. If the components aren’t intuitive to find, or if the symbols are cumbersome to customize, then we’ve missed our mark.
When adding a new component or pattern (or adjusting one that already exists), thinking critically about where it belongs is just as important as how it’s built.
We also considered this the breakthrough in our thinking. All of our decisions revolve around what is the most useful when pulling a symbol into another project. It’s helped turn Goldstar’s component library into one of the most useful libraries I’ve encountered.