Help Scout Properties
Objective
To be more useful to our support customers, our team wanted to add a system to allow them to add properties for their contacts. Knowing information like a customer’s plan tier, permission level, or user ID is often key to solving issues a customer might be experiencing.
Role
I was the sole designer for the discovery and design phase of this project, working with a product manager and engineering team. We had a few changes in the product manager role during the lifespan of this project, and during the implementation phase, I moved to a different team within Help Scout (to optimize for team member time zones), so another designer oversaw the implementation, consulting with me on any questions that arose that needed my input.
When thinking about the problem, I saw a few pieces to be addressed:
Property management
Creating, editing, and display preferences for properties
Properties appearing in the sidebar
How the properties appear alongside a conversation
I started with some sketching some ideas for the management piece, because this page didn’t exist yet, and I felt it had the most potential for exploration.
Sketch ideas for the Properties Management page
My initial instinct was to design this in a way that visually mimicked the sidebar, showing the user how the values would ultimately be represented. I was also very concerned with how this would scale. Space is very limited in the Help Scout conversation sidebar. If a company adds three properties, no big deal. But if they add 100 properties, then what? That’s where I had the idea that there should be some kind of visibility toggle for properties.
Here I was exploring a threshold idea. Anything dragged above the “Hidden” line would be visible in the sidebar, and anything below wouldn’t.
Here are some examples that more visually call back to the conversation sidebar…
API vs Manual Editing
As part of this project, we wanted to allow for auto-population of properties via API, in addition to manual editing of properties. This initially posed some issues for us regarding edit levels. Which changes take priority in the event that something is being overwritten? This got us stuck in the weeds for a bit.
When thinking about the source of a property though, it seemed important to know when that property was last updated, and via what source.
Some early examples of properties in the customer sidebar, with and without source attribution.
Properties Management
Ultimately, where I landed on the management screen was an accordion menu layout that would house all the properties and allow for copying the property ID (used with APIs), and editing the property’s name.
A property’s data type can’t be changed once it’s been created, but the dropdown property type can have items added, removed, or reordered at any time.
Initially I wanted to account for reordering here, however it made more sense to allow per-user reordering since different roles would likely find different properties valuable. Below is a prototype for adding properties from the main list, as well showing the ability to reorder via drag and drop.
Customer Profile
There was also the need to add properties to the customer profile. There was already a pattern in place for editable fields within a profile, so I extended that pattern to include properties as well.
There were some other ideas I tried before reaching this conclusion, including a tab between default and custom properties, but ultimately we went with this option because we were taking the stance that all properties were customer properties, whether they were default or created custom by the company. Separating them made sense to us because of how the properties originated, but to a support user, it might not make sense to separate them seemingly arbitrarily.
Post Launch
A note: Since launching this, I’ve switched teams with another designer (to help with timezone overlap), so he’ll be finishing out the next stages of this project, but I still keep up to date on what’s going on.
Using Looker, we were able to see that (about two months after launch), we’ve had almost 150 companies add at least one custom property, with about 50% of those property types being text. We could also see that a large number of properties were made to store “User ID” (or its equivalent). It’s exciting to see the adoption of this feature, and at the time I’m writing this, the team is still pending a full retrospective of this project.
The next steps for this feature include allowing for conditions to trigger throughout the Help Scout app based on different property values (ie, If a customer’s plan type = “Pro”, assign to a particular support specialist).
Additionally, there’s an effort to make per-user preferences for property visibility, as some properties are auto populated for tracking or automation reasons, and aren’t helpful to support pros who are responding to conversations.
Additional concepts
Adding properties to Help Scout is useful for 1:1 support conversations, but to get the most out of a feature like this, it needs to be 1) customizable for the individual user, and 2) present throughout the product. Someone in sales may care a lot about properties than someone in customer care, and to the second point, using a feature to automatically run workflows on customer messages meeting certain criteria would be a natural expectation.
The video below is a small prototype I did for being able to customize the properties in a user’s sidebar view.