Herald
Herald is a collaborative repository for user feedback. It allows users to tag feedback from a variety of channels and then slice and dice it on a number of dimensions. As a co-founder, I led our design and frontend engineering efforts, encompassing everything from mocking up UIs in Figma, inventing a coherent design system on the fly, and building out components and the final app in React.
For the sake of this case study, I’m going to walk through the thought process for how we implemented advanced filtering on the data within Herald.
user pain points
For Herald, we decided we wanted the product to solve three specific problems for our target persona.
Lack of flexibility with analyzing feedback at scale—when users need flexibility, they should be able to figure out how to get it. By obfuscating this complexity, we can deliver a much cleaner experience. We wanted Herald to be flexible.
Overwhelming interfaces for feedback management—other products in this space were bloated with “loud” features that made it difficult to pick where to start. our UI needs to be welcoming, easy to get started with. Advanced features should be discoverable, but not omnipresent. We wanted Herald to be simple.
Friction in submitting and analyzing feedback—every Herald interaction, every workflow should be fast. Not just from a technical perspective, but especially from a UX perspective. We wanted Herald to be fast.
As users tag more and more pieces of feedback, Herald needed to provide tooling to make sense of it all. Important issues should be easily discoverable, as well as trends and notable changes. Our motto was to give users everything they need to track everything, but zoom in on the most important pieces of information. Designing the right UI is essential to making good on that promise.
design process
There were two key UX problems that needed to be solved here: the first, was how to handle filtering, and the second was about how to show the data and surface trends.
Filtering
The most conventional was to have a filtering menu, usually on the right or left-hand side that listed options and expanded when clicked. This is a pattern often employed by flight or hotel pickers.
Another option was to keep the filtering menu at the top and have it scroll to show all the filters. Clicking on a filter might open a dropdown menu that shows further options for that filter.
The last, and relatively new pattern was to use a “command menu” to reveal a large number of filters. This pattern was made popular with new apps like Superhuman and Linear, both of which place a similar emphasis on speed, like Herald intended.
Ultimately, I chose the command menu option because it scaled very well for the number of filters we wanted to provide. With the ability to easily search for filters and a keyboard shortcut to launch the menu, it also felt like the fastest and simplest option, immediately solving two of our key user problems. It allowed for almost unlimited flexibility, but only when users required it.
Showing Data
Based on Herald’s data model, there were two views we knew we needed to support right off the bat. The first was a list of individual pieces of feedback from users (“feedback view”), and the second was the same feedback grouped by topic (“topics view”).
But making Herald truly flexible requires infusing each of these views with better insights. We talked to our users to understand the key questions they wanted answered from Herald and we came up with summary cards that helped answer them.
What are newly emerging problems our customers are bringing up? For this, we added a card in the topics view that showed which topics got the most feedback over the last week as compared to the previous week. That percentage change helped us highlight the top 3 “movers” for each week.
What type of feedback are my most important customers giving me? Herald already provided the ability to define “personas” that represent important customers. We leveraged that to show cards in the feedback view that showed the percentage of feedback that was coming from those personas.
shipping & iterating
We shipped this initial version of the filtering menu to users and then iterated on it based on initial feedback from users. Some key improvements we made in the first couple weeks after release.
Jamming all the filters in this additional menu did lead to some discoverability issues. So we soon darked the color for the CTA to add filters.
We discovered that a pure text search on the filters was a challenge for usability. People would type “time” to find the filter feedback coming in the last week. To fix this, we added synonyms for each filter’s description to the search string.
We also think this pattern needs improvement for handling date-range filtering. Right now, because we wanted everything to be keyboard-friendly, we allow users to type a date range and have it appear as a filter option. This is not the most intuitive date filtering paradigm, and while it works well for users once they know it exists, it’s tough to educate new users about it.