Custom Properties
Help Scout
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.
There were two areas to address for this project:
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…
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
Using Looker, I was able to see that (about two months after launch) that almost 150 companies added 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 was exciting to see the adoption of this feature!
The next steps for this feature included 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).