Workfront was founded 17 years ago and although they have made efforts to improve their search experience, there have been technical limitations which 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.
- Decrease the number of duplicated (repeated) searches.
- Decrease the time it takes users to get to accurate results.
- Simplify the 120,000 filter system.
- Make a single search experience.
Our team was split into two teams. The first was over core functionality of the product and did mainly front-end work. The second team was the Search team that worked solely on the backend.
I was brought on to work on both teams. 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.
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.
Discovering the problem
After doing onsite usability tests, remote usability test, reviewing our customer NPS feedback and talking to our customer experience team we came up with a list of problems we needed to solve. The main problems with the current search experience were:
- Search indexing was not working correctly, returning incorrect results.
- Inherited permissions were confusing due to missing results.
- The relevancy of search results was extremely low.
- The search experience was slow.
- The entire search experience was too complex and needed to be simplified.
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.
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 thousand (7%) users perform repeated searches each month
- 78 thousand (2.6%) of users perform a third search each month
- 98% of users successfully find what they are looking for on the first page of results.
A problem that our teams had to deal with was that we were releasing our products at different times. Workfront was redesigning their 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 front-end experience through Alpha and Beta Preview to give the backend team time to release their Alpha. We would then combine the teams work for Beta Production so we would have time to test them together before our GA release.
Closed alpha preview
The changes we were releasing in Alpha were product-wide so it was decided to make the Alpha a closed preview. That meant that we selected a few customers with good standing and a few of our partners to first show the redesign. They could work inside the preview environment and it wouldn’t affect any of the work they did in their production environment.
Since Search was started much later than the rest of the product 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 get the initial search bar and newly introduced quick links out for the Alpha.
Because it was a closed Alpha, 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 these to be our top list of problems:
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 saying things like:
“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.”
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 individually.
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 ghost text and adding a search button so users could click to activate a search.
Object type filters narrow down search results significantly. Users often don’t know the entire name of an item but know what type of item it was. This allowed them to narrow down the results and search the few words they remembered to find an item.
This was done 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.
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 larger user base.
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.
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.
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.
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.
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 search to find those items. The New For Me list was also confusing for users since we found that it was typically empty.
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.
Quick links: We took out “New For Me” and brought Favorites to the global level. We also introduced a section for recent searches.
Why? New For Me was not bring value since it was typically empty so 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 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 have to type it out again.
Where we are now
As I am writing this we are getting towards the end of Beta Preview, which means we still have a lot to learn. As of right now, we are waiting for the Search’s backend team so we can merge the two experiences.
- (WIP) Decrease the number of duplicated (repeated) searches.
- (WIP) Decrease the time it takes users to get to accurate results.
- (Complete) Simplify the 120,000 filter system.
- (Complete) Make a single search experience.
We are continuing to research whether or not the time to value is worth it when we start adding more filters. While the time to value is greater right now compared to a typical dropdown with filters, we are working to validate/disprove our assumption that at scale typing to apply filters within a query will be the better experience.
While the response to the new filters has been great, there are still customers that need more advanced filtering. Once the new backend is up we will research with those customers to see if the changes have fixed their problems, if not, we will start to expand the types of filters that can be applied to search queries.
Users are still getting disoriented when a search is opened and takes over the full screen. We have tested animating the search screen over the current content to show it’s an overlay. This has been validated through research and is waiting to be developed.
What I learned
A feature with 120,000 options brings more confusion than it does value. Although it was scary to remove almost all the existing filters, doing extensive research led us to believe it was the right move. We now have an extremely simple filter system that we can expand and grow to only include filters that bring the most value to customers.
Customers are extremely reluctant to change and this can be hard to get passed when improving an experience. I have found that creating a baseline metric to test against is crucial to being successful in these situations. When both new and existing customers are performing better with this new solution you have data to back up the changes even if you get pushback from current customers.