When the Client Becomes the User: A Human-Centered Approach to Legal Technology

Legal technology is no longer developed only by specialized software companies. Law firms, legal departments, and legal service providers are increasingly building client portals, automated workflows, and AI-enabled applications. Artificial intelligence, low-code platforms, and accessible development tools have lowered the barrier to building technology to address workflow problems.

Lawyers and legal professionals understand their clients’ problems in ways outside product teams often do not and can translate that knowledge directly into technology.

Much of legal technology has historically been built around legal professionals, focusing on making lawyers, law firms, and legal departments more efficient.

Clients complete intake forms, upload documents, manage records, and move through automated workflows themselves. A firm may build a tool, but the person using it may be a client who has never encountered the underlying legal process.

A lawyer and a client can look at the same information and see different things. A lawyer may understand why a document matters, what a term means, which information is relevant, and what happens next. A client may encounter the same concept for the first time.

The question is no longer only whether a tool can automate a legal workflow. Product teams also need to ask whether the people participating in that workflow can understand and use it.

When the client becomes a user, too, human-centered development becomes part of good legal technology development.

Start With the User, Not the Legal Workflow

My background in product management has shaped how I think about this problem. Product teams are taught to begin with the user and the problem before deciding what the product should look like.

Design thinking follows a similar approach: understand the user, define the problem, explore solutions, prototype, and test what works.

That process is especially important in legal technology because legal professionals naturally think in legal categories. A lawyer might think in terms of capitalization, corporate records, governance, filings, or compliance obligations. A business owner may think, “I added a partner,” “we gave an employee equity,” or “an investor put money into the company.”

The client does not necessarily recognize the legal category behind those events.

A product can contain the right legal information and still feel confusing. Product teams should, therefore, ask not only, “What information belongs in this workflow?” but also, “What does this user understand at this point?”

What a Capitalization Table Taught Us About Simplicity

I encountered this while working on a client-facing legal technology platform, particularly when we began developing its cap table.

There is no shortage of established cap table software. They can model complex ownership structures, securities, vesting, dilution, rounds, and other capitalization scenarios that a spreadsheet cannot easily match.

And yet, many companies still rely on the good old Excel spreadsheet.

Excel has an important advantage: familiarity. Users open a grid they recognize and understand how to begin.

That does not make Excel the better tool. Spreadsheets introduce problems around accuracy, version control, calculations, permissions, and maintaining a reliable ownership record. But their continued use illustrates that a more capable product is not automatically more approachable.

When designing the cap table, we asked not only what functionality it should have, but what the experience would look like for someone who may never have managed one before.

At its most basic level, a cap table answers: who owns the company? Underneath are authorized shares, issued shares, fully diluted ownership, outstanding ownership, options, vesting, and convertible instruments. Those concepts may be familiar to attorneys, investors, and experienced founders, but not to a business owner opening a cap table for the first time.

We focused less on how much information the system could display and more on what the user needed at a particular moment. We simplified the experience, reconsidered what needed to appear immediately, and added “Learn more” explanations where needed.

The goal was not to recreate Excel or hide capitalization complexity. It was to combine the accessibility of familiar tools with the structure and guidance of purpose-built software.

Simplification is an Information Problem

In legal technology, making products “simpler” can be dangerous if it means removing important distinctions. The better question is how information should be structured.

When evaluating a client-facing workflow, product teams should ask:

• What must the user understand right now?
  The immediate decision should receive the most attention.

• What can wait?
  Some details matter, but do not need to appear during every interaction.

• What needs explanation?
  Terms that feel obvious internally may be unfamiliar to the client.

• What should remain available for users who want more detail?
  A simple experience should not prevent sophisticated users from going deeper.

Progressive disclosure can keep the interface approachable while more information remains available through examples, expandable content, tooltips, or “Learn more” links.

The complexity is still there. It is simply introduced when relevant.

The Product Has to Carry Some of the Context

Professional users bring knowledge into legal software. A lawyer does not need a contract-review tool to explain why a particular clause matters or why certain language may create risk.

Clients may not have that background.

Therefore, client-facing technology must provide context that professional software can leave unstated. An explanation, example, confirmation message, or “Learn more” option may be enough.

The goal is to give the user enough context to understand the decision, not teach them everything about the law.

Good Client Design Helps the Lawyer, Too

Designing around the client experience does not mean prioritizing the client at the expense of the lawyer. The experiences are directly connected.

If a client misunderstands an intake question, counsel may receive incomplete information. If they do not know which document is requested or whether a process is complete, someone has to follow up.

Better client-facing design can reduce that friction. Clearer questions yield better information; contextual guidance reduces the need for clarification; status visibility reduces follow-up; and organized records give lawyers better information when advice is needed.

The objective is to improve the interaction among the lawyer, the client, and the technology.

Usability is Not Enough

Completing a workflow does not necessarily mean the user understood it.

Consider a founder entering ownership information into a cap table. The founder may add every stockholder, enter the correct number of shares, and save the record without difficulty.

From a traditional usability perspective, the workflow succeeded.

But if the product displays current and fully diluted ownership, does the founder understand why the percentages differ, that fully diluted ownership may account for securities or equity rights not yet outstanding, and which percentage is relevant to the question they are trying to answer?

A user can interact with the software correctly while still misunderstanding the information it produces.

For client-facing legal technology, I think there are three levels of success:

• Usability: Can the user complete the task?

• Comprehension: Does the user understand what they did and what the information means?

• Outcome: Did the technology help the user accomplish the underlying legal or business objective?

Those levels should influence testing. Beyond whether users can complete the workflow, product teams can ask them to explain what a number means, why two figures differ, or what they would do next.

Those conversations can expose problems that completion rates and click data will never show.

Design the Hand-Off, Too

Some legal tasks are routine. Others involve ambiguity, unusual facts, significant consequences, or professional judgment.

A human-centered product should recognize that boundary.

Technology can organize information, explain routine concepts, surface uncertainty, and guide clients through predictable steps. It should also make the transition to professional assistance clear when needed.

That hand-off should feel like part of the experience. Technology handles organization and routine guidance, while the lawyer focuses on questions requiring legal judgment.

A Practical Test for Client-Facing Legal Tech

When reviewing a workflow that clients will use directly, I would ask five questions:

1. Does the user understand what they are being asked to do?
2. Does the user understand why the information matters?
3. Is the right amount of complexity visible at the right time?
4. Does the user know what happens next?
5. Does the product recognize when professional judgment is needed?

These questions are simple, but answering them well requires discipline. It is often easier to add a feature than decide what information should appear and what the user needs to understand.

Designing for Both Sides of the Relationship

Working on client-facing legal technology has reinforced this lesson for me. Important product decisions include what belongs on the first screen, which terminology requires explanation, where context should be available, and what the user should understand before moving forward.

Those decisions determine whether a product simply digitizes a legal process or helps a client participate in it.

Legal technology will continue to make legal teams more efficient, while clients become increasingly active users of the systems that support legal work.

Designing for the client experience becomes part of designing better technology for legal professionals, too. The strongest products give clients enough context to participate effectively while preserving professional judgment where it adds the most value.