2021 Case Study

Compose by Casetext

A screenshot of the current release of the Compose brief-drafting product

Project goal

Ship a new, web-based document editor for laywers that dramatically reduces the time it takes them to write a high-quality legal brief.

Project phases

Conceptual development, prototyping and user research.
V1 release and follow-up user research.
Additional releases.

Outcome to date

76%

Reduction in time to write a brief. This is insanely good!

Background

Casetext is on a mission to make the law accessible and affordable to all. The law impacts our lives in deep, vast and important ways, and the majority of Americans can’t afford meaningful legal representation when they need it. This limits access to justice in the most direct terms. Casetext dove into solving this important challenge by building faster, more affordable, more effective legal research tools. Making more more effective and more affordable research tools is one of the most impactful ways to expand access to justice. Casetext reduces the financial overhead required by law firms to pay for legal research services and allows attorneys to take on clients who have less money while still making a profit from those clients. The formula is working. Since leading the design of the first A.I. legal research tool for the law and lauching it’s legal research platform three years ago, Casetext has grown to over 8,500 paying customers. Those customers serve a huge client base and has helped ensure that many more people have access to justice.

Still, there is much work to be done. About a year ago Casetext’s leadership decided to bet the company's future on a totally new product that we believe will reduce time it takes for an attorney to successfully represent their client by an order of magnitude. This new product is called Compose and it launched publicly in 2021.

Background information Example brief Example legal brief
ROI reportCompose is a brief drafting assistant for attorneys. Legal briefs are documents written by attorneys to persuade the courts that their clients should win. Legal briefs are the core pillar of every litigation and every legal battle. Unfortunately, briefs are expensive to produce. This expense comes primarily from the time it takes expensive attorneys to write them. Briefs take a long time to write because each brief must be written largely from scratch and each element of a brief must be copiously researched using a basic text search engine to ensure the brief is supported by legal precedent. Compose dramatically reduces the time it takes an attorney to write a high quality brief - on average by over 76% (source). That level of improvement hasn't been seen for decades and rivals the impact of online research on the law. Similarly, Compose can increase the quality of a legal brief dramatically, even when being used by the best attorneys. The overall consequence is to dramatically reduce the cost to the client for effective legal representation and therefore broaden access to justice.

Let's dive in.

This case study

In this case study I'll cover the main phases of the development of this product. Each phase will cover a problem or series of problems and I'll describe how I chose to solve them.

My role

I worked both as an individual contributor and as the Director of Design overseeing other designers on this project. Specifically, I was responsible for driving the high-level product strategy and overseeing the research and development being done by ICs who reported to me.

Phase One

Prototyping and conceptualization

The problem:
How might we validate that this product concept is worth building?

Solution:
In order to validate this concept at the highest level I built a rough prototype for Compose in less than a week. We immediately started testing it with attorneys to gauge their reaction. Specifically, we were looking to understand what part of an attorneys workflow Compose would impact, how it would impact it, and whether attorneys could articulate in their own words how Compose would make their brief-drafting processes faster or better. If they could understand the product and articulate how it would improve their current process in a meaningful way, it was worth continuing to explore. We iterated on the prototype over a one month period and tested it with over 100 attorneys. The research and prototyping was primarily done by myself, a lead designer on my team, and our CEO.

The screenshots below include some of the earliest prototypes we showed to attorneys.

← Scroll →

Brief setup

Compose workspace and arguments list

Reviewing legal standards to your selected argument

Return to the arguments list to continue adding more arguments and legal standards

Prototype hypotheses

My initial prototypes relied on one core product hypothesis and two UX hypotheses.

Core product hypothesis: By providing a list of pre-assembled and high-quality legal arguments, legal standards, and supporting case law for a brief, attorneys could eliminate the time it takes to find, research and support these elements and thereby reduce the overall time it takes to complete a brief.
UX hypothesis: By mapping the overall product flow to the IRAC legal framework (more on that soon) attorneys are more likely to understand what Compose is and how it works
UX hypothesis: By mirroring the visual and typographic styles of a typical legal brief in portions of Compose attorneys are more likely to understand what Compose is and what the output of the product is.

Core product rational

The IRAC legal framework This framework is core to the product and these prototypes. IRAC stands for Issue, Rule, Analysis, Conclusion. Every law student is taught to include each of those elements - in that order - in their legal briefs. The Issue in IRAC is essentially what legal argument the lawyer is making. The Rule is the piece of law that the attorney must include to show what specific law has been broken. Compose is focused on automation the first two portions of the IRAC framework - the portions that technology can help to automate. It's useful to understand that the prototypes were primarily oriented around two core inventions present in Compose. The first is called the Arguments List. "Legal Arguments" is a more specific term for the Issues part of the IRAC legal framework (see a fuller description to the right). Having a list of arguments available for any specific kind of brief, we believed, would dramatically reduce the time it takes to write a brief because a large proportion of an attorney's time is searching for well-supported legal arguments across millions of pages of case law and legal briefs. This old way of doing this was facilitated by Casetext's legal research engine - our core product for the past three years. In this new world of Compose, a user simply selects the arguments they wanted to include in their brief. After selecting an argument and adding it to your brief (the right pane in the Compose interface) you are then shown Supporting Legal Standards for the argument you just added. A Legal Standard is again a more specific term for the Rules in IRAC. And again we invented a new core feature that would automate the tedious work involved in finding, articulating and supporting legal standard - an essential part of the IRAC framework. We believed that having a list of supporting Legal Standards for each legal argument would be an incredible time-saver given that attorneys often spend a ton of time looking for legal standards.

Outcome of user research

Our two UX hypotheses were validated by my early prototypes. Attorneys described how the presence of elements of the IRAC framework were familiar with them in our product flow and helped them understand what the product did. Attorneys also immediately understood that the output of Compose was a legal brief, which helped orient them and understand the value of the tool.

Similarly, our core product hypothesis was validated. Attorneys articulated that the arguments list and legal standards we included in Compose would save them a large percentage of the time it took to create a motion.

Issues uncovered in user research

Some issues did come up, though, including:

The initial flow - even though it included the right ingredients - needed to be simpler. Attorneys were getting lost and couldn't find their way back to where they started, for example. Similarly, some users were confused by the formatting of the arguments list.
Lawyers are generally familiar with the terminology we used, but there is no universally accepted definition of many of the legal terms we used. This required us to think about clearer ways to train and onboard attorneys using our product for the first time, and how to simplify the terminology.

Phase Two

V1 release and follow-up user research

The problem:
How might we release a customer-ready application that firms will buy?

Solution:
Simplify the UI and UX and double-down on the core ingredients.

Simplified argument list and overall UI

Simplified Legal Standards. No need to "save and close" to return to the Arguments List, eliminating some common confusion.

My approach to leading the design of the first public release of Compose was based on two strategies. First, focus on flows, not screens. This allows us to maintain focus on the core problem of writing a brief and eliminating the repative, time-intensive tasks involved, and not fixate on what the layout looks like, for example. Second, keep things simple so that we could learn more quickly. The rationale here was based on the knowledge that learning quickly and improving the Compose product after getting it to real customers would be what makes us successful. Keeping our design scope small would allow us to ship more quickly, learn more quickly, and ultimately be a competitive advantage for any future copycats.

Design decisions made for launch

The primary changes made to V1 based on the prototype were focused on addressing the feedback we heard and saw in the prototype. We focused on simplifying the flows and UI. For example, based on the feedback from our prototype testers, I knew that the UI elements on the page that indicated how to enter into the products main flow - adding arguments and standards - needed to be even simpler. I believed that the concept of "edit and add '' present in the early prototypes didn't do anything to help them understand what they were looking at or how it worked - it just added complexity and confusion. Similarly, making the user click to expand each section of the argument list with a button was just silly UX (I'm sure this is what attorneys testing the prototypes thought at least). Our solution was to take out all the elements of the argument list that didn't absolutely need to be there.

→

Additionally, to make it clearer that the right section of the page was not part of the main flow we made it look and feel even more like a piece of paper in the same way a legal motion would be.

V1 user research

The first version of Compose was launched and garnered significant attention. More importantly, it started to garner sales from the most distinguished law firms in the country. The lawyers at these firms are most sophisticated attorneys, which lend credibility to the idea that this kind of automation helps the attorneys do real and important work. This also validated the core product promise.

We also learned a lot by talking to the attorneys at these firms about their experiences. My top takeaways where:

Attorneys' workflows are much more chaotic and flexible than I anticipated.
Attorneys were sometimes focused only on a small portion of a brief - a task that was delegated by a larger team that was all working on one brief together. This meant that prioritizing the flow of writing a full brief in one sitting wasn't mapping entirely to the workflow of these practicing attorneys.
Attorneys who wanted to use our Parallel Search tool found themselves going through the process of setting up a motion (which includes selecting the motion type, the jurisdiction, naming the parties, and a few other steps) in Compose just to do a search, which was frustrating.
Attorneys who wanted to use the legal arguments in Compose as a checklist to make sure they'd covered all the important topics in their brief also had to go through the entire setup process without getting any value for setting up a brief.

We did iterate on some of these issues between V1 and V2, which can be seen on our current public website.

Phase Three

V2 release

The problem:
How might we address the primary design issues present in the first version of the app? After talking with dozens of attorneys and seeing how they used the first public release of Compose, it became clear that the primary design issues present in the application were:

Attorneys often went through a lengthy setup process for each motion to access features in the tool that the setup was not relevant to
Attorneys worked in ways that were much more flexible and fluid that we anticipated, and wanted to be able to use Compose to, for example, address one legal issue rather than sitting down to write a full brief in it

Solution:
I went back to the drawing board. I asked one member of my team to find out what a more flexible approach to the tool might be given the feedback we were receiving. Based on her explorations and testing, we decided to remove the unnecessary rigidity in the text-editor portion of the interface and replace it with a very basic out-of-the-box text editor. We also found ways to eliminate the setup process entirely in many cases.

The screenshots below include the changes to the main UI.

The new workspace elimites the motion setup and puts more ephasis on the content attorneys love.

The simpler editor gives attorney a more flexible ways to use the tool.

A simpler editor

The V1 of Compose that we shipped to customers included a text editor that was designed to mimic working in Microsoft Word, but customized to the formatting requirements of a read-to-file legal brief. When you clicked an argument to add it to your brief, for example, we created a block in the brief that automatically indented it to the right level of the argument tree and added dynamic numbering to each argument block you added. One consequence of this approach was that attorneys could only work in one block at a time due to technical constraints. The design thinking for our v1 document editor was also based on the assumption that attorneys would want to sit down and write a full brief in Compose and that formatting the text of their work with the same rules as they would use in the final version of their briefs would be useful to attorneys. This was partially right, but proved to be mostly wrong. We quickly learned after talking to attorneys that they mostly didn't want a highly formatted document at this phase of their project. They noted that sometimes they do sit down and write the final draft of a brief - this is what we focused on in our early user testing - but more often they are exploring a brief and tackling smaller legal issues before they dive into writing the final brief. They wanted to not only quickly jump into Compose to solve a discrete task without going through a setup process that wouldn't help them finish that task, but they also wanted to use it more like a scratchpad than a full editor. They wanted to take parts of an argument and pull it apart and move it around. They wanted freedom from the - as they described it - brittle formatting we forced on them.

→

Left: The highly formatted text editor in v1 with text blocks, indentations, etc.
Right: The upcoming release with a faster, more flexible, and more bare-bones editor.

The solution one member of my team came up with was to dramatically simplify our editor and make it more like a scratchpad. We removed all the custom formatting flows that were making the editor brittle. Now, you could edit the text freely. Deleting an argument just deleting the text rather than using a custom delete button we had in the V1 release, for example. This was a controversial change inside the company, but we brought the receipts from user research and built support for the change inside the company.

This new design allowed us to make accessing the content in Compose much easier and gave us more space to show that content, and it allowed the editor to be much more flexible and address a larger percentage of an attorneys working time. It also helped us get into the attorney's workflow earlier in their process, which meant they would use Compose more often.

A more flexible workspace

The V1 release of Compose also focused on a workflow that included the following steps: 1. Select a brief-type, 2. select a jurisdiction, 3. include the names of your parties, 4. select whether you are the party bringing the suit (movant or non-movant). Attorneys told us a few important things that made us want to rethink this flow.

First, they said they often were working on two potential briefs for the same client and wanted to explore each option before commiting. This was difficult to do in our V1 release because it meant creating two motions and reviewing them separately. In reality, they wanted to be able to explore the arguments from the different motions side by side and include them in their working space alongside one another. In other words, they wanted to be able to quickly switch between different argument lists in the same workspace. That wasn't possible in the V1 design.

Additionally, as mentioned earlier, they didn't want to go through our setup flow just to see an argument list. Our solution to these issues was to make our workspace more flexible. Instead of the original five steps required to use the primary Compose workflow, we boiled it down to one. 1. Select a brief-type. Everything else was optional. If you wanted to see legal standards specific to your jurisdiction, you could set a jurisdiction (JX) in that portion of the UI. You didn't need to include the names of the parties in your suit. In this world, you could quickly change argument lists at any time.

Lastly, by making the editor more like a scratchpad, we also had more room to make the content in Compose - what attorneys said they loved about it - more accessible and easier to navigate. Rather than clicking in and out of arguments and legal standards, you could see them side by side. This made it much easier to review an argument before committing to adding it to your brief, and made it much easier to navigate.

A screenshot of the upcoming release of the Compose brief-drafting product with the flexible workspace and simplified editor

Thank you for reading

I am incredibly proud of the work my team and I did to ship and improve this product so quickly. It will be a transformational tool in law and we've already seen its impact at some of the largest law firms in the country. I'm particularly proud of how quickly we were able to iterate on the product and react to the core needs of our customers. There were also many, many small iterations and improvements to the product that were not included here.

- Saha Hammari