Designing a design system

A concise overview of how to set up and start a living UI pattern library

Earvin Fanfair

Published in

Design Voices

6 min readMar 23, 2017

by Earvin Fanfair

Modularity of design components and elements are a vital part of creating a UI library. When building a library, the approach of it should be abstracted from pages and focused around elements and components. (I will discuss this a bit further in the “design tokens” section.) Having a roadmap and artifacts to help govern and frame the contribution and consumption model of a designs system at an organizational level should be established prior to the start of a design system. Often, companies find themselves in a situation where design teams need to consume the pattern library prior to it being fully integrated, so finding a way to empower autonomous design teams early on is vital.

The setup

Here is an outline of the steps involved in setting up your living UI pattern library that I’ll be covering:

Documenting and defining your intent
Establishing the workflow
Creating your baseline inventory
Setting up a tactical Sketch file “Designing for designers.”
Design tokens
Documentation
Repository
Next steps

Intent

A living UI pattern library is not created in a linear process. Your UI pattern library on its own is rather useless. Defining the intent helps establish your guiding principles and approach on voice and tone, visual language, motion and product vision. This will help create a philosophy to anchor the decisions you and other design teams will make as the UI pattern library grows.

Workflow

With all the new design tools available for designers, establishing a workflow for a creative team can become a huge challenge in its own. Integration of teams and legacy files are just a few of the things that might make a company hesitant to change tools, so it will require a bit of buy-in from an organizational perspective. That should go back to a more holistic view of what a design system enables for company (consistency and cohesion, speed in workflow, shared vocabulary, future friendly…).

When picking tools to establish your workflow, aside from the methodology of a design system, there are some variances in what design tools can provide for a design team. For design systems I’ve worked on in the past, Sketch has been the consensus.

Creating a seamless hand-off can really accelerate the designer, developer workflow. Having a central place where developers can go to get all the assets they need will greatly reduce time spent skimming through Sketch files. There are a wide range of tools to help accelerate this process, including Inspect by Invision, Zeplin, Sympli, Avocode. (While they all have different pros and cons. I’ve found Zeplin to work best, as it’s the most refined out of the bunch.)

Baseline of inventory

Next, you will need to establish your core elements. Your inventory will serve as the building blocks for creating a layout. The baseline of an inventory can be summarized as all the basic elements needed to construct a page layout and build its way out from there. Establishing scalability (e.g. modular scale, baseline) and WCAG 2.0 should be considered in the creation of your baseline inventory.

Here is a list of what your baseline inventory should consist of:

Grid
Colour
Typestack
Buttons and text links

Working file

The Sketch file should be very tactical, greatly organized and easy for a designers to consume. Grab what you need, build your layout and repeat. Here are a few organizational tricks that I use to help designers navigate a Sketch file swiftly:

Tip 1 — Artboard position

Start artboard at an X and Y position of zero. Ensuring you have a consistent position will help a designer have a starting point when they open the Sketch file. (And don’t forget to collapse all your layers!)

Tip 2 — Bird’s-eye view

Lay all your elements on a single page and use large headers when labelling them. This gives designers a bird’s-eye view of the entire inventory from a zoomed-out view in Sketch. This also works great to help encourage designers to use the often forgotten filter (search) feature in Sketch to find what they are looking for quickly.

Tip 3 — Accelerators

Having a good set of plugins and documentation for what they achieve should live near the beginning of your documentation, to ensure every designer will install them as part of the on-boarding when beginning to use the design system. Some great design accelerators that I have used in my workflow on design systems include:

Nudg.it: You can set pixel amounts for your small and big nudges in Sketch.
Animas auto-layout: Auto-layout for different screen resolutions, with the integration of Stacks.
Sketch palettes: Unfortunately, Sketch doesn’t have the most robust colour management system, which means there isn’t a quick way to share palettes, aside from manually entering colour values. Sketch palettes allow you to save your global and document colour and load them into your picker. Alternately, you can create a “Designer start here” blank page in your Sketch doc to encourage designers to work from a duplicated download of the master file, and just absorb the master files file size as an addition to the output of your working files size.

Design tokens

Design tokens are the abstraction of design values to named entities that house design attributes. Tokens are the building blocks for developers; they view development from an integration standpoint to ensure ease of consistency for a design system. Although Zeplin is good because it displays a variety of markup languages for front-ends, there isn’t a way of outlining token variables in Zeplin’s style guide, aside from colour and your base fonts. Your inventory of tokens will need to live as an additional document. This will serve as a style sheet for your developer. As you work through creating your design token style sheet, you should be reviewing it with your developer to ensure your naming structure is accurate and clean (e.g. camel or pascal casing). This can be setup using tables in Google Doc or Dropbox Paper.

Documentation

Documentation is probably the most important step in creating a UI pattern library. Documentation should capture the look, functionality and usage examples. As you start to document things, the language naturally will feel design-specific, but as developers start to codify things, it should become a more collaborative explanation. Then, a copywriter can help the overall tonality of the documentation. Until you have a web-based UI library, Google Doc or Dropbox Paper works best for housing your documentation.

Central repository

Having a central repository for your Sketch file is important so designers don’t start creating new components because they are working off an old version of your pattern library. Your Sketch file will go through a weird period where you are outlining every single instance and state of an element and component. This is because things aren’t codified yet. But as they become codified, outlining every state isn’t necessary, as the code snippets become the bible for the design outputs. A central repository using SemVer in your file naming structure can be setup with a Git Repo (a great bonus as you can add notes to your commits as a change log) or Craft with a shared file on Dropbox (relies on JSON objects stored as text in subfolders).

Whats next…

As you start to build out your pattern library and teams begin consuming this design language, you can — using artifacts established at the beginning of your project — start to expand on having a centralized design team or governing body, with a governance model that outlines creation, contribution and consumption of design components. The governing body will also audit, ensure scalable and repeatability of the system. In addition to management of the backlog with net new component requests, the submission of pull requests, change logs and updating design documentation.

Thanks,
Earvin Fanfair