Buzz Usborne


About Help Scout

Help Scout is a customer support platform — a single place where phone, email and chat communication is directed. Much like Zendesk or Intercom. The key difference is that Help Scout prioritizes human-centered conversations and aims to facilitate world-class support. Our customers are drawn to the platform because they’re not “bots”, and their customers aren’t “tickets”.

The Brief Direct link

In it’s simplest form, Help Scout is a shared inbox of incoming customer communication — a single “queue” of requests, where teams work from oldest to newest. This works great until teams hit a certain scale — at which point customers need automation to help split their inbox into smaller chunks. This automation is the responsibility of an existing feature called Workflows.

Workflows help teams make sense of the noise when there are too many incoming requests to manually triage. They’re powerful, but technical and complicated to use. As an example, a couple of people within a support team might be responsible for dealing with postage — so they might use a Workflow like this:

Workflow Query

1 WHEN subject contains
2{ “deliveryortracking” }
3 assignTeam: Fulfilment
4 Then crash_the_database(); 

Lots of teams do this, but due to the volume of complicated (and expensive) queries, the existing architecture wasn’t able to keep up with demand — making the feature slow and problematic. So to unblock our future roadmap, and continue to support the types of customers who operate at this scale — Workflows required a total architectural overhaul.

My task was to consider whether there was a way to encourage better use of Workflows, and help customers achieve a similar level of automation without the need for overly-complex queries.

Research Direct link

With the help of our data analysts, we found that 80% of existing workflows were used to simply direct incoming conversations to a folder. In other words, millions of expensive database queries were being used to do something very basic.

I figured that if we could make that task easier, then we could free-up Workflows for the heavier lifting and more technical use-cases. So my PM and I ran a bunch of customer interviews — what we call “VOC” (Voice of the Customer) — to talk through how customers use Workflows today, to get a sense of their business and what they're trying to achieve. I spoke mostly to the customers who represented the sort of audiences we wanted to serve with this feature.

The research was pretty conclusive. Essentially it showed that whilst teams used Workflows — they were scary and difficult to understand. We also learned a lot about how our customers triage their inbox, underpinning what we already knew… every company works in a unique way.

Some of the core themes

During the research phase I also documented some basic design guidelines that I felt would be important later down the line. These emergent design principles were formed alongside some UX basics, like the importance of natural language in complex UI and the expectation of real-time results.

Emergent design principles

Defining the Problem Direct link

From the research I felt strongly that a separate, new feature was necessary — and whilst I didn’t technically need “permission” to go in that direction, I felt like it was worthwhile to take my engineering team on the journey.

So I packaged up the research findings into some cute illustrations centered around how teams need tools to order, segment and organize their work depending on the nature and size of their organization.

A poorly-illustrated analogy

Whilst this might have been a (gross) oversimplification, the engineering team were really receptive — and were able to get excited about the opportunity to build a better and more useful customer solution.

Discovery Direct link

As with all projects at Help Scout, this one was collaborative and remote-first — the notable difference here was that I wanted to involve the entire design team in the early stage concepts. Creating a new feature requires many minds.

I pulled together some quick inspiration, a discussion guide and a bunch of wireframes — and we designed a few different creative approaches together in realtime.

A totally real screenshot I took in anticipation of this case study

There was a lot of time saved by discussing concepts together early on in the process — amongst other benefits it gave a shared context and made subsequent feedback more relevant. Plus it’s always fun to use Figma’s collaboration tools.

Sketching makes a big part of my process in the early stages too (as does coffee). For me pen and paper is an opportunity to get ideas out of my head without getting bogged down with pixels and design systems. More UI sketches here

Early sketches

Then of course the sketches become wireframes, which were shared amongst the team at regular intervals — and occasionally user tested when I came to a point where a hypothesis was formed, or there was a point of indecision.

Early wireframes

Being in an entirely different hemisphere to my team, I leaned a lot on asynchronous communication to explain my progress and ideas — Loom being one of my most frequently-used tools. Videos accompanied by Dropbox Paper is still — for me — the best way to share daily updates and communicate progress with the team.

A discovery phase for a project like this is long, requires lots of concepts that go nowhere, and a decent amount of user-testing to validate or disprove some assumptions. This project was no different, but the journey highlighted some key desires that I wanted from the final designs:

  1. Requiring customers to write database queries doesn’t scale.
  2. Organizing conversations should happen where the conversations do.
  3. Any team size should find value in this.
  4. Automation should be fun and empowering.
Some creative directions

Visual Design Direct link

Say hello to Views. I ended up creating a WYSIWYG builder which is designed to overlay the existing folders users are already familiar with. It’s fun to use, restrictive in the options it provides, yet still services +90% use-cases.

I created prototypes like the one above (play with the demo) to get a feel for the interactions, which were also useful for user-testing. Functional prototypes like this uncovered a lot of usability issues that might not have surfaced until launch.

This project was also an opportunity to have some fun with interactions, animations and create re-usable components that could inject a bit more life into the product outside of this feature. The popover styles and depth from these designs have since made their way to other new features.

Early wireframes
Early wireframes

Status Direct link

The big full release is set for mid–2022.

In the meantime… the research for this project helped identify other smaller areas of opportunity which didn’t require so much engineering effort. One popular addition we recently launched was a better way to assign data to customers, an improvement I designed using a lot of the patterns and interactions I created for Views.

The upcoming addition of Views has also been a forcing function for rebuilding older parts of the app, like the global navigation. Since that was on the cards, I took it as an opportunity to make the sidebar fully accessible and responsive — that’s live now too.

Early wireframes