Search experience — SandraVilarrubias

Making the search experience for eDiscovery an easy thing

Context overview

eDiscovery is the electronic method of identifying communications used for legal evidences on legal cases. The search is one of the most important pillars of the product but the search that was implemented solution was presenting some doubts, misunderstandings and lack of trust on customers.

Task

My goal was to redesign the search feature and create an intuitive and solid experience that reduce the amount of problems the users were facing that would and reduce customer churn.

Analysis

Before starting to design I wanted to know what was going wrong with the search we had implemented.

I did a quantitative and a qualitative analysis and from that I defined the user journey from the basic search, advanced search and I defined what would be the ideal.

Identified problems

Users don’t trust on the search because they get different results depending on the search they use when entering the same query
2 different searches, basic search and advanced search
2 different pages for search results outcomes
Advanced search was not intuitive
User needs to verify the query entered
Results are provided on different places and associated actions are not the same

User journey

3 user journeys to place all feedback on the corresponding part of the search workflow.
Trigger a search > Define query > Get results > Additional actions

“Lost time spent: Modifying search (parameter labels are not always intuitive, so multiple iterations are often required)”

“Building a query can be time consuming and frustrating as functionality is not always reliable.”

“Advanced search UI is “very clunky and unintuitive to use”

Pre-ideation

Before jumping into a design process a deep analysis about syntax was needed to be able to make a single search experience.

Ideation

I started by doing a few drafts to organize concepts and how to structure the information. After that I started to build wireframes that I refined progressively till I got the final version I felt that covers all user needs.

Use cases identification

When finally I did with a structure that was easy to use and covered all user needs, I addressed all use cases identified. From each scenario I considered happy/unhappy scenarios. Here a list of some of the main use cases:

As a user I want to be able to read and distinguish all elements that composes my search query
As an experienced user I want to create a search query easily
As a user I want to be able to configure my searchable fields
As an unexperienced user I want to create a search query easily
As a user I want to be able to re-run a search query I’ve previously saved
As a user I want to be able to add custodians to my search (one or many)
As a user I want to be notified when there’s an error on my query / the query cannot be processed by whatever

I defined carefully the experience for all of them and taking into account all problems mentioned before.

Increasing visibility as one of the most relevant diferentiators

It was essential to increase the visibility of the operators and conditionals that users were using, so when reviewing the query they would have a better understanding of all the parts that make it up and if there are possible errors.

To do so, I decided to assign colors to each type of content and to facilitate access to all the search fields offered by the product.

Looking for a seamless experience

Basic search has been created for those users who have knowledge of how to build a search based on operators that look for information in the metadata, while the search builder is for a much less experienced user, who wants to learn and we offer him the possibility to discover all those parameters with which we are able to offer valuable results.