Prototyping and Experimentation

Introduction

Prototyping is the practice of making an idea tangible enough to examine, discuss, and test. In user experience (UX) work, a prototype is not simply a preliminary version of a finished interface. It is an experimental model designed to reduce uncertainty. A prototype may be a hand-drawn screen, a clickable wireframe, a role-played service interaction, or a realistic simulation of a digital product.

Experimentation connects prototyping with evidence. Designers use prototypes to investigate assumptions about users, tasks, content, technology, and service delivery. The purpose is not to prove that a design is correct, but to learn whether important assumptions are sufficiently credible to justify the next investment of time and resources.

Effective prototyping therefore requires two decisions: what must be learned, and what is the cheapest credible prototype capable of producing that learning? This chapter explains prototype fidelity, prototype types, experiment design, testing practice, interpretation of findings, and the professional limits of prototyping.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the purpose and principles of prototyping in user-centred design.
2. Select an appropriate level of prototype fidelity for a research question.
3. Create paper, wireframe, interactive, and service prototypes.
4. Formulate assumptions, hypotheses, tasks, and success criteria.
5. Conduct small, ethical prototype experiments and interpret evidence.
6. Identify limitations, risks, and appropriate next steps.

1. Prototyping as a Learning Activity

A design concept usually contains several kinds of uncertainty:

• Desirability: Do users recognise a need and value the proposed solution?
• Usability: Can users understand and operate it?
• Feasibility: Can the organisation and technology support it?
• Viability: Can it be sustained financially and operationally?
• Accessibility: Can people with varied abilities use it effectively?
• Acceptability: Does it fit social, cultural, legal, and ethical expectations?

A prototype externalises decisions that might otherwise remain hidden in conversation. Once an idea is visible or enactable, users can react to something concrete, designers can identify contradictions, and stakeholders can negotiate requirements more precisely.

A prototype should be judged by its learning value rather than its visual polish. A highly realistic prototype can create a false impression of certainty, while a rough sketch may reveal a fundamental problem early. The central principle is:

Build only as much as is necessary to answer the current question.

This principle reduces waste, but it does not mean that every prototype must be crude. Fidelity should be matched to the risk and nature of the assumption being tested.

2. Fidelity and Prototype Choice

Fidelity refers to how closely a prototype resembles the proposed experience in appearance, content, behaviour, data, and context. Fidelity is multidimensional. A prototype may have high visual fidelity but low functional fidelity, or realistic interaction but unrealistic service operations.

Fidelity should increase when the research question requires realism. For example, a paper prototype is suitable for comparing navigation structures, but it is inadequate for evaluating animation timing or screen-reader behaviour. Conversely, high fidelity is often inappropriate when the team is still deciding whether the underlying concept is valuable.

A useful selection sequence is:

1. State the assumption.
2. Identify the observable behaviour or response that would provide evidence.
3. Choose the least expensive prototype that can produce that evidence.
4. Test it with appropriate participants or stakeholders.
5. Revise the assumption, prototype, or decision based on findings.

Common Prototype Types

Paper prototype. Hand-drawn screens, cards, forms, or interface components are changed during a moderated session. Paper prototypes are inexpensive and encourage discussion. They are particularly useful for early structure, content grouping, and task-flow exploration.

Storyboard. A sequence of illustrations describes a user, context, problem, action, and outcome. Storyboards are useful for testing whether a proposed experience fits a real situation, especially before interface details exist.

Wireframe. A wireframe represents information hierarchy, layout, navigation, and key controls. It may be static or interactive and usually minimises decorative styling. Wireframes help teams focus on structure rather than visual preference.

Interactive prototype. A linked digital model allows users to tap, click, type, or navigate through selected flows. It is useful for testing task completion, terminology, feedback, and transitions without implementing the complete product.

Coded or functional prototype. A small working implementation tests technical behaviour, performance, device characteristics, or integration risks. It may be discarded after learning and should not automatically be treated as production-ready software.

Service prototype. A service is prototyped through role-play, scripts, journey maps, mock forms, physical artefacts, and simulated backstage processes. It tests the relationship between customer actions, employee actions, policies, systems, and evidence of service.

Wizard-of-Oz prototype. Users believe that a system is automated, while a human secretly performs some of the proposed system’s functions. This can test demand and interaction before automation is built. It must be disclosed appropriately in research debriefing and must not mislead participants about consequential decisions.

Concierge prototype. A team manually delivers a proposed service to a small number of users. Unlike Wizard-of-Oz testing, the manual delivery may be openly described. It is useful for learning what users actually need before investing in a scalable system.

3. From Assumptions to Experiments

A prototype experiment begins with an explicit assumption. An assumption is a belief that may influence a design decision. Examples include “new users will understand the term ‘scheduled transfer’” or “customers will accept identity verification through a mobile application.”

A strong hypothesis states the expected user behaviour and the conditions under which it will be observed. For example:

When first-time customers are shown the revised payment flow, at least 4 of 5 will identify the payment date without assistance.

The statement is more useful than “the flow will be clear” because it specifies a participant group, a situation, an observable action, and a threshold. The threshold is not a universal law; it is a decision rule selected by the team according to risk, sample size, and the importance of the feature.

Experiment Components

A practical experiment plan should include:

• Research question: What uncertainty is being investigated?
• Assumption or hypothesis: What does the team currently believe?
• Prototype scope: Which screens, roles, data, or service steps are included?
• Participants: Who has the relevant experience or characteristics?
• Task: What realistic goal will participants attempt?
• Evidence: What actions, comments, errors, or choices will be recorded?
• Success criterion: What result supports continuation or revision?
• Procedure: How will the session be introduced, moderated, and concluded?
• Decision rule: What will the team do if evidence is positive, mixed, or negative?

The experiment should isolate the assumption where possible. If a participant fails, the failure may result from confusing terminology, an unrealistic scenario, an inaccessible control, or a moderator’s instructions. Researchers should avoid attributing every difficulty to the same cause.

Tasks and Prompts

A good task expresses a user goal rather than prescribing interface actions. “Find the cheapest available appointment next Tuesday and book it” is preferable to “Click the appointment filter.” The latter tests whether participants obey instructions, not whether they can use the design naturally.

Moderators should use neutral prompts such as “What are you thinking?” or “What would you do next?” They should avoid teaching, defending the design, or hinting at the expected answer. If assistance is necessary, the moderator should record the intervention and interpret the result cautiously.

4. Creating Prototypes in Practice

Paper Prototypes

Begin with the task flow rather than isolated screens. Draw only the elements required for the task: page title, primary content, navigation, controls, system feedback, and possible errors. Use separate sheets for screens, overlays, menus, and notifications. One team member can act as the computer by replacing sheets when a participant points to an action.

Paper prototypes are especially valuable when several alternatives can be produced quickly. For example, three ways of organising a library catalogue can be compared before any visual design is developed. The limitations should be stated: participants may accommodate rough handwriting, and the physical manipulation does not reproduce actual touch or keyboard behaviour.

Wireframes

A wireframe should communicate hierarchy and relationships. Important questions include:

• What information must be noticed first?
• Which action is primary?
• How are users oriented within the system?
• What happens after submission, cancellation, or error?
• What content is required for a confident decision?

Use realistic labels when language is part of the test. Placeholder text can hide problems in length, ambiguity, translation, or comprehension. A wireframe should also represent empty, loading, success, and error states where these affect the task.

Interactive Prototypes

An interactive prototype normally contains a limited “happy path” and selected alternative states. Define the boundaries clearly. If a button is not implemented, decide whether it should be visibly unavailable, simulated by the facilitator, or excluded from the task.

Before testing, inspect every link and state. Confirm that the prototype works on the intended device, that text is readable, and that interaction does not depend on accidental gestures. When accessibility is relevant, test keyboard navigation, focus order, contrast, labels, zoom, and assistive technology behaviour rather than assuming that a visually convincing prototype is accessible.

Service Prototypes

A service prototype maps the visible customer experience and the invisible organisational work that supports it. It may include:

• customer actions and emotions;
• employee dialogue and decisions;
• forms, receipts, notifications, and physical artefacts;
• systems or databases consulted;
• policies, approvals, and escalation paths;
• handoffs between departments or channels.

Role-play can expose problems that a screen prototype cannot. For example, a redesigned returns process may appear simple to customers but require staff to access unavailable information or apply contradictory policies. Testing the entire sequence reveals operational friction early.

5. Conducting a Prototype Test

A typical moderated session has five stages:

1. Introduction: Explain the purpose, confidentiality, recording arrangements, and approximate duration.
2. Context: Ask brief questions about relevant experience without turning the session into an unrelated interview.
3. Task: Present a realistic scenario and allow the participant to act.
4. Probing: Ask neutral questions after an observed action or difficulty.
5. Debrief: Explain the prototype’s status, invite overall feedback, and provide compensation or next steps where applicable.

The facilitator should distinguish observation from interpretation. “Participant paused for eight seconds before selecting ‘Continue’” is an observation. “Participant disliked the layout” is an interpretation that requires evidence. Notes should record the task, action, verbal response, assistance, and consequence.

A compact evidence table can support synthesis:

Small qualitative studies are useful for discovering issues, but they do not estimate population prevalence precisely. A finding from five participants can justify further investigation; it cannot automatically establish that a fixed percentage of all users will behave similarly.

6. Evaluating Evidence and Making Decisions

Prototype evidence may be qualitative, behavioural, or quantitative. Qualitative evidence includes misunderstandings, questions, workarounds, and emotional responses. Behavioural evidence includes task completion, wrong turns, time, and requests for help. Quantitative measures can be useful when the task, prototype, and sample are sufficiently controlled.

For a simple task, the completion rate can be calculated as:

The denominator should be defined in advance, and “completion” should specify whether assistance, errors, or partial completion count. For example, if 6 of 8 participants complete a task without assistance, the completion rate is (6 ÷ 8) × 100% = 75%.

This percentage describes the observed participants under the test conditions. It is not automatically a population estimate, especially when the sample is small or recruited by convenience. Time-on-task is also context-dependent: a longer time may indicate confusion, but it may reflect careful reading or an unrealistic scenario.

Teams should synthesise evidence by looking for patterns, severity, and consequences. A usability issue is more urgent when it affects a critical task, causes irreversible harm, blocks access, or recurs across participants. Do not count comments mechanically. One severe accessibility barrier may matter more than several minor aesthetic preferences.

Possible decisions include:

• continue with the current direction;
• revise a specific interaction or content element;
• compare alternative prototypes;
• investigate a technical or service constraint;
• stop the concept because a critical assumption failed;
• conduct a larger or more controlled study.

A useful experiment produces a decision, not merely a collection of opinions.

7. Illustrative Case: A Community Clinic Appointment Service

This is a fictional illustrative case.

Background

A community clinic planned a digital appointment service for adults booking routine consultations. The initial concept contained a calendar, a choice of clinician, and a confirmation page. The team suspected that patients might struggle with appointment categories and might not understand whether a booking was confirmed.

Problem and Assumptions

Two assumptions were selected:

1. Patients would understand the difference between “routine review” and “new concern.”
2. Patients would recognise the final screen as a confirmed appointment and know what to do next.

Because the team was still uncertain about structure and terminology, it chose a paper prototype rather than a polished application.

Approach

The researcher created two alternative category screens and three confirmation messages. Eight adults with recent clinic-booking experience were invited for moderated sessions. Each participant received the scenario: “You have a new health concern and want the earliest suitable appointment next week.” Participants were asked to think aloud while completing the booking.

The facilitator recorded selections, hesitation, requests for explanation, and whether participants could state the appointment date and next step after reaching confirmation. No medical information was collected beyond what was necessary for the scenario.

Findings

Five participants selected “routine review” because they interpreted “new concern” as a serious or emergency problem. Three participants asked whether the displayed time was reserved or merely being considered. The confirmation message used the phrase “request received,” although the service team intended to communicate that the appointment was booked.

The findings did not demonstrate that the complete digital service would fail. They did show that the category language and confirmation status were unsafe assumptions. The team revised the labels to plain-language descriptions, added an emergency-care warning outside the booking flow, and changed the confirmation to state the exact date, time, location, and whether the appointment was confirmed.

Further Experiment and Outcome

A clickable wireframe was then tested with a new group. The task was repeated, including cancellation and rescheduling. The team discovered that participants could book successfully but did not notice the rescheduling option. A new prototype made post-booking actions more visible and was reviewed with clinic staff to ensure that the operational process could support them.

Learning Points

The case demonstrates that low fidelity was appropriate for testing language and structure, while a more interactive prototype was justified for testing post-booking actions. It also shows why service feasibility must be examined alongside interface usability. Finally, health-related services require careful handling of risk: ambiguous language can have consequences beyond inconvenience.

8. Ethical, Inclusive, and Professional Considerations

Prototype tests involve people, personal information, and sometimes sensitive situations. Participants should understand that they are evaluating an early design, not being tested themselves. Obtain informed consent, explain recording, protect personal data, and allow withdrawal without penalty. Avoid collecting real credentials, financial details, medical records, or other unnecessary information in a prototype.

Recruitment should include people affected by the design, including users with disabilities and people who may have limited digital access or language proficiency. Compensation should be fair and should not create undue pressure. Researchers must avoid treating accessibility as a late visual check; interaction, content, assistive technology, physical environment, and service policy may all create barriers.

Prototype deception requires particular care. A Wizard-of-Oz arrangement may conceal who performs a task during an exploratory session, but participants should be debriefed. Deception is inappropriate where it could affect consent, privacy, safety, financial decisions, or medical care. Prototypes should not be used to make consequential automated decisions merely because they appear functional.

Stakeholders also need accurate communication. A prototype may contain simulated data, incomplete error handling, or manual backstage work. Label its limitations so that a demonstration is not mistaken for a production specification. Version control and clear documentation reduce the risk that an obsolete prototype becomes an unintended commitment.

9. Technology, AI, and Contemporary Practice

Design platforms now support rapid linking, component libraries, remote collaboration, and realistic simulations. These capabilities can shorten iteration time, but they can also encourage teams to polish before understanding the problem. Generative AI can help produce alternative wording, sample records, or exploratory screen concepts; however, generated content must be checked for bias, accessibility, factual accuracy, privacy, and cultural appropriateness. Synthetic data must not accidentally reproduce identifiable personal information.

AI-generated prototypes are hypotheses, not evidence. Only appropriate user research can establish whether people understand, trust, and can use the proposed experience. In high-risk domains, human oversight, auditability, explainability, and regulatory requirements must be considered before testing an apparently intelligent service.

Remote and unmoderated prototype testing can expand reach, but it may reduce the researcher’s ability to diagnose misunderstanding and may exclude people with poor connectivity or assistive-technology needs. Choose methods according to the research question, not convenience alone.

10. Best Practices and Common Failure Modes

Best practices include:

• start with the riskiest assumption rather than the easiest screen;
• match fidelity to the question;
• test realistic goals and language;
• include errors, empty states, and recovery paths;
• separate observation from interpretation;
• document prototype boundaries and version changes;
• include accessibility and service operations early;
• define a decision rule before reviewing results;
• iterate with evidence rather than personal preference;
• stop or redirect a concept when critical assumptions fail.

Common failure modes include building a polished prototype too early, testing only colleagues, asking leading questions, mistaking stated preference for observed behaviour, changing several variables without tracking them, and presenting a prototype as if it were a finished product. Another failure is “confirmation testing,” in which the team unconsciously seeks evidence that supports its preferred solution. Good experimentation makes disconfirming evidence useful and safe to report.

Chapter Summary

Prototyping makes uncertain ideas tangible so that teams can learn before committing to full implementation. Paper prototypes, storyboards, wireframes, interactive prototypes, coded prototypes, and service role-plays serve different purposes. Fidelity should be selected according to the assumption, context, risk, and evidence required—not according to a desire for visual polish.

Effective experimentation converts assumptions into observable hypotheses, realistic tasks, evidence, success criteria, and decisions. Moderated testing requires neutral facilitation, ethical treatment of participants, careful observation, and cautious interpretation of small samples. Completion rates and other measures can summarise observed performance, but they do not automatically generalise to a wider population.

Professional prototyping includes accessibility, privacy, operational feasibility, stakeholder communication, and responsible use of technology and AI. The strongest prototype is not necessarily the most detailed one; it is the simplest credible model that enables a consequential design decision.

Key Terms

Assumption: A belief about users, context, technology, or service operation that may be tested.

Coded prototype: A partially working implementation created to investigate technical or interaction questions.

Concierge prototype: A manually delivered service used to test value before building scalable systems.

Completion rate: The proportion of observed participants who complete a defined task under stated conditions.

Experiment: A planned investigation that produces evidence about an assumption or hypothesis.

Fidelity: The degree to which a prototype resembles the proposed experience in appearance, behaviour, data, or context.

Hypothesis: A specific, testable prediction about observable user behaviour or response.

Interactive prototype: A digital model through which users can perform selected actions and navigate flows.

Paper prototype: A hand-drawn or physical representation used to explore structure and interaction.

Prototype: A tangible model of a product, service, or interaction created for learning and evaluation.

Service prototype: A representation of frontstage and backstage service activities, roles, systems, and artefacts.

Storyboard: A sequence of images or scenes showing a user’s situation, actions, and outcome.

Task: A realistic goal that a participant attempts during a research session.

Usability: The extent to which specified users can achieve specified goals effectively, efficiently, and satisfactorily in a context.

Wireframe: A simplified representation of interface structure, hierarchy, and navigation.

Wizard-of-Oz prototype: A prototype in which a human performs functions that users believe are automated.

Review Questions

Short Answer Questions

1. What is the main purpose of a prototype in user-centred design?
2. Define prototype fidelity and name two of its dimensions.
3. Why is a realistic user goal preferable to an instruction such as “click this button” in a usability task?
4. What is the difference between an observation and an interpretation?
5. State two ethical responsibilities when conducting prototype research.

Long Answer Questions

1. Explain how a team should choose between a paper prototype, wireframe, interactive prototype, and service prototype.
2. Describe the process of converting an assumption into a testable prototype experiment.
3. Discuss the benefits and limitations of high-fidelity prototypes.
4. Explain how accessibility and service operations should be incorporated into prototyping.
5. Analyse why prototype findings from a small qualitative sample should not automatically be generalised to a whole population.

Analytical / Application Questions

1. A banking team believes that first-time users understand the label “beneficiary.” Design a low-cost experiment, including the prototype type, task, evidence, and decision rule.
2. In a test, 7 of 10 participants complete a booking task, but 2 of the 7 require moderator assistance. Define at least two possible completion measures and explain which one should be reported for unaided usability.
3. A hospital service prototype allows patients to request appointments, but staff cannot process the requests within the promised time. Explain how the team should revise the prototype and what further evidence is needed before launch.

Multiple Choice Questions with Answers

Question 1

What is the primary purpose of a UX prototype?

A. To guarantee that the final product will succeed

B. To reduce uncertainty by making an idea testable

C. To replace all user research

D. To demonstrate visual polish to stakeholders

Correct Answer: B. To reduce uncertainty by making an idea testable

Question 2

Which prototype is generally most appropriate for exploring alternative information structures early?

A. Paper prototype

B. Production-ready application

C. Fully automated service

D. Load-testing environment

Correct Answer: A. Paper prototype

Question 3

What should determine prototype fidelity?

A. The number of colours available in the design tool

B. The personal preference of the project manager

C. The question, risk, and evidence required

D. The expected advertising budget

Correct Answer: C. The question, risk, and evidence required

Question 4

Which task is best written for a usability test?

A. Click the blue booking button

B. Open the third menu and select appointments

C. Use the interface exactly as demonstrated

D. Find the earliest suitable appointment next week

Correct Answer: D. Find the earliest suitable appointment next week

Question 5

If 6 of 8 participants complete a task unaided, what is the observed unaided completion rate?

A. 60%

B. 70%

C. 75%

D. 80%

Correct Answer: C. 75%

Question 6

Which statement correctly describes a Wizard-of-Oz prototype?

A. It uses only hand-drawn screens

B. A human secretly performs functions users believe are automated

C. It is always a production-ready system

D. It tests only colour and typography

Correct Answer: B. A human secretly performs functions users believe are automated

Question 7

Which is an observation rather than an interpretation?

A. The participant disliked the layout

B. The participant was careless

C. The participant paused before selecting Continue

D. The participant did not understand the product

Correct Answer: C. The participant paused before selecting Continue

Question 8

Why should a prototype’s limitations be documented?

A. To prevent an incomplete model being mistaken for a finished specification

B. To make the prototype appear more complex

C. To avoid testing it with users

D. To remove the need for version control

Correct Answer: A. To prevent an incomplete model being mistaken for a finished specification

Question 9

Which issue is especially important when prototyping a health-related service?

A. Whether the prototype contains decorative animation

B. Whether ambiguous language could create harmful misunderstanding

C. Whether every screen uses the same illustration style

D. Whether the prototype can replace clinical governance

Correct Answer: B. Whether ambiguous language could create harmful misunderstanding

Question 10

What is a key limitation of a small qualitative prototype study?

A. It cannot reveal any usability problems

B. It automatically provides precise population percentages

C. Its findings may identify issues without establishing population prevalence

D. It can only test visual design

Correct Answer: C. Its findings may identify issues without establishing population prevalence