Rethinking Document Sending,
Starting with the Basics.

Testing a faster path for simple document sending before scaling to complex workflows

Role
Product Designer
Collaborators
Audrey (Design Lead) · Bruno (UI Lead) · Cadu (Data Analyst) · Mariana (Product Manager) · Zé (Team Lead)
Context
Document signing platform · Enterprise
17
Interviews across customers, competitors, and internal users
3
Proto-personas defined from research
35
Participants in the Design Sprint
2
Directions explored: traditional vs conversational
01 — At a glance

What this
project covers.

02 — Problem

Works for simple use.
Not complex ones.

The document sending flow works well for simple use, but becomes less efficient for complex ones.

As volume or complexity increases:

Effort increases
What works for one document doesn't scale as frequency or configuration needs grow.
Confidence can drop
Without clear guidance, users aren't sure their setup is correct before sending.
Steps move outside the flow
Additional steps end up handled outside the main flow.
03 — Challenge

Improve efficiency
without adding complexity.

How might we improve efficiency and confidence in document sending without adding more complexity to the experience?

04 — Opportunity

Reduce friction.
Improve confidence.

Reduce friction in repetitive tasks and improve confidence in configuration.

Key opportunities identified:

Reduce manual repetition
Recurring tasks shouldn't require the same effort every time.
Introduce smart defaults
The system should assume sensible behaviors instead of asking everything upfront.
Guide instead of asking everything
Step-by-step guidance reduces the cognitive load of full configuration upfront.
Shorten time to send
Fewer decisions between intent and execution means faster, more confident completion.
05 — Approach

Reframe around
efficiency and confidence.

We reframed the problem around efficiency and confidence.

Instead of exposing all configuration upfront, we explored:

Target Reduce interaction effort in multi-step flows
Expected behavior change From multiple steps and repeated checks — to completing the process in one session, with confidence
06 — Process

From research
to a focused experiment.

1
Discovery
Interviews with 17 participants · Quantitative data analysis · Benchmarking · Usability testing on the current flow
2
Design Sprint (3 days)
35 participants from different areas · Adapted format · Final output: Crazy 8s
Goal: align on the problem and explore solution directions collaboratively
3
Concept Exploration
Two directions explored: an improved traditional flow and a conversational approach
4
Decision
The conversational direction was selected for further exploration — not as a full solution, but as an experiment
5
Experiment Design
Intentionally started simple. Target: Fast Operator · Scope: 1 document, up to 5 signers, minimal configuration
Principles: assume defaults · ask only what matters · guide step by step · allow edits without blocking
The conversational flow acts as a shortcut, not a replacement.
6
Hypothesis
Do people choose a faster path when everything is already standard?
Usability tests and interviews

Discovery — usability tests and interviews across different user profiles

Research

3 proto-personas
defined from research.

Synthesized from interviews and support data, the proto-personas helped the team align on who we were designing for — and why the current flow wasn't working for all of them.

Proto-persona detail

Proto-persona — synthesized from interviews and support ticket analysis

Proto-personas overview

Proto-personas — full overview of the 3 profiles mapped during research

Benchmarking

What others do.
What still falls short.

Benchmarking helped identify patterns in how similar platforms handle sending flows — and where most still require too much from the user.

Benchmarking comparative table

Comparative benchmarking — how competitors handle document sending flows

Benchmarking overview

Benchmarking overview — full competitive analysis across platforms

Design Sprint

35 people.
3 days. One direction.

With 35 participants from different areas of the company, the sprint was adapted to allow diverse voices to contribute. The final output was a set of Crazy 8s that guided the two concept directions.

Goal: align on the problem and explore solution directions collaboratively — before any design decisions were made in isolation.

Design Sprint overview

Design Sprint — 35 participants from product, design, engineering, and beyond

Facilitating the Design Sprint

Facilitating the sprint — keeping 35 people aligned across multiple sessions

Validation

What we
measure.

To validate the experiment, we focused on behavioral signals — not just satisfaction:

Adoption of the shortcut
Do users actively choose the faster path when it's available?
Time to send
Does the conversational flow reduce time from intent to completion?
Number of clicks
Is the interaction effort meaningfully lower than the standard flow?
Completion rate
Do people who start the conversational flow actually finish it?
07 — How AI was used

Faster execution.
Same grounding.

NotebookLM
Used to cluster interview transcripts and connect support data with qualitative insights.
Figma Make
Used to translate sprint decisions into navigable prototypes in under 2 days.

AI supported execution speed. Decisions remained grounded in real user behavior and team alignment.

NotebookLM AI synthesis

Research synthesis — AI-assisted clustering of interview transcripts and support ticket patterns

08 — Why conversational

Step by step.
Less cognitive load.

Instead of requiring full configuration upfront, the system guides the person step by step and reduces cognitive load.

The focus is not on adding features, but on helping the person complete the task faster with less effort.

Experiment design and handoff

Experiment design — conversational flow specs and interaction details

09 — Key decisions

Intentional
constraints.

Start with the simplest use case
1 document, up to 5 signers, minimal configuration. Validate behavior before increasing scope.
Validate before expanding scope
Don't build complexity until simpler patterns are confirmed to work.
Keep the existing flow available
The conversational flow is an optional path — not a replacement for the current experience.
Treat it as an optional path
Users who prefer the traditional flow can still use it. The conversational flow is a shortcut, not a mandate.
What this is not

A focused
experiment.

This is a focused experiment.

10 — Key takeaway

Validate speed first.
Then complexity.

Speed matters. The next step is to validate whether a conversational chat is the best way to deliver it.

If people choose this path when the task is simple, that signal supports expanding the approach.

If not, we learn early and adjust direction.

Back to
All case studies
Next case
Journey Maps for a Complex Loyalty Program