LegalEasy

Product Design Case Study · 2024

Making legal language human again

82% of people sign contracts they don't fully understand. We designed LegalEasy — an AI-powered app that translates legal jargon into plain language, in seconds.

My role

Product Designer

Team

4 designers

Timeline

3 weeks · Bootcamp

Methods

Design Thinking · UX Research · Prototyping

Tools

Figma · Maze · Miro


01 — The Problem

Legal language excludes the people it's meant to protect

Every day, citizens sign contracts, receive fines, open bank accounts, and navigate bureaucracy using documents written in a language designed for lawyers — not people. The result? They sign without understanding, feel ashamed to ask, and turn to Google, which makes things worse.

We set out to understand the real depth of this problem before designing anything.

82%

of people have signed a contract without fully understanding it

100+

people surveyed across ages and education levels

2

core barriers: document length and complex terminology

#1

workaround was Google — which increased confusion, not clarity

"One of the biggest problems is when clients use Google to clarify doubts. Google creates more problems than solutions. They don't know how to search properly."

— Legal professional, interview participant

02 — Research

We listened before we designed

Our research combined a quantitative survey of over 100 participants with qualitative interviews of both everyday users and legal professionals. This dual perspective revealed not just what users struggled with, but why the problem persisted.

Method 01

Desk research & benchmarking

We mapped existing solutions and identified their shared weakness: they explain terms in isolation, without context or consequence for the user.

Method 02

Survey — 100+ participants

Mixed demographics across Spain. We focused on frequency of document encounters, comprehension difficulties, and help-seeking behaviour.

Method 03

User interviews

Two scripts: one for everyday users, one for legal professionals. This revealed the systemic nature of the problem from both sides.

Method 04

Affinity mapping

We clustered all findings into themes. Three categories emerged: plain language, tools, and accessible education.

Shame as a barrier

Users didn't ask for help not because they didn't need it — but because they felt embarrassed. Invisible in the survey data.

Google makes it worse

The most common workaround actively increased confusion. Users drew wrong conclusions. Our biggest opportunity.

Context beats translation

Users didn't just need definitions — they needed to understand what a term meant for them, in their situation.

Length is a UX problem

Document length alone caused abandonment. Users skipped critical sections not out of laziness, but because they were overwhelmed.

"Most people don't ask questions out of shame or laziness when reading documents."

— Key insight from user interviews

03 — The Solution

One core flow. No noise.

After an extensive ideation phase — gamification, mascots, video pills, Q&A chatbots — we made a deliberate product decision: focus on one core flow and do it exceptionally well.

Upload a document → AI detects complexity → Plain language output with context-aware explanations and risk alerts.

We used a MoSCoW framework to ruthlessly prioritise and avoid the scope creep that plagues most bootcamp projects.

Must have
Document upload (PDF / photo)
AI term detection
Plain language explanation
Document summary
Risk / alert highlighting
Should have
Filter by document type
Basic / expert mode
Document history
Share results
Q&A per document
Won't have (v1)
Gamification
Video pills
Virtual mascot
Social features
Legal advice

Key design decisions

Decision 01

Highlights over modals

Inline term highlighting with expandable cards kept users in context, reducing cognitive load compared to modal-based definitions.

Decision 02

Risk alerts as first-class feature

Surfacing harmful clauses shifted the product from "dictionary" to "legal companion." The insight that elevated the entire concept.

Decision 03

Summary before terms

Leading with a plain-language summary gave users immediate value and reduced anxiety before engaging with detailed explanations.

Decision 04

AI humanisation

Testing showed users responded better when explanations used "you" and specific examples. We tuned prompts to always personalise the voice.


04 — Testing & Iteration

We tested early and learned fast

We ran usability tests with low-fidelity wireframes in Maze before investing in high-fidelity design. Two flows were tested: uploading a document and navigating the glossary.

Success

Upload task: 84% success rate

Users found the upload flow intuitive. Average completion time was 30 seconds — within our target range.

Problem identified

Glossary: 50%+ failure rate

Users couldn't reliably find saved documents via the glossary. The navigation needed a full structural rethink.

Insight

AI felt cold and impersonal

Early outputs read like encyclopaedia entries. Users wanted to feel spoken to — not lectured. We rewrote the AI prompt voice entirely.

Validation

High perceived usefulness

Despite UX friction, users rated the concept 4–5/5 for usefulness. The problem was real; execution needed refinement.

Based on testing, we restructured the navigation, separated the document library from the glossary, and rewrote AI output prompts to use direct, personal language with practical examples.


05 — What I Learned

Product thinking starts before the first sketch

Key takeaways

01

Focus is a product decision, not a design decision

The strongest move we made was cutting features. A product that does one thing exceptionally beats a feature list every time. The MoSCoW process was more valuable than any wireframe.

02

Emotional barriers are invisible in surveys

The shame of not understanding legal language only emerged through qualitative interviews. Quantitative data told us what — conversations told us why. Both are non-negotiable.

03

Test the concept, not the polish

Our most valuable feedback came from low-fidelity wireframes. Testing early saved weeks of rework and revealed a critical navigation flaw before we invested in visual design.

04

AI is a design material, not just a technology

How we prompted the AI shaped the entire user experience. Voice, tone, and practical examples were product design choices — not engineering ones.

What's next

With current AI capabilities, LegalEasy could be built as a real product today. The next iteration would include live AI analysis, Q&A per document, document type–specific guidance, and a freemium model targeting individuals and small businesses.

The legal tech market remains underserved for everyday citizens — not just corporations. That's the gap LegalEasy was designed to fill.