The benefits of design systems are pretty self-evident at this point - only needing to invent the wheel once saves time and energy and makes for better experiences for users. But in order to have a design system, you have to create it and then make sure people use it. How does that happen?  

As part of the design system team at my organization, a small group of designers & developers, we grew our design system from a handful of code components to a robust library containing almost everything a designer or developer would need.

Some of the issues we tackled during this time:

• How do we keep track of which components we have, need, and want?
• How do make the library usable? How do we make the offerings easy to find and easy to implement?
• How do we accomodate the needs of different types of users (designers, developers, stakeholders) while keeping the project scope manageable?
• How do we work around the limitations of legacy implementations? How do we identify opportunities to address technical debt? 
• How do we keep *this* system alive, unlike the other systems that got left behind?

I was assigned to work on this project in 2017 and I worked on it until 2020. My personal goal for this project was to create a single source of truth for designers & developers to eliminate the need for everyone to be continually shopping for patterns from each other and digging up old Sketch files to find an accordion or a dropdown.

Pattern Library website structure

Our last big project for the design system was combining the original "Design" and "Development" tabs into one unified section called "Pattern Library".

Design challenge

The original version of the pattern library website was simply a list of simple code components and HTML snippets, like buttons, form inputs, and dropdowns.

As we worked to develop the library, everything grew: There were more components, the components became more complex and needed more explanation, the types of components multiplied and needed differentiation & usage rules. Because there were more components, they needed to be organized. At the same time, the design documentation was growing too, like documentation of interaction states and options, as well as big-picture information like color palettes and icons. As these two sets of information got bigger they also started to overlap each other and the differences between them got fewer.

But the simple page template we were using wasn't designed to contain anything but the name of a component and the code needed to run it. And the navigation wasn't designed to be anything but a list of components. So we would need to design something new that could present everything we wanted to present.

Solution

First iterations

My first attempt at combining these two sections into one. This attempt was still holding on to the idea that "Design" and "Development" still needed to be two different things, and so this design called for a lot of fussy detail to make that distinction obvious. At first I thought, well maybe this isn't such a good idea after all if this is what the result is! But the more I looked at it the more I realized that whatever the theoretical differences are between design and development, it doesn't help the user to spend a lot of time talking about it in the navigation of the website.

Final iteration

As we considered the original iterations as a team, our development team brought up some examples of other design system websites that used sub-tabs to divide up design and development content relating to the same topic. I used those examples to produce this final iteration. This single page template could be applied to any topic, whether it was a code component or just guidance.

We knew that this iteration was the one because it could be applied to the entire set of content with no gaps. This was the document I made to explain the content strategy to the other designers & developers on the team.

Pattern library component display

Design challenge

As the amount of information we had about our library was growing, we didn't have a strategy or plan for improving the design of the website to accomodate it. I had been thinking for awhile about how to communicate information about:

• How to know when to use each type of component - when do I use a primary button vs. a secondary button? When do I use a modal? When do I use a toggle button vs. a dropdown? 
• What are the interaction states and guidelines for each component, beyond just what they look like?
• How do we display components that we have design specs for but no code yet?

This was information that designers needed, which I knew because it was information that I needed. Instead of being able to reference a single source of truth, we just had to ask each other "Do you have something for this?" and maybe we were asking the right person or maybe not.

I decided to explore how the design system website could be revamped to include everything we had.

Solution

First iteration

My idea was to group components by how they are used, presenting the usage rules first and then the components that that applied to. For each design I tried, I tried applying it to the entire set of components to see if they fit and where the template would need to be adjusted. As I made these iterations I learned more about what information was common across components and could be included in a template and what information was unique.

This my first attempt:

Final iteration

This was my final wireframe, which we then perfected by working with the talented visual designers on the team.

Features:

• This gave us the ability to display components that we had visual specs for in InVision even though the code had not been developed yet. This meant no more "Do you have this?" and shopping for old Sketch files amongst team members.
• For those components, I had the idea to let users let us know that they needed code by opening a pre-filled Google form to help the development team know where to focus their efforts on building out the code library.
• For components we did have code for, a direct link to the new "Code" tab for implementation details.

For my deliverable, I included:

• Brand new copy written by me, and refined by our copywriting team, about when each component should be deployed.
• Descriptions of each component
• Links to each component in our InVision UI kit
• Pre-filled link for google form for each applicable component