top of page

Simplifying Search

Overview

Workfront was founded 17 years ago and although they have made efforts to improve their search experience, there have been technical limitations that continue to cause problems for customers. A search team was created to build a brand new experience for both the front and backend. This case study is focused on how our team simplified search to improve the entire experience.

*Company names, images, and all other information that is private to Workfront have been excluded from this case study.

Business objectives

Rebuild Workfront's Search experience to help increase adoption by decreasing the time it takes to navigate Workfront. Increased adoption will result in getting Workfront closer to the goal of 600,000 weekly active logins. 

Goal

1. Decrease the number of repeated search queries.

2. Decrease the time it takes users to get accurate results.

3. Simplify the 120,000 filters that are currently given to filter search results.

4. Remove advanced search and combine it with the classic search to make a single search experience.

 Our team

Our team was split into two parts, the first was over the core functionality of the product and did mainly frontend work. The second team worked on improving reliability and relevancy from the backend.

Team.png

My role

I was initially asked to discover the problems we were trying to solve with this new solution. Once we found the problems to solve, I led the design and research for solutions to the front-end.

 

I worked closely with the Product Manager to research and define requirements. I also worked closely with the Senior Engineers on the team to brainstorm and create mock-ups to help define technical requirements.

Outcome

Our team was able to create a simplified search experience that was both feasible as well as validated by customers. Towards the launch of our Alpha priorities changed within the company and the Search's backend team was taken to work on authentication. This project is currently on hold until they are brought back on. 

Where we started

Before this project began there were two separate search experiences. The first experience was the classic search experience that searched within a subset of our data. The second was called advanced search and this searched our entire database.

Classic Search
Advanced Search

Classic Search (Top), Advanced Search (Bottom)

Discovering the problem

After doing onsite usability tests, remote usability tests, reviewing our customer NPS feedback and talking to our customer experience team we came up with a list of problems we needed to solve.

It's important to note that Search had been a problem for so long that we had customers going out of their way to give feedback. Some customers had search issues that had been going on for multiple years.

Discovery research

Discovery research session

Findings

1. Search indexing was not working correctly, returning incorrect results.

​2. Inherited permissions were confusing due to missing results.

​3. The relevancy of search results was extremely low.

4. The search experience was slow.

5. The search experience was complex and overwhelming, it needed to be simplified.

"I opened a ticket with your support team 2 years ago and every time they fix the problem it breaks a few weeks later."

The key problem that the front-end team was asked to solve was simplifying the search experience. This meant creating an experience that was easier to understand, filters that could be easily applied and removed, and figuring out how people searched within our system so we could start to predict relevant results.

Baseline Metrics

To find base metrics we used Pendo to find click funnels going in/out of search and the number of times features are used. We combined this with data extracted from our database that help us get an idea of users to click path to determine base metrics. This is what we found:

  • 3 million searches are performed each month

  • 9 thousand advanced searches are performed each month

  • 124,000 (7%) of searches performed each month are repeated search queries.

  • 78,000 (2.6%) searches a month are a users third try to find the right result.

Timeline

A problem that our teams had to deal with was that we were releasing our products at different times. Workfront was redesigning its entire application and needed a new design for search. The backend team was just starting to build everything from scratch and would not meet the deadline for the Alpha release.

We ended up deciding to design the frontend experience through Alpha and Beta Preview to give the backend team time to release their Alpha. We would then combine the team’s work for Beta Production so we would have time to test them together before our GA release.

Release timeline

Release timeline

Alpha

Workfront's Alpha was a closed preview. What that meant was that we selected a few customers with good standing and a few of our partners to first show the new designs. They could work inside the preview environment and it wouldn’t affect any of the work they did in their production environment.

The Search team was started much later than the rest of the teams so we had to focus on getting an MVP out for the initial launch. This meant that important things were missing, like filters. Our goal was to release the new search bar as well as introduce quick-links for the Alpha.

Alpha - 1.0.png

Search - MVP

MVP problems

Our MVP release was a closed Alpha so getting feedback was extremely easy. We had all customer feedback coming directly to our team. This meant that we could arrange for follow up user-research to get the root of our customers problems. After getting around 30 pieces of feedback and running 15 usability tests we found the best areas to focus on improving for the next release.

Filters: This is something we expected going into Alpha since the job users were trying to do could not be completed. Customers have hundreds of thousands of items to dig through, the backend was still broken, and we had no filters, so we knew it was going be a pain-point that needed to be solved quickly after launch.

What we decided to do during this time is to read the feedback and see which filters were the most requested. This allowed us to start learning what our users needed so we could remove the filters that were not being used.

Fullscreen: When a user clicked the search icon, search appeared as a full-screen overlay with a slightly transparent background. Users found this to be disorienting.

"Did I lose everything I was working on? Where is my navigation?"

Accessibility: The color of the text did not have enough contrast and the search bar did not have an accessible focus state.

Quick links: The lists expanded up to 50 items. This meant that users were scrolling down the page to find a recent item they had worked on. A quote from one of our Alpha customers:

"There is way too much scrolling. I don't find it faster than searching for the item."

Solving the problem

Throughout the entire Alpha, we designed and tested solutions to the problems we were finding. We used it as an exploratory phase so we could be confident going into Beta Preview. To make our efforts more focused we made micro-changes to the designed and tested each change individually.

Research - Sketches.png

Team ideation - Crazy 8's and whiteboarding sessions

V2 

The first thing we added to the product was the ability to search by object type (project, task, issue, etc.). This was the number one requested item and was something that we could build fairly simply since it lived in the existing product.

We also made a few small adjustments to the UI such as bringing the magnifying glass in context with the placeholder text and adding a search button so users could click to activate a search.

Beta - 1.png

Alpha - V2

Why we made these changes

One of the main reasons we added the filters we did is because object type filters narrow down search results significantly. Users also didn't often know the entire name of an item but know what type of item it is. This allowed users to narrow down the results and search the few words they remembered to find an item.

We adjusted the magnifying glass icon because it allowed users to tab into filters, select a filter, then tab to the search button to submit the search. It created a fast way for power users to search, as well as making it more accessible.

Beta

During the Beta, we allowed all customers to opt-in to the new experience. This was still done in a preview environment, so it would not affect their production environment, but it allowed us to see a general impression from a much larger user base.

Beta Feedback

When we launched into Beta around 10x the number of customers joined the New Experience. This meant that we had a lot more feedback coming in through a variety of sources. 

Our team handled this by reading through feedback during our standups then following up with group ideation sessions where we focused on the main problems we were hearing about.

Beta Updates

1. Filters: To speed up the filtering process, even more, we found that creating a way for users to apply them without using a mouse was the fastest and most efficient way when creating a search query. When a user types a forward slash the list of object type filters was shown and they could continue to type to filter down the list and apply the filter.

2. Fullscreen: Search now overlayed the current content but did not hide the navigation. This allowed users to see where they were in the app and made the experience less disorienting for them.

3. Accessibility: A focus state was added to match the other components in the design system. All text was darkened (other than ghost text) to pass WCAG 2.1 AA standards.

4. Quick links: Lists now truncated when an object type had more than 5 items. This allowed users to expand the lists they found important while reducing the noise.

Search - Beta.png

Beta - V1

Still not right

Filters: While users liked the interaction of applying filters, it was not as discoverable as we wanted. This concept of using a forward slash to open a dropdown was a brand new interaction that we were adding to Workfront and was something that needed to be taught.

Quick links: Users wanted favorites to be more accessible. They did not like clicking into the search to find those items. The New For Me list was also confusing for users since we found that it was typically empty.

 Sketches - Beta.png

More ideation and team whiteboarding

How we solved the problem

Filters: We moved the text from inside the search bar to under it and added a “add a filter” clickable link that automatically typed a forward slash for the user and opened up the filter dropdown list.

Why? The text originally was inside the search bar and would disappear once users started typing. Moving it below allowed users to be able to read it after searching for something.

The “add a filter” link allowed an easy way for users to learn that typing a forward slash would open the filter dropdown. Because this interaction was new to our users told them how to type to add a filter and gave them a way to learn how it worked.

Add Filter.gif

Add filters without using a mouse

Quick links: We took out “New For Me” and brought Favorites to the global level. We also introduced a section for recent searches.

Why? We found that New For Me was not bringing value becuase users did not have enough new things to populate it. We decided to remove it until we could develop a better way to populate the list.

Favorites at the global level allowed users a quick way to get to their favorites as well as add their current page to favorites. Because there was not a consistent way to add all pages as favorites throughout the app, bringing this to the global level added functionality that it would not have when in Search.

Recent searches came from feedback that users were searching for the same thing multiple times, and selecting different items. They wanted a way to quickly see their recent searches so they didn’t to type the same query multiple times a day.

Search - Beta V2.png

Beta - V2

Fast forward to today

As I am writing this we are going into General Availability. Unfortunately, our backend team was taken off Search to work on an authentication service Workfront was trying to finish. What this meant for our team was that we were told to put this project on hold and reskin the classic search experience until we could finish the backend and launch the entire experience together. 

Where we are with the initial goals:

1. (WIP) Decrease the number of repeated search queries.

2. (WIP) Decrease the time it takes users to get to accurate results.

3. (Complete) Simplify the 120,000 option search filters.

4. (Complete) Make a single search experience.

What I learned

This entire project has been a huge learning experience for me. I increased my understanding of how data is stored and how we can use user information to increase their search relevancy. I got a better understanding of how a business must make difficult decisions even if it means putting a project on hold. Lastly, I learned how to work along-side multiple teams and use the design process to get buy-in from stakeholders, as well as evangelize the work we did. 

"I learned how to work along-side multiple teams and use the design process to get buy-in from stakeholders."

Design System: Icon Tutorial

The process our team went through while trying to empower our design team to contribute their own icons to our Design System.

bottom of page