RelativityOne - dtSearch (Processing)
Relativity's dtSearch engine provides advanced search functionality such as proximity, stemming, and fuzzy searches across any field type. It also supports the use of Boolean operators and custom noise word lists as well as the basic searching features available in keyword searches. These explorations looked into how we could add this functionality to the Processing Files page.
Team: Nick Manoogian, Michelle Wu, Danny Frank, Namit Dua, Robert Simpson, Emily Williams
Role: Lead UX Designer
Tools: Figma, Figjam
The Problem
Today, dtSearch functionality only exists on the review side of Relativity. Through multiple client requests, we began to explore the idea of adding in this functionality to the Processing side of Relativity. Since this is an existing feature, we needed to make sure that it would be built following the same paradigm as it exists in review. We also knew of a limited scope based on estimates to build this out fully, so we needed to brainstorm how this feature could look pared down but still following paradigm.
The Process
Discovery - User Research, Opposite Thinking
Synthesis - Data Synthesis, Opportunity Ideation
Design - User Flow, Wireframes, Hi-fi Designs, Prototype
*If we had decided to pursue this feature we would have started testing and iterations.
Discovery & Synthesis
We started out our discovery with client calls to better understand how this feature could benefit our users by being integrated into processing. Not surprisingly, almost every user that we were able to interview found that there would be some benefit to them. The benefits were primarily focused in the areas of publishing less data and saving time. Working as a triad, we established a list of questions that would help us better understand our users point of view when using the dtSearch feature or if they were not familiar with it, their basic understanding of how it works.
The extended triad also performed an activity called opposite thinking. This tool helps us challenge our assumptions about the problem and possible solutions and come up with non-obvious ideas. This was critical because we knew that we would not be able to build the entire feature for an MVP. Looking at our notes from our user interviews we were able to narrow down the parts of the feature that were deemed necessary by our users.
Focusing on the question “How might we implement dtSearch in processing so users can further cull down data prior to publishing?”, we filled out our own assumptions of how this might be possible and shared as a group. Recognizing that some assumptions belonged in a similar bucket, we grouped them together before formulating our opposite/alternative ideas. This part requires us to challenge our assumptions by 10x-ing (inflating the assumption to the extreme), flipping the assumption, or alternating the assumption for a slightly different version. After, we move to ideation but we are only looking at our opposites/alternatives. The ideas that are formulated in this part are truly remarkable because they stem from a place that on the outside, is not obvious. Taking the time to retrospect with the team and sorting the ideas into actionable areas to begin designing.
Design
Once we had several routes to explore, we began to create visuals to further explain these ideas. Starting with a model of how the feature looks already, we then took out the parts that we knew were not in scope for the project. This left a skeleton like page that needed layout attention. Through multiple iterations we were able to form a dtSearch lite version which even included possible feature enhancements for the full fledge version on the review side.
Conclusion
A change in priority determined that the need to create this feature was no longer needed, something that is normal when working in tech. What we were able to create provided a foundation to be revisited if the need is seen again for this feature. We also were able to share our work across the platform and provide future backlog improvements on the review side.