A mockup can look complete while representing only a narrow range of the information a service needs to handle.

I encountered this while designing a provider directory. Bringing real data into staging and development surfaced variations our mockups had not fully accounted for: phone extensions, U.S. military medical facilities outside the country, and differences in how address and contact information needed to be presented.

These were not simply unusual values to squeeze into existing fields. They raised questions about page space, information hierarchy, and the sequence in which people would encounter the data.

A phone number without an extension can look straightforward. Add an extension, different phone types, and records with missing information, and the interface has more decisions to make. An address pattern that looks sufficient for a domestic facility may not cover an overseas military location.

That is why I see the prototype and the working implementation as parts of a continuing learning loop. Realistic records in staging or development expose conditions that selected mockup examples can miss. We can then return to the prototype to explore a better response before committing to implementation.

In this case, our proposed response separates the needs of editing from the needs of reading.

During entry, users would select the location or phone type, with the applicable elements exposed for editing. In the display view, fields without values would be omitted. The intention is to make space for meaningful variations while reducing the noise of empty fields.

That is a design hypothesis. It has not yet been implemented or validated with users.

Our planned testing will ask participants to add an extension to a facility’s phone number and enter a military medical facility’s overseas address. The prompts should describe the situation without naming the control we expect people to use.

We need to observe whether participants can identify the appropriate options, enter the information, and understand the resulting display. Hiding an empty field may make a page quieter, but that alone does not tell us whether people can find where to add the missing information.

Before those sessions, proxy reviews and AI agents working from defined personas can help identify potential problems and sharpen the research questions. Their findings remain hypotheses. Agreement between agents is not evidence that actual users will succeed.

The practical lesson is to make data variation part of design exploration early. Include incomplete records and less common contact and address patterns alongside the ideal examples.

A useful prototype helps a team identify what it still needs to learn. Real data makes some of those unanswered questions much harder to miss.

Commentary reflects an independent perspective and does not represent any current or former employer, client, or affiliated organization.

Written with AI assistance and approved by the author.