Above/ Quickly constructing ready-made UI that perfectly matches our production environment
Help Scout has always been strong on visual guides and documentation for their brand. 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.
Design Systems aren’t a new concept, though having built and worked with large and complicated 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 they 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.
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”
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.
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. Additionally each designer could pick and choose only the libraries that affected their role, meaning easier onboarding and maintenance. This approach meant that by adding, removing or changing an asset (an icon, for example) in the core library, 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 all components were immediately updated.
A centralized library also means that matter what team or project a designer is part of — they reference the same shadows, color pallets and core shared elements for a consistent brand experience:
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 used 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 used and contributed to by every Designer and UI Engineer across the business — fully documented and managed by a group with no single point of ownership. 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 are comitted.