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:
Time to Insight
Data Exploration
Problem
Associate lawyer
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
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
Once it was clear the bottleneck was navigation, not reading speed, two directions were considered for how to help reviewers find what they needed.
Improve free-text search (highlighting, better matching, jump-to-next). Keep the existing search-driven model, but make it more precise. Highlight matches inline, support jumping between hits, and reduce noise in results.
Structured filters (clause type) were added alongside search with autosuggestion option and the save search option for the frequent searches. The column filter were added, letting reviewers narrow results directly in the table. Navigation through the document insights was treated as a separate tab for enable users to have a better context.
Solution
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.
Showcasing the insights as a separate tab to reduce cognitive load and enable documents navigation
Learnings
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
Peau.ai and Prof.Dr.Steinkraus ›