Low-Fidelity and Experience Prototyping

Introduction

Product prototyping is not limited to building functional software, hardware, or polished interfaces. In the early stages of entrepreneurial innovation, the most valuable prototype may be a sketch, a role-play, a paper screen, or a simulated service encounter. These low-cost representations allow a team to explore what a product or service might be like before committing substantial time, money, and technical effort.

Low-fidelity prototyping is especially important when the innovation involves uncertainty about customer needs, service processes, user behaviour, or the meaning customers attach to an experience. A digital product may appear simple on screen but depend on complex backstage activities, human support, logistics, trust, and communication. Experience prototyping makes these elements visible and testable.

This chapter explains how entrepreneurs can use sketches, storyboards, paper prototypes, role plays, journey simulations, and Wizard-of-Oz prototypes to investigate interactions and customer experiences rapidly. The emphasis is not on producing attractive artefacts. It is on generating useful evidence, exposing assumptions, and improving decisions.

Learning Objectives

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

1. Explain the purpose, characteristics, and applications of low-fidelity prototypes.
2. Distinguish between sketches, storyboards, paper prototypes, role plays, journey simulations, and Wizard-of-Oz prototypes.
3. Select an appropriate prototyping method for a particular uncertainty.
4. Design and conduct rapid prototype tests with users and stakeholders.
5. Analyse observations, feedback, and behavioural evidence without overclaiming.
6. Apply experience prototyping to frontstage and backstage service activities.
7. Evaluate ethical, operational, and managerial implications of low-fidelity experimentation.

1. Prototyping as an Instrument for Learning

A prototype is a selective representation of a proposed product, service, system, or experience. It does not reproduce every feature of the final offering. Instead, it makes some aspect of an idea tangible enough to inspect, discuss, use, or challenge.

The central managerial question is not “How realistic is this prototype?” but “What uncertainty is this prototype designed to reduce?” Typical uncertainties include:

• whether a customer recognises a problem;
• whether a proposed sequence of actions is understandable;
• whether a service interaction feels trustworthy;
• whether users can complete a task;
• whether employees can deliver a promised service;
• whether a business process is feasible;
• whether a concept creates value greater than its cost or inconvenience.

A low-fidelity prototype deliberately sacrifices detail, durability, automation, and visual polish in order to increase speed and flexibility. A team can change a paper screen in seconds, whereas changing coded software may require substantial effort. This difference creates an important learning advantage: the team can test more alternatives before becoming attached to one design.

1.1 Representation and fidelity

Fidelity refers to how closely a prototype resembles the eventual offering. It has several dimensions:

Fidelity is not universally good or bad. High fidelity can improve realism, but it may also narrow discussion, increase cost, and encourage users to focus on superficial details. Low fidelity is valuable when the team is exploring fundamental assumptions or comparing multiple alternatives.

1.2 Prototype fidelity and learning objectives

A prototype should be matched to the decision it supports. If the question is whether users understand a proposed value proposition, a storyboard or conversation may be sufficient. If the question concerns navigation between screens, a paper prototype may be appropriate. If the question concerns waiting, trust, handovers, or employee behaviour, an experience simulation may provide better evidence.

A useful principle is to prototype the riskiest assumption at the lowest reasonable cost. This does not mean always choosing the least realistic method. It means avoiding unnecessary realism before the underlying concept has earned further investment.

2. The Main Forms of Low-Fidelity and Experience Prototyping

2.1 Sketches

A sketch is a quick visual representation of an idea, interface, physical object, environment, or process. It may include boxes, arrows, annotations, stick figures, labels, and alternative versions. Sketches are useful because they externalise thinking. Once an idea is visible, team members can identify omissions, contradictions, and opportunities for improvement.

Sketching is particularly useful for:

• generating many alternatives;
• discussing layout and hierarchy;
• explaining a concept to a non-specialist;
• mapping an interaction sequence;
• communicating a physical form or service environment.

Effective sketches are intentionally unfinished. Excessive polish can discourage criticism because stakeholders may interpret the artefact as a final design. An entrepreneur should label assumptions clearly, separate facts from hypotheses, and record unresolved questions beside the drawing.

2.2 Storyboards

A storyboard represents an experience as a sequence of scenes. Each frame normally shows an actor, context, action, and consequence. Storyboards are derived from visual storytelling and are valuable for products and services that unfold over time.

A service storyboard might show:

1. a customer encountering a problem;
2. discovering the service;
3. signing up or requesting assistance;
4. receiving the core service;
5. dealing with an exception;
6. completing the experience and deciding whether to return.

Storyboards reveal temporal and emotional dimensions that a static screen cannot show. They help teams ask whether the experience begins at the moment of purchase or earlier, and whether it ends when the transaction is complete or when the customer achieves the desired outcome.

A strong storyboard avoids portraying only the ideal path. It should include realistic variation, such as uncertainty, delay, failed payment, missing information, or a request for human help. These moments often determine satisfaction and trust.

2.3 Paper prototypes

A paper prototype uses paper representations of screens, controls, cards, menus, forms, or physical components. One team member acts as the “computer” by moving or replacing paper elements in response to the participant’s actions. The participant can point, write, speak, or manipulate the paper interface.

Paper prototypes are effective for testing:

• information architecture;
• task sequence;
• labels and terminology;
• navigation;
• form completion;
• error recovery;
• the relative prominence of choices.

They are less suitable for evaluating animation, response speed, visual branding, or complex technical behaviour. A paper prototype may also underrepresent accessibility concerns if it does not simulate screen-reader output, contrast, tactile feedback, or motor demands.

The facilitator should avoid explaining the interface too much. If the participant is unable to find a control, that may be evidence about the design rather than evidence that the participant needs training.

2.4 Role plays

A role play is a structured enactment in which participants assume the roles of customers, employees, partners, support agents, or other actors. It is useful when the proposed value depends on communication, judgement, emotion, or coordination between people.

Role plays can explore:

• sales and onboarding conversations;
• customer support;
• healthcare or advisory services;
• conflict and complaint handling;
• delivery and installation;
• internal workflows;
• service recovery after failure.

Role plays should have a clear purpose and scenario, but they should not be over-scripted. A fully scripted performance tests memorisation rather than service design. Participants should be given enough context to behave plausibly while retaining freedom to respond.

A role play can be followed by a debrief with three perspectives: the customer’s experience, the employee’s ability to deliver the service, and the organisation’s operational requirements. Disagreement among these perspectives is often more valuable than a superficial consensus.

2.5 Journey simulations

A journey simulation reproduces the stages through which a user moves while achieving a goal. It may combine a storyboard, paper interface, physical props, role play, and timed activities. The purpose is to examine the complete experience rather than an isolated interaction.

A journey simulation should identify:

• the user’s goal and starting condition;
• touchpoints and channels;
• user actions;
• visible service activities;
• backstage activities;
• waiting, uncertainty, and handovers;
• emotional or trust-related changes;
• points at which the user may abandon the journey.

The method is especially valuable for service ventures. For example, a meal-delivery service can simulate discovery, ordering, payment, preparation, delivery, receipt, complaint handling, and repeat purchase. Each stage may expose a different assumption about responsibility and timing.

Journey simulations should not be confused with customer journey maps. A journey map is an analytical representation, whereas a simulation is an enacted or experiential test. The map can guide the simulation, but it cannot substitute for observing what people actually do and feel during the sequence.

2.6 Wizard-of-Oz prototypes

A Wizard-of-Oz prototype presents users with the appearance of an automated or technically advanced system while a human secretly performs some of the underlying functions. The term refers to the concealed “wizard” who creates the system response.

Examples include:

• a human classifying customer questions behind an apparently automated chatbot;
• an operator manually selecting recommendations displayed as an intelligent system output;
• a person controlling a vehicle or device while users believe it is autonomous;
• a concierge manually coordinating suppliers behind a digital booking interface.

The method tests user behaviour, perceived value, and interaction requirements before the technical system exists. It is particularly useful when the team does not yet know which functions require automation and which may remain human-supported.

The Wizard-of-Oz method requires careful ethical management. Participants should not be deceived in ways that expose them to material risk, financial loss, or consequential decisions. Researchers should determine when disclosure is necessary, protect personal data, and avoid presenting simulated capability as a production-ready system.

3. A Framework for Selecting a Prototype Method

Method selection can be organised around four questions:

1. What uncertainty is being investigated? Meaning, sequence, usability, emotional response, operational feasibility, or technical performance?
2. Who must participate? Customers, employees, partners, regulators, or several groups?
3. Where does the experience occur? Online, in a physical setting, across channels, or through human interaction?
4. What evidence is needed for the next decision? Conversation, observed behaviour, timing, error patterns, emotional response, or operational constraints?

A single investigation may use several methods. For example, a team might begin with sketches, create a storyboard of the preferred concept, simulate the service with role play, and then test a paper interface for a particular touchpoint.

4. Designing a Rigorous Low-Fidelity Prototype Test

Low fidelity does not mean low rigour. A rapid test should still be designed systematically.

4.1 State the learning question

A learning question is narrower than a general ambition. “Do customers like our service?” is too broad. Better questions include:

• Can first-time users identify what to do next without assistance?
• Do customers understand why identity verification is required?
• Can a support employee recover trust after a delayed delivery?
• Does manual recommendation improve perceived relevance enough to justify further development?

The question should identify the user, situation, behaviour, and evidence of interest.

4.2 Identify assumptions and risks

Assumptions may concern desirability, usability, feasibility, viability, legality, or ethics. They should be written as testable statements. For example: “First-time users will permit location access if the benefit is explained before the request.” The team can then construct a prototype that exposes this assumption.

An assumption becomes more important when its failure would seriously damage the venture and when the team has little evidence for it. This risk-based approach helps entrepreneurs avoid spending time testing minor visual details while major behavioural or operational risks remain unresolved.

4.3 Construct only what is necessary

The prototype should contain enough material to produce the intended interaction and no more. A paper interface may require only the screens encountered during one task. A role play may need a scenario card, customer profile, service policy, and a few physical props. Unnecessary detail creates cost without necessarily improving learning.

4.4 Recruit appropriate participants

Participants should resemble the people whose behaviour matters for the decision. Convenience participants can be useful for early brainstorming, but they are weak evidence for market-wide conclusions. For service prototypes, include both customers and delivery personnel when the experience depends on their interaction.

The number of participants is a design decision rather than a universal rule. Early qualitative tests often use small numbers to identify major breakdowns and refine the prototype. The goal is not to estimate a population percentage unless the study has been designed for quantitative inference.

4.5 Facilitate without leading

The facilitator should provide a realistic task rather than a detailed route. Instead of saying, “Click the booking button,” say, “You need to arrange a repair for tomorrow morning.” Follow-up questions should focus on interpretation and reasoning: “What are you looking for?” “What do you expect to happen?” and “What concerns you at this point?”

Leading questions such as “Isn’t this option convenient?” generate agreement but little evidence. Silence is often useful because participants may reveal confusion or expectations that would otherwise remain hidden.

4.6 Capture evidence

Evidence can include:

• actions taken;
• points of hesitation;
• incorrect interpretations;
• requests for help;
• completion or abandonment;
• quotations;
• emotional reactions;
• workarounds;
• employee concerns;
• time and resource implications.

A facilitator should distinguish observation from interpretation. “The participant selected the wrong option twice” is an observation. “The participant dislikes the service” is an interpretation requiring further evidence.

4.7 Synthesise and decide

After testing, the team should group findings by pattern rather than by individual opinion. A useful classification is:

• confirmed or supported assumption;
• weakened assumption;
• unresolved question;
• newly discovered issue;
• implementation constraint;
• ethical or compliance concern.

Each finding should lead to a decision: modify, investigate, discard, defer, or proceed. Prototyping is incomplete if the team collects feedback but does not change its next action.

5. Experience Prototyping and Service-System Thinking

Products and services are experienced through systems. The customer may see an interface, employee, package, or physical environment, while many activities occur invisibly in the background. Experience prototyping should therefore distinguish frontstage and backstage elements.

• Frontstage: activities visible or directly experienced by the customer.
• Backstage: activities performed by staff, software, suppliers, or partners that support the experience.
• Support processes: infrastructure, policies, data, training, and governance that enable both.

For example, a digital appointment service may show a confirmation screen to the customer. Behind that screen, a scheduling engine, clinic calendar, payment processor, reminder service, and staff workflow must coordinate. A prototype that tests only the screen may falsely suggest that the service is feasible.

A service blueprint can combine a customer journey with frontstage and backstage actions. During a simulation, the team can use cards or lanes to show who acts at each stage. This makes handovers and failure points visible.

5.1 Moments of truth

A moment of truth is a point at which the customer forms or changes a significant judgement about the organisation. Examples include the first response to a complaint, a payment failure, an unexpected delay, or the handling of personal information. Low-fidelity simulations are powerful because they allow teams to rehearse such moments before they occur in the market.

5.2 Emotional and temporal fidelity

Experience is influenced not only by what happens but also by when it happens and how it feels. A simulation should therefore consider waiting, uncertainty, anticipation, embarrassment, relief, and trust. A service that appears acceptable when described verbally may feel unacceptable when a participant waits alone for ten minutes without information.

Temporal fidelity does not always require exact timing. The team can represent waiting with a pause, timer, or explicit instruction, provided participants understand the intended condition. If timing is itself a key hypothesis, however, the simulation should approximate realistic duration.

6. Worked Application: An Illustrative Case of a Community Repair Platform

Background

The following is a fictional illustrative case. “FixLocal” is a proposed platform connecting households with independent technicians for small appliance repairs. The founders believe customers want transparent pricing and rapid appointments, while technicians want a steady flow of local work.

Problem

The founders initially planned to build a fully automated platform with diagnosis, pricing, scheduling, payment, technician allocation, and customer messaging. This would require significant software development. However, they were uncertain whether customers could describe faults accurately and whether technicians would accept the platform’s proposed process.

Analysis

The team identified four high-risk assumptions:

1. Customers can describe a repair problem sufficiently for an initial estimate.
2. Customers trust a price range rather than demanding a fixed price.
3. Technicians can accept or reject jobs without creating unacceptable delays.
4. Customers value rapid matching more than the ability to choose a particular technician.

The assumptions involved customer comprehension, trust, operational coordination, and preference. A single interface test would not address all four.

Approach

First, the founders created three storyboard alternatives: immediate technician assignment, customer choice among technicians, and a diagnosis-first process. Interviews using the storyboards revealed that participants were less concerned with choosing a technician than with avoiding surprise charges.

Second, the team built a paper prototype containing screens for problem description, photograph upload, estimated price range, appointment selection, and technician messages. Participants were asked to arrange a repair for a malfunctioning washing machine. The facilitator manually changed screens and recorded confusion. Several users expected the platform to explain what information was required before asking for a price estimate.

Third, the team conducted a Wizard-of-Oz trial. Participants submitted a problem through a simple form. Behind the scenes, a founder manually reviewed the description, contacted two technicians, and returned a proposed appointment and price range. The participant believed the process was supported by the intended platform, but the team disclosed before any paid transaction that the matching was being manually operated as a prototype.

Finally, a role play simulated a difficult case: the technician discovered an additional fault after arriving. The customer, technician, and platform coordinator each received separate instructions. The exercise exposed a major gap: the proposed platform had no clear policy for diagnostic fees, cancellation, or customer consent to additional work.

Outcome

The team postponed automated diagnosis and technician ranking. It revised the concept around three principles:

• collect structured information before generating an estimate;
• show a transparent price range and explain possible variation;
• provide a clear approval step before extra work begins.

The founders also discovered that the backstage coordination process was initially too slow. They decided to pilot one neighbourhood with manual matching before building complex automation.

Learning points

The case demonstrates that low-fidelity methods can test a business model, not merely an interface. The Wizard-of-Oz prototype revealed actual coordination requirements, while the role play exposed policy and trust issues. The prototypes did not prove market demand or financial viability, but they reduced uncertainty and prevented premature investment in automation.

7. Evaluating Evidence from Prototype Tests

Prototype evidence is conditional. A participant’s behaviour in a simulated setting does not automatically predict actual purchasing behaviour. The participant may be unusually attentive, may know that the artefact is unfinished, or may respond differently when money, time, reputation, or risk is genuinely involved.

Evidence should therefore be interpreted according to its strength and limitation. Observed difficulty in completing a basic task is often a strong signal that the design needs improvement. Positive comments such as “That looks useful” are weaker evidence of future adoption. Actual behaviour in a realistic pilot is generally stronger evidence than stated preference, although it too may be affected by incentives and context.

Teams should avoid false precision. A small qualitative test can reveal themes and failure modes, but it cannot establish that a particular percentage of the market will behave in the same way. Quantitative claims require an appropriate sampling and measurement design.

A useful decision record includes:

8. Ethics, Privacy, and Governance

Low-fidelity prototyping may appear harmless, but it can still affect participants and third parties. Ethical practice includes informed participation, appropriate consent, privacy protection, and honest handling of risk.

Participants should know the purpose of the activity, what will be recorded, whether the prototype is non-operational, and how their information will be used. Personal data should be minimised. Teams should use fictional or synthetic data where real data are unnecessary.

Wizard-of-Oz studies require special care because the participant may not know which functions are human-operated. Concealment should be limited to what is necessary for the research question. It should not be used to obtain sensitive information, induce a financial commitment, or create a false impression of safety or capability.

Accessibility should be considered from the first prototype. A handwritten interface may be inaccessible to a person with visual impairment; a role play may exclude people with speech or mobility differences; a service simulation may ignore language or cultural needs. Inclusive testing may require alternative formats, interpreters, assistive technologies, or modified scenarios.

Entrepreneurs should also consider regulatory consequences. A prototype involving healthcare, finance, employment, transport, children, or personal data may fall within sector-specific obligations even if it is described as an experiment. Legal advice may be necessary before exposing participants to consequential decisions.

9. Technology, AI, and Contemporary Practice

Digital collaboration tools can make low-fidelity prototyping easier, but they do not eliminate the need for direct observation. Shared whiteboards, clickable mock-up tools, video calls, and digital service-blueprint platforms support distributed teams. However, a digital prototype may become visually polished too early and encourage debate about aesthetics rather than assumptions.

AI tools can generate alternative interface sketches, sample dialogue, synthetic personas, or scenario variations. They can help a team explore possibilities quickly, but AI-generated artefacts should not be treated as evidence of customer need. AI may also reproduce stereotypes, invent unsupported requirements, or use sensitive information inappropriately. Human review, data governance, and explicit documentation of AI involvement are necessary.

In contemporary product development, low-fidelity prototyping increasingly extends to service operations, algorithmic decision processes, and human–AI collaboration. A team may role-play how a human employee reviews an AI recommendation, how a customer challenges an automated decision, or how responsibility is assigned when an AI-supported service fails. These scenarios are valuable because technical feasibility alone does not establish accountability, trust, or acceptability.

10. Best Practices and Common Failure Modes

Best practices

• Start with the uncertainty, not the artefact.
• Use the cheapest method that can produce meaningful evidence.
• Test alternatives rather than presenting only one preferred concept.
• Include realistic exceptions and failure conditions.
• Observe behaviour, not only verbal opinions.
• Separate observations, interpretations, and decisions.
• Include employees and partners when the service depends on them.
• Treat accessibility, privacy, and safety as design requirements.
• Document what the prototype cannot test.
• Convert findings into a specific next experiment or decision.

Common failure modes

Premature polish: A visually impressive prototype discourages criticism and creates attachment to a weak concept.

Over-explaining: The facilitator rescues participants so often that the test measures the facilitator’s guidance rather than the design.

Testing the wrong audience: Colleagues or friends are used even though they do not share the target user’s context.

Ignoring backstage work: The customer-facing journey appears simple because operational burdens are hidden.

Confusing preference with behaviour: Participants express approval but do not demonstrate willingness to act, pay, wait, or change habits.

Treating one test as proof: A prototype provides evidence for a specific question; it does not validate an entire business model.

Concealing risk in Wizard-of-Oz testing: Participants are allowed to believe a simulated capability is reliable in a high-consequence context.

Chapter Summary

Low-fidelity and experience prototypes are practical instruments for learning under uncertainty. Sketches support rapid ideation; storyboards represent experiences over time; paper prototypes explore interaction sequences; role plays examine human communication and coordination; journey simulations investigate complete service experiences; and Wizard-of-Oz prototypes test the value of apparently automated functions before technical construction.

Effective prototyping begins with a clear learning question and a high-risk assumption. The prototype should contain only the detail needed to investigate that assumption. Rigorous testing requires appropriate participants, neutral facilitation, careful observation, disciplined interpretation, and a clear decision after the test.

Experience prototyping is especially important for services because customer value depends on frontstage interactions, backstage operations, handovers, waiting, trust, and recovery from failure. Ethical practice requires informed participation, privacy protection, accessibility, responsible use of concealment, and attention to regulatory obligations. AI and digital tools can accelerate prototype creation, but they do not replace evidence from real users and realistic contexts.

Key Terms

Low-fidelity prototype: A simple, inexpensive representation used to explore an idea rapidly.

Experience prototype: An artefact or enactment designed to simulate how a person experiences a product or service.

Fidelity: The degree to which a prototype resembles the eventual offering.

Sketch: A quick visual representation of an idea, structure, object, or interaction.

Storyboard: A sequence of illustrated scenes showing an experience over time.

Paper prototype: A paper-based representation of screens, controls, or interface states.

Role play: An enacted scenario in which participants assume relevant user or organisational roles.

Journey simulation: A staged reproduction of the sequence through which a user achieves a goal.

Wizard-of-Oz prototype: A prototype in which a human secretly performs functions that appear automated.

Learning question: A focused question that defines what a prototype test is intended to discover.

Assumption: A belief about users, value, feasibility, operations, or the environment that has not yet been adequately verified.

Frontstage: Activities and interactions directly visible to or experienced by the customer.

Backstage: Activities performed behind the customer-facing experience to deliver the service.

Service blueprint: A structured representation of customer actions, frontstage activity, backstage activity, and support processes.

Moment of truth: An interaction at which a customer forms or changes an important judgement about the organisation.

Fidelity trade-off: The balance between realism, cost, speed, flexibility, and learning value.

Facilitation bias: Distortion caused when a facilitator leads, rescues, or influences participants during a test.

Prototype evidence: Observations and responses generated through interaction with a prototype.

Review Questions

Short Answer Questions

1. What is the primary purpose of a low-fidelity prototype?
2. How does a storyboard differ from a paper prototype?
3. What is the role of the hidden human in a Wizard-of-Oz prototype?
4. Define frontstage and backstage service activity.
5. Why should prototype findings be distinguished from market-wide conclusions?

Long Answer Questions

1. Explain how an entrepreneur can select an appropriate prototyping method for a particular uncertainty.
2. Discuss the advantages and limitations of role plays and journey simulations in service innovation.
3. Describe a rigorous process for planning, conducting, and analysing a low-fidelity prototype test.
4. Explain how prototype fidelity can influence stakeholder behaviour and decision-making.
5. Analyse the ethical and governance issues associated with Wizard-of-Oz prototypes.

Analytical / Application Questions

1. A start-up is designing an online mental-health support service. Propose a sequence of low-fidelity and experience prototypes that could test user trust, service coordination, and escalation processes. Justify each method.
2. A paper prototype shows that users repeatedly choose the wrong payment option. Develop two competing explanations and design a follow-up test that could distinguish between them.
3. A team claims that a Wizard-of-Oz test has validated its artificial-intelligence recommendation engine. Critically evaluate this claim and specify what additional evidence would be required before development investment.

Multiple Choice Questions with Answers

Question 1

Which statement best describes the central purpose of low-fidelity prototyping?

A. To reproduce the final product exactly before launch

B. To reduce uncertainty rapidly and inexpensively

C. To demonstrate technical performance under production conditions

D. To replace all forms of customer research

Correct Answer: B. To reduce uncertainty rapidly and inexpensively

Question 2

Which prototyping method is most directly suited to exploring an experience that unfolds through a sequence of scenes over time?

A. Storyboard

B. Database schema

C. Production deployment

D. Financial audit

Correct Answer: A. Storyboard

Question 3

In a paper prototype test, who commonly simulates the system’s responses by moving or replacing paper elements?

A. The regulator

B. The customer’s employer

C. A member of the test team

D. An unrelated market analyst

Correct Answer: C. A member of the test team

Question 4

What is a defining feature of a Wizard-of-Oz prototype?

A. It contains no interaction at all

B. A human performs functions that appear to be automated

C. It can be used only after the final system is built

D. It tests manufacturing tolerances exclusively

Correct Answer: B. A human performs functions that appear to be automated

Question 5

Which of the following is a backstage activity in a service experience?

A. A customer reading a confirmation message

B. A customer entering a delivery address

C. An internal employee coordinating the supplier schedule

D. A customer choosing a preferred appointment

Correct Answer: C. An internal employee coordinating the supplier schedule

Question 6

Why should a facilitator avoid telling a participant exactly which control to select?

A. It increases the cost of the prototype

B. It may hide usability problems in the design

C. It prevents the prototype from being photographed

D. It guarantees that the participant will abandon the task

Correct Answer: B. It may hide usability problems in the design

Question 7

Which finding is an observation rather than an interpretation?

A. The participant selected the wrong option twice

B. The participant dislikes the entire business model

C. The service will certainly fail commercially

D. The participant is irrational

Correct Answer: A. The participant selected the wrong option twice

Question 8

A journey simulation is especially valuable because it can reveal:

A. Only the colour preferences of users

B. Backstage handovers, waiting, and service failures

C. The exact market share after launch

D. The final software architecture

Correct Answer: B. Backstage handovers, waiting, and service failures

Question 9

Which practice is ethically appropriate in a Wizard-of-Oz test?

A. Using concealment to expose participants to undisclosed financial risk

B. Presenting simulated safety performance as proven capability

C. Limiting concealment to the research purpose and protecting participants

D. Collecting unnecessary personal data because the prototype is temporary

Correct Answer: C. Limiting concealment to the research purpose and protecting participants

Question 10

A team wants to know whether users understand a proposed value proposition before designing an interface. Which method is generally most suitable initially?

A. A concept sketch or storyboard

B. A fully automated production system

C. A load-testing programme

D. A manufacturing stress test

Correct Answer: A. A concept sketch or storyboard