Help Scout Design System

Product Designer Design Systems / UI 2018–2020
Building a Design System

Above/ Quickly constructing ready-made UI that perfectly matches our production environment

I recently wrote an article for Smashing Magazine on moving the Help Scout Design Systems to Figma. You should check it out

Help Scout has always been strong on visual guides and documentation for their brand — check out the Brand Handbook. However, there were no established UI standards that covered the product, or anything that served as a ‘single source of truth’ for anyone on the team. In fact, Designers were referencing and re-drawing what was on the live site — a pretty common, though less than ideal situation for any product.

This approach worked well until the business hit a period of growth which saw the expansion of both our team and product footprint. At this point I saw an opportunity to define how we manage, share and contribute to our UI at scale. Our first cross-functional Design System.

Taking a different approach

Design Systems aren’t a new concept, though having built and worked with large design systems at Campaign Monitor and Atlassian, I was familiar with the challenges various approaches bring with scale. Before long, UI Libraries risk become too difficult to maintain, or worse restrict the creative process — ours needed to be different.

Below/ A selection of HSDS components. The lower libraries reference components from those above to form interdependency

Working with the design team and UI Engineers, I proposed a system of inter-dependent UI Libraries that spanned the various products and functions of the business — Marketing, Product, Embeddables and Mobile. Each Library came with its own documentation, GitHub repository and associated React component Storybook. I called it, unimaginatively, HSDS. The Help Scout Design System.

Creativity first

Our fully-remote Design team is spread across 3 continents and 5 timezones, so our approach to how the Sketch Libraries were constructed needed to be self-explanatory and protected from accidental damage. So instead of following the popular “Atomic” approach, our components were constructed in pre-built chunks with total color and over-writing control, example uses and a commit process similar to submitting code. Some of my approach is covered in this article — but simply, my approach meant that anyone could create a full and accurate UI in seconds.

At its core, HSDS was designed to be flexible in the sense that it doesn’t come with the strict rules and guidelines common with these types of systems. Instead it expects the designer to use best judgement, and acts as a non-restrictive creative starting point.

“A Design System is a set of rules, and rules and creativity aren't mutually exclusive. Rules can be broken”

Mina Markham

The pre-build components are there for ease — but if a designer wants to freestyle their own design and use only the smallest building blocks, we support that too. Designers exist to serve the problem being solved, not beholden to the systems created to help them.

Every library comes with its own “Example Usage” files which outline the more common ways components are grouped

Below/ An example of how just one component can have a number of different states and configurations

Splitting our Design System by business function also meant that we could centrally manage our brand assets such as colors, illustrations, icons and anything that is agnostic to environment or team. This approach meant that by adding, removing or changing an asset (an icon, for example) in one single place, every other UI Library would gracefully consume that change. This was perfect for our 2018 brand refresh, where we changed our entire color pallet — there was no risk to ‘downstream’ libraries and no risk of out-of-date files.

For example, no matter what team or project a designer is part of — they consume the same shadows, color pallets and core shared elements:

Bridging the gap

Below/ The React Storybook that contains all components and visual QA tools

Design Systems are only useful when they’re easy for Engineers to consume — otherwise Designers are operating in a vaccuum. From the outset, HSDS involved UI Engineers from across the business to build the necessary tooling that sees each component visualized, tested and self-contained — ready to be consumed by anyone who implements code. Thanks to a monumental effort from Help Scout’s Design Engineer (our very own Q), HSDS now operates as a single-source of truth and visual quality benchmark for every team.

Although I initially designed and orchestrated the construction of HSDS, today it’s being consumed and contributed to by every Designer and UI Engineer across the business — fully documented and managed by a group with no single point of failure. This way the system can continue to grow and evolve without much overhead. Even the documentation (below) gets automatically updated when new changes and examples become available.

Help Scout
Design Systems
Design Ops
HTML prototyping