A trust decision map for unfamiliar financial products
People commit money when a product answers the questions that matter before payment and keeps answering them afterward. Polish cannot carry that trust on its own.
I built this model from the Farmcrowdy sponsorship journey, where first-time users had to understand what they were funding, what would happen after payment and how progress and returns would be communicated. It applies to savings, investment, insurance, lending and other products that ask people to trust a new financial arrangement.
Map the decision before mapping the screen
A funnel shows where people leave. A decision map explains what they still need to know. Start with the user’s questions at each stage, then decide what evidence, terms, progress and recovery the product must provide.
| Decision stage | Question in the user’s head | Product response |
|---|---|---|
| Understand | What am I putting money into, and how is value expected to return? | Explain the unit, use of funds, duration, return logic and material limits in plain language. |
| Compare | Which option fits my amount, timing and appetite for uncertainty? | Make differences visible. Do not force users to open several pages and remember the terms. |
| Verify | Why should I believe this product, asset or operator exists? | Show the responsible operator, location or underlying asset, terms and evidence that can be checked. |
| Commit | What exactly happens when I pay? | Show the total amount, irreversible point, confirmation, expected timeline and immediate next state. |
| Follow | What is happening now, and is it still on plan? | Provide dated updates, milestones and specific exceptions. Avoid generic progress theatre. |
| Resolve | What happens if the plan changes or something goes wrong? | Name the exception path, responsible party, support route and likely timing before the problem occurs. |
| Complete | What did I receive, and where is the final record? | Show settlement, outcome, receipt or statement, then make the next decision clear without hiding the completed one. |
Give every promise an owner
Trust falls apart when the interface makes a promise that no team, partner or policy can actually honour. For every claim on the page, record who owns it, where the evidence comes from and what happens when the claim stops being true.
- Who owns the promise inside the organisation?
- What evidence can the product show at the moment the promise matters?
- How often does that evidence need to be refreshed?
- What part is guaranteed, estimated or dependent on another party?
- What will the interface say when the original timeline changes?
- Can support see the same terms and evidence the user saw before payment?
Treat post-payment clarity as part of conversion
The trust problem continues after the first purchase. A user who pays and then enters a silent dashboard learns that the product was clear only while selling. The post-payment experience should preserve the same level of explanation, evidence and next-step visibility as the purchase flow.
- Confirm what the user bought and the terms that applied at payment.
- Show the current stage, last update and next expected milestone.
- Separate normal waiting from a real exception.
- Keep historical updates and documents available.
- Explain settlement or return with the same precision as the original payment.
Use the worksheet
The worksheet gives each decision stage a row for the user question, evidence shown, promise owner, timing, uncertainty, next action and support path. Use it with product, legal, operations, customer support and design before polishing the funnel.
A credible financial-product journey makes uncertainty visible, assigns an owner and keeps the next step clear.