Denis Kharchenko — Lead Product Designer
RateWise · Case Study
RateWise had built a mortgage simulator tuned to find the lowest rate. Brokers don't sell rates, though. They sell the judgment of which product a particular borrower can carry. So the tool sat unused, and advisors quietly went back to Excel.
The Simulator shipped, and brokers ignored it. They ran their numbers in Excel instead. It was faster, even though Excel couldn't share a result, save anything, or turn into a loan request. Internally this read as a UX problem: clean it up, smooth the funnel. What I found was narrower and more awkward. The tool had been built to chase the cheapest rate, while a broker sitting across from a client is trying to work out which product fits the person in front of them.
So I split it in two. Advisory is a fast wizard meant for the meeting itself: rough inputs, readable output, something you can run while the client watches. Fulfillment stayed as the heavier data-entry flow for lender submission, and the two keep in sync: whatever gets entered in Advisory carries over the moment a broker decides to commit. After the redesign, a simulation took about four minutes instead of twelve. Over a three-month beta with 13 advisor accounts, advisor adoption of the Simulator rose 14%, 78% of simulations were shared with borrowers, and simulation-to-loan-request conversion rose 9%.
Results: 4 minutes per simulation, down from 12; advisor adoption of the Simulator up 14%; 78% of simulations shared with borrowers; simulation to loan request conversion up 9%. Measured during a 3-month beta with 13 advisor accounts.
RateWise is a B2B platform used by mortgage advisors and brokers across Europe, and the Simulator was its centrepiece. It was built, reasonably enough, to find the best available rate. The trouble is that the rate isn't what a broker gets paid for. Banks already publish calculators. What an advisor brings is the read on a specific borrower (the shape of their income, the timeline of the project, how much risk the file carries, where the LTV lands) and the match to a product that holds up. A tenth of a percent on the rate matters far less than picking something that won't push the borrower past their debt-to-income limit half a year in.
The original Simulator never engaged with any of that. It wanted precise, mandatory figures before it would tell you anything, returned its results in dense financial language, offered no way to compare options, and no way to hand a summary to the person across the desk. A very thorough calculator, which wasn't what anyone in the room needed.
Where it started: the original Simulator was a dense form that demanded exact figures up front and gave back little an advisor could use mid-conversation.
Research ran on two tracks. One was a structural audit, separating the data that's genuinely required by law from everything the product had simply gotten into the habit of asking for. The other was time with advisors, watching how they work a file rather than how the product assumed they did.
One advisor said it plainly: "I don't use RateWise's simulator because it takes too much time, and the results are worse than my manual Excel sheets."
Five complaints, one underlying shape. The Simulator was a database with a form on top, when a broker mid-meeting needs something closer to a sketchpad.
The Simulator user journey runs through the advisory simulation flow, ending in a loan request.
Sophie is forty-five, a senior loan advisor in Brussels, fifteen years in mortgages. She moves fast, sees around five clients a day, and likes to land on a product before the borrower has left the room.
We didn't have to invent her. She's the advisor RateWise was already losing to Excel, and her line from the interviews stayed taped above my monitor for the whole project: "I don't use RateWise simulation because it takes too much time and the results are worse than Excel calculations."
Designing for her meant finally accepting the thing the product had been resisting: the simulation has to hold up inside the meeting, not sometime after it.
Mapping the everyday workflow turned up two things the product had underweighted. Borrowers routinely combine loans or pledge extra collateral to bring their LTV down, and a borrower's DTI quietly decides which lender products are even on the table.
Before committing any pixels, I sketched three ways the screen could go and put them in front of the team. The one on the right held up: inputs on the left, the financial picture on the right, with the split between cost and financing doing the structural work. The other two folded that split into a single crowded screen, which was exactly the trap we'd come from.
The right-hand sketch became the Advisory flow's Financial Plan screen. The other two earned their keep differently, mostly by showing me what to leave out.
Three things showed up in every flow and clearly mattered more than the rest:
People could now get through a simulation start to finish. The extra fidelity also dragged out the edge cases the sketches had let us ignore:
A feature request fell out of this too: side-by-side product comparison for one or two borrowers. The nice-to-have we'd parked in the scoping grid suddenly had people asking for it.
The Add Project step in the redesigned Advisory flow shows an LTV gauge, cost breakdown, and total financing, all straight out of the lo-fi tests.
The mortgage specifics are almost incidental. I've watched the same failure play out in products that have nothing to do with lending. The interface optimises for a number that's easy to compute and easy to defend, and the decision the user came to make goes unsupported.
The engineering was never the problem. The Simulator was organised around its own database when it should have been organised around the half-hour an advisor spends with a client. When the database wins that argument, people don't file a complaint. They open Excel.
More case studies and notes: denisxko.com · full text of everything: /llms-full.txt
© Denis Kharchenko. All rights reserved.