BRIEF ANALYZER

Brief Analyzer Report

Litigating can be a complex, tedious and time-consuming process. Brief Analyzer was developed as a workflow tool for attorneys to streamline the tasks of researching and responding to arguments made by the opposing counsel.

 

BACKGROUND

As the market for legal research products shifts towards more workflow-based tools, BloombergLaw wanted to get ahead of the curve and create a tool that litigators had been clamoring for.

Brief Analyzer provides litigators with a tool to simplify the process of researching and drafting counter-arguments to the opposing counsel at the start of a new court case. The product ingests an opposing counsels brief and pulls out all the citations mentioned, as well as suggesting related content for further research. Normally, this is a manual process that requires printing and highlighting as well as hefty, in-depth research.

The ultimate goal was to reduce response time and effort by digitizing the complex manual process and using artificial intelligence and machine learning to suggest highly relevant content.

MY ROLE

Innovation. Research strategy. Iteration.

I was the dedicated user experience resource on the team, which consisted of a product owner, scrum master and 8 developers. I provided the team with wireframes and prototypes as well as conducting the user research.

With only one loosely similar competitor product on the market, it was important to do significant research in order to provide unparalleled value to users and set our product apart.

We began the research process with a condensed, 2-day design sprint which generated many promising ideas and worthwhile insight from which to get started.

 

STARTING WITH A ROUGH CONCEPT

After the design sprint generated some ideas worth further exploration, it was time to do some early-stage wireframes to get in front of users.

In an early prototype, we used tabs to separate content pulled from the brief into type-specific buckets, had a standard left-aligned filter panel and right-aligned results list. The earliest stage of the prototype did not include suggested content.

 

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 iterations of both large- and small-scale changes to the prototype, consistent and positive usability feedback and customer satisfaction, we finally felt the designs were at a place where we could develop and release the MVP. This would lead to an initial BETA test for additional changes and enhancements before a production releaase.

Major changes exhibited in the final prototype (left):

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

2) Clear navigation extracted from uploaded documents and content areas.

3) Interactive document viewer integrated into product interface.

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

5) Interactive tour and help areas to onboard first-time users.

6) A way to search for related content, using criteria and parameters extracted from the uploaded brief document.