In a survey, I asked Discord users about their experiences with search features in the app. I wanted to get a sense of how people were using the tools available and how they felt about them.

All respondents reported daily Discord use and membership of large, active servers (>100 members, daily activity). Overall satisfaction was generally high.

With lukewarm results, it seemed necessary to explore different pain points, until I took a closer look at the results and discovered that more than half of the respondents were unaware of Discord’s search filters.

I wanted to really dig into what a user would encounter when searching for a specific message, from any possible starting point. I created a detailed wireflow and heuristic evaluation of the current search journey. Below is a short summary of the main issues.

Based on the survey results, the most popular entry point into search was typing in a keyword. In the current flow, as soon as a user starts typing, the options for search filters disappear with no clear way to return to them. This was a key usability issue.

Based on the survey results indicating even seasoned users’ misunderstanding of search filters, I choose to focus on “power users” - respondents who reported daily Discord usage, who are members of large (>100 members), active servers.

The areas that present the greatest opportunities in the current journey are just before and during a search query. Because users tend to prioritize speed, there is very little time allocated to learning a new system while actively searching. Similarly, when finding a message takes too long, users become frustrated (ex: a keyword yielding many pages of results).

The two core elements in this search journey seemed to be
1. a highly specific end target (usually a particular message)
2. minimal time to complete the task

The functional needs of the user were used to evaluate potential solutions during ideation. Below is a summary of the solutions most likely to solve for the main issues (signifiers, grouping, and blank screens).

While Discord’s design system isn’t publicly available, they have a downloadable brand guide with color, font, and copy standards. This info was the basis for recreating a set of components for the screens which would be used in prototyping (pulled from the wireflows above).

Certain UI elements like bottom cards, dropdowns, and various buttons were used frequently across screens, but not present in the search flow screens. To maintain design consistency, these were referenced as well.

With the main pain points in mind (lack of signifiers, no visual grouping of filters, and filters disappearing), I worked to make quick prototypes of a few brainstormed solutions.

One initial idea was to overhaul the search flow by providing users with results as they searched, rather than directing them to a separate page.

While this flow would theoretically reduce search time by saving users a step, it would reduce the ability to quickly select auto-filled results while typing and would require a redesign of the way filters were displayed. There were also additional technical considerations like load times/lag with the vast amount of messages many servers contend with.

I focused instead on building out wireframes for the way filters could be displayed to users during search.

A few designs were brought into high-fidelity using the components I had created, to get a better sense of scale with text and iconography.

Based on quick usability testing with Discord users and an evaluation of the JTBD’s functional needs, it was determined that minimal changes to the search flow were the most successful. This was unsurprising, given earlier findings about users prioritizing speed when searching.

The addition of help text and a CTA to the blank search screens, plus tag-style filters were prototyped and tested. A summary of the changes made can be seen below.

I set up prototypes and used Maze to collect feedback from Discord users. In order to validate my designs, I wanted to understand the following:

With a relatively small group of 10, the results seemed to indicate an overall positive response to the changes and relative ease of completion.

Despite the original labels used for search, a significant portion of testers found them confusing, indicating the need for further testing and refinement.

One major constraint was the technical limitations for prototyping. I couldn't give testers an accurate typing experience with the resources available, and that made the feature less satisfying and understandable for users.

Additionally, not having access to real user data was a roadblock in both discovery research and testing. Many of the conclusions drawn were from the initial survey, which had limitations on the breadth of search usage. I would love to dig into real user data to see how search is actually being utilized in the app.

I would have also loved to see some A/B testing results comparing the same tasks before and after the changes were made. Some users didn’t understand the help text and CTA addition to previously blank and impassible pages, so I’d like to see how folks approached that with Discord’s current search flow.

In my deep dive into Discord’s search, I realized how broad and complex of a feature it could be. Trying to capture every individual use case and search style was not realistic in this project scope. With this case study, I feel like I scratched the very surface of issues and search paths.