Role
Product designer
Client
Independent, but inspired by previous work for Toyota Motor Europe
Year
2026
TL;DR
A finance calculator I designed worked smoothly with predictable mock data, but real APIs introduced delays, timeouts and connection failures we had not designed for. I built a coded prototype to simulate those conditions and design clearer, more trustworthy responses.
Earlier visibility
Real-world behaviour exposed before development
Shared understanding
Intended behaviour made tangible for developers
Design tooling access
Cursor expanded from developers to designers
Everything worked until the real API hit
I worked on Toyota Motor Europe's new buy online service, from design system creation through to production. The finance calculator was one part of it, and the part where things started to break.
Figma prototypes and mock data worked fine. But once real APIs were integrated, it lagged. In a high-stakes stage of the journey where we needed to gain trust, we were falling flat. Our team didn't have direct access to the backend team during design, so API behaviour wasn't something we could test against until integration. We shipped a loading overlay as a short-term fix, but it didn't solve the real problem.
Building a prototype designed to break
I built a prototype specifically to test the conditions our earlier designs had missed: delays, fluctuating connections and timeouts. Users could not control those conditions, but the interface could give them a clearer sense of what was happening.
The moments where an experience could fall apart are precisely the moments where product builders need to step up. A slider that recalculates a monthly price at every step feels broken regardless of added latency. But trigger the calculation only once the user stops dragging, and the same interface feels completely different.
Every handoff between systems is a chance for things to go wrong
Building this prototype gave me something static design never could: a way to understand what's happening underneath the interface.
Every deliverable I had produced until this point assumed an instant response. That assumption was mine, but it was also reinforced by a process in which system behaviour remained invisible until development.
Delay as a design material
Once I understood where the delays lived, I stopped seeing them as problems. Each one is a moment when a user decides whether the product works for them. Each one is a design opportunity.
Static tools reinforce the invisibility of these moments, which is why they're often overlooked until build, when the cost of fixing them is highest.
Without the counter, the price snaps suddenly from one value to the next. With it, the price counts from the old value to the new one: the user sees the change, not just the result.
Making design intent tangible earlier
I shared the prototype with developers to understand whether it could work as more than a design exploration. It gave them a clearer reference for how the interface should behave under real conditions, rather than leaving that behaviour to be interpreted from static screens.
The prototype creates a tangible proposal for how latency could be handled in future work. This way of working has also become integral to my practice: AI-assisted prototyping helps me make behaviour tangible earlier and communicate clearer intent to developers. I’m now exploring how to push this further, with reusable skills that could document what motion happens, where it happens, and why.
Before this case study, Cursor access had been limited to developers, with wider design access considered too technical. Sharing this work internally helped provide a practical case for broader access and contributed to Cursor being explored as a design prototyping tool with major clients — including Toyota Motor Europe, whose product first prompted this exploration.
Understanding what happens between a user’s action and the interface’s response has become central to how I design.