An AI can extract 128 fields. A lawyer still has to check every one.

The interface showed the answers. Reviewers still had to find the evidence.

The existing screen had a contract on one side and extracted information on the other. There were labels, values, highlights, and technical AI scores. Some information appeared in more than one place.

It looked like the system had done a lot of work. But when someone needed to check an extracted value, they often had to search through the contract themselves.

Take a termination date. The AI might show a date in the panel. But the reviewer still needs to read the clause it came from. Is it the termination date or the notice period? Are there exceptions? Does another clause change its meaning?

Customer complaints and feedback from internal users pointed to the same issue. The screen wasn't helping enough with the actual review. We wanted to improve adoption and reduce manual effort, but making extraction faster wouldn't solve everything if checking the results remained difficult.

I began with a different question:

Reviewers relied on the original contract to check whether an extracted value was correct.

Legal reviewers don't judge an extracted value on its own. They read the surrounding text to understand what it means. A party name in the opening paragraph of an agreement may be straightforward. The same name appearing deep inside another clause might refer to something different. The location and context help them decide.

The old interface didn't support this particularly well. It presented the extracted value, but reviewers still had to work to connect it to the source. It also showed model scores that made sense to the AI team but weren't especially useful for making a legal decision.

During the project, I discussed the new design direction with legal subject-matter experts and had an opportunity to speak informally with members of IBM's legal team. These conversations, along with reviewing the existing experience, helped shape the direction.

I wanted three things to be easier:

What if we started with the document instead of the extracted data?

My first thought was to remove the right panel. Reviewers were already reading the document. Why make them move between the document and a separate list of fields?

I started exploring how the extracted information could live directly alongside the text. That led to three approaches.

Making the next step easier

Once someone accepts a value, the interface confirms the action, opens the next field, and moves the document to its source. I deliberately kept the confirmation visible before advancing. I wanted reviewers to see that their decision had been recorded.

The idea was to remove repeated searching and navigation, while leaving the actual judgment with the reviewer.

One value at a time worked for reviewing. Not for everything.

I tested the Figma prototype with approximately four to five participants, asking them to use the interface and speak aloud as they worked. I wanted to see how they moved between values, inspected the document, and responded to the one-card-at-a-time approach.

I had made that approach deliberate. During a detailed review, I wanted the current value and its evidence to be the main focus. After making a decision, the reviewer could move to the next item. Participants doing detailed review were comfortable with this.

Some participants, though, wanted to scan all the extracted information before reviewing individual values. They found the sequential interaction restrictive when they were simply trying to understand what was there.

I had been treating scanning and reviewing as if they were the same task. They weren't. So I kept the sequential flow for detailed review and added a separate preview where people could see extracted information together. The preview made it easier to look across the contract. The review cards remained the place for checking individual values. Both approaches became part of the shipped experience.

A review doesn't always finish in one sitting

A contract might contain 128 fields, or even more. During onboarding and detailed audits, someone might need to come back several times to finish the work. I introduced review progress so people could see what was complete and what still needed attention.

This wasn't something we had measured as a user problem. It was a design decision based on the size and nature of the task. The progress controls were included in the released product.

What happens when the AI points to the wrong place?

The new experience depended on connecting an extracted value to the right passage in the document. But that connection wasn't always reliable. Sometimes the system had incorrect document coordinates. A reviewer could select a value and land on the wrong passage, or somewhere without a useful highlight.

The PM wanted to retain repeated extracted text in the panel so the reviewer could still read it when document navigation failed. It was a reasonable concern. My worry was that we would end up designing the normal experience around something that was going wrong. We had already seen how duplicated information made the original interface harder to understand.

I proposed keeping document navigation as the primary experience and giving reviewers another way to retrieve the exact text when positioning failed. That way, the fallback was available when needed without taking over the interface. We eventually agreed on this as an interim direction while engineering worked on improving positioning.

It was a useful lesson in balancing what we wanted the experience to be with what the technology could reliably support at the time.

Letting people correct the AI

What if the AI found the wrong value? Or associated it with the wrong passage? The reviewer needed more than an Accept button.

The design supported accepting a correct value, editing an incorrect one, or re-tagging the source when the wrong text had been selected. I wanted correcting an AI result to feel like a normal part of reviewing, not like something had gone unusually wrong.

Keeping larger reviews manageable

With more extracted fields, finding a particular item also became harder. I compared visible filter chips with a grouped dropdown.

I chose the grouped approach because it worked better with larger sets of information.

I also paired colour with different shapes to help people distinguish metadata, clauses, obligations, and service levels without relying on colour alone.

These were smaller decisions, but they mattered in a tool people would use repeatedly.

The first phase shipped with assist bars, sequential review, preview, review-progress controls, source references, and actions to accept, edit, and re-tag extracted values.

The business wanted better adoption, less manual review effort, and more sustained use of the module. We didn't measure everything we should have. In particular, we didn't compare review completion time or verification accuracy before and after the redesign.

But we did have retention data from Heap. At month four, retention was 5.0% in an earlier cohort and 23.1% in a later cohort.

This project taught me a few things that I still use in my work.

The biggest thing I took away was simple. The AI finding an answer is only the beginning. Someone still has to decide whether it's right. That's the part I was designing for.