Published on | Prototyping: From UX to Front End — Medium Jeff Harris

From choosing the right tool to selling the concept

Any designer with more than a few years of experience behind them has war stories of redlines and style guides — late nights and early mornings spent meticulously documenting spacing, typography, color codes, dimensions, and every other meticulous detail into a PDF.

Any time the design changed? Re-issue the redlines.

For ages, this kind of heavily edited, ultimately static document translated the abstraction of a designer’s work into a guide for the people actually delivering a product.

For designers delivering software, (especially for the web), this long felt like madness. The internet is, after all, a platform of dynamic documents. Why can’t designers and developers communicate through web pages of code snippets and examples, pulling from the same styles as the final product?

More importantly, why can’t designers behave more like developers, with a shared library of components that we plug and play and modify as needed, ensuring that every color and border radius and text style is in sync.

This approach is called a Design System (also Living Style Guide, Design Resource Guide, or Design Language). If you weren’t already aware, for the past couple years it’s gained major acceptance in the design community.

While a Design System is clearly superior to the old static style guides, it does threaten some new challenges. Having developed and sustained Design Systems for several clients now, I’ve learned a few key lessons along the way.

If you’re considering building a Design System for your next project, here is a quick introductory guide to get started.

Choose the Right Tool

Any design team will need software with a shared library feature to facilitate collaboration. Popular platforms that currently offer this feature include:

Sketch
Adobe XD
Figma
Atomic.io

The new native library functionality in the latest version of Sketch

A shared library of typography, components, page templates, etc. ensures a consistent design and rapidly speeds up design iterations.

The bottom line is this:

The less time I have to spend re-drawing buttons and checkboxes, the more time I have to explore the problem space.

Make Changes Painless

Our team keeps all library assets on cloud storage with a desktop syncing application (e.g. Google Drive, Box, OneDrive, etc.) This means that everyone has a local copy of the library files to reference in their design, but that local version is synced through the cloud.

Accepting a shared component update in Sketch

The master library document can then be edited (say, a color needs to be added) and the change will then propagate throughout our designs. It’s relatively painless.

A web-based platform like Figma or Atomic.io have no need for desktop syncing, and maintain the library in the cloud by default.

Start at the Extremes

After much trial and error, I’ve learned that a Design System needs to begin at the extremes — the largest possible element and the smallest. Then, you can freely design everything between.

The largest possible element in a composition is the frame. How large is the page? If this is a web-based design, is responsiveness an issue? What are our margins? Oftentimes in the case of enterprise software, users will be restricted to a certain size and resolution of monitor provided by their employer. It can be especially helpful to borrow that device to test your design assumptions (instead of your luxurious 4K color-balanced monitor).

As a team, we set a layout default in Sketch

At the same time that you consider the scale of the whole page, look at the smallest typographic element on the page. This might be a footnote, or a tiny label. The use case isn’t as important as the baseline — what is the smallest, comfortably readable size your design should support? This isn’t the basic body copy size, it’s a step or two down in the typographic scale.

From this smallest element, an entire typographic scale can be developed up to the largest header. The scale for body typography (the most basic paragraph) should then determine the baseline grid and rhythm for your page(s). (For the web, it’s worth remembering that you may want a different typographic scale and baseline grid for different responsive breakpoints).

Setting a baseline grid and basic components based on basic paragraph type

This is the first stage for laying out any design system.

Doing Things In The Right Order

In order, I initially set:

Page size(s)
Smallest type element (e.g. footnote)
Typographic scale up through Headers
Colors
Icons
Simple selectors (links, checkboxes, tabs, etc.)
Buttons (i.e. CTAs)
Form fields and pickers (dropdowns, text inputs, etc.)

From there, larger and more complex patterns naturally flow. Also, this is a flexible process. Our last client used a card-based system (similar to Google’s Material Design), so we designed basic Cards before diving into Colors, Icons, and the rest.

A Design System Isn’t Just For Designers

Implementing a Design System is a real effort. Every time we have had to work hard to convince clients and stakeholders (and even the occasional design director) that this is worthwhile.

I’ve found the most compelling argument for building these systems isn’t the benefit to designers, it’s the benefit to developers.

If the components in your Design System can be exported as code (or even just styling markup) it is of enormous benefit. Design hand-off platforms like Zepelin, Invision’s Inspect tool, and some plugins from Sketch have already shortened this gap. For our most recent client engagement, I actually wrote a simple Sketch plugin that exported the CSS markup for every component in our Design System.

A Design System will certainly make screen layout easier, but ultimately those compositions are a dead artifact.

The real power of this process is ensuring the fidelity between what is drawn in pixels and what is written in code.

A Final Thought

A Design System is a product in itself, and it isn’t right for every project from the beginning. I believe it’s better in the early stages to be a little sloppy, to redraw and cut-and-paste elements instead of dogmatically punching through a checklist.

You need to see how things look on the page, let the lines and color and text respond to each other in a real context, instead of the artificial environment of a Design System file. Draw a real screen from scratch. Keep what you like and change what you don’t. Then, repeat.

In my experience, it takes about 3 design sprints before your design elements really start to gel. Only then should you consider a Design System.

I think you’ll agree, though, that it’s well worth the effort.

If you enjoyed this article, please throw some claps at it to help other folks find it.

If you have any questions or feedback, don’t hesitate to drop a line in the comment section below.

<a href="https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href">https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href</a>

How To Implement a Design System was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

How To Implement a Design System

Cool stuff, every week

More Articles