technical prototypingvalidationtechnical

Prototype validation

Should prototypes have validation? A four-level framework for fidelity that matches the research you're running.

The debate

There’s a long-standing discussion about how much fidelity a prototype needs. My position: if you’re running usability testing, the prototype should be as close to the real service as the research question requires. Sometimes low fidelity is enough. When you’re testing flows, errors, and edge cases, validation matters.

A four-level approach

  1. Branching: Does the prototype follow the right paths?
  2. Passing data: Does information persist correctly between screens?
  3. Conditional logic: Do the right options appear based on prior answers?
  4. Error validation: Do users see meaningful errors when something goes wrong?

Implementation

For empty required fields, we used HTML form validation with data-required attributes and custom error messages. A small JavaScript layer handles the error summary and inline messages.

<fieldset data-required data-error="Enter the Reference Number" aria-required="true">
  <label for="reference">What is the Reference Number?</label>
  <input id="reference" name="reference" type="text">
</fieldset>

Error state, validation message and summary

For server-rendered prototypes (e.g. Nunjucks + Express), we moved to express-validator for server-side validation, more control, clearer separation of concerns.

The principle

Prototype quality is a design decision. The closer the prototype behaves to the real thing, the more reliable the research. If users can’t trigger errors, you won’t learn how they respond to them.