LegalTech Product Design

Design the legal portal people reach when something has gone wrong — the answer they can read, the intake they can finish, and the request a lawyer can act on without asking everything again.

A steel robotic arm on a tall post sets an orange weight on a steel balance scale opposite a stack of white ceramic documents.
For legal help services
Portals, intake, lawyer matching
Two audiences, one request
Public and professionals
Your lawyers own content
We design how it reads
Scope per service
Set in the proposal

In short

People find the legal information they need, and know what to do next.

What's included

  • Topics and search
  • Plain-language answers
  • Intake forms
  • Finding a lawyer
  • Documents
  • Professional workspace

Answers you'll have before development

  • What does someone need before they speak to a lawyer?
  • Which intake questions come first, and which can wait?
  • What does a professional see when a request arrives?

Where it stops

Compliance & RegTech Design

Software for teams who manage rules, policies and audits.

LegalTech Product Design

Journeys for people looking for legal help.

Not included

  • Legal advice or review of legal content
  • Case outcomes or conversion figures

From a worried question to a clear request

The reader's path and the professional's, designed as one product.

Discuss your product
  • A white ceramic base where one path of steps splits in two, a graphite tile at the end of one branch.

    Audience and journey map

    Citizens, clients and professionals, what each comes for and where they arrive.

  • A white ceramic card index with tabbed dividers, a thin steel magnifying glass with a graphite handle resting on it.

    Information structure and search

    Topics, answers and search that match how people describe their problem.

  • A white ceramic tablet on a steel stand carved with a form and an upload box, a closed ceramic folder beside it held by a graphite clip.

    Intake and document flow

    Questions in a sensible order, uploads, and a handoff to the right person.

  • A white ceramic monitor on a thin steel stand, carved with a list of rows, one row raised in graphite, a tray of ceramic cards in front.

    Professional workspace

    Incoming requests, documents and status for the people who answer them.

You receive

  • A journey map for each audience
  • Flows with every state
  • UI and a clickable prototype

Designed for people who don't know the legal word for it.

People arrive worried, describing the problem in their own words, often on a phone. The product meets them there, and hands a clear request to the professional on the other side.

Every screen is designed for

  • Question matches no topic
  • A legal term the reader doesn't know
  • The answer depends on the country
  • Intake stopped halfway
  • Document missing or unreadable
  • No professional free for this matter
  • A deadline is close
  • Waiting for a reply
  • Details seen by the wrong person

A fit when people bring problems, not legal terms

It fits when people bring a problem in their own words and someone qualified has to pick it up.

  • People arrive with a problem, not a term

    Visitors search in everyday words and leave before they find the page that answers them.

  • Two audiences share one product

    The public asks, professionals answer, and each needs its own view of the same request.

  • Requests arrive half-formed

    Lawyers or advisers ask the same questions again because intake did not.

  • Your lawyers own the content

    A legal team writes and checks what the product says; we design how it is found and read.

Let's make the next legal step easy to find

Tell us who comes to your product, what they are looking for and who answers them. We'll answer with a sensible first step and the service it belongs to.

Scope, access and who does what

A legal portal comes to us as a project under one of our services, and that service's proposal carries the terms.

Scope
Per service fixed or phased, set in the proposal
Timeline
Agreed after scope, access and dependencies
  1. You provide

    The product
    The live portal or a staging copy, with logins for public visitors and for professionals.
    The content
    The legal topics, answers and forms you publish, and who writes and approves them.
    Evidence
    Search terms, where intake is abandoned, and what professionals ask again.
    Engineering
    The team, the case or CRM system behind intake, and how documents are stored.
  2. Who does what

    ANODA
    Maps the public's path and the professional's, designs the structure, intake and every screen state, and specifies what developers need to build it.
    Your team
    Writes and approves the legal content, checks each stage, and builds and publishes the portal. Legal, privacy and regulatory checks are your team's to make.
  3. Boundaries

    Outside LegalTech design
    Development, writing or checking legal content, legal advice, and regulatory or privacy review.
    After the design
    Engineering, in-house or a partner, builds the portal and connects it to your case system. Build reviews by us are a separate, optional scope.

Where do people get lost on the way to legal help?

Say who uses the portal, what they ask, and where requests go once they are sent.

What do you need? *
Project budget (USD) *

What is your product, who uses it, and what would you like us to do?

    Within 15 minutes, we’ll reply with initial feedback and follow-up questions.

    Read more about clear, findable products

    All articles

    LegalTech Product Design: common questions

    Have you designed for legal services before, and what can you show?

    Yes. Our LegalTech work covers legal information and finding a lawyer: helping people understand where they stand and reach someone who can help. There is no published case study for it yet, so the client stays unnamed here; we walk through the work on a call instead. Court tools, case management and legal AI we would approach the same way, but we make no claim of past work there. When you compare teams, ask each one the same thing: which part of legal work did they actually design?

    People give up halfway through our intake. How would you make the questions and document requests clearer?

    Good legal portal design starts from the words people use, not the names of legal categories. Topics and search accept everyday language and lead to a short answer in plain words, with the full detail a click away. Intake asks only what the professional needs first, explains why each question is asked, saves progress, and shows which documents are needed before the upload step, not after it. At the end, people see what happens next and when they will hear back.

    Whose journeys does legal tech UX design have to cover?

    Members of the public and clients looking for information or help; lawyers, advisers and paralegals who pick up requests; and the operations and content teams who run the service. The workflows are finding and reading information, checking whether a matter fits, intake and documents, choosing or being matched with a professional, messages and status, and the professional's queue of incoming work. The citizen's journey and the professional's are designed as separate paths that meet in one request. A member of the public may visit once, in a hurry and under stress; a lawyer uses the workspace every day and needs speed, filters and a complete picture of each matter.

    What kind of engagement suits a legal portal or a lawyers' workspace?

    Our legaltech design services come in three shapes: UI/UX & Product Design when the product or module is new, Web App Design when the portal and the lawyers' workspace run in a browser, and Mobile App Design when people look for help and send documents from a phone. If a live portal already loses visitors mid-intake, start with a UX Audit. Software that manages a company's rules and audits belongs to Compliance & RegTech Design.

    Will your design ever amount to legal advice, and who looks after sensitive data?

    We design around the rules your legal team gives us and never write or check legal content ourselves. That covers where a disclaimer appears, how an answer that depends on the country is shown, who can see a document, and how consent and deletion requests work. Whether the content is correct, and whether the product meets the rules that apply to it, stays with your lawyers and your privacy and regulatory advisers. A well-placed disclaimer is still not legal sign-off, and we never present our screens as one.

    Who and what from our side do you need at the start?

    A staging portal with a login for the public side and the professional side; the topics, answers and forms you publish and who approves them; search terms, drop-off data or support questions if you have them; someone empowered to make product decisions; and a conversation with engineering and whoever owns the case or CRM system behind intake. It also helps to hear from two or three of the professionals who answer requests: they know which details are always missing, and which questions people ask again after they have read an answer.

    What will we have at the end, and what sets the price?

    A journey map for each audience, the information structure and search, the intake and document flow, the professional workspace, the states between them, the UI and a prototype you can click through. Price and schedule follow the number of audiences and legal topics, the platforms, whether the portal is already public, and how many systems intake feeds. Each project is scoped in the proposal for the first service rather than priced from a list, and its schedule is set once access and dependencies are known.

    Can you redesign a live portal without breaking the pages people find through search?

    Yes. Most legal products start from content, systems and professionals already in place. We take up your existing design files and system, design around content your legal team owns and approves, sit with your designers, engineers and lawyers, and deliver all the files to you. When the portal is already live, we keep the addresses, terms and paths people and search engines know, and change the structure around them, so a redesign does not cut off the people who found you through a search.