20 UX rules to follow when designing a prototype

01Define the decision the prototype should support

Before drawing, write one question: Can a customer change a booking without phoning support? That brief helps identify the screens you need. The test should lead to a decision, such as revising date selection or proceeding to development. A broad instruction to “validate the design” is usually too vague because it leaves the behaviour you want to observe undefined.

02Describe the complete primary task

Record where the person arrives from, what they already know and how they will recognise completion. A booking change does not necessarily begin inside a signed-in dashboard. It might start with an email link and finish with a new confirmation. Include the parts needed to investigate that journey; a convenient slice may exclude the actual problem.

03Design for a specific group and situation

“All customers” is not a useful testing profile. Distinguish a first-time visitor, a regular user and a staff member with different permissions. Record the device, setting and constraints. A technician wearing gloves works in different conditions from an accountant at a desk. Do not invent their preferences. Mark uncertain assumptions and investigate them through interviews or observation.

04Match the detail to the question

A rough sketch may be enough to compare two routes. Testing a form's clarity requires realistic wording and error states. GOV.UK's alpha guidance focuses prototyping on the riskiest assumptions. Tell the team what is simulated. A visually finished prototype does not establish technical feasibility or readiness for production, even when the main demonstration looks convincing.

05Use realistic content

Include long names, a missing image, no search results and a large number of records. Try a longer translation where localisation matters. Placeholder text can hide an unclear button or an unreadable table. Use safe example information. Real customer details are usually unnecessary for a navigation test, and realistic structure does not require identifiable records.

06Give each screen a clear primary action

People should recognise how to move the task forward. Name the main button after its outcome, such as “Choose a time” or “Confirm change”. Compare its emphasis with secondary options. If every action competes equally, the design gives little guidance about priority. Keep a visible route back and a way to leave the task as well.

07Keep terminology and behaviour consistent

Do not alternate between “request”, “order” and “case” for the same record unless these terms mean different things. Use the same label for the same action across screens. Create a short glossary and a set of recurring components. Document the reason for an exception. Consistency includes confirmation, filtering, saving and dismissing dialogues, as well as button colours.

08Design orientation and return routes

At each step, people should understand where they are and how to go back. Test returning from a detail page to a filtered list, closing a dialogue and interrupting a multi-step task. Decide what is retained. If the prototype always jumps to a clean starting screen, it may conceal a loss of context that customers will later experience.

09Include form labels and instructions

For every field, record its purpose, required status and constraints. Keep the label visible during entry; an example inside the box is not a substitute. W3C's forms tutorial also explains the relationship between labels and controls. Add implementation notes to the design. A static picture alone cannot demonstrate that the accessible association works.

10Show errors and a route to recovery

Prepare at least one invalid entry and one service failure. Distinguish what the user can correct from what the operator must resolve. Preserve entered information and describe the next step. Let a participant recover without help. If the designer has to explain the message, you have a specific reason to revise the wording or the flow.

11Include empty, loading and unavailable states

A list of ideal records says little about a first visit or a failure. Design what appears without data, while waiting and when the service is unavailable. For an empty result, explain whether someone should change a filter, add a first item or wait. Document each state's trigger so developers can distinguish missing records from a failed request.

12Explain consequences and confirm outcomes

Before a committing action, show what will change. Afterwards, confirm its actual result. Decide whether deletion can be undone. Avoid using one vague dialogue for removing a note and cancelling an entire order. In the prototype, investigate whether the person understands the consequence and can recognise that the task has really finished, rather than simply reaching another screen.

13Plan keyboard use and visible focus

Show the navigation order, focused control appearance and where focus returns when a dialogue closes. WCAG 2.2 on focus not being obscured requires a focused component not to be entirely hidden by author-created content. Check sticky bars accordingly. Verify technical behaviour in implementation or an appropriate functional prototype; linked pictures cannot establish it.

14Provide practical pointer targets

Review small icons, checkboxes and table actions in particular. WCAG 2.2's minimum target size criterion sets a 24 by 24 CSS pixel baseline with defined exceptions, including sufficient spacing. That is not a recommendation to shrink every button to the minimum. Give important touch actions comfortable space and try them on a phone.

15Offer an alternative to dragging

If an item moves through dragging, design another option, such as a “Move to” menu or reorder buttons. WCAG 2.2's dragging criterion describes an alternative using a single pointer without dragging, unless dragging is essential. A keyboard shortcut alone is not that alternative. Also check whether people understand the resulting order and can correct a mistaken move.

16Try narrow screens and longer text

Do not simply shrink a desktop layout. Decide which information people need first and how they will reach the rest on a phone. Try long labels, enlarged text and the on-screen keyboard. In a table, check whether an action still clearly belongs to the right record. Hiding a necessary column transfers the problem to the person using the product.

17Distinguish roles and information visibility

Prepare screens for roles whose primary tasks genuinely differ. A staff member might edit a record while a customer can only read it. Explain unavailable actions and limit unnecessary exposure of personal information. At handover, make clear that hiding a button does not implement server-side authorisation. The prototype describes intended behaviour; it cannot replace technical verification of those permissions.

18Give test participants a goal, not instructions

Say “you need to change tomorrow's booking”, rather than “open the menu on the right and choose its second item”. GOV.UK recommends tasks that do not reveal the answer. Participants need the situation and objective, not the correct route. Recruit relevant people and first observe what they try when they struggle, rather than immediately helping.

19Separate observations from explanations

“Three participants missed the date change” is an observation from that test. “The button is too grey” is a possible explanation to investigate. Record the task, location, impact and proposed change for each finding. Do not turn a small qualitative study into a percentage forecast for the whole market. Address blocked tasks and serious mistakes before cosmetic preferences.

20Hand over decisions, states and open questions

Include primary journeys, field rules, empty and error states, mobile behaviour and accessibility notes with the prototype. Mark which decisions the test supported and which remain assumptions. Review uncertainties with developers before implementation. After a change, repeat the affected task and update the original decision so the team does not work from conflicting versions.

Need to connect design, research and development? Prepare the main task, intended audience and current prototype. Our How we work page describes the collaboration process. Set the specific handover requirements around what still needs to be demonstrated in your project.