Having created and worked with design systems of various sizes at previous companies — with varying levels of frustration — I was relieved to find that Help Scout didn’t have one. Instead designers created the right UI for the job rather than retrofitting existing components… which worked well, until it didn't.
An origin story Direct link
My spicy opinion was that design systems classically destroy a designer’s ability to be creative — forming a lego-block mentality to creating solutions instead of approaching each UI challenge on its own merit. So when I joined Help Scout and started using their existing Sketch pattern library, I breathed a sigh of relief.
Of course as the team and codebase grew, so too did the need to find consistency and reusability — both of code and visual style. Eventually a simple re-design of our settings made it apparent that we needed a better way to design and build, so I led a small group of designers and engineers to discuss a possible solution, which was inevitably to create a design system.
We called it the The Help Scout Design System. Imaginative. (Jokes aside, building a design system is as much a political exercise as a creative one — so having a name everyone can understand turned out to be quite important).
Doing it different Direct link
In an attempt to avoid the mistakes I’d seen at other organizations, I set out some principals to help guide our decision making — these helped us collaboratively build the system we needed whilst giving everyone the opportunity to pitch their own ideas.
№1. Be an aid to creativity
The system and its parts should be flexible enough to encourage variation, deviation and creativity — whilst accepting that convention can (and will) be broken.
№2. Code is the source of truth
Code is the closest relationship we have with our customers. The biggest threat to our success is when designed components fall out of parity with their coded counterparts.
№3. Contribute together
Design Systems need to mirror the structure and nature of the organization they serve. To do this, the current team need to create the tools that the current team needs.
The outcome Direct link
On the design side we broke components down into verified and unverified states which signified items with code parity and those that were to be considered experimental or work-in-progress. Components were also broken into individual libraries that represented unique codebases — all of which pulled brand elements from a central “Core’ library.
To help ease-of-use for designers, documentation was made directly in Figma using the components themselves — this prevented documentation from becoming stale, and acted as a resource for designers to copy-and-paste without needing to create complex UI from scratch. These are also accompanied by entire screens made entirely from components.
Everything with a verified status in Figma had corresponding code in Storybook — complete with documentation, ownership and reciprocal links. This made it easy for any engineer to find and consume components whether they were navigating a spec in Figma, or reading code in React.
A creative resource Direct link
It’s been a long road to success, but one of the most promising outcomes has been that designers and engineers have leveraged the system to create new components and remix existing ones to suit their needs. Far from limiting creativity, HSDS has set the groundwork for more fun and more experimentation.