Industry
E-commerce, Healthcare
Client
Dr. Max Group
Rapid prototyping: Common Map
Executive Summary
Our checkout map kept failing usability tests. That’s risky in a conversion-critical step, so we needed to act. Standard Figma prototypes weren’t enough. We had to test real search, real density of locations, and three variants with different behaviors. I built a production-like prototype using Google data and our actual places (pharmacies, pick-up boxes). I coded it in Cursor, connected Google APIs, imported our locations from CSV, and iterated until it behaved like the live site. We tested three variants end-to-end and selected one to refine in the next iteration.
The problem we were solving
In recent qualitative and evaluation studies, users struggled to find and select pick-up place in the map. Search was usability hell, the map did not behave correctly, and the whole experience was a amess. Because this sits in checkout, the impact is direct. We needed a realistic way to evaluate solutions with real data and authentic behavior before committing development time.
Why normal prototypes weren’t enough
Figma was perfect for visuals, not for live-like search, API integration and different, complex layout interactions. We also needed to redefine search logic and interaction defaults, which required real inputs. A believable prototype had to let users search naturally, see their actual nearby options, pick the place they usually use with production-like behavior.
Paths considered
Building three full variants in engineering would be slow, capacity-heavy, and hard to maintain in parallel. “Auto-code" (Lovable, Bolt.new) shortcuts weren’t predictable enough and gave too little control for our constraints. I chose to code the prototype myself in Cursor, with the help of their Cursor AI. Figma and Cursor communicated via MCP, I wired Google APIs, loaded our places from CSV, and refined behaviors until it felt like production.
Building the production-like prototype
I implemented three variants with distinct interaction behaviors and search defaults, all reading from the same data source so comparisons were fair. The prototype supported natural search, nearby browsing, filtering, selection, loading, feedback and intended map behaviour. It looked and behaved like production, which made sessions smooth and the findings trustworthy.
Testing & results
Sessions on the coded prototype let people search, find, and select their real, familiar place. No major blockers across the three variants, which confirmed overall viability. Variant cues mattered. A visible map/list switch (segmented control) was discovered faster than a floating action button. A mini-map in list detail improved orientation. Recent searches sped re-selection. Gaps were clear. PSČ (postal code) didn’t always resolve; “Enter to confirm” wasn’t available in the overlay; default sort wasn’t obvious; filters were hard to discover; provider labels led some to assume a location was “full” rather than simply unavailable.
Decision & next steps
We selected the strongest variant based on the sessions and rolled its interaction model forward. As we iterate further, the prototypes and their behaviors now give engineering a concrete base.