UX CASE STUDY · LEGAL TECH · May to July 2026
People sign contracts they don't understand. This one reads it back, with the law attached.
ClauseGuard checks rental and employment contracts against BC and Ontario law. Every flagged clause carries the statute, what it could cost you in dollars, and one sentence you can send to push back. A UX case study that became a working product.
Solo build. I kept a dated decision log from day one and let the product follow it: 17 ADR-style decisions, one six-pillar audit, one aesthetic pass. The audience is renters and new hires under time pressure, looking at a document the other side wrote.
The Problem vs. The Solution
Most people in Canada sign rental and employment contracts without knowing which clauses hold up under provincial law. Lawyers are expensive. Government resources exist, but none of them connect to the document in front of you. The other side wrote it, you have a day to sign it, and no way to tell which parts would survive a dispute.
Signing blind
The document works on you after you sign it, and nothing flags the parts that would never hold up.
The document becomes the interface
Pick your province and contract type. ClauseGuard reads the contract clause by clause and puts the analysis on the document itself.
The Impact
ClauseGuard is a design-led MVP, so the numbers are about integrity, not revenue. These are the three I check before calling it done. The public demo runs on four example contracts, and every screen says educational tool, not legal advice.
Key Design Decisions
Five calls from the 17-file log shaped the product most. Each is a dated, ADR-style decision with the rejected options written down.
Demo mode originally shipped two sample datasets. Ask for BC employment or Ontario rental and you silently got the wrong one, header and all. The first patch added a banner explaining the swap. The real fix was authoring the two missing datasets and routing on the actual selection.
A disclosure next to a lie is still a lie, just a labeled one. The banner, the mismatch branch, and their CSS are all gone.
The input screen had an editable paste box. Nothing you typed was ever read; demo mode dispatches on the two dropdowns. The box is read-only now and previews the exact sample your selection loads. The one action that works, Analyze This Example, is the biggest element on the page.
Selection is the input, so the UI says so. The fake agency of a dead textbox is worse than no textbox.
The results screen used to treat the contract as disposable: analyze it, then never show it again. Now the Analysis tab is a split pane. The contract stays on the left, each clause tinted by severity, a thin rail marking flags at their position, findings on the right. Hover either side and its counterpart lights up.
The document is the thing people are anxious about. The analysis only makes sense on it, so it never leaves the screen. Selecting opens the clause detail in place instead of navigating away.
What's at Stake states the concrete consequence per flagged clause: the Ontario damage deposit is $1,500 you cannot legally be charged, the BC overtime waiver is roughly $15,400 a year. If You Want to Push Back is one copyable sentence citing the statute section, phrased as something a person could actually send.
Amounts derive only from figures inside the sample contracts, so every dollar is honest. And a sentence you could send beats a paragraph of advice.
Every flagged clause locates itself verbatim in the document pane. Demo mode controls both the sample text and the clause records, so all 46 clauses anchor, checked before build. A clause that failed would render unhighlighted, not break.
Graceful failure was designed before the feature. The severity rail only earns trust if it never points at the wrong paragraph.
Audited, Then Dressed
A six-pillar UI audit ran against the working build with a Playwright walker, then one craft pass re-skinned the layout without moving it. Findings on the left, the skin on the right.
Findings that mattered, fixed at the root
The walker covered all four combos, five tabs each, the mobile viewport, clause detail, and every external link. Zero console errors. What it found got fixed and the fixes got logged.
The core action of the results page was a div with an onClick. Keyboard and screen reader users could not open any clause. Fixed: real buttons.
The data-integrity blocker that started the honesty thread. Resolved by authoring all four datasets, not by another banner.
The 404s were replaced. The remaining 403s were re-probed with real Chromium and confirmed as anti-bot blocks, not breakage.
Re-tested and closed: the statute site scrolls an inner container, so the audit heuristic misread it. Written down so it never gets re-flagged.
One pass, no layout changes
The layout was right; the skin was stock. Inter body, Playfair headings, gradient CTAs, soft shadows, uniform rounding. Decision 017 committed to a single direction: the app is about legal documents on paper, so it dresses like one.
Newsreader, an optical-size serif, for headings and the contract text itself. Public Sans for UI. Mono confined to spec labels, uppercase and letterspaced.
Rules replace drop shadows, corners sharpen to 1 or 2px, gradients flatten to solid ink and amber. Hover moves color, not position.
Focus rings stay loud, and the navbar carries an A- / A / A+ text-size control, because the people reading a contract at 11pm deserve type they can enlarge.
Cream, teal, and amber already carried the risk semantics. A de-AI pass that scrambled the color system would trade one problem for a worse one.
One missing viewport meta tag
The whole mobile @media block was dead until decision 007 added the viewport meta. Drag to compare the layout at 390px before and after.
Try it
This is the production build, embedded. Pick a province and contract type, run the example, and hover the findings to watch the document answer back. Demo mode runs on four example contracts, and every screen says educational tool, not legal advice.
Inside the App
Real captures: live production screens plus the working screenshots kept in the research log. Every image opens full size.
Design Process
The decision log is the process. Every call that shaped the product is a dated file with the alternatives that lost and why. The four phases below are how those 17 files group.
- ▸Problem framing: blind signing, JTBD before solutions
- ▸Scope cut to BC + Ontario, rental + employment only
- ▸Educational tool, never legal advice, set as a founding constraint
- ▸Traffic-light risk tiers; amber for warnings, red only for unenforceable
- ▸Every red flag cites the Act, section, and official link
- ▸Three disclaimer tiers, three visual treatments
- ▸Health gauge + professional summary lead the results
- ▸Document map: split pane, severity rail, stakes, push-back lines
- ▸Solicitor's desk aesthetic pass, one reversible diff
- ▸Six-pillar audit with a Playwright walker, 33 captures
- ▸Blockers fixed at the root, not bannered over
- ▸All four combos re-verified on desktop and mobile
The demo stopped pretending, and the product got more convincing
The most useful review note on this project came from watching the demo lie. The paste box implied it read your contract. It never did. Fixing that meant deleting an affordance people liked, then authoring two whole datasets so no selection could return the wrong answer. That work shows up nowhere on a feature list. It shows up everywhere in how the product feels. An honest demo of a small thing beats a staged demo of a big one.
Let's build something impactful.
I'm currently open to new opportunities in UX/UI Design, Product Design, and GovTech transformation roles.