Not only should the Help Scout brand humanize the product and build relationships with customers, but vice versa. Great products delight people without ever getting in the way or distracting from their purpose.
The constraints we apply to our product design are intended to catalyze creativity, which is why we apply them to any new project.
HSDS is the Design System that helps us create a consistent and coherent experience for anyone who interacts with the Help Scout suite of products. It’s our way of sharing the latest visual styles across a fully distributed design team, and it serves as a jumping-off point for our creativity.
A design system is a set of rules, and rules and creativity aren't mutually exclusive. Rules can be broken.” Mina Markham
At its core, HSDS is a UI framework made from a number of interdependent Sketch Libraries (and accompanying documentation and example usage), React components, technical documentation and dev tools.
It is a contained design ecosystem that spans both design and front-end, which all engineers can implement to construct our UI. A single source of truth.
HSDS exists to serve the people using it — it can be bent, broken, overridden and extended to best serve the needs of our customers. No single person “owns” HSDS — it's a living, breathing system that constantly adapts as more people use it.
Our design principles act as creative guidelines — a voice-and-tone gut check for everyone who contributes to the product. They’re broad enough to apply to any part of the product, but specific enough that they only apply within the Help Scout ecosystem.
Give customers the ability to provide helpful, relevant, contextual and conversational support
Our platform should give users an additional dimension to their conversations, like a superpower that helps them fully understand what their customer is asking, and provide world-class responses.
ExampleBeacon timeline gives users a clear view of all past interactions a customer has had leading up to the current conversation.
Convey a human and organic energy by injecting the unexpected, delightful and casually weird
Our products provide an important service, so functionality is paramount — but we’re mindful that real people spend their entire working day interacting with our software. We want to reward, delight and support them when appropriate.
ExampleCustomers love our “Huzzah” images that appear when the conversation queue is cleared — it’s a small moment of joy at a point when we could have otherwise opted for function over form.
Varying levels of disclosed complexity are required to build a tool that is useful to both beginners and pro users.
Making advanced functionality less visible ensures the main pathways of our product are easier to understand and use for everyone.
ExampleReports are easy to use and understand, but they don’t include every permutation of the data that more advanced users may require. In this case, we’re comfortable limiting that additional information to availability via the API.
Relate features and interactions back to the humanity behind the tools — the people being supported, and the people providing that support
We are responsible for brokering real, human connections, and strive to be more than a “ticketing” system. Strengthening human connections means encouraging natural language, and avoiding canned responses, mismatched expectations and machine-led conversations.
ExampleAt a fundamental level, we don’t refer to tickets or send automated replies on behalf of customers — instead we opt for and encourage a more conversational tone to support
We strive for a seamless experience across mobile, tablet, and web.
Our platform should give users an additional dimension to their conversations, like a superpower that helps them to fully understand what their customer is asking, and the ability to provide world-class responses.
A seamless experience allows users to be efficient in undertaking tasks without having to learn new patterns, and lets us deliver a consistent Help Scout brand across platforms. We shouldn’t design for mobile in isolation. We should, however, be mindful of the best practices dictated by each platform and look for balance when exploring using native patterns.
AskHow does this relate across platforms?
Navigating the mobile apps should be clear and obvious.
It should not require explanation, and should communicate the current location of the app, while maintaining a consistency throughout to prevent disorientation.
AskAre where, what, and how understandable?
The mobile apps are, by their nature, designed for use on the go.
We should consider then the scenarios in which they could be used. A low contrast screen can be aesthetically pleasing indoors, but fail when taken outside.
The emergence of ever expanding phone sizes has resulted in screen areas that are becoming increasingly difficult to reach. Consider how the design is interacted with. Frequently used actions should exist in areas that do not require strain, while destructive, less commonly used actions can exist in harder to reach areas. Touch targets should be large enough for someone to interact with easily.
AskHas this been tested in different scenarios?
