Self-serve legal answers
Designing a diagnostic tool that helps people get reliable answers to common legal questions in minutes
Client
Legal tech platform
Website
Context
The same simple questions, over and over
A legal tech platform working on a government project, aimed at giving the public a faster way to get reliable answers to routine legal questions, without needing to contact a legal professional for every query.
Legal teams and public services kept fielding the same kind of question repeatedly, things like whether a project involves personal data, and what obligations follow from that. Most of these had a clear, fairly simple answer once a few key facts were known, but there was no way for people to work that out themselves.
Problem
Simple questions still needed a person to answer them
Legal teams were spending real time on questions that, in most cases, had a predictable answer based on a handful of facts. Users had no way to self-serve, so even a straightforward question meant waiting on someone to respond.
The challenge was building something that could resolve genuinely simple cases on its own, while reliably recognising when a question was too complex for that and handing it to a person instead of guessing.
Success meant most simple questions never needed to reach a person at all, and the ones that did got routed there automatically, not after a failed attempt at self-service.
Goals
What the tool had to do
Let users answer their own legal question in a few minutes, without contacting anyone.
Keep the flow short, a maximum of four context questions, so it stayed usable rather than becoming another long form.
Build in a reliable path to a real contact for anything too complex for the tool to resolve on its own.
Reduce the volume of repeat, low-complexity questions reaching the legal team.
Constraints
What made this harder than a typical form
Government involvement meant extra review cycles. Every question and every branch of logic needed sign-off from legal and government stakeholders before it shipped, which set a slower pace than a typical consumer product.
Accessibility wasn't optional. As a public-facing government tool, it had to meet accessibility standards for a genuinely wide range of users, not just a general audience, so that shaped the interaction design from the start rather than being retrofitted at the end.
The logic underneath was more complex than it looked. A simple four-question flow still had to hold up against real legal nuance, getting the branching right took close, iterative work with legal experts, not just a UX pass.
Being wrong carried more weight. Because the tool spoke with government backing, a misleading answer was a bigger problem than it would be on a typical product, accuracy had to be checked at every step, not just at launch.
Decisions & trade-offs
Three calls that shaped the final design
01 | A hard cap of four questions, or an open-ended flow | |
Explored | Tested | Chose |
|---|---|---|
An open-ended flow that could keep asking clarifying questions until it reached full precision. | Completion rates and drop-off, a capped flow against a longer one. | A hard cap of four context questions. |
Why: longer flows lost people before they reached an answer. For the simple cases this tool was built for, four questions was enough, anything that needed more got routed to a person anyway.
02 | The tool decides on handoff, or the user does | |
Explored | Tested | Chose |
|---|---|---|
Letting users choose at any point whether to keep going or request a person. | How confidently non-experts could judge their own case as simple or complex. | The tool makes that call automatically. |
Why: people without legal background often couldn't tell whether their situation qualified as simple. Taking that decision off the user removed both friction and the risk of someone guessing wrong.
03 | Text labels, or icon shortcuts, for navigation | |
Explored | Tested | Chose |
|---|---|---|
Leading each result with the specific regulation it was based on, for transparency. | Comprehension with the target, non-legal, audience. | Plain-language answer first, citation included but secondary. |
Why: leading with a citation made the result feel like the same legal text the tool was meant to replace. People wanted the answer first and the legal backing available, not upfront.
Process
From common questions to a working flow
Research
Reviewed the most common legal questions the team received, to find patterns and identify which were simple enough to automate.
Mapped the decision logic behind each question, the specific facts that actually determine the answer.
UX design
Designed the diagnostic flow as a short, guided sequence, capped at four questions.
Built in a clear branch point: a direct answer for straightforward cases, a handoff to a real contact for anything more complex.
UI design
Designed the question flow and results screen, keeping the tone plain and approachable rather than legalistic.
Worked within accessibility requirements throughout, contrast, focus states, and screen-reader support, as a baseline rather than a final pass.
Review & testing
Every question and branch went through legal and government review before anything shipped.
Tested the flow against real questions to check whether four questions was consistently enough to reach a reliable answer.
Shipped design
UI craft
End-to-end flow
From first question to an answer
Outcomes
Impact
Simplified process | What used to mean contacting a person now takes a few guided questions, cutting a multi-step inquiry down to minutes. |
Resources in one place | Users get a direct answer and, where relevant, a link to the specific policy behind it, instead of having to track that down separately. |
A structured, repeatable process | The underlying question logic is documented clearly enough that new legal topics can be added following the same pattern, rather than rebuilt from scratch each time. |
Fewer simple questions reaching legal | Routine questions that used to land directly with the legal team are now resolved by the tool itself, freeing that time for genuinely complex cases. |