UX CASE STUDY · GOVTECH · Q1 2026
A court portal built to answer in under 2 minutes with a clerk verifying every AI response.
A proof of concept portal that gives self-represented litigants clerk-verified answers, remote filing, and affordable AI transcripts. Built from four years of watching where the court process locks people out, designed against a 72 hour legacy baseline.
I designed and built this proof of concept solo. Four years on the Supreme Court of BC's In-Court Technology team put me on the front line of every bottleneck this portal targets.
The Problem vs. The Solution
Courts run on dense legal language, in-person filing, and expensive transcripts. After four years at the Supreme Court of BC fielding the public's questions, I knew exactly where people got stuck, so I designed the portal I wished the registry desk could offer.
The legacy process locks people out
Dense legalese, mandatory travel, and per-page transcript pricing combine to make the court system hardest on the people with the least slack.
Clerk-verified AI, remote by default
An AI plain-language engine with a human verification layer, wrapped in a portal that works from any device at any time.
The Impact
This is a proof of concept, so these are design targets drawn from real legacy baselines, not measured production outcomes.
Velocity impact
Key Design Decisions
Three calls that shaped the concept, each anchored to a constraint I saw firsthand at the court.
AI drafts the plain-language summary, but clerks cross-reference it against legal citations and users only see clerk-approved steps.
A wrong legal answer can cost someone their case. No court can publish unverified AI output, so the verification layer is what makes the AI usable at all.
Same-day AI transcripts billed at a flat rate per day requested instead of up to $9.25 per page.
Per-page pricing scales with how much justice you can afford, and it was pricing low-income litigants out of proper representation. Financial accessibility is the ultimate usability feature in a government product.
Data handling was scoped conservatively from the start, carrying over the security-first approach of every tool I built at the court.
Court files hold sensitive personal data, and at the court I watched policy review kill projects that raised security questions. Designing for privacy up front is what keeps a concept like this shippable.
The User Flow, Before and After
Two journeys to the same filing. One is defined by travel, queues, and rejection loops; the other by a plain-language path a litigant never has to leave home for.
- 01Identify the legal need, no guidance offered
- 02Research the requirements in dense legalese
- 03Travel to the courthouse, 45 to 90 minutes each way
- 04Queue at the help desk, 45 minute average wait
- 05Complete dense paper forms by hand
- 06Submit at the counter, no digital receipt
- 07Await a response, 24 to 72 hours
- 08Rejected filing forces a return trip, start over
- 01Open the portal from any device, zero travel
- 02AI explains the step in plain language, instantly
- 03Guided smart form catches errors inline
- 04Submit digitally, instant timestamped receipt
- 05A clerk verifies the AI answer in under 2 minutes
- 06Track the case file 24/7 from the dashboard
- Identify the legal need, no guidance offered
- Research the requirements in dense legalese
- Travel to the courthouse, 45 to 90 minutes each way
- Queue at the help desk, 45 minute average wait
- Complete dense paper forms by hand
- Submit at the counter, no digital receipt
- Await a response, 24 to 72 hours
- Rejected filing forces a return trip, start over
- Open the portal from any device, zero travel
- AI explains the step in plain language, instantly
- Guided smart form catches errors inline
- Submit digitally, instant timestamped receipt
- A clerk verifies the AI answer in under 2 minutes
- Track the case file 24/7 from the dashboard
Who Can See What
A court file isn't one document with one audience. Eight kinds of record, five kinds of person, and almost none of those pairs are a simple yes or no. This is the access model I designed the portal around.
| Record | Public | Litigant | Counsel | Clerk | Judiciary |
|---|---|---|---|---|---|
| Case metadata and hearing dates | ● | ● | ● | ● | ● |
| Their own filed documents | ○ | ● | ● | ● | ● |
| Opposing party filings | ○ | ● | ● | ● | ● |
| Clerk log notes | × | ◐ | ◐ | ● | ● |
| Court audio recording | ○ | ○ | ○ | ● | ● |
| Transcript orders | × | ● | ● | ● | ● |
| Sealed or restricted documents | × | ◐ | ◐ | ◐ | ● |
| Publication-ban content | × | ◐ | ● | ● | ● |
Hearing dates and the style of cause, nothing more without asking. Filed documents come through a records request. Audio needs a listening session booked through the registry, which is a real counter transaction, not a download.
Their own filings and the other side's, in full. Clerk log notes stay internal. Audio still goes through the registry, same as anyone.
Everything a litigant sees, plus publication-ban material they need to argue the case. Audio on an undertaking.
The working view. Log notes, transcript orders, the audit trail. Sealed content stays closed to them too, because handling a file isn't the same as being entitled to read it.
Full file, including sealed material. The only role with no redaction.
This is the portal's designed access model, built from four years of handling these requests at the registry counter. It's not a statement of BC court records policy, and a real deployment would get scoped with the court's records office.
What This Was Built Against
Government work has a floor. WCAG 2.2 AA and the GC Design System are it, and each one changed the design in ways worth naming.
The six that bite at AA
WCAG 2.2 landed in 2023. Most accessibility write-ups still quote 2.1. These are the new ones, and what each cost this design.
The route to a human clerk sits in the same spot on every screen. It never moves to make room for anything.
Case number, party names, and address carry through the filing flow. Nobody types their case number twice.
The progress bar and the help bar are both sticky, so both had to be checked against every focused field. A sticky header that covers the field you just tabbed into fails this.
Exhibit ordering has up and down buttons. Drag works, but nothing needs it.
The floor is 24 by 24 CSS pixels. Everything here is 44 by 44, because the people using this are often stressed and on a phone.
Sign-in is a case number and an emailed link. No puzzle, no memorized secret, nothing that tests your memory as a condition of filing.
Federal patterns, provincial court
The GC Design System is the Canadian Digital Service's component library for federal services. Bilingual by default, Angular, React and Vue, with a paired Figma library.
The Supreme Court of British Columbia is provincial. GC Design System is federal, so none of it binds here. I designed against it anyway. A pattern that already cleared federal accessibility and official-languages review beats one I invented, and a BC concept that speaks the federal system's language is one that can move.
The part worth stealing is how the bilingual content gets authored. Labels, error text, and help copy are written as English and French pairs from the start, not translated at the end. That order does more than it sounds like it does. Writing both at once kills the clever English phrasing that has no French equivalent, and the English comes out plainer for it.
Switching languages partway through a filing doesn't dump your progress. Sounds obvious. It is the single most common place a bilingual form breaks.
Borrowed straight from the GC Forms pattern. Long court forms are where self-represented filers give up, and the error rate at the counter said so before any research did.
Walk through the A2J Portal
The conceptual portal, running. Move through the plain-language guide, the smart form, and the clerk-verified answer, from any device. This is a prototype, not a production system.
Design Process
From mapping the legacy journey to a high-fidelity prototype, with clerk verification designed into the AI logic at every step.
- ▸Drew on four years fielding public questions at the court registry
- ▸Documented the legacy friction: 40% error rates, 72 hour responses
- ▸Mapped the before and after journeys in a full user flow comparison
- ▸Set clerk verification as a hard requirement for every AI answer
- ▸Scoped the portal to filing, responses, case files, and transcripts
- ▸Committed to plain language over legalese on every screen
- ▸Built the end-to-end UX strategy deck in Figma Slides
- ▸Designed the human-verified AI logic: summarize, verify, approve
- ▸Trust badges show users only clerk-approved procedural steps
- ▸Shipped a high-fidelity interactive prototype of the portal
- ▸Published the full case study deck and user flow comparison
- ▸Labeled the work honestly as a conceptual prototype
The Decks
Two presentations carried this project. The end-to-end UX strategy, and the core case deck that walks through the clerk-verified AI logic. Both are built in Figma Slides and embedded live below.
UX process deck. Discovery and diagramming through to the exact interaction logic, in the order the work actually happened.
Core case deck. The human-verified AI logic in three moves. AI summarizes the code in plain English, a clerk cross-references it against the citations, and users only ever see clerk-approved steps.
Designing from the registry desk
Most govtech concepts start from a technology looking for a problem. This one started from four years of answering the public's questions at the registry desk, where I watched the same people hit the same walls every week. The AI is not the interesting part. The clerk verification layer is, because it is the piece a real court could actually adopt. The honest next step is a pilot with a live registry to turn these design targets into measured outcomes.
Let's build something impactful.
I'm currently open to new opportunities in UX/UI Design, Product Design, and GovTech transformation roles.