40% Less Time Buried in Legal Documents
Intro
Melior is a legal SaaS platform designed to help legal teams analyze, review, and extract insights from large volumes of legal documents. As the product designer on this project, I worked with our design lead to analyze findings from her user interviews, translating the synthesis into concrete design concepts. I then presented those concepts directly to stakeholders to align on direction.
Impact
The redesigned experience transformed dashboards into actionable insight tools:
↑ 40%
Data Exploration
Increased interaction with filters and deeper analysis
↓
Time to Insight
Faster identification of relevant clauses and risks
Problem
From Document Overload to Insight Bottlenecks
"We don’t lack data - we lack speed and clarity in understanding it."
Legal teams were spending a disproportionate amount of time on manual document review: searching for clauses, scanning lengthy contracts, and repeatedly validating potential risks.
- 50–200+ documents per case
- 20–100+ pages per document
- 10–30+ hours of manual review per case
Key findings
Finding Where Legal Teams Lost Time
-
Search only matched exact document text, not legal concepts. The existing advanced search worked as a raw text query builder - reviewers had to guess the exact wording used in a document rather than search by clause type or legal category.
-
There was no way to filter by contract metadata. The results table only surfaced File Name, Type, and Status — reviewers couldn't filter or sort by party, effective date, or expiration date, even though those were the fields they needed most when triaging a stack of contracts.
-
Recurring searches had to be rebuilt from scratch every time. Because there was no way to save a query, reviewers who ran the same kind of check across new documents (e.g. checking for a specific clause type) had to reconstruct the same AND/OR text query manually each time.
Exploration
Searching Faster vs. Searching Differently
Once it was clear the bottleneck was navigation, not reading speed, two directions were considered for how to help reviewers find what they needed.
Solution
Designing for Exploration, Not Reading
We chose structured filtering over search-only improvements because the findings showed reviewers weren't struggling to phrase a search query, they were repeatedly hunting for the same known categories and building manual workarounds (checklists) to compensate. Filtering solved the actual repeated behavior directly, where better search would have only made the old workaround slightly faster.
Learnings
Designing Systems That Scale Beyond Humans
By analyzing how users interacted with complex information, a few clear patterns emerged that shaped both the structure and behavior of the final solution. 1. The real fix wasn't a smarter query, it was making matches visible in context The shipped Insights view highlights every match directly inside the document and lets reviewers step through them ("1 of 2," next/previous) instead of just filtering the file list. 2. Structured filtering and inline document review turned out to be two parts of the same problem, not two separate features 3. A phased rollout meant deciding which piece proved the concept first Since the full structured search system was too large for one release, an early priority was picking a slice, e.g. keyword search with inline highlighting, that was small enough to ship quickly but still demonstrated the core feature