Laura Benavente · Story 02 B2B SaaS · AI-native

Removing the
blank page from
client documents

AI product designDesign strategyHuman review Concept validationMVP definitionStakeholder alignment
Built inside a practice management product at a global professional software company, and released in the Canadian market. Under confidentiality, original screens and product names cannot be shown. Everything here is reconstructed at concept level. For this case study, let's call it Practice Suite.
01

The context

A requirement
about editing

Accounting and tax professionals regularly send documents to their end clients for signature. The product requirement I was given was narrow and reasonable: improve the document editing experience for those documents.

At the time, a professional had three options. Start from a predefined template that rarely fit. Write the whole thing by hand. Or leave the product entirely, draft it somewhere else, and paste it back.

All three were slow. The handwritten route also introduced exactly the kind of typing errors you do not want in a document a client is about to sign.

HOW A DOCUMENT GOT WRITTEN Predefined template Rigid. Rarely a real fit. Heavy editing anyway. Write it by hand Slow. From an empty page. Typing errors carry risk. Leave and come back Draft it in another tool, paste the result back in. Document sent to the end client for signature The third route was the one nobody had designed, and the one that took client information outside the product.
Reconstructed · routes, not interfaces

02 · The insight

Our users were already writing with AI. They were just doing it outside our product.

AI was not in the requirement. But earlier research among our own users had already established something nobody had connected to this brief: they were using ChatGPT to draft emails and written content as part of their working day.

So the real problem was not that editing was clumsy. It was that the product handed people an empty page, and people had already found their own way around it, one that sat outside the system entirely.

Improving the editor would have made a bad starting point slightly more comfortable. It would not have addressed why people were leaving.

WHAT THE COMPANY ALREADY KNEW The product requirement Improve document editing for documents sent to end clients. Prior user research Our users already used AI to draft emails and written content. Nobody had put these two together That connection was the proposal. The evidence was not new. Using it to redefine the scope was.
Reconstructed · reasoning, not findings
03

My role

The AI was not
in the brief.
It was my proposal.

I designed the full navigation and interaction flow for the improved signature experience, from the first wireframes through to the concepts used for user validation.

But the decision that mattered came earlier. As a design strategy, I proposed incorporating AI-assisted drafting into a requirement that had asked for none, and I defended it in stakeholder reviews using the research the company already had.

The outcome of those reviews was not a yes or a no. Stakeholders expanded the scope of the initiative and phased its construction into the roadmap.

  • 01Reframed a document-editing requirement as a blank-page problem
  • 02Proposed AI-assisted drafting, justified with existing user research
  • 03Defended the direction in stakeholder reviews, which expanded the scope
  • 04Designed the end-to-end flow, from wireframes to validation concepts
  • 05Defined what the first release would and would not include
04

The design

Review is not
a step. It is
the product.

These documents go to an end client for signature. A generated draft that reaches a client unread is not a time saving. It is a liability. So the flow was built around a single non-negotiable principle: the professional reads and approves before anything is stored or sent.

THE FLOW 01 · THE USER Writes an instruction What the document needs to say, in their own words. 02 · THE SYSTEM Generates a draft A starting point, inside the product. Never an empty page. 03 · THE PROFESSIONAL Reviews and edits Full editing. Nothing is stored until the human is satisfied. 04 Saves A deliberate act, not an automatic one. 05 Sends for signature Reaches the end client only after approval. The AI never finishes the document. A person does. Generation is assistance. Approval stays with the professional who signs their name to the work.
Reconstructed flow · no original UI
05

Scope

What I chose
not to build

The concept included saving a generated document as a reusable template, a genuinely useful idea, and the obvious next step for anyone producing similar documents repeatedly.

It did not ship in the MVP. Templates introduce a second lifecycle: ownership, versioning, who can edit them, what happens when the underlying rules change. None of that could be answered responsibly before we knew whether the core drafting behaviour worked at all.

It went into a later phase of the roadmap. Deferred, with a reason, not dropped.

ShippedInstruction-based drafting inside the product
ShippedFull human review before saving or sending
DeferredSaving generated documents as reusable templates
ReasonTemplate ownership and versioning were unanswered
06

Validation and release

Tested small,
released for real

We ran a fast concept validation with three trusted customers before committing to build. The results were strongly positive: they found the feature intuitive and useful, and the concept design validated well enough to proceed.

I want to be precise about what that was and was not. Three customers is a directional signal, not statistical evidence. It was enough to justify building the MVP. It was not enough to tell us how the feature would behave once it met a whole market.

The feature was released within the practice management product in the Canadian market.

Three customers told us it was worth building. The market told us what we had actually built.

07 · What I got wrong

I thought this was a tool for contracts. People used it for anything that needed a signature.

My working assumption throughout design was that the feature served formal, structured documents: engagement letters, contracts, the heavyweight paperwork of a practice.

In use, the pattern was broader. People reached for it for anything that required a client signature, including short, routine correspondence. In effect it became a better way to write anything that had to go out formally, closer to an improved email than to a contract generator.

The blank page was a bigger problem than the document type. I had scoped the feature around the artefact when I should have scoped it around the moment.

WHAT I DESIGNED FOR Formal, structured documents. WHAT PEOPLE USED IT FOR Anything that needed a client signature. The scope was set by the artefact. The need was set by the moment: facing an empty page.
Reconstructed · qualitative observation, not measured data
08

What I took from it

Three things
I kept

The best AI feature is often already happening

Our users had solved their own problem with an outside tool. The research existed; the work was connecting it to a requirement nobody had linked it to. Behaviour that routes around your product is a specification.

In regulated work, review is the feature

When a document carries a client's signature, the value is not what the model writes. It is that a qualified person read it, changed it, and chose to stand behind it. Design the approval, not just the generation.

Scope the moment, not the artefact

I framed this around contracts. Users framed it around the blank page. Getting that boundary wrong is cheap to discover after launch and expensive to assume before it.