Industry

E-commerce, Healthcare

Client

Dr. Max Group

Rapid prototyping: DateOfBirth

Green background featuring the words 'Rapid Prototyping' in white text.
Green background featuring the words 'Rapid Prototyping' in white text.
Green background featuring the words 'Rapid Prototyping' in white text.

Executive Summary

While buying OTC online in Romania, unregistered users must enter their date of birth. Our existing three-dropdown solution was painful to use, and the team debated switching to a calendar datepicker. Figma couldn’t express real calendar logic or input behavior, so we built working prototypes with AI-assisted coding tools and tested them the next day.

The component that broke our usual process

Watching people scroll 30+ years in a year dropdown made the problem obvious. We hypothesized that a proper calendar might help, especially on desktop, but we couldn’t validate the real interaction in Figma. Proper behaviour and interactions are where datepickers live or die, and those need code.

Why design tools weren’t enough

We tried to simulate it in Figma (and Figma Make), but the calendar either couldn’t render the MUI component or fell apart under interaction, spinning us in circles. For a truthful test, we needed a real component with correct behavior.

Building functional prototypes fast

Using bolt.new we generated a clean React implementation of MUI Date Picker configured for birthdate input. When bolt couldn’t preview on mobile, we moved the working code into Macaly to get a public, phone-ready prototype. In parallel, we used Lovable to build the comparison variant: three separate inputs (DD/MM/YYYY) following the UK Government Design System pattern. Total time with switching and cleanup: roughly 45 minutes.

two datepicker variants
two datepicker variants
two datepicker variants

What we tested

We put both variants in front of five participants in quick, face-to-face sessions. We looked at discovery (how people start), focus behavior (what happens when they click the input), path to completion (calendar navigation vs. typed inputs), and common errors. On mobile, we also checked how reliably people could open/close the calendar and recover if they clicked away.

Office meeting room with several people seated at desks, two monitors at the front displaying a video call or presentation.
Office meeting room with several people seated at desks, two monitors at the front displaying a video call or presentation.
Office meeting room with several people seated at desks, two monitors at the front displaying a video call or presentation.

Test results

The three-input pattern performed flawlessly. Everyone knew what to do and completed the field quickly. It aligned with prior expectations and minimized surprises. The calendar datepicker worked but had friction. Some users clicked into the input and were confused when the year was highlighted instead of the calendar opening. Others opened the calendar, closed it, then reopened it before proceeding. Nothing was “broken,” but small behaviors added cognitive load, especially on mobile. We ended with a clear direction: ship the three-input solution now; capture a checklist for any future calendar work (open/close rules, focus on open, clear keyboard paths, mobile reliability, and explicit formatting).

Decision & impact

We shipped the three-input DOB pattern, simplifying the OTC purchase path and reducing friction where it mattered. More importantly, we proved a repeatable approach: when interaction truth matters more than visuals, designers can code functional prototypes, validate quickly, and make evidence-based decisions without waiting for a full dev cycle.