top of page

Visual file searches
for lawyers

We created a product designed to empower lawyers to effortlessly locate all the digital files needed for their cases, regardless of their storage locations, all through a single, intuitive interface.

TYPE

Standalone web app

MARKET

Orgs with Internal Legal Depts

LENGTH

8 months

YEAR

2023

Team

1 Senior UX Designer

Me, as a UX Designer

2 UXR Consultants

1 Junior UX Design

1 Product Manager

1 Dir. of Engineering

3 Backend Engineers

1 QA Engineer

2 Frontend Engineers

Skills

Problem Definition

Data Analysis

Prototyping

Usability Testing

Design Iterations

User Interface Design

Coordination with Developers

Design Presentation

A Story for Context

Let's imagine Suzie, who heads the legal department of a US-based company. She faces a legal issue and needs evidence to support her employer's position. She asks all involved employees to send her relevant information, including physical and digital files, emails, and chat conversations.

Problems

  • A lot of employees may need to take part in that process, or IT may take charge. It takes time and may require many follow-ups.

​

  • Searching all the data locations (OneDrive, Box, SharePoint) separately is repetitive.

​

  • Built-in search tools in those locations are all different in terms of performance and functionality.

​

  • Certain information must be shared as it's legally required, and therefore can't be missed.

​

  • Legal professionals don’t have a lot of time to learn how to use new tools.

Goals

  • We wanted to understand how legal professionals start a new case, to create a search flow that felt natural to them.

 

  • The interface would be easy to use without training. The tool’s searching mechanics would also need to be transparent and trustworthy enough that the process to get the results could be explained with confidence in the courtroom.

 

  • Legal professionals would be able to take ownership of the search process instead of relying on IT or other employees.

​

  • The product would work on its own, but also integrate seamlessly with 2 additional products within the company's portfolio.

Process

A research interview conducted over teams.

Research

During the research phase, I helped guide consultants on the problem space and the persona. 25+ interviews were conducted in a month.

 

I added to to that material all the information collected on searching during previous interviews stored in central repository in Dovetail.

Insights


From the collated qualitative data we learned that:

​

  • 5 types of legal cases were the most common. They could all be started with the simple questions of who, where, when, and why. 

​

  • What matters about the case is often discovered while searching.

​

  • Knowing about volume and the number of files in the search results mattered as much as the results themselves. Too large results or too many results meant that search parameters could be renegotiated with a judge.

The questionnaire with emphasis on the questions who, where, what, when.
Step 1 of the form, the questionnaire.
Step 2 of the form, the visualizations.
Step 2 of the form, the table.

Design

The design process engaged the expertise of three UX designers, myself included, to ensure a comprehensive approach.

​

We initiated the project with the concept of a step-by-step form.

The 3 steps

Initially, the form would guide users through a basic questionnaire, using fundamental inquiries such as who, where, when, and what as a foundational framework to establish criteria.


In the subsequent step, users would encounter visualizations enabling them to refine their criteria based on insights gained from exploring the dataset and case facts.


The final step would present users with a table for previewing the results, facilitating quality assurance, and offering opportunities for further refinement.

Search result metrics

To provide users with real-time feedback, the number of files resulting from the search and their corresponding volume would be prominently displayed in the header.

​

These metrics would dynamically update as users adjust their criteria, ensuring transparency and informed decision-making throughout the process.

Part of the UI for the project discussed. This is the page header, and emphasis is placed on a card displaying the number of files and the corresponding volume resulting from a search query.
The dialog that appears when copying a search.

Testing

I tested the interface and flow with users to gradually iterating the design into a high-fidelity prototype.

While testing, I learned that it is preferable to iterate on a search criteria in a new search rather than continue working from the first search. We needed to leave a trail.

Duplication functionality

I added a duplication functionality to make it easy to repeat a search criteria while leaving the initial one intact. I also added a note section in each search so that the reasons for these changes could be documented.

The copy functionality explained with annotations in a Figma file.
A bird's eye view of the Figma file delivered to the dev team with all the annotation.

Handoff & first implementation

I annotated the prototype by describing each component and its interactions. Everything was organized by ticket to make it easier for developers to find their way in the Figma file. Links to the Figma frame were added to the Jira tickets as well. I participated in daily standups to explain the tickets as they were assigned and resolve problems. 

We created the first version of the tool to present at an industry conference to get feedback and test with users.

bottom of page