sImoN Yee
Product Design

BuiLding a desigN sysTeM From scratc•H

A quick and dirty guide to building a scalable design system for early-stage startups

Design Systems are all the rage right now, and a number of companies have already shared some awesome examples with us, such as Airbnb, IBM, Shopify, and of course, Google. This is great and all, but how are you supposed to build a scalable design system when the team consists of only one or two people, and your company doesn’t have an army of designers at its disposal?

I’ve had the pleasure of building these types of systems in-house three times now, so I’ll pass on some of the knowledge (and lessons learned) I’ve picked up over the years, along with some resources and files to help young organizations get started.

Getting Started The goal of a building a Design System is to have a universal source of truth the entire company can reference as a wayfinding guide. With that said, the system should be detailed enough so that it is easily adhered to, but also flexible enough so that it is forgiving when used suboptimally, especially by non-designers.

The first step to making this happen is by having a conversation with Engineering and understanding what frameworks and libraries are in use, what the technical constraints are, and what compromises have to be made. For example, it wouldn’t make a lot of sense to create a UI library from the ground up if they are just going to use Font Awesome or the default glyphs in Bootstrap.

It is also worth mentioning that as you progress through your system, you can never check-in with Engineering too often, especially as it scales in complexity, since there will always be technical constraints to consider.

If your organization is large enough to have a marketing team, it would be wise to have a conversation with them as well, since decisions that are made in building the Design System will ultimately have an impact on them. There will inevitably be an intersection where product, marketing and communication designs overlap, so this is a good place as any to bring up relevant thoughts about brand, tone, compatibility, and expectations.

An example of the Polaris design system from Shopify.

Setting the Foundation You can’t build a freeway without a solid foundation, and likewise, you can’t design a product without one either. I typically start by harvesting the low-hanging fruit, and address typography and the color palette first since these can be standardized pretty quickly without much technical resistance. There are essentially two ways to go about this:

1) If you are the design lead in your organization (or one of them), use your best judgment and determine these things yourself with very little input upfront. This allows you to present several options to your team without all the preliminary back and forth that typically accompanies the exploration phase. This also makes it look like you are working collaboratively, instead of being a militant designer plotting a hostile takeover.

2) You can take a more democratic approach with a handful of key stakeholders, present a variety of fonts and a color map, and have them vote on their favorites using the Google Ventures/IDEO sticker method.

I’m a big fan of the latter, but how you approach this really depends on the organization, the level of trust and authority Design has within the company, and what you want to accomplish. If you are the sole designer at the company, and everyone looks to you for design decisions, you can take the first option in order to move quickly and use your time to focus on more intricate parts of the Design System. However, if you want to foster a collaborative environment and instill Design Thinking within your organization early on, the second option would be more conducive to that, though it would be more time-consuming initially.

Designing In Units Regardless of whether you measure in pixels, rem (web), dp/sp (Android), or pts (iOS), build the Design System so that it translates across all the platforms your company will be developing for. In this sense it’s best to remove the labels from the measurements and just think of everything as units.

Since web browsers have their own inherent design language built in, we can use a browser’s existing framework to our advantage. Pixels may display differently across different browsers, but rem will always be consistent since it is based on how a browser renders typography (which is usually around 16px). For this reason, I use rem as my base unit, but you can use any measurement to suit your context.

The main point here is that everything should be measured in increments (or derivatives) of your base unit (1.0rem in this example). I like to leave no room for ambiguity and address any potential edge cases before they surface, so I tend to enforce this rule pretty strictly. For example, I will define container radiuses at 0.5rem and button radiuses at 0.25rem—details that might cause friction later on.

Establishing the Grid, Spacing, and Rhythm Once there is a general aesthetic direction, the next step is to apply the earlier input you gathered from Engineering and standardize the spacing with a grid and vertical rhythm system. Depending on your situation, the grid column may already be set in stone based on an existing front-end framework. Even if it isn’t, the important things to think through are: 1) the layout (is it responsive or adaptive?); 2) how content reflows when it reaches a breakpoint (does it float or use flexbox?); and 3) how your design language translates into the overall front-end ecosystem.

Vertical rhythm is something that is often overlooked and absent (or at the very least, undocumented) in even the most mature Design Systems. What it essentially does is ensure consistency in spacing and alignment along the vertical axis—a kind of vertical grid, so to speak. In practice, it’s actually quite easy to standardize. To continue with my example, I just follow the same rules for my base unit and define all elements having vertical separation in increments (or derivatives) of 1.0rem. I've linked additional articles that go much deeper into grids and vertical rhythm systems below.

A diagram of a responsive 12-column grid based off of Bootstrap.

Components By this time, you should have enough of a design language to map out some wireframes and high fidelity prototypes to see how it all comes together. I highly recommend going through a core product flow in its entirety. It might sound tedious, but you can see your Design System at work in full context and in a variety of different states. This can reveal anything that might have been missed or require rethinking. But if it all makes sense, looks great, and gets buy-in from the powers that be, then you can officially document these standards in a style guide.

If there are any custom components to your system, now is the time to figure out what to do with them. For example, if you created a custom icon set for the UI, how will it be called—will it be converted into a font? Will it live in an asset library instead? If so, will they be broken up into individual icons, or live together in a single image sprite?

When creating components, try to be minimal and modular. What this means is to reduce the amount of elements that only serve one purpose and try to recycle as many as possible. This will help design decisions easier in the future, make maintenance of design assets cleaner, and streamline the development workflow for Engineering.

Depending on the depth of the illustrations, and how often they will be used, you may also want to consider an illustration guide to go along with your style guide as well.

Microsoft's Fluent design system standardizes icon positioning and sizing.

Post-Design Considerations Now that a system is in place and a style guide has been created, we’re all done, right? Not exactly. Another vastly underexplored area of design is what I refer to as Post-Design, which is what happens after the last pixels have been pushed and the files have been exported.

There are three major things to consider, which are all interconnected to each other:

1) File-naming conventions: Is there a system in place that allows anyone at the organization to look at any given file and know which iteration it is and what project it belongs to? Is it still clear without a folder or directory?

2) Version control: If a designer opens up another designer’s Sketch file, is there a system in place that allows them to edit said file without overwriting the original since Sketch continously autosaves? Can the team revert back to a previous design if necessary? What happens to older designs?

3) File handoff: How do files get to engineers? Do they even get files at all? How does Design communicate to Engineering the nuances of any given component? How do PMs bridge this gap and document required changes on a design?

Epilogue In an effort to limit the amount of design variations and CSS classes that have to be written, try to keep the system relatively simple. For instance, should an h1 require different vertical padding than an h2? Unfortunately, as hard as we try to keep our Design Systems simple, exceptions invariably happen. When they do, find a way to future-proof, scale, and recycle them.

This is by no means a perfect solution, and I don’t anticipate everyone benefitting from this, but I wish I had something like this to guide me when I was starting out. The intention of this article is to help young organizations lacking design resources to focus on essentials and get running quickly, but I included a couple follow-up articles in the Resources section below that go much deeper into the subjects discussed here.

As you dive deeper into Design Systems though, you will come across opinions that will differ, and even contradict what is written here. For example, some of the articles in the Resources section follow an 8-point grid (don't worry, all the material included therein is fully compatible with a 16-point grid system). One article advocates measuring typography by baseline, but another provides a counterargument for measuring by line height. So what's the deal? Why all the differing opinions on this subject when the goal is to build a unified Design System?

While yes, the ideal is to build something uniform, there's enough flexibility in design for multiple viewpoints. So long as the system remains cohesive and scalable, that's really all that matters.

Resources Style Guide (.sketch)
Brand Asset Usage Guidelines (.sketch)

Additional reading:
Spec, The 8-Point Grid
Built to Adapt, The 8-Point Grid: Vertical Rhythm

Simon Yee, Post-Design Considerations
Intercom, The Full Stack Design System