Guessed Values Are Not Data: Mark Mockup Placeholders
Unmarked guesses in a mockup survive into official presentations. Label every value's origin so a deliverable stops lying about its certainty.
TL;DR
Mockups filled with unmarked guesses look authoritative, and one screenshot turns fabricated numbers into client expectations. Fix: label every value either "Source: catalog" for verbatim data or "PLACEHOLDER, question #9" for guesses, tied to a numbered open question. A guessed value is not data; without provenance markers, developers build validation on fiction that costs far more to rewrite.
While reviewing a facility-booking form mockup with a client, I noticed something on the screen. Some numbers, like the price-package range and the support-facilities list, never came from the client. I had guessed them so the mockup would look complete and professional. Not a single marker on screen distinguished real client data from my assumptions.
At first I treated the mockup as just a temporary picture. Made-up details felt harmless because their only job was to give an early visual impression. The client would surely understand it was design illustration, or so I thought.
In reality, an unmarked guess survives until it becomes a screenshot in an official presentation. One sentence, "but the mockup says so", is enough to move a guessed number onto the expectations list. A deliverable that mixes verbatim values from the source with unmarked guesses is lying about its own certainty.
The Illusion of Certainty in a Mockup
In the KotaPortal project, the booking form mockup had a support-facilities list and an activity-level dropdown that the source document never fully specified. The source document was cut off mid-list, so some of the options on the mockup were my plausible guesses to keep the layout intact and reviewable.
The fix: every value that did not come from the source was marked as a placeholder bound to a numbered open question for the client, items 7 through 10. The questions were specific: the price package and its pricing basis, the full support-facilities list, the official list of bookable facility names, and the activity-level options. The sections that were verbatim from the source, form sections A through G, stayed untouched. One sentence went into the design doc: values not from the source must not be treated as client data before they are answered.
The simplest form of this marking is just two labels. "Source: catalog" for values copied verbatim, and "PLACEHOLDER, question #9" for guesses. The labels never need to appear in the final presentation; they live in the working file and the question log. What matters is that every number traces back: which document it came from, or which question ticket it waits on.
In practice this starts smaller than it sounds. When copying a value from the source document into the mockup, I now keep its origin attached: a small note in the working file naming the catalog item it came from. A deliberately guessed value gets a different label plus a question number. Those two labels then decide each value's fate: source-labeled values just get used, guess-labeled values need an answered ticket before the mockup can be treated as reference material.
If you have ever seen a demo whose numbers look suspiciously neat, you were probably looking at placeholders whose labels got trimmed. That is no reason to be shy about filling a mockup with guesses; a mockup needs numbers so the proportions can be judged. What it needs is honesty about where each number came from, and that costs one label.
If a developer receives a mockup without markers, they will build logic on top of guessed numbers. If the number is wrong, the form validation gets rewritten. That costs far more than one marker label at the design stage.
TBC: The Engineering Habit Developers Skip
The requirements-engineering guide has standard designations for unconfirmed values: To Be Confirmed for values still under evaluation, To Be Determined or To Be Supplied for values whose existence is known but are not yet available [5]. Marking provenance is often skipped because it looks like bureaucracy that slows things down. It is actually the cheapest quality practice in the whole workflow. The principle fits in one sentence: a guessed value is not data.
My Desk Rule
From now on, a mockup or spec that cannot show which values are verbatim from the source and which are guesses does not leave my desk. Every guess gets a traceable question number, then gets deleted once the official answer arrives and the document is updated.
This discipline removes ambiguity before a single line of code is written. When a number shows up on screen, everyone knows whether it is a fact from the client or a temporary space filler. If it is a filler, it is not a basis for business decisions.
Sources