04 · Solution
Every screen answers a question the user is actually asking.
Instead of forms, conversations. Instead of dense tables, summaries that are easy to scan. Each step has one job — and tells you exactly what comes next.
Approval will not be possible: the payment exceeds the client's maximum capacity.
- Amount
- $200,000
- Insurance
- $680
- Annual rate
- 35%
- Risk level
- Excellent
- First payment
- $13,000
- Second payment
- $13,500
capacity$10,000
- Requested amount
- $50,000
- Term
- 8 months
- Insurance amount
- $800
- Payment capacity
- $10,000
Amounts in multiples of $500
- Requested amount
- $50,000
- Term
- 8 months
- Payment capacity
- $10,000
Amounts in multiples of $500
The second instalment nearly touches your $10,000 ceiling. Raise the term to 14 months to bring it down.
The prospect's risk level caps the maximum amount at $200,000.
- Requested amount
- $50,000
- Payment capacity
- $10,000
Valid range: $30,000 — $200,000
- Insurance
- $140
- First instalment
- $8,500
- Second instalment
- $9,600
- Payment per thousand
- $450
- Annual rate
- 35%
- Total amount
- $56,600
Simulated conditions are not saved until confirmed.
Swipe to see the five screens
One screen, one interaction
Each number answers the user's need to know which banking factors to adjust — to set a more realistic amount with a lower long-term debt ratio.
Information at a glance
By keeping the loan data pinned at the top, the decision to use the component to simulate better conditions feels reassuring and clear.
Words that sound like the user
Interactions, keywords, and scannable features were written in language close to the user — which builds more trust in the process and the next steps.
What we gave up to get there.
What we deferred
Showing the simulator at the very start of an application
What users asked for was to see the simulator before being offered a credit. But because of the data drop-off, we first needed bureau data, monthly sales and business details — the minimum required to show a figure that means anything.
The hardest disagreements were not about design — they were about implementation, with the enabling teams: Cloud, Database and Offer Service, the service that adjusts amortization rates from the risk and bureau evaluation.
Their position was fair: a simulator that renders without the factory offer data can show adjusted amounts that are inconsistent, or simply hang when the service does not answer. I did not push the simulator through as a pure front-end feature.
What I decided instead: no state of the simulator would ship without a defined behaviour for missing or late data. That turned an argument into a shared contract — loading, timeout, out-of-range and capacity-exceeded became designed states, and the release stopped depending on the service always being up.