Practice 02.02 · Retention

Build trust before a key action

Before registration, verification, or a transaction, users often stop because of one specific doubt—not because the button is weak. Answer that doubt at the moment of decision.

Practice outcomeA one-doubt card with the user question, a verified answer, placement in the interface, an owner, and a validation metric.

75 minutes for the first analysis

In plain language

Trust comes from a clear answer, not a promise

A trust moment is a short explanation next to an important action: why the data is needed, what happens after the tap, how long the process takes, and where to go if something breaks. It must be backed by how the product actually behaves.

What you will need

One screenPick a step with a visible drop-off: registration, document upload, transaction confirmation, or the first deposit.

Live questions10–20 support requests, reviews, or cancellation reasons tied to that exact step.

Answer verificationA support representative and the process owner who can confirm the timing, conditions, and a safe help channel.

Terms in plain language

When to use it

Users reach an important action but postpone or cancel it, and support keeps answering the same question about conditions, data, or status.

In plain language

Where to find the real doubt

Do not guess the user's fear from a mockup. Connect the drop in the data with the user's words and the actual rules of the process.

Drop-offs at the step

In the funnel, compare screen opens, taps on the primary button, successful completions, and technical errors.

Without analytics, do ten walkthroughs and ask three new users to say out loud why they are — or are not — ready to continue.

Support and cancellations

Group the questions: why the data is needed, is it safe, how long it takes, what the conditions are, and what to do on error.

If tags are not set up, manually review the last 20 messages about the chosen step.

The real process

Verify the answer with the operations team, support, and a legal specialist wherever conditions or personal data are involved.

If the team cannot back a promise, do not publish it — fix the process first or state an honest limitation.

Remove one main doubt

Pick one critical screen

Start with a step where the drop-off is visible and the action requires trust. Do not try to rewrite the whole journey at once.

Where to do it: The registration, verification, or key-transaction funnel.
What the result looks like: Document upload screen: 1,000 opens, 540 successful submissions, 90 technical errors.

Collect the users' words

Write down recurring questions without the team's internal phrasing. Each question should sound the way a user asks it.

Where to do it: Support requests, reviews, cancellations, and walkthrough observations.
What the result looks like: “Who will see the document?”, “How long do I wait?”, “Can I finish later?”

Choose the main doubt

Weigh frequency, impact on completion, and the risk to trust. Take one question the team can answer honestly.

Where to do it: In the first row of the doubt map.
What the result looks like: The main question: “what happens to the document after I send it?”

Put the answer next to the action

Show the timing, the next step, the conditions, or help before the tap — not in a distant help section.

Where to do it: Above the field, under the CTA, or on the confirmation screen — wherever the question arises.
What the result looks like: Under the button: “Verification usually takes up to 10 minutes. The status will appear on this screen.”

Verify the promise and the effect

Make sure the product does what the text says. After the release, compare step completion and requests about that doubt.

Where to do it: On a test account and in the report after 14 days.
What the result looks like: The status really updates, and “how long do I wait” requests dropped from 34 to 12 a week.

Practical examples

Doubt: what happens to the document

Above the upload, the team explains the purpose of the check; next to the button — the usual time of up to 10 minutes; after submission — a visible status and a help channel. All four promises are verified against the real process.

Doubt: did the transaction complete?

Instead of a generic “Processing,” the screen shows the stage, the expected time, and a safe action in case of delay. The check: step completion and the number of status requests after 14 days.

The finished artifact

A doubt map for one screen

Do not add a generic “You can trust us” block. Give a short, verifiable answer to a specific question at the point of decision.

User question	Verified answer	Where to show it	Check
Why is the document needed?	To verify identity; the data is protected	Above the upload field	Agreed with the process owner
How long will it take?	Usually up to 10 minutes	Next to the CTA	Verified over 30 days
What happens next?	We show the status and send a notification	Below the button	The status really updates
What if an error occurs?	You can continue later or contact support	On the error screen	The channel responds
Are there any restrictions?	The terms are available before confirming	A link next to the action	The text is readable without searching

First change: explain the review time and the next step right on the document upload screen. Owner — product + support. Check: step completion and status-related requests after 14 days.

Trust checklist

If an answer cannot be backed by the process or data, it must not be used as reassuring copy.

One screen and one specific doubt are chosen. The doubt is confirmed by users' words or cancellation reasons. The answer contains a fact: the why, the timing, the next step, the conditions, or help. The text sits next to the action and can be read without opening the help section. The promise is verified by the process owner and tied to an outcome metric.

How to know the trust moment helps

Step completion

Conversion of the chosen action grew without extra pressure on the user.

Clarity

Requests and cancellations about the doubt the new text answers went down.

Promise reality

After the release, the timing, statuses, and help channel match what is written.

Do not mask anxiety with a brighter button: give an honest, verifiable answer where the user makes the decision.