LITIGATION ANALYTICS

BACKGROUND

We began the Litigation Analytics product in response to customer and market desires for a business development style tool. From the start, we had a vague, loose sense of what the tool would need to provide users based on internal stakeholder requirements.

We soon learned that attorneys needed a way to quickly gather up-to-date metrics that could help them better advise clients, predict case outcomes, inform their litigation strategy and drum up new business.

Although we had a general sense of the direction of the tool, it was essential to gather feedback from prospective users to get at the crux of their needs and expectations. It was also important to talk to people that used similar products already on the market and how we could provide value where they were lacking.

MY ROLE

Data Visualization. User Research. Prototyping.

The Litigation Analytics tool was a joint design effort between myself and two of my colleagues: Tim Reeder and Brittany Moore. I took on much of the data visualization pieces and many of the user research sessions as well as adding interactivity to the wireframes for research and demo purposes.

The team also consisted of a product owner, scrum master, 7 developers, and various stakeholders throughout the organization.

IDENTIFYING HOW AND WHAT DATA USERS NEED

Our data team collects hundreds of thousands of data points about various entities that practitioners care about when conducting research for their litigation or business development processes. The question we sought to answer was what data did the users find most helpful, and how to display that data to be most effective for their needs.

Through market research, customer calls and preliminary discussions with users, we discovered that they were most interested in viewing analytics on judges, companies, law firms and attorneys. They want to know how those entities faired in court, what practice areas they were most effective in, and their historical data on their litigation practices. Furthermore, it was important to be able to compare these entities against each other using a variety of pivot points.

So, we set out to provide them with a tool that could do just that.

EARLY ITERATIONS OF THE ANALYTICS

We began the process of presenting the data in various ways to see what resonated most with users.

Usability Testing

Next, it was time to begin to early-stage user research sessions. Our research process consisted of the following:
- 3 usability tests every 3-week sprint
- Each round of tests completed in one day
- Project team observes the tests
- Debrief as a team afterwards
- Adjust designs, prioritize work for the next sprint based on results

BEGINNING THE ITERATIVE PROCESS

We learned there were far better ways to organize the information on the screen, and some important content and functionality that users wanted to see.

1) We need more context at the top of the page, and needed to find a new way to navigate between type-specific results.

2) Users needed to see suggested content and have it be easily accessible.

3) Users wanted to be able to open and read the documents while remaining in the tool’s interface.

We made changes to the prototype, and tested the next iteration (left).

FINE-TUNING the end result

After considerable user testing, any many rounds of both large and small changes to the prototype, and high levels of user satisfaction and ease-of-use during final testing rounds, we finally felt the designs were at a place where we could develop and release the MVP.

Major changes exhibited in the final prototype (left):

1) Showing extracts, or snippets, from the documents in the result list.

2) Clearly bucketed navigation for easier access to specific content.

3) Document viewer integrated into product interface.

4) Suggested content, with clear explanations as to why it’s being suggested.

5) Identify content that requires further investigation and explanations as to why.

6) A system for favoriting items for later use.