Designing a focused workspace for document-heavy case review
Status: In progress — MVP build planned for 2027Confidential: Details have been anonymizedTo add · Dates
Overview
- Status
- Prototyping and testing the attorney review workflow; MVP build planned for 2027.
- My role
- Primary product designer responsible for research synthesis, journey mapping, workflow definition, interaction design, prototyping, and the product-specific design library
- Team
- Product manager, engineering team, design lead, and internal stakeholders
- Stakeholders
- Represented through the team: CEO, CTO, and attorney-management lead
- Users
- Attorneys, operations team members, and regional attorney managers
Attorneys were moving cases through a process spread across legacy software, manual entry, paperwork, and operational handoffs. The primary case tool was slow, inconsistent, and difficult to learn. New attorneys spent about a week onboarding to it and continued discovering unfamiliar behaviors after they were already using it.
I joined after the initial discovery workshops. My responsibility was to turn the research into a usable product direction: synthesize the findings, map the journeys for different tasks, define the requirements the interface needed to support, and design the interactions that would connect the process.
The work is still in progress. I am currently using low and mid-fidelity prototypes to test the attorney review workflow before the team commits to detailed visual design and implementation.
The problem
A slow, inconsistent case tool and a process split across software, paperwork, and handoffs made the task in front of an attorney hard to see.
Context
A tool that displays every available detail at once may be complete, but it can make the immediate task harder to see.
Attorneys need to get into a case, understand it quickly, do focused work, and leave.
The case filing process contains many documents, rules, and possible paths. Attorneys do not necessarily remain in the platform all day.
Model
To add · Statement
One sentence on the model behind the workspace: how a case, its documents, and the work on it fit together
To add · Text
The parts of the model as a short list, then how each screen answers the question that belongs to its level
How I got there
To add · Text
From workshop notes to product brief: how you synthesized the discovery findings and mapped the journeys for different tasks
Problem
The question
How might we give attorneys enough space to focus on the document or decision in front of them while keeping the rest of the case only a few intentional actions away?
What I inherited
To add · Text
The existing tools, workflow, and research you started from, and what the product-specific design library had to cover
Constraints
To add · Text
The constraints that shaped the design, such as AI support still waiting on requirements and technical feasibility
Process
To add · Statement
One line on the decisions made with the team
I did not optimize for the fewest possible clicks.
I focused on whether each action moved the attorney toward the task without forcing them to reorient. Supporting information could move out of the way during document review, but it needed to remain predictable and close enough to retrieve without breaking concentration.
To add · Decision cards
Three decisions made with the team, in one row: a short title, who decided (product, design, engineering, users), and a sentence or two each
Ideation
Designing for focus without removing context.
The working hypothesis is that a stable workspace that progressively reveals supporting information will help attorneys orient themselves faster than a dense interface that keeps all case information visible at once.
That is a hypothesis, not yet an outcome. The prototype review is testing whether hiding secondary information supports focus or removes context attorneys need.
Control
Adding AI without removing attorney responsibility.
The team is considering AI support for a few tasks.
- Ask questions about the current case
- Compare the case with past filings
- Retrieve relevant rules and regulations
- Autofill selected information
Whatever is built, the attorney stays responsible for the filing.
These are requirements, not confirmed features. I'm not presenting any of them as final until requirements and technical feasibility are confirmed.
Show where answers come from.
The design has to make the source of an answer or autofilled value visible, and keep retrieved facts apart from generated interpretation.
To add · Screenshot
AI source, review, and correction states
Attorneys review before anything is submitted.
They have to be able to review and edit information before submission, and the system must never imply it has completed legal review.
To add · Screenshot
Reviewing and editing an autofilled value before submission
There is a record.
The design has to preserve a record of what was suggested, changed, and submitted.
To add · Screenshot
The record of what was suggested, changed, and submitted
Failures
To add · Statement
One sentence on what happens when something goes wrong
The design also has to define what happens when sources conflict or no reliable answer is available.
To add · Text
The exception, empty, loading, and unavailable-data states, and where the design's help stops for now
Testing
To add · Statement
One sentence on what attorney reviews have shown so far and what you're learning
I'm testing the attorney review workflow with low and mid-fidelity prototypes.
To add · Text
Four findings, one sentence each, in two columns: what attorneys did and said, a decision an attorney review changed, and an engineering constraint that changed the design
I don’t have results on attorney speed, accuracy, or onboarding yet, so this page doesn’t claim any.
To add · What I learned
One or two sentences, in your own words, on what this project is teaching you
Takeaways
To add · Takeaways
Three lessons so far, each a short title and a sentence or two
What I would test next
To add · Text
What you'd test next, and why