Redesigning a Legaltech AI SaaS platform for lawyers and legal professionals

The brief didn't arrive as a brief.

It arrived as a product that already existed — technically functional, internally deployed, and quietly failing.

A leading law firm — recognized as the largest full-service legal practice in APAC — had built an internal AI platform for their legal teams. The platform could do impressive things: summarize contracts, analyze multi-document datasets, extract clauses, translate legal text, redact sensitive information.

On paper, it was powerful.

In practice, almost nobody was using it.

Lawyers opened it, stared at it, and closed it. Associates tried the AI chat a few times, got confused, and went back to doing things manually. The platform had become an expensive internal project with near-zero adoption — and the firm knew it.

That's when they reached out.

"The technology worked. The experience didn't. People didn't trust it — not because the AI was wrong, but because the interface never gave them a reason to trust it."

What we walked into

When we first got access to the platform, the reaction wasn't "this is bad design."

It was: "there's a lot happening here and none of it connects."

The product had been built feature-by-feature over time. Each capability — chat, document upload, templates, history, batch processing, prompt management — had been bolted on as a standalone utility. Nothing talked to anything else.

The result was an interface that felt like seven different products duct-taped together.

What we noticed immediately

The homepage was a blank chat box. No guidance. No suggested actions. No context. Just a cursor blinking in an empty field — expecting lawyers to know exactly what to type.

File management was chaos. Uploads went into a flat list. No version tracking. No folder logic. For legal teams dealing with fifteen iterations of the same contract, this was operationally dangerous.

AI outputs had no source. The system generated answers — sometimes good ones — but never showed where they came from. No citations. No page references. No document linking. For a profession built on evidence and traceability, this was a dealbreaker.

Templates existed but nobody understood them. The template system was technically sophisticated. It could do structured extraction, multi-field analysis, batch processing. But the interface made it feel like configuring a database query. Lawyers aren't database administrators.

There was no feedback loop. When things went wrong — and they did — there was no mechanism for users to report confusion, flag bad outputs, or signal that a workflow didn't make sense. The product was flying blind.

The real problem wasn't the AI

This is the part that changed our entire approach.

When we started this project, we assumed the core challenge was "make the AI chat better." Improve the prompting, clean up the outputs, add some formatting.

We were wrong.

The deeper we got into understanding legal workflows, the more we realized:

Lawyers don't think in chat.

They think in tasks. In evidence. In comparisons. In references. In outcomes.

A lawyer reviewing a contract isn't looking for a conversation. They're looking for:

• What are the risk clauses?

• How does this compare to the last version?

• What's missing from the standard template?

• Can I trust this enough to send to a partner?

The chat-first paradigm — the one that works for consumer AI products — was fundamentally wrong for this context.

"We kept asking: why are lawyers abandoning the chat? The answer wasn't that the chat was broken. The answer was that the chat was the wrong starting point."

Understanding how lawyers actually use AI

This was the research phase that reshaped everything.

We spent time studying how legal professionals interact with documents, how they validate information, how they build trust in a source, and how their workflows actually move through a typical day.

What we found contradicted most of the assumptions baked into the original product.

Discovery 1: Legal users need traceability, not creativity

Mainstream AI products celebrate open-ended generation. "Ask me anything." "Let's brainstorm."

Legal professionals don't want that.

They want:

• Precise answers

• Cited sources

• Predictable formatting

• Verifiable references

• Structured outputs they can drop into a memo or email

The AI wasn't being used as a creative tool. It was being used — or rather, it should have been used — as an operational accelerator.

Discovery 2: Prompt anxiety is real

One of the most surprising patterns we observed: users would open the AI chat, type something, delete it, type something else, delete it again, and then close the window.

They were afraid of asking the wrong question.

This wasn't a UX problem in the traditional sense. It was a psychological barrier. The blank prompt field communicated: "You need to know how to talk to AI." And most lawyers — brilliant, experienced professionals — didn't feel like they knew how.

The system was accidentally making smart people feel stupid.

Discovery 3: Context switching kills adoption

In the original product, completing a single workflow required bouncing between multiple disconnected screens.

Want to upload a document, run an analysis, and export the result? That was three separate areas of the platform with no continuity between them.

Every context switch was a chance for the user to lose momentum. And in a profession where billable hours matter, losing momentum means losing patience.

Discovery 4: Trust is earned in layers

We assumed lawyers would trust AI outputs if the outputs were accurate.

That's only half true.

Accuracy is the baseline. But trust in legal work is built through:

• Showing the source

• Showing the reasoning

• Allowing verification

• Maintaining consistency

• And never, ever making the user feel like they can't trace something back

A correct answer with no citation is, to a lawyer, an unverifiable answer. And unverifiable is functionally the same as untrustworthy.

The design challenge, reframed

After research, we reframed the entire project.

The original brief was: make the AI product more usable.

Our reframed challenge became:

How do you embed AI into legal workflows so naturally that lawyers don't feel like they're "using AI" — they feel like they're just doing their job, faster?

This shifted everything:

• From AI-first design → to task-first design

• From open-ended chat → to guided workflows

• From feature showcase → to operational clarity

• From "look what AI can do" → to "here's what you need, done"

Rebuilding the experience

We didn't redesign screens. We redesigned the operating logic of the entire platform.

The architecture was rebuilt around three principles:

1. Guide, don't assume. Never present a blank state. Always give the user a clear next action.

2. Connect, don't fragment. Every workflow should flow from start to finish without forcing the user to jump between disconnected areas.

3. Prove, don't promise. Every AI output should carry its own evidence. Citations, references, source links — embedded, not optional.

The Conversational Workspace

The homepage was the first thing we killed.

The blank chat box was replaced with what we called the Conversational Workspace — a structured landing experience that gave users:

• Suggested actions based on common legal tasks

• Starter prompts written in plain legal language

• Quick workflows for the most frequent operations

• Recent context so users could pick up where they left off

The goal was simple: remove the blank page problem entirely.

Instead of "What do you want to ask the AI?" the interface now communicated: "Here are the things you probably need to do. Pick one."

"We didn't want the homepage to say 'talk to AI.' We wanted it to say 'get things done.'"

Prompting without prompt engineering

This was one of the hardest design problems in the project.

Legal professionals needed to give the AI specific, detailed instructions to get good results. But they didn't know how to write prompts. And honestly, they shouldn't have to.

We explored several directions:

Direction A: Fully automated prompting. The system would generate prompts entirely from user selections. This felt too restrictive. Lawyers lost control over nuance.

Direction B: Prompt templates with fill-in-the-blank fields. Better, but it still felt like filling out a form. Legal work is too varied for rigid templates.

Direction C: Guided prompt scaffolding. This is where we landed. The system provided a structured starting point — a prompt skeleton with clear sections — but allowed full editing. Think of it as training wheels that could be removed.

We also introduced the Prompt Vault — a saved library of proven, reusable prompts that teams could share, refine, and standardize. This turned individual prompt experimentation into organizational knowledge.

Designing AI outputs that lawyers can trust

Every AI-generated response was redesigned to carry its own proof.

Outputs now included:

• Inline citations linking to specific document sections

• Source mapping showing which uploaded document contributed to which part of the answer

• Structured formatting — tables, bullet points, key-value pairs — matching how lawyers actually consume information

• Confidence indicators that flagged when the AI was working with limited context

• Text and table modes so users could toggle between narrative and structured views

The goal was that a lawyer should be able to read an AI output and, within seconds, verify every claim without leaving the screen.

"In legal work, an answer without a source isn't an answer. It's a liability."

Unifying the document ecosystem

The file management system was rebuilt from the ground up.

The new system consolidated:

• Direct uploads — drag and drop, bulk upload, format-aware

• Source libraries — persistent, organized, searchable

• Version history — every iteration tracked, compared, and accessible

• Cloud integrations — connecting to where legal teams already store documents

• Contextual linking — documents tied directly to the AI conversations and outputs they influenced

For legal teams managing hundreds of contract versions, this was the difference between operational confidence and operational chaos.

Simplifying the template system

The template system was one of the platform's most powerful features — and one of its most confusing.

Templates allowed structured extraction across multiple documents: pull specific clauses, compare key terms, generate summary tables. For batch processing of legal documents, this was incredibly valuable.

But the original interface required users to understand template logic, configure extraction fields, define output structures — essentially, to think like a developer.

We redesigned it around:

• Pre-built template categories — organized by legal task type (due diligence, contract review, compliance checks)

• Guided creation flows — step-by-step template building with plain-language instructions

• Preview before execution — see what the template will extract before running it

• Reusable and shareable — templates saved to team libraries for organizational consistency

The power stayed. The complexity disappeared.

Batch processing that doesn't overwhelm

Legal teams often need to process dozens — sometimes hundreds — of documents simultaneously.

The original batch processing feature existed but provided almost no feedback during execution. Users would start a batch job and see... nothing. No progress. No status. No estimated time. Just silence.

This created two problems:

1. Users thought the system had crashed

2. Users had no way to prioritize or manage ongoing processing jobs

We introduced:

• Clear progress tracking with document-level status

• Processing queues showing what's pending, active, and complete

• Error handling that identified specific documents with issues instead of failing the entire batch silently

• Result summaries at completion with direct links to outputs

The design system underneath

A platform this complex — with dense information, multiple workflow states, AI-generated content, enterprise data tables, and multi-step processes — needed a design system that could hold it all together without visual chaos.

We built a system that prioritized:

Density without clutter. Legal professionals work with large volumes of information. The interface needed to display a lot without feeling overwhelming. Every element earned its space.

State clarity. Documents could be uploading, processing, analyzed, errored, or archived. AI responses could be generating, complete, cited, or flagged. Templates could be draft, active, or shared. Every state needed to be immediately distinguishable.

Typographic hierarchy. With so much text — legal text, AI-generated text, system text, metadata — the typography system had to create clear reading paths. IBM Plex Sans was selected for its high readability in dense, document-heavy environments.

Visual restraint. This was not a consumer app. The visual language needed to feel serious, trustworthy, and operationally focused. We stayed close to the firm's established brand — Berry Burst (#B2204F) and Midnight Navy (#092236) — while improving contrast and usability.

Component decisions worth noting

Cards over lists. We used modular cards extensively — for templates, documents, prompts, and workflow actions. Cards allowed progressive disclosure: show the essential information upfront, reveal details on interaction.

Contextual toasts over modal interruptions. Legal workflows require focus. We avoided modal dialogs wherever possible. Instead, system feedback — upload confirmations, processing updates, error notifications — appeared as contextual toasts that informed without interrupting.

Tables that work. Legal data is tabular. Contracts have structured fields. Extraction results are comparative. We invested heavily in table components — sortable, filterable, exportable, and dense enough for enterprise use.

Icons from Tabler. Clean, consistent, and readable at small sizes. Legal platforms have a lot of secondary actions — filter, sort, export, share, compare, archive — and each one needs to be recognizable at a glance.

Two phases of evolution

The design work happened across two distinct phases, each with different goals and constraints.

Phase 1: Making it work

The first phase was about fixing what was broken — immediately and practically.

This meant:

• Restructuring navigation around task groups

• Fixing workflow continuity so users could move from upload → analysis → output without context switching

• Adding citation systems to all AI outputs

• Redesigning the homepage into the Conversational Workspace

• Cleaning up file management

• Simplifying the template creation flow

• Establishing the base design system

Phase 1 was designed for production. Every decision was validated against development feasibility. Every component was built to be implementable within real engineering constraints.

This wasn't the aspirational version. This was the "people need to be able to use this product next quarter" version.

Phase 2: Pushing further

With the foundation stable, the second phase explored where the platform could go.

This included:

• More advanced AI interaction patterns

• Deeper document intelligence features

• Enhanced multi-document comparison workflows

• Expanded template capabilities

• Future-facing concepts for legal research integration

• Richer collaboration features

Phase 2 was less about immediate implementation and more about strategic product vision. It gave the client a roadmap — a tangible picture of what the platform could become over the next year and beyond.

"Phase 1 answered: can lawyers use this? Phase 2 answered: what happens when they can't stop using it?"

Working with the development team

This project couldn't have worked in a design-then-handoff model.

The platform was AI-driven, which meant:

• AI capabilities evolved during the design process

• Backend constraints affected what workflows were possible

• Feature dependencies changed as the engineering team built

• What worked in a prototype didn't always work with real AI latency and real document sizes

We worked alongside the development team continuously — not in a "here's the Figma, good luck" handoff, but in a "let's figure out what's buildable this sprint" partnership.

Some of our best design decisions came from engineering constraints. When the dev team told us that real-time citation mapping would add processing time, we designed a progressive loading pattern — show the answer first, then layer in citations as they resolve. The result actually felt better than an instant full load, because it matched how lawyers naturally read: text first, then verify.

The features, connected

Here's what the final platform included — not as isolated features, but as a connected system:

Designing for dense information

This deserves its own section because it was one of the project's recurring challenges.

Legal platforms are not clean, minimal, white-space-heavy products. They can't be. The information is inherently dense — contracts, clauses, metadata, timestamps, version numbers, status indicators, action options.

The temptation is to simplify by removing information. But in legal work, removing information is removing context. And removing context is removing trust.

Our approach was: show everything, but create hierarchy.

• Primary information gets the most visual weight

• Secondary information is present but recessed

• Tertiary information is accessible on demand

• Status and state use color and position, not size

The interface isn't minimal. It's organized. There's a difference.

What almost didn't work

No honest case study skips this part.

The Prompt Vault almost became a feature graveyard.

Our first version of the Prompt Vault was essentially a long list of saved prompts. It worked technically, but nobody used it during testing. Prompts without context — without knowing when to use them or what they were for — were just text strings.

We iterated by adding categories, usage descriptions, and team tagging. The Vault became useful only when it stopped being a list and started being a library.

Guided prompts felt patronizing in the first iteration.

Our initial prompt scaffolding was too prescriptive. It felt like the system was telling experienced lawyers how to do their job. We pulled back — made the guidance optional, lighter, and more suggestion-oriented. The scaffolding needed to feel like a shortcut, not a tutorial.

The citation system created information overload.

When we first implemented inline citations, every AI response became cluttered with reference markers. It was technically correct but visually exhausting. We redesigned citations to be progressive — subtle markers inline, full references on hover or click, detailed source panel on demand.

Enterprise filters were too powerful.

The filtering system for documents and templates had so many options that users couldn't find the filter they needed. We reduced the visible filter options to the most common ones and moved advanced filters into an expandable section. Sometimes the best UX decision is giving people less power upfront.

Reflection

This project changed how we think about AI product design.

We walked in believing the challenge was interface design. We walked out understanding that the real challenge was workflow psychology — understanding how specific professionals think, what makes them trust or distrust a tool, and where AI actually fits into their operational reality.

A few things that stuck with us:

AI is not the product. The workflow is the product.

The AI is infrastructure. What users experience is the workflow around it — the inputs, the guidance, the outputs, the verification, the export. If the workflow is broken, the best AI in the world won't save adoption.

Trust is designed, not declared.

You can't tell users to trust AI. You have to design every micro-interaction to earn trust — through citations, through transparency, through consistency, through giving users the power to verify.

Simplifying for experts is harder than simplifying for beginners.

Legal professionals are experts. They need sophisticated tools. But they don't need complicated interfaces. Finding the line between powerful and accessible — without being patronizing or reductive — was the hardest part of this project.

The best design decisions came from constraints.

Engineering limitations, AI processing times, legal compliance requirements — these constraints didn't limit the design. They shaped it into something more honest and more usable than our unconstrained vision would have been.

What the project became

The SaaS product started as a technically capable but experientially broken AI tool.

It became a structured legal productivity ecosystem — a platform where lawyers could upload documents, run analyses, extract structured data, manage templates, track versions, verify AI outputs, collaborate with teams, and export results, all within a connected, trustworthy experience.

The platform moved from being an internal side project that people avoided to a daily operational tool that legal teams relied on.

Not because we added features.

Because we made the existing features make sense.

TYPOGRAPHY: IBM PLEX SANS

ICONS: TABLER ICONS

ILLUSTRATIONS: THE NOUN PROJECT

BRAND COLORS: BERRY BURST (#B2204F) · MIDNIGHT NAVY (#092236)