Design Systems Sprint 1: The Interface Inventory

10 min readApr 7, 2017

A brief introduction: I’m Marcin: a former UX manager and now co-founder and CEO at UXPin — the full stack UX design platform. In this series of posts, I’m reporting on UXPin’s journey of creating our own design system. In the first post, I discussed the fundamentals of design systems (the why? the what?). Now, it’s time to get some work done! Here’s the story of how we kicked off the process of building our Design System with an Interface Inventory.

If you’re wondering why or how to build a design system, follow this series of posts. Lots of practical advice coming up!

After our initial research, we learned that the lack of design consistency is one of the biggest problems in product development. We also confirmed that we needed to fix this issue in our own product.

More importantly, we determined that a design system is the right solution to prevent inconsistencies. We needed to fully commit to building a process that would improve the long-term survival of the design system as it grows to support our newest projects.

Nathan Curtis

, design systems expert and author of Modular Web Design, famously said:

“A design system isn’t a project. It’s a product serving products.”

A design system isn’t a standard carved in stone, nor is it a one-time deliverable. It’s the heart of your product development process, not an artifact of the process.

To us designers, that all sounds great. A shift in the process to eliminate design inconsistencies and repetitive work? Sign me up! Unfortunately, things are more complicated.

Selling a radical change in process is always very difficult. You force people out of their comfort zones, point at their mistakes, and ask them to do their jobs differently. Don’t expect them to welcome you with open arms. They’ll resist at first — it’s human nature, and you should be prepared.

So how can we change others? We don’t.

Some of the most important life advice I’ve ever received is that changing people is futile. Instead, we should inspire others to follow our lead. So let’s start with ourselves.

Start with yourself

You’re probably thinking, “Hey, aren’t you the CEO? Can’t you just tell people to start working on the design system?”

While that’s technically true, it’s not that simple in practice.

First of all, even CEOs live in a world full of constraints. I can’t just pull people out of time-sensitive projects, make them work with me on a design system, and still hold our VPs accountable to delivering important projects on scope, on time, and on strategy. That’s clearly an unreasonable expectation.

Secondly, teams need to fully buy into your ideas or they’ll never adopt them. To do that, you need to let them experience the pain and taste the solution. Whether you’re a design leader or lead designer, it’s our first responsibility to sell the design system to our organizations.

Enter the Interface Inventory — a simple tool that’s the perfect starting point of the design system. One that’s equally useful for evangelizing and kick-starting the journey.

What’s an Interface Inventory?

Brad Frost

, author of Atomic Design, defined an Interface Inventory as:

“…a comprehensive collection of the bits and pieces that make up your interface”.

In other words, the Interface Inventory is a neatly organized box with all the pieces of your product. In one “compartment” you might have all the buttons collected from the entire product or a family of products. In another, all the colors, the styles of text, etc.

The Interface Inventory is a phenomenal tool for showing all your glaring inconsistencies. It makes the problem undeniable to your team and stakeholders. Instead of ranting, you’re showing them easily consumable pieces that are easier to correct.

You also end up with a better understanding of the different phases in a product’s life. For example, a collection of all the different tables will show which ones are outdated and need to be refactored to the newest version.

The Interface Inventory is like the rings in a tree trunk. And just like with tree rings, you can see when there was a fire in the project and when the system was well nourished. This is an invaluable lesson for the entire organization. Good and bad times get reflected in the product experience. They’re a testament to our organizational efficiency.

Let’s get started!

Where to start an Interface Inventory

Brad Frost suggests that Interface Inventory should start with a simple task of taking a lot of screenshots of the UI and categorizing them into chunks in a keynote presentation.

While this approach can certainly work very well, it wasn’t a fit for UXPin.

We had an existing code architecture that I wanted to use as the foundation for our system. Our UI Architect (this guy is a pure genius and my front-end development guru) introduced a well-structured and modular approach to CSS years ago. We followed it religiously ever since. He divided our CSS (or rather Less, since we’re using a Less preprocessor to build and manage our stylesheets) into:

Elements — the smallest individual pieces of the interface which act as building blocks for components (e.g. buttons, form fields…)
Components — independent and repeatedly used pieces of the interface built out of elements (e.g. toolbar item, page loader)
Modules — full functionalities built out of components (e.g. toolbar, search)
Layout definitions — All of the above use core files (such as variables, icon font definitions etc.) to unify styling.

Last year, two-thirds of our product got rewritten into React.js, so we also started to take advantage of Javascript components, which are closely tied to a stylesheet architecture (maybe not as closely as we would like, but definitely a solid start).

Ignoring this whole foundation would make building our design system really difficult since it’d require massive refactoring. For us, refactoring would only give diminishing returns while costing a lot of time and morale.

With that in mind, I formed a different kind of process for creating the Interface Inventory:

Compare. Compare pieces of the interface with their representation in code and identify logical chunks.
List. List all the pieces of the interface in categories derived from the code environment. Add additional suggestions of categories where necessary.
Note. Take notes of any inconsistencies between elements. If possible list classes and files for future reference.

With this simple process I was almost ready to go. I just had to decide on the final format.

Since we’re aiming for overall reusability, I decide to make our Interface Inventory 100% reusable. Instead of taking screenshots, I aspired to collect patterns directly from past projects — when that wasn’t possible, I redrew them.

In the end, I hoped to have an inventory that could be quickly reorganized into at least a rudimentary design system.

The Inventory of Building Blocks

In my first post in this series, I divided a design system into three parts:

Building Blocks — the smallest, most general and most reusable pieces of the interface such as colors, typographic scales, grid definitions or icons.
UI Patterns — the pieces of the interface directly used to build experiences.
Rules — guidelines for implementing and growing a design system

As much as possible, the inventory should follow a similar structure.

Since you’re working on a living product organism rather than a well-organized system, not everything might be ready for ‘inventorization’ (for example I had problems with grids and rules). I assure you though that some building blocks and all the patterns are ready for you.

An easy building block that I decided to start with is color. Since our web development team uses Less, I was hoping I’d find Less files full of color variables, which would help me identify the core palette used in our product. After a brief GIT investigation, I identified 6 files listing…116 colors variables. I was a bit overwhelmed, but definitely curious about what was going on there.

After talking to the team and thoroughly checking all the files, turns out that some of the Less core files (and colors) were deprecated and some colors were duplicated.

Nonetheless, these 116 color definitions existed in our environment and perhaps asked for a little bit of refactoring. After all how can we understand our primary palette, if it’s hidden among 116 different colors? We can’t.

To give our team material for future discussions and a possible clean up, I decided to list all of the colors in a UXPin project. I also started to write a ‘Design Journal’ as an unstructured documentation to the inventory, so the team could know my thoughts from the moment an inventory item was created.

Here’s what the final list of colors looked like:

And this is the journal part:

Encouraged by the initial progress and a growing interest of the team, I then created an inventory of the typography.

For quite some time, UXPin has always had a strict typographic standard. Inside of the application we use ‘Proxima Nova’ exclusively and only in the two most legible weights (regular and semi-bold). That’s great and definitely creates a sense of consistent design. I wanted to see the full scale though to understand the semantic structure in the product.

This task required a little bit more of a detective work. I used the inspector tool from Chrome Developers tools to check the markup and selectors of all the specific text elements in the UI.

Here’s the list of all the text styles in the typographic scale:

The Inventory of Icons

The UXPin interface is definitely icon-heavy. Back in 2015, we invested in our own icon family as a custom solution for clarity and consistency.

On the code end, we continue to use icons as a font file. It gives us great performance and makes any icon management, on the code end, a bliss. The industry is heavily divided though — there’s definitely shortcomings to the approach. I highly recommend these two articles, so you can form your own opinion:

Nonetheless, my task was just to build a list of our icons. I could drop all the SVGs to UXPin and call it a day, but then we wouldn’t have desired sync with development. Instead, I went straight to the source and used icon font files to create a repository of icons.

This way, in the future versions of our system, we could use exactly the same assets as developers.

I spent a fun weekend with Javascript and created a little utility app that takes our font files and Less files with icon definitions and creates a searchable icon list with generated mixin definitions.

All packaged as a Mac App to make it easily accessible to our designers and developers alike:

Little app that generates a list of icons from an icon font and shows mixin declaration from Less files

The app was easy to build and proved invaluable during the later stages when I had to build actual patterns in UXPin. All the font icons are reusable in UXPin since our Enterprise plan (which, of course, our internal team uses) comes with the ability to upload custom fonts.

Added benefit: I had a lot of fun working on this little project.

The Inventory of Patterns

With colors, typography and icons all documented in our inventory, it was time to list all the interface patterns.

Similarly to colors and typography, I had to inspect our production code to find the right Less files to understand the categorization in our architecture. It takes a bit back and forth between the design, browser inspector and github, but produces the most reusable inventory.

I also documented all the classes used to style a particular pattern. If I’d ever want to modify it in the future, the inventory delivers all the necessary information:

Whenever I identified issues, I annotated them for the team to resolve:

Once completed, the patterns inventory is an easy and accessible reference point for future work on the design system.

Summary

The Interface Inventory is the source of truth about the status quo.

All the elements are documented and ready to either be corrected, deprecated or included in the first canonical version of the design system. Share it with the team and stakeholders.In a matter of minutes, you’ll help them realize the benefit of cleaning up the experience with a design system.

Once you have them on board, you’ll need to focus on unifying the elements in the inventory with a common design language. And that’s exactly what we’ll cover in the next post!

Are you looking for all the articles in this series? Here they are:

And you’re into more in-depth thoughts on Design Systems: