Six of every ten people abandoned the application. Not because of the rate — because they had no certainty about the credit they were taking.
The starting point
Baseline: bank landing page in Adobe Analytics, previous year vs. current, highest-volume months. After: Hotjar + moderated sessions, 15+ participants, first 80 days.
The cost
The landing showed an approximation. People could not tell whether the number described their situation or an example.
Even when the maths was right, nothing told them which variable to move so the loan would fit their business.
Without payment capacity on screen, over-indebtedness was a decision the product let people make blind.
Users did not believe the figures they saw until they verified them on their own. That hypothesis is what sent me to research before production — I had to know whether the real problem was calculation, clarity, or trust in the number.
Initial hypothesis
Research design
A comparative journey with 15 people actively looking for credit: once on the bank's live landing page, once on a simulator prototype carrying a dummy amortisation rate.
15 interviews · 5 WhysThe point was never accuracy. It was whether a number tied to their situation reads differently from a range — and it does.
The finding
In their words
"On the page it's an approximate that doesn't feel real to me. I don't know if that's my payment or an example."
Interviewee 04 · landing page"Here I can see what I'd be paying and how much room I have. That's what tells me whether I can take it."
Interviewee 09 · simulator prototypeThe call I made
The request was "build us a simulator". I decided not to take that as the problem statement.
People were not missing a calculator — they could not tell which variable to move. So I reframed the brief from showing the maths to showing the consequence of each adjustment, and that set the architecture of every screen after it.
Architecture
Move one variable and see what it does to the payment.
Two scenarios side by side, summarised before the detail.
Data capture only once the decision is already made.
The final terms restated, with nothing new introduced.
Interviews showed drop-off clustered wherever a screen asked for a decision and a data entry at once. Anything that could not be reduced to a single question got split — even when that meant adding a step.
The solution
Each number answers which banking factor to adjust, so the amount lands realistic instead of optimistic.
Terms stay visible while you simulate, so changing conditions never means losing your place.
Interactions and labels written in their language, which is what makes the next step feel safe.
The trade-off
Show me what I'd pay before you offer me anything.
Bureau data, monthly sales and business details are the minimum needed for a number that means anything. Showing one earlier would have meant showing a guess — the exact problem we were solving.
Alignment
What the flow does when the service is slow or silent.
Adjusted amounts that contradict the factory offer are worse than none.
Amortisation adjusts from the risk and bureau evaluation.
I did not push the simulator through as a front-end feature. No state would ship without a defined behaviour for missing or late data — so loading, timeout, out-of-range and capacity-exceeded became designed states, and the release stopped depending on the service always being up.
Results
Drop-off in simulation
Against the previous version, 80 days after release.
Completed applications
Time to accept the credit fell from 7+ days to 1.
Reported score
On the experience of the process and the analysis time.
Hotjar behaviour data plus interviews and moderated sessions, 15+ participants. Internal product figures, not an audited study — the share attributable to design is what the qualitative sessions support.
What I take away