top of page

Helping people finish a legal document they actually trust

Rocket Copilot Document Generation lets people create a legal document by answering questions in conversation with Copilot instead of filling out a long legal form. I led the foundation and optimization that reframed it around a person's situation, so users stopped abandoning at the legal-setup wall and started reaching a finished, trustworthy document. At a glance: Lead Product Designer, solo design owner on a cross-functional team; a nine-week research and redesign effort; status is validated in research, next step is live funnel testing.

This is the story of one decision that reshaped the whole flow: stop asking people to think like lawyers, and let Copilot do the legal reasoning for them. I owned the diagnosis, the strategy, the interaction design, and a six-study testing program, partnering closely with Product, Engineering, Research, and Legal to ship something that was both faster to complete and easier to trust.

The Document Generation experience was leaking badly. Data showed just 2.2% of people who started a document ever finished one, over an average of 78 minutes. The fix wasn’t fewer fields or nicer tooltips; it was changing what we asked people to decide. I reframed the flow from “answer every legal question” to “pick your situation and let Copilot do the legal reasoning,” then validated it across six studies that solved the completion problem and pinpointed trust as the next lever.

PH_ Hero collage showing dashboard, AI revie.png

MY ROLE

Lead Product Designer: owned UX strategy, end-to-end interaction design, and the research plan

WHO I WORKED WITH

Product (scope & funnel goals)
Engineering (feasibility & defaults logic)
Research (6 user testing studies)
Legal (clause accuracy & guardrails)

THE BET

Bet that guided confidence beats a blank questionnaire — let Copilot carry the legal reasoning, not the user.

WHAT THE WORK PROVED

Starting from a 2.2% completion rate that Amplitude flagged as a Critical funnel leak, testing showed the redesign essentially solved completion friction (V4 near-perfect on ease) and isolated trust as the single remaining lever, giving the team an evidence-backed path to close the gap.

Business Context

A high intent funnel that was quietly failing: 2.2% completion.

Document Generation is where intent becomes revenue: a person says “I need an NDA,” and this is the surface that turns that into a real document and into a reason to become a member. But the data told a hard story. Of 951 people who started a Doc Gen session, only 95 got as far as a downloadable document (9.1%), and just 21 finished one end-to-end, a 2.2% completion rate, and an average of 78 minutes from start to finish. In the post-launch review it was flagged Critical: one of the top three leaks in the entire Copilot funnel, a high-intent feature quietly failing at scale.

My first move was to stop treating this as a visual-design problem. The issue wasn’t how the questions looked, it was that we asked people to make legal decisions before they had any way to know what the right answer was.

The strategic challenge became: How might we help users complete a document confidently, without asking them to act like a lawyer at step one?

after business model diagram.png

User Problem

People weren’t struggling to fill a form. They were struggling to feel sure.

I sat with session recordings and the drop-off data side by side. The pattern was consistent: users hesitated, re-read the same question two or three times, clicked into the document to try to fill it directly, then abandoned — almost always at the upfront legal questions. It wasn’t that there were too many fields. It was that every field asked them to make a legal call they had no context to make, and the editable-looking preview gave them a second place to fail.

“Do I even need this clause?”
“What happens if I pick the wrong option?”
“Is this actually right for my situation?”
“Wait — am I supposed to type in the chat or in the document?”

The two root causes:

First, we front-loaded legal decisions, asking people to configure an instrument before they understood it.

Second, the document preview showed blank, editable-looking fields, so attention split between chat and document and people tried to fill the doc directly, breaking the guided flow. Confidence and clarity collapsed at the same moment.

PH2_ Mental model mismatch diagram.png

Strategic Reframing

The reframe: let people recognize their situation instead of configuring a document.

I considered three directions, and judged each against the same three criteria: does it actually lift completion, does it protect trust in the document, and is it feasible for engineering and legal to ship? One: keep the questions but add inline help and tooltips — cheap and low-risk, but it treated the symptom, not the cause, so completion wouldn’t move. Two: progressively disclose the same questions over more steps — less overwhelming, but it still asked people to make legal calls they couldn’t make, so trust stayed fragile. Three: invert the model — let people pick a real-world situation, have Copilot select the legal setup, and only ask for the basics. I pushed for the third: it was the only option that removed the decisions rather than repackaging them, and the added feasibility cost (defaults logic, legal guardrails) was worth the only real shot at moving completion and trust together.

What did Copilot decide for me?
So the flow became: choose a situation → Copilot selects the recommended legal answers → the person reviews and edits if they want → they answer only the basics (names, dates, addresses). Every Copilot choice has to answer three questions for the user:

Why does it fit my situation?
What’s actually left for me to do?

That last detail mattered: I made every recommendation editable and added an explicit “make your own choices” path. Reducing decisions builds speed; keeping them reversible is what keeps trust.

PH2_ Legal momentum ladder. Level 1_ What we.png

System & Flow

One guided system, not a form bolted to a chatbot.

I replaced a questionnaire, a chat, and a preview competing for attention with a single system built on one rule, Copilot reasons, the person confirms, and the document reflects. Each layer has exactly one job:

HOW THE FLOW MOVES

Group 1618870929.png

THE SHIFT

Group 1618870930.png

Guided vs. Classic

Why guidance beats a blank legal form

Most legal questionnaires assume the reader already knows what an indemnification clause is, or when a mutual NDA is different from a one-way one. That assumption is the real barrier for people without legal training, not the number of fields on the page. Rocket Copilot's guidance model replaces “fill in this term correctly” with “here's what most people choose, and why” — so the user is reasoning about their situation, not decoding legal vocabulary.

What guidance hasn't fully solved yet: once users reach the clause-by-clause legal language itself, comprehension still drops, testers called “understanding all the terms” their most negative moment. That's the next problem for the trust layer to solve, not a reason the guided model failed.

Classic legal questionnaire

✗ Assumes you know the legal term for what you need
✗ One long form, no feedback until you submit
✗ Wrong answers fail silently, discovered later
✗ No sense of where you are or how much is left

Copilot-guided flow

✓ Plain-language prompts: “who are you sharing this with?”
✓ Conversational, one question at a time, methodical pace
✓ Recommended, explained defaults reduce guesswork up front
✓ Clear progression — users always know what's next

Deep Dive · Situation-First Setup

Replacing the legal-setup wall with a situation and a smart default.

Problem: The original flow front-loaded legal setup questions, clause choices, terms, and configurations, the moment a user arrived. Users had no context to answer them, so they stalled, guessed, or abandoned before the document ever felt real.

Design decision: I moved the experience from “answer every legal question from scratch” to “choose your situation.” Users select the legal scenario that fits them; Copilot then makes smart default selections for the legal setup and tailors the clauses, so users start from a document that already matches their situation.

The tradeoff I weighed: smart defaults risk feeling like a black box. I bought back that trust by always showing “key factors considered” and “why Copilot chose this,” and by making every answer editable, so the speed never costs the person control.

What changed:

  • Users now pick a situation first; Copilot selects recommended answers for that situation.

  • Defaults are explained: “Key factors considered” and “Why Copilot chose this.”

  • Recommendations are editable — users can review and change anything before creating the document.

  • An explicit opt-out (“Prefer to make your own choices?”) preserves control for confident users.

  • Legal decision-making is reduced to confirming, not configuring.

Group 1618870931.png

Deep Dive · Guided Answers

Making the remaining inputs fast, and never a blank page.

Problem: Even after defaults handled the legal setup, users still had to provide the basics — names, dates, addresses, party details. In the original flow these were open text fields that felt like work and left users unsure what “good” looked like, which is where typing into the document and chat split their attention.

Design decision: I designed guided answer inputs that keep users in the conversation and reduce typing. Each remaining question offers quick choices where possible and a “Help me answer” option for anything ambiguous, so users are never staring at an empty field wondering what to write.

What changed:

  • Remaining inputs framed as a short, guided set — basics only, not legal decisions.

  • Quick choices replace free text wherever the answer is constrained.

  • “Help me answer” offers context and examples for anything unfamiliar.

  • Copilot confirms progress (“I’ll use your selections… next, a few quick details”) to keep momentum visible.

  • Inputs live in the chat, so the document preview never competes for the user’s attention.

What I chose not to do: auto-fill everything and hide the work. People needed to feel they were still in charge of their own details, so I kept the basics as quick, guided inputs rather than silent automation.

Group 1618870932.png

Deep Dive · Live Read-Only Preview

Turning the preview from a trap into a trust signal.

Problem: The original preview showed the document with blank fields that looked editable. Users split their attention between the chat and the document, tried to type directly into the preview, and lost the thread of the guided flow — unsure where they were actually supposed to act.

Design decision: I made the document preview read-only and live. As users answer questions in conversation, the preview updates in real time — but it is clearly a reflection of progress, not an input surface. Action happens in one place: the Copilot conversation.

Making the preview read-only and live resolved the split-attention problem and let the document act as a real-time trust signal that the answers were landing correctly.

What changed:

  • The preview became read-only — no more blank fields masquerading as inputs.

  • The document updates live as users answer, so progress is visible and reassuring.

  • A single, unambiguous place to act: the chat. The document is the outcome, not the form.

  • Microcopy sets expectations: “Complete the document in conversation with Copilot, and this preview will update automatically.”

PH2_ Document generation or document-created.png

From Document to Membership

Turning a finished document into a protected business

The document isn't the end of the job, it's the moment the user has the most context and the least patience for a hard sell. The paywall had to do three things at once: show the value of the finished document before asking for payment, explain in plain language what a membership actually unlocks, and recommend one plan instead of forcing a comparison shopping exercise. Usability testing on this exact flow is what shaped the design below. It builds directly on the completion work above: once more people were finishing documents, each finished document became a moment of real intent, not just traffic. The membership recommendation reuses that same trust model, Copilot suggests one plan based on the person's activity and the specific document they just created, so the completion gains and the conversion gains come from the same underlying decision architecture.

WHAT MEMBERSHIP UNLOCKS, SHOWN AFTER THE DOCUMENT IS DONE, NOT BEFORE

Sign

Send the finished document for signature

Connect with an Attorney

Ask a human attorney about this document

Manage Document

Edit, store, and track every document in one place

The Recommendation Logic:

Testing found that “based on your activity” felt opaque and mildly manipulative when the reasoning wasn't visible. So Copilot's recommendation is driven by five concrete signals — and the case study below states them in plain language instead of hiding them.

Group 1618870933.png

The 3 real membership tiers, priced

Frame 1000003030.png

“Based on your activity, Plus is the membership that will benefit you most” only works if the user can see why. The recommendation banner names the specific signal, the document type, the next action clicked, or the stated need, instead of hiding behind the word “activity.”

WHAT TESTING FLAGGED AS CONVERSION RISK
• Pricing/discount consistency:
any mismatch between “50% off,” monthly vs. yearly display, and checkout is the fastest way to lose trust.
• Cancellation clarity: users want “$0 today, cancel anytime” stated plainly near the CTA, not implied.
• Value framing: someone who wants just one document shouldn't feel pushed into a membership mindset.
• Unmistakable unlock: confirm the document is actually unlocked; don't make the user wonder if payment worked.

The strongest signal from testing wasn't about design polish: transparency converted better than a cleaner layout would have. Users tolerated being asked to upgrade, they didn't tolerate ambiguity about price, cancellation, or why a plan was recommended. Showing the finished document before the ask, and naming the reasoning behind the recommendation, did more for conversion than any visual treatment on this page.

Trust and Design Principles

Principles that guided the Doc Gen optimization, and the trust model behind them.

01

Recognize, don’t configure
Let users choose a situation and confirm smart defaults. Reduce legal decision-making instead of asking users to act like a lawyer.

02

Reduce decisions, then explain them
Copilot makes defaults, but always shows “Key factors considered” and “Why Copilot chose this,” so reduced effort never feels like a black box.

03

One place to act
The conversation is where the user answers and commits. The document preview is read-only — it reflects progress, it is never an input.

04

Recommendation with reversibility
Every Copilot selection is editable before the document is created. Smart defaults reduce effort; the ability to change them preserves trust.

05

Make a human help reachable
Confidence comes from knowing a licensed Legal Pro is one tap away (written or live consult) especially at the moments users hesitate.

Testing and Evidence

Validating the direction with a six-study user testing program.

The trigger was quantitative: Amplitude showed a 2.2% end-to-end completion rate and a 78-minute average time-to-finish — a Critical funnel leak. To pressure-test the fix, we ran six UserTesting studies on one shared rubric — a benchmark plus five prototype variants (V1–V5) — with about 57 participants per study (deltas are directional). Each build was scored on two axes: Usability — ease of completing the document (Q6) — and Trust in the document (Q23). The goal was to find a build that was both frictionless and trusted.

Benchmark — the original, front-loaded flow: liked, but not trusted.
V1 — leanest situation-first flow: best-liked, lighter trust scaffolding.
V2 — situation defaults + visible logic: most balanced (≈4.0 on both axes).
V3 — heaviest trust scaffolding: trust leader, rougher to complete.
V4/V5 — smoothest, leanest flows: usability leaders, smallest trust gains.
Axes scored every build: Usability (Q6) vs. Trust in document (Q23).

Decision table123.png
PH2_ MVP scope boundary diagram. In MVP_ Lega.png

Impact

What the work moved

WHAT SHIPPED
Reframed Doc Gen around the person’s situation and shipped the rebuilt flow end to end — every step pointed at the Started → Saved → Completed funnel where users had been dropping. (The flow itself is detailed in sections 08–10.)

WHAT CHANGED FOR USERS
Removed the two failure points I’d diagnosed: legal decisions asked without context, and an editable-looking preview that split attention — leaving one place to act and one source of truth.

WHAT TESTING VALIDATED
Against an Amplitude baseline of 2.2% completion and a 78-minute average (a top-three Critical funnel leak), a six-study UserTesting program (n≈57 each, directional) showed the situation-first model essentially solved completion friction — V4 scored near the top of the usability scale — and isolated trust as the single remaining variable.

WHAT’S NEXT (SCOPED)
Defined the next build to test against the live funnel: V4’s low-friction flow plus V2/V3’s trust scaffolding (editable recs, visible logic, a prominent Legal Pro path). The work also left the team reusable assets — a trust model for AI-native flows and a benchmark rubric (Ease Q6 × Trust Q23). Note: results here are validated in research, not yet post-launch funnel numbers.

PH2_ Future architecture diagram. Dashboard =.png

Reflection

What I took away

The hard part of AI document creation isn’t generating the document, models do that well. It’s deciding how much thinking to take off the user’s plate without making them feel like they’ve lost control of something legal and consequential.

  • Designing for inclusion shaped the entire experience. I learned the importance of centering users who might otherwise be left behind. By enabling Copilot to communicate in a user’s preferred language, explain legal concepts in plain terms, and support incremental revisions, I created a more accessible experience. I also considered screen reader compatibility, while recognizing that low-vision-specific needs remain an area for future improvement.
     

  • Research and scoping were critical in aligning stakeholders. I learned how to navigate differing perspectives by grounding decisions in user insights. Product questioned whether Copilot should answer legal questions at all. I showed that users wanted guided explanations, not legal advice, so I shaped responses to explain concepts and help users decide for themselves. Engineering was concerned about the complexity of editing recommendations. I simplified this by letting users flag items to revisit in the conversation instead of building a separate editing tool. In 13 interviews, 11 participants responded positively, while 2 expected similar task time but greater confidence.
     

  • Reframing the problem led to a more meaningful solution. A key learning was recognizing that the challenge was not just a UI issue. Users were being asked to make decisions they did not feel confident making. By shifting the focus from interface improvements to supporting decision-making, I was able to design a more impactful solution.
     

  • Measuring trust and behavior is essential for future validation. I learned that designing for trust requires ongoing validation. The next step would be to test the experience at scale, using the same research framework and tracking key behaviors such as revisions, clarification requests, drop-off, and completion to understand how users engage with the system.

© 2026 by Omar Alamrani.

bottom of page