Research and instrumentation for an AI workspace that generates legal filings

Users already had a working alternative, and there were two kinds of it.

A general-purpose assistant.

The specialist from the state prosecution office downloaded PDFs from the court system, processed them in the general-purpose AI assistant his institution licenses, and pasted the result into the office’s drafting system.

A specialized legal AI tool.

The head of the municipal attorney’s office used a competitor every day. So did attorneys in two of the other activated offices.

The product had to beat both on quality and speed, in a domain where an imprecise sentence can end up in a filed document. The second baseline set a higher bar: users who already had a legal AI tool compared the draft with that tool’s output, and not with their manual work.

I planned and moderated first-use sessions with think-aloud, a task script and the SUS questionnaire. The participant used the product first without guidance, so the questionnaire would not be biased, and the open conversation came after it. I classified findings with Nielsen’s severity scale, which combines frequency, impact and persistence, and adapted it for the domain: legal imprecision was raised to severity 3 because it can reach a filed document.

Session 1 · state prosecution office, 30 and 31 July

A specialist from a state prosecution office with advanced criminal-law practice, on his first use of the current version. 2h27 of recording, SUS 57.5: below the market reference of 68 and above 50.

What worked.

He found the case and created the study without help, went to the quick-action card and generated a summary without hesitation, and read parties, court, requests and case history from the home screen without opening the files. The value he named was integration: one environment for what today takes three systems.

Script hypotheses.

4 validated, 2 invalidated, 5 inconclusive. The two invalidated: he did not understand where the generated document went (about 8 minutes between generating and finding it the first time, and the difficulty came back twice), and the “detach” control was not understood without a verbal explanation, given twice. Three tasks were not executed and went to the next session.

The most severe finding.

Asked about the sentencing calculation, the AI stated a sentence of 3 years and 6 months and answered that the sentence was not in the accessible files. The sentence was in the imported files.

Content.

Good base with gaps at the decision points of criminal practice: sentencing, prescription, two defendants with different outcomes, appeal status. Two conceptual errors: an administrative-misconduct case treated as part of the criminal case, and a criminal chamber assigned to the district instead of the court.

Trust.

His first question, before any task, was whether the PDF he uploaded with his institutional credential would stay inside the environment.

“If it is telling me there is a conviction of 3 years and 6 months, it is because it has the sentence. It just did not show the document.”

There was no usability catastrophe. Of the six severity-3 findings, three sat in the AI core (generation errors, a chat question with no answer, the sentence the AI said it could not find), one was raised by the domain caveat and two were raised by persistence in the activity that dominates the user’s day: reading long texts. Traceability to the source was the most repeated request of the session, in four surfaces: summary events, case history, a split case and each item of the draft.

Session 2 · municipal attorney’s office, 3 August

The head of a municipal attorney’s office, a daily user of a specialized legal AI tool, on the previous version of the product. She requested the meeting herself. SUS 37.5.

Navigation caused no difficulty: she found her workspaces, opened cases, added and removed sources and used the available skills. The rejection was about content, and it held across every skill tested (response, motions, appeals): a draft with no legal citation although the law was in the imported files, the main argument turned into a different one, and her own template, added as a source, ignored. Her questions about the interface were about vocabulary: “source”, “context document” and “strategy” are not the words attorneys use.

“I imagine it could be much better than what we use today. As it stands, it falls well short.”

She also described why she trusts the tool she uses: before the draft, it shows the resources, searches, sources and strategy it is using, with links to the origin; it brings law and precedent without being asked; and it applies the office’s templates with an adherence level she chooses.

Reading the two sessions together

SUS scores are from different versions and user profiles, so I did not compare them. I placed the two sessions side by side on the same themes, without concluding a common cause:

• Source retrieval failed in both versions: a document present in the imported files did not reach the answer.
• Both participants asked to see the origin of the information before accepting the result.
• Both completed the flow without help, and both criticized the content.
• Interface terms needed translation in both sessions.
• The verdicts on content differed, and so did the participants’ reference: the user who already had a legal AI tool judged against it.

From the second meeting on, the session 1 participant worked as a domain expert for the team.

Cross-validation, 6 August

The specialist watched the video of session 2 and commented on each of its eight findings. I coded his answers with a convergence matrix (Farmer et al., 2006, with complementarity added) and separated what he observed, what he reported from his own experience and what was his opinion. The result: two findings confirmed, two confirmed with a caveat, one deepened into a requirement, three outside the meeting’s scope, and no divergence.

Confirmed and explained.

The draft stayed in the facts of the case and left out the legal framing the attorney needed. He named the missing doctrine.

Caveat of method.

He pointed out that the comparison in session 2 mixed two causes: the product received only a shortcut command, while the competitor received a prompt that explained the case. A test with and without context was designed in the session to separate prompt quality from tool capability.

Deepened.

Style personalization has three layers: the individual, the institution (writing manual and unwritten rules from internal review) and the type of office.

Participant-led comparison, 11 August

The specialist ran the same inquiry PDF in the product and in the general-purpose assistant, with an identical, deliberately short prompt (“draft the indictment for the case”), and read both against the indictment actually filed in the case.

Content.

“Both brought satisfactory answers.” The product included a request for minimum compensation to the victim, supported by the asset appraisal in the files. The general-purpose assistant and the filed indictment both left it out. It was the first record in the program of the tool going beyond the human-written filing on one item.

Gaps.

The product listed 11 witnesses against a legal limit of 8 and stated a qualifying circumstance without narrating how it happened. Both tools anticipated evidence that belongs to a later stage.

Speed and stability.

The assistant was faster, shorter and more objective. The product was slower and sometimes did not answer: “the Studio sometimes has this problem, and then it makes the work impossible.” A demonstration to a stakeholder had failed for the same reason.

Two outcomes went to the team. The method stayed for the program: compare each generation with the document actually filed. The product direction was consolidated in the session: build fixed legal rules into the system by stage and document type (witness limit, narration of qualifying circumstances, compensation request when there is an appraisal) instead of depending on a detailed prompt from the user. A hypothesis fell in the same session: a legal-search aggregator’s API is not an official source of case law.

A/B test of a beta generation mode

Same case and same prompt. The beta mode produced a more correct indictment (one offense, no spurious second count, office formatting, pages analyzed and sources listed) in about 3 minutes. The participant said the output could be copied and filed. Model unavailability stalled the test for about 8 minutes.

After the third session with the specialist I reclassified the findings at program level, with the activations as evidence of frequency. Two findings went to severity 4, “fix before launch”: AI instability (chat with no answer, generation errors, answers that stop halfway; four occurrences with the specialist and convergent reports from three activated offices) and the sentence the AI said it did not have. Requests and positives went to a Kano classification, marked as inferential until validated with the users’ paired questionnaire. Basic requirements (traceability, data scope, generation status, file naming, keyboard editing, autonomous case import) formed a separate queue. The rest went to an impact by effort matrix with silent voting (NN/g), where UX and product vote impact and engineering votes effort.

By the third session the team had shipped part of the queue: generation status and error states in the quick actions, direct access to the generated document, search performance analysis, mapped error feedback, a revised files tab and document naming, all scheduled for verification with the specialist on 13 August.

The qualitative sessions and the soft-launch data pointed at the same cause. Engineering confirmed a bottleneck in the document pipeline, the PM framed slowness and missing feedback as the blocker to engagement, a fix was released, and new client activations were paused while it was reviewed.

I built the evidence base that escalated performance to product leadership and into the development pipeline as an urgent priority.

A technical assessment of latency, and a new test with an active user at one of the client offices once performance improves substantially.

• Nielsen, J. Severity Ratings for Usability Problems (opens in new tab). NN/g.
• Nielsen, J. First Rule of Usability? Don’t Listen to Users (opens in new tab). NN/g, 2001.
• Farmer, T. et al. (2006). Developing and implementing a triangulation protocol for qualitative health research. Qualitative Health Research, 16(3).
• Lincoln, Y. S. and Guba, E. G. (1985). Naturalistic Inquiry. Sage.
• Kano, N. et al. (1984). Attractive quality and must-be quality. Journal of the Japanese Society for Quality Control, 14(2).