
Redesigning privacy, for users
How a dating app's dense legal document became an interactive experience people could actually navigate
Client
Dating app platform
Website
Context
Making a privacy policy people actually read
A dating app's privacy policy was long, dense, and almost never read in full. I led the UX and UI redesign that turned it into an interactive, navigable document, without touching legal accuracy or losing GDPR compliance.


Problem to Solve
Nobody was reading it, and that was a real risk
Users couldn't find the specific information relevant to them without scrolling through pages of unstructured legal text. That had two effects: people disengaged before reaching anything useful, and most accepted the policy without understanding what they'd actually agreed to.
The business goal was narrower than "make it nicer to read." It was to raise real comprehension and findability for a user base that varied widely in age and region, while keeping every clause legally defensible under GDPR.
Success meant someone could land on the page with one question in mind and leave with an answer, not a headache.
Constraints & iteration
What made this harder than a content refresh
Legal accuracy was non-negotiable. Every structural change needed legal sign-off before it shipped, which set the real pace of iteration.
Content ownership was split. Legal owned the plain-language rewrite of the clauses themselves. My job was how that content got organized, navigated, and read, not the wording.
The audience was wide and uneven. Some users skim for one answer, some read end to end, some have no patience for legal language at all. The design had to work for all three without over-indexing on one.
No bespoke build budget. Interaction patterns had to work within the platform's existing page templates rather than a fully custom build.
Decisions & trade-offs
Three calls that shaped the final design
01 | One scrolling page, or split by topic | |
Explored | Tested | Chose |
|---|---|---|
Splitting the policy into separate pages per topic, closer to a native app flow. | Five users, three find-a-clause tasks, both versions. | A single page with a sticky table of contents. |
Why: most users fell back on browser search (Cmd/Ctrl+F) when they got stuck, and that only works on one continuous page.
02 | Expanded sections, or collapsed accordions | |
Explored | Tested | Chose |
|---|---|---|
Collapsing each section by default to shorten the page. | Task completion plus a short confidence check-in. | Sections expanded by default. |
Why: collapsing shortened the page, but more people believed a topic wasn't covered at all. A longer page was the smaller risk.
03 | Text labels, or icon shortcuts, for navigation | |
Explored | Tested | Chose |
|---|---|---|
Icon shortcuts per topic in the table of contents, for faster scanning. | Cold comprehension, icon shown with no label. | Text-based topic labels, grouped by theme. |
Why: icons scanned faster but were ambiguous for abstract topics like data retention or third-party sharing. Clarity won over speed.
How it came together
From research to shipped interface
Legal's plain-language rewrite and the structural redesign ran in parallel rather than one waiting on the other. Testing surfaced one real problem along the way, the first version collapsed every section by default, and that one finding sent the design back for a rework before anything shipped.

End-to-end flow
From landing on the page to finding an answer

Outcomes
Impact
Found faster | In usability testing, people located the clause they needed through the new table of contents, instead of scrolling the full original document. |
Fewer gaps in understanding | Switching to expanded-by-default sections closed the comprehension gap the collapsed version created, people stopped assuming a topic simply wasn't covered. |
Shipped, fully compliant | Every structural change cleared legal review. The policy stayed fully GDPR-compliant throughout, nothing was simplified at the cost of accuracy. |
Live in production | Shipped and live, replacing the original static policy page on the platform. |
Adopted beyond this project | The legal team, used to reviewing static text changes, adapted to reviewing structure and navigation alongside wording, and reused the same table-of-contents pattern as a reference for other policy work afterward. |
