Coded prototypes: what to validate before handing over an interface

An interface can look finished in a presentation while still leaving questions unanswered: what happens when the title takes up three lines? How do you correct an error without losing what you typed? Where does focus go when a dialog closes?

A coded prototype lets you investigate those questions in the browser. Its value depends on the decisions it helps you make. Before building it, define which uncertainty you want to reduce, which behaviour you need to reproduce and what evidence you will consider sufficient to move forward.

When to use Figma and when to move to code

Figma is useful for exploring hierarchy, composition, visual alternatives and journeys. If you need to compare two navigation structures, a simple representation may be enough. Coding every variant too early adds work that may not yield any learning.

Code becomes valuable when the question depends on real browser behaviour: typing into a form, navigating controls with a keyboard, adapting content to different widths or checking dynamic updates with a screen reader. GOV.UK highlights the realism of these prototypes for researching mobile and desktop interactions. Making prototypes.

A practical rule: choose the lightest medium that reproduces the difficulty you need to observe. Both tools can coexist. You can explore the structure in Figma and code only a complex selector, without rebuilding the entire product.

Define the scope before building

Write a specific hypothesis: “The person will be able to correct their booking after an error without entering the details again.” Define the boundaries of the journey, simulated states and test tasks. Also clarify what is out of scope, such as authentication, persistence or live availability.

That agreement helps distinguish a design failure from a known limitation of the prototype.

Responsive design: check what happens between two screens

Two screenshots, one mobile and one desktop, leave a lot unexplored. Change the width continuously and watch for the point at which the relationship between content, controls and available space breaks down.

Test long titles, buttons with long labels and rows with uneven amounts of information. Check whether the visual order preserves the task’s priorities. A fixed bar may seem convenient until the virtual keyboard appears and reduces the usable area.

Include zoom. WCAG’s Reflow criterion provides for vertically scrolling content to be presented at a width equivalent to 320 CSS pixels without losing information or functionality or requiring two-dimensional scrolling, with exceptions such as certain maps or tables. Understanding Reflow.

As a practical check, zoom a 1280-CSS-pixel-wide window to 400%. Then test on a real device: emulation is useful for exploration, but does not reproduce every interaction condition.

States: design for waiting and recovery too

For each important action, prepare at least the relevant initial, loading, success, empty and error states. Add insufficient permissions or a lost connection when they affect the journey. Not every component needs every state.

The useful question is what the person can do next:

• If a search returns no results, can they change the filters?

• If submission fails, is what they typed preserved?

• If an operation takes time, is it clear that it is still in progress?

• If they press twice, is there an understandable response?

Make these scenarios repeatable. A small scenario selector makes review much easier than relying on an error appearing by chance.

When a status message updates without moving focus, it needs to be available to assistive technologies. W3C explains this requirement for results, waiting states, progress and errors. A visible “Changes saved” notification may need an appropriate status region; moving focus to every notification can interrupt the task. Understanding Status Messages.

Keyboard and accessibility: work through the whole task

Disconnect the mouse and complete the journey. Check that actions can be performed with a keyboard, that focus is visible and that the order lets you understand where you are. WCAG requires operability through a keyboard interface, with a limited exception for functions that depend on the path of movement. Understanding Keyboard.

Start with native HTML elements where appropriate. Then review accessible names, labels and error messages. An automated audit helps detect problems, but should be combined with manual tests and, where possible, research with disabled people.

Pay attention to dialogs

A modal dialog requires decisions about focus: it needs to enter the dialog when it opens, remain inside while it is active and return to a logical place when it closes. The WAI pattern also describes closing with Escape and recommends a visible close control. Dialog (Modal) Pattern.

Test these transitions with short and long content. Adding ARIA attributes without implementing the corresponding behaviour can create a misleading experience.

Realistic content: introduce variation without exposing data

Prepare plausible fictional data: multi-part names, long addresses, different amounts, empty lists and dense lists. Include a longer translated label if the product will support several languages.

Content reveals unresolved decisions. Truncation may hide the very detail that distinguishes two options. A generic message may force someone to guess how to correct a form.

Avoid unnecessary real personal data and operations with consequences. Document which information is fictional and make it possible to reset the scenario for each session.

Performance: identify risks without promising results

Test loading under constrained network and device conditions. Observe when the main content appears, how an interaction responds and whether elements shift position unexpectedly.

These dimensions relate to LCP, INP and CLS. web.dev distinguishes lab measurements from real-user data: the former are useful during development but do not replace the latter. A conventional Lighthouse run without interactions also does not measure INP. Web Vitals.

In a prototype, record risks and test conditions. A simulated API, placeholder images or the absence of external services prevent results from being extrapolated directly to production.

A hypothetical example: changing a booking

Imagine a flow for changing the date of a booking. The team prepares three scenarios: availability, no spaces available and a save failure.

The test asks the person to choose a date, confirm and recover from the error. Observe whether they understand what happened, retain their selection and find how to retry. Run the test with a keyboard and zoom too.

If the notification falls outside the visible area or the selection disappears, there is a specific decision to revisit. The expected outcome of the session is evidence to adjust the flow; any subsequent improvement will need to be verified, without attaching invented figures to it.

Checklist for handing over the prototype

• Hypothesis, tasks and limitations documented.

• Intermediate widths, zoom and variable content reviewed.

• Relevant states repeatable and recovery defined.

• Keyboard journey, focus and accessible messages checked.

• Fictional data and a resettable scenario.

• Performance risks recorded with their test conditions.

• Findings, decisions and open questions shared.

The handover should clarify what we learned and what still needs to be verified. GOV.UK warns that prototype code should not simply be copied into production. Security, architecture, integration and operational quality require their own review. A clearly scoped prototype supports better decisions without confusing a convincing demonstration with a ready product.

Sources

1. GOV.UK Service Manual. Making prototypes.

2. W3C WAI. Understanding Success Criterion 1.4.10: Reflow.

3. W3C WAI. Understanding Success Criterion 4.1.3: Status Messages.

4. W3C WAI. Understanding Success Criterion 2.1.1: Keyboard.

5. W3C WAI, ARIA Authoring Practices Guide. Dialog (Modal) Pattern.

6. web.dev. Web Vitals.