Foundations and Language of Product Prototyping

Introduction

Product prototyping is the disciplined practice of making an idea sufficiently tangible to examine, communicate, test, and improve. In entrepreneurship, a prototype may be a sketch, a physical model, a clickable interface, a service role-play, a technical experiment, or a limited live offering. Its value does not arise from appearance alone. A prototype is valuable because it exposes assumptions and produces evidence before the entrepreneur commits substantial resources to full-scale development.

Entrepreneurial product development is characterized by uncertainty. Customers may not experience the proposed problem as expected; a technology may not perform reliably; a business model may not generate acceptable margins; regulations may constrain the design; and users may behave differently from what interviews suggested. Prototyping creates structured opportunities to learn about these uncertainties. It therefore connects creativity with evidence-based decision-making.

A prototype is not simply an unfinished product. It is an intentional representation or enactment of a proposed product, service, system, or business process, created for a particular purpose and audience. The appropriate prototype depends on the question being investigated. A paper sketch may be superior to a polished digital interface when the objective is to compare alternative layouts. Conversely, a high-fidelity prototype may be necessary when testing accessibility, response time, or emotional trust.

Learning Objectives

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

1. Explain the purpose and evolution of product prototyping in entrepreneurial development.
2. Distinguish among models, mock-ups, proofs of concept, prototypes, minimum viable products, pilots, and related terms.
3. Select an appropriate prototype type and level of fidelity for a specific learning objective.
4. Differentiate desirability, feasibility, viability, usability, and validation.
5. Interpret prototyping as an evidence-generation and risk-reduction activity.
6. Apply prototyping language to a practical entrepreneurial case.
7. Recognize ethical, regulatory, inclusion, and governance issues in prototype testing.

1. Why Entrepreneurs Prototype

Entrepreneurs rarely possess complete information. At the beginning of a venture, assumptions may concern:

• the existence and importance of a customer problem;
• the identity and accessibility of target users;
• the technical possibility of a solution;
• the cost and reliability of production or delivery;
• user willingness to adopt or pay;
• operational capacity and partner requirements; and
• legal, safety, privacy, or environmental constraints.

Prototyping helps transform assumptions into questions that can be investigated. Instead of asking, “Will customers like our idea?” an entrepreneurial team can ask more precise questions: “Can first-time users complete the booking task without assistance?” “Can the sensor detect the target condition under ordinary conditions?” or “Will a clinic integrate this workflow without increasing staff workload?”

A prototype can produce several forms of learning:

• Descriptive learning: what users do, say, notice, or misunderstand.
• Technical learning: whether a function can work within specified constraints.
• Operational learning: whether people, processes, suppliers, and systems can deliver the experience.
• Economic learning: whether acquisition, delivery, and support costs are compatible with the business model.
• Regulatory learning: whether the proposed design meets applicable obligations.

The central principle is proportionality: the investment in a prototype should be appropriate to the uncertainty and the consequence of being wrong. A cheap experiment is preferable when it answers the question adequately. However, low cost must not be confused with low quality. A poorly designed test can create false confidence just as easily as an expensive prototype can waste resources.

2. Evolution of Prototyping

Prototyping has long existed in engineering, architecture, manufacturing, and craft production. Physical scale models, pattern pieces, tooling samples, and test rigs enabled designers to inspect form and function before final production. Industrial design later formalized iterative development through sketches, foam models, appearance models, and engineering prototypes.

Software development expanded the vocabulary. Wireframes, storyboards, clickable interfaces, simulations, alpha releases, beta releases, and test environments allowed teams to investigate interaction and performance before public launch. The growth of digital fabrication, cloud computing, open-source hardware, and low-code tools has further lowered the cost of producing functional representations.

Entrepreneurship and innovation practice broadened prototyping beyond the artifact itself. Service design uses role-play, journey maps, front-stage and back-stage enactments, and simulated environments. Business model experimentation tests pricing, channels, partnerships, and delivery arrangements. A prototype may therefore be a temporary service, landing page, manual process behind an automated interface, or restricted market release.

Contemporary prototyping is closely associated with iterative and learning-oriented approaches, including design thinking, lean-startup experimentation, agile development, user-centred design, and systems engineering. These approaches differ in language and emphasis, but share a commitment to making assumptions visible, testing them, learning from evidence, and revising the concept.

The evolution also creates a managerial challenge. Modern tools can make a prototype look highly polished very quickly. Visual polish may conceal unresolved technical, operational, or ethical risks. Entrepreneurs must therefore evaluate what a prototype demonstrates—and what it does not demonstrate.

3. The Core Language of Prototyping

3.1 Concept, representation, and prototype

A concept is an abstract proposal for a product, service, or solution. A representation is something that communicates or embodies part of that concept. A prototype is a representation deliberately created to learn, evaluate, communicate, or make decisions.

The distinction matters because not every representation is a prototype. A marketing illustration may communicate an imagined product but may not be intended for testing. A prototype normally has an explicit purpose, such as testing a user flow, demonstrating a mechanism, or estimating production effort.

3.2 Model

A model is a simplified representation of a system, object, process, or relationship. It may be physical, visual, mathematical, computational, or conceptual. A scale model represents dimensions; a process model represents activities and decisions; a financial model represents revenue and cost assumptions; and a simulation model represents behaviour under specified conditions.

A model is not necessarily interactive or testable in the same way as a finished product. Its usefulness depends on what it preserves and what it deliberately omits.

3.3 Mock-up

A mock-up is a representation focused primarily on appearance, arrangement, or communication. It may show the external form of a device, the layout of packaging, or the visual structure of a mobile application. Mock-ups are useful for discussing aesthetics, hierarchy, branding, and spatial relationships. They often lack working functionality.

A mock-up can be a prototype when it is used to investigate a defined question. For example, two packaging mock-ups can be compared for shelf visibility and comprehension. A decorative render with no evaluative purpose is better described as a visualisation.

3.4 Wireframe and storyboard

A wireframe is a simplified diagram of an interface, showing information structure, navigation, and major controls. It normally minimizes colour and visual detail so that attention remains on structure.

A storyboard presents a sequence of situations, actions, and outcomes. It is particularly useful for services and experiences because it represents context over time. A storyboard can expose assumptions about who performs each activity, what triggers the service, and where failure may occur.

3.5 Proof of concept

A proof of concept (PoC) is a limited demonstration that a critical technical or functional principle can work. It addresses feasibility rather than complete user experience or commercial readiness. For example, a PoC may show that a device can transmit data through a required environment, or that an algorithm can classify images with acceptable preliminary performance.

A PoC may be built with temporary materials, expert operators, or simplified conditions. Its result should therefore be stated carefully. “The communication protocol worked in a controlled laboratory test” is more defensible than “the product is technically proven.”

3.6 Engineering or functional prototype

An engineering prototype investigates function, integration, performance, reliability, or manufacturability. It may use substitute materials or components, but it should represent the relevant technical behaviour. A functional prototype may be closer to the eventual product than a PoC, although the terms sometimes overlap in practice.

Important distinctions include:

• Breadth: how many functions are represented.
• Depth: how realistically a particular function operates.
• Integration: whether components work together as a system.
• Robustness: whether performance is stable across expected conditions.

3.7 Minimum viable product

A minimum viable product (MVP) is the smallest product or service that delivers a sufficiently meaningful value proposition to a defined group of users while enabling the venture to learn from actual use. “Minimum” refers to the smallest responsible scope, not the lowest possible quality. “Viable” implies that the offering can function for its intended users and context; it does not necessarily mean that the business is already profitable.

An MVP differs from a PoC. A PoC primarily tests whether a principle can work. An MVP places a usable value proposition in the hands of intended users. A manually operated service may be an MVP if users receive genuine value and the operation is safe and transparent. It is not an MVP if it merely creates publicity without delivering the proposed benefit.

The MVP concept is frequently misused to justify defects, inadequate support, or unsafe release. A responsible MVP must meet non-negotiable requirements concerning safety, privacy, accessibility, consumer protection, and applicable regulation.

3.8 Pilot

A pilot is a limited, controlled implementation in a real or realistic operating environment. It examines adoption, workflow, reliability, support requirements, outcomes, and contextual effects. Pilots are commonly used in healthcare, education, logistics, public services, and enterprise software.

A pilot is not automatically a market launch. It should have defined scope, participants, duration, success criteria, escalation procedures, and a decision rule. A pilot may reveal that a technically successful product is operationally unsuitable.

3.9 Beta release and field trial

A beta release is a pre-final version made available to selected or broader users to discover defects and gather feedback under realistic conditions. A field trial evaluates a product in the environment where it is expected to operate. Both may generate stronger evidence than laboratory tests, but they introduce greater exposure to privacy, safety, security, and reputational risks.

4. Fidelity: Choosing the Right Level of Realism

Fidelity refers to how closely a prototype resembles the intended product, service, system, or use context. Fidelity is multidimensional rather than a single scale. A prototype may have:

• high visual fidelity but low functional fidelity;
• high functional fidelity but low technical fidelity because a human performs hidden tasks;
• high data fidelity but low interaction fidelity; or
• high environmental fidelity but low product fidelity.

Low-fidelity prototypes

Low-fidelity prototypes include sketches, paper interfaces, rough physical forms, simple diagrams, role-play, and manually simulated interactions. They are inexpensive, quick to modify, and useful early in exploration. Their roughness can encourage criticism because participants do not assume the design is final.

Their limitations include limited realism, possible difficulty imagining use, and the risk that participants evaluate drawing quality rather than the underlying concept.

High-fidelity prototypes

High-fidelity prototypes resemble the intended experience more closely. They may contain realistic visual design, working interactions, representative materials, integrated electronics, realistic data, or deployment in an actual setting. They are useful for testing detailed usability, performance, trust, accessibility, and operational integration.

High fidelity requires more time and may create design fixation. Users and managers may become attached to details that were never intended to be final. A polished prototype can also cause stakeholders to overestimate technical readiness.

Fidelity as a strategic choice

The correct question is not “Should the prototype be high or low fidelity?” but “What fidelity is necessary to answer the current question?” A team investigating information hierarchy may need only paper screens. A team testing vibration, heat, or mechanical safety requires relevant physical and environmental fidelity. Fidelity should increase selectively as important uncertainties are reduced.

5. Feasibility, Desirability, Viability, and Validation

Feasibility

Feasibility concerns whether a proposed solution can be built, delivered, operated, and maintained within relevant constraints. Technical feasibility includes performance, integration, materials, data, cybersecurity, and reliability. Operational feasibility considers people, skills, facilities, suppliers, and workflows. Legal and regulatory feasibility concerns compliance obligations.

A PoC often investigates a narrow feasibility question, while an engineering prototype investigates broader technical feasibility.

Desirability

Desirability concerns whether users or customers perceive the problem as important and the proposed solution as valuable, understandable, accessible, and preferable to alternatives. Desirability is not established solely by positive statements in interviews. Behavioural evidence—such as repeated use, referrals, time commitment, or payment—can provide stronger evidence, although it too must be interpreted in context.

Viability

Viability concerns whether the offering can be sustained economically and institutionally. It includes revenue, costs, pricing, adoption, support, channels, partnerships, incentives, and strategic fit. A desirable and feasible product may still be commercially unviable if delivery costs exceed achievable revenue.

Usability

Usability is the extent to which specified users can achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use. Usability testing should define the user, task, context, and observed outcomes. A participant’s preference is useful, but completion, errors, assistance required, and recovery from mistakes often provide more actionable evidence.

Validation and verification

Validation asks whether the team is building something appropriate for the intended users, context, and purpose. It is outward-facing and concerns value and suitability. Verification asks whether the product or component has been built according to specified requirements. Verification is inward-facing and concerns conformance.

For example, a medical scheduling system may be verified as implementing its appointment rules correctly, yet fail validation if patients cannot understand the booking process. Conversely, users may value a concept that cannot be verified as safe or technically reliable.

Validation is not a single event. It is a progressive argument supported by evidence. The strength of that argument depends on the quality of the test, the representativeness of participants and context, the reliability of measurements, and the transparency of limitations.

6. Prototyping as an Evidence and Decision System

Effective prototyping begins with an assumption register. Each assumption should identify:

1. the claim being made;
2. why it matters;
3. the evidence required;
4. the prototype or experiment that can produce evidence;
5. the threshold for a decision; and
6. the action if the evidence is weak.

A useful prototype brief states the learning objective, target participants, context, prototype scope, test method, measures, ethical safeguards, and decision rule. Without these elements, teams may collect abundant comments but little usable knowledge.

Evidence can be classified as:

• opinion evidence: what people say they might do;
• behavioural evidence: what people actually do in a test or trial;
• performance evidence: measured technical or task outcomes;
• economic evidence: observed costs, conversion, retention, or payment;
• institutional evidence: acceptance by partners, regulators, operators, or procurement authorities.

No single evidence type is universally strongest. A prototype test should match the evidence to the decision. If the decision concerns a safety limit, opinions are inadequate. If it concerns emotional appeal, a purely technical benchmark may be insufficient.

A simple prioritization method is to rank assumptions by expected consequence and uncertainty. A qualitative matrix can classify assumptions as low, medium, or high on each dimension. High-consequence, high-uncertainty assumptions deserve early testing. Teams should avoid spending weeks refining low-risk visual details while critical feasibility or adoption assumptions remain unexamined.

7. A Practical Prototyping Process

Frame the problem

Define the user, context, problem, desired outcome, constraints, and alternatives. Avoid beginning with an unexamined solution. A problem statement should be specific enough to guide testing but open enough to permit alternative solutions.

Identify the riskiest assumptions

List assumptions about user behaviour, technology, operations, economics, regulation, and ethics. Identify which assumptions could invalidate the concept if false.

Select the prototype form

Choose the cheapest and fastest representation that can generate credible evidence. A sketch may test structure; a role-play may test service choreography; a PoC may test a technical principle; a pilot may test integration in practice.

Define measures and thresholds

Measures should correspond to the learning objective. Examples include task completion, error frequency, time on task, latency, failure rate, material strength, retention, repeat use, cost per transaction, or reported confidence. Thresholds should be defined before observing results where practical, to reduce motivated interpretation.

Build and test

Recruit participants or establish test conditions appropriate to the question. Provide consistent instructions, record observations systematically, and distinguish observed behaviour from interpretation. In technical tests, document configuration, environmental conditions, inputs, outputs, and failures.

Learn and decide

After testing, decide whether to persevere, modify, narrow, combine, pause, or abandon the concept. The purpose is not to defend the prototype. It is to improve the decision. A failed prototype can be a successful learning intervention if it prevents larger losses or reveals an important constraint.

Iterate with increasing commitment

As critical assumptions become better supported, increase fidelity, integration, participant scale, and environmental realism. Do not increase all dimensions at once. Controlled progression makes it easier to identify the cause of a failure.

8. Illustrative Case: “FreshRoute” Community Food Delivery

The following is a fictional illustrative case.

Background

FreshRoute is an entrepreneurial venture proposing scheduled delivery of surplus produce from local retailers to households in a university district. The team assumes that customers value lower prices and reduced food waste, while retailers value a predictable channel for surplus stock.

Problem

The initial concept involved a sophisticated mobile application with real-time inventory, automated routing, and integrated payment. The team had not established whether households would accept variable produce boxes, whether retailers could prepare orders consistently, or whether delivery density would cover operating costs.

Analysis

The team identified three high-risk assumptions:

1. households would accept substitutions and variable quantities;
2. retailers could prepare collection boxes within a fixed time window; and
3. a concentrated delivery route could be served without excessive labour cost.

A full application would not test these assumptions efficiently. The team therefore chose a low-technology service prototype.

Approach and solution

For two weeks, the team used a simple online form and a messaging channel. A spreadsheet represented inventory. Staff manually contacted two retailers, assembled boxes, and delivered them to a single collection point. Participants were told clearly that the service was an early trial and that inventory was limited.

The prototype included a paper information sheet showing possible substitutions and a short post-delivery interview. The team measured orders completed, substitutions accepted, collection punctuality, complaints, repeat orders, preparation time, and delivery effort. It also recorded packaging waste and participant accessibility needs.

The prototype revealed that customers accepted substitutions when notified before collection, but disliked unpredictable collection times. Retailers could prepare boxes, although staff needed a standard packing guide. The collection-point model reduced delivery effort, but some participants required home delivery because of mobility constraints. The team also discovered that the initial price did not cover packaging and coordination time.

Outcome

The team did not immediately build the proposed application. It revised the concept toward scheduled collection hubs, transparent substitution rules, reusable crates, and a separate accessibility option. A subsequent pilot was designed with clearer operating procedures and a revised cost model.

Learning points

The manual service was an MVP-like prototype because it delivered a limited but genuine value proposition while generating evidence from actual use. It was not a PoC because the central questions were customer, operational, and economic rather than merely technical. The case also demonstrates that a prototype can reveal inclusion requirements and cost drivers that would remain invisible in a polished digital interface.

9. Challenges, Limitations, and Ethical Governance

False confidence and weak evidence

Small samples, leading questions, unrealistic scenarios, and self-selected participants can produce misleading results. Teams should state limitations and avoid generalizing beyond the tested population and context. Positive reactions to a demonstration do not establish sustained adoption.

Prototype bias and design fixation

A prototype frames attention. Participants may comment only on visible elements, while hidden operational assumptions remain untested. A polished prototype can create anchoring, causing teams to refine an unsuitable concept rather than reconsider it.

Safety and responsible exposure

Products involving health, transport, children, food, finance, or physical risk require appropriate safeguards. A prototype must not expose participants to hazards merely to obtain learning. Test environments, supervision, emergency procedures, and stopping criteria should be proportionate to risk.

Privacy and data governance

Prototype testing often uses personal, behavioural, location, health, or payment data. Teams should collect only necessary data, explain its use, obtain appropriate consent or other lawful basis, restrict access, protect storage, define retention periods, and remove identifiers where possible. A temporary prototype is not exempt from privacy obligations.

Inclusion and accessibility

A prototype tested only with convenient, highly literate, digitally confident participants may encode exclusion. Recruitment, interface design, physical access, language, disability, affordability, and cultural context should be considered. Accessibility is not merely a final compliance check; it is a design and validation concern from the beginning.

Deception and transparency

Concierge prototypes and Wizard-of-Oz tests may involve hidden human work behind an apparent automated system. Such methods can be legitimate for learning, but participants and institutional stakeholders should not be misled about material risks, commitments, or decisions affecting them. Transparency is especially important when a prototype collects sensitive data or influences consequential outcomes.

Intellectual property and confidentiality

Early prototypes may disclose inventions, trade secrets, customer information, or partner processes. Teams should clarify ownership, confidentiality, publication rights, and access controls before demonstrations or collaborative testing. At the same time, excessive secrecy can prevent useful feedback and partnership formation.

10. Contemporary Developments and Professional Practice

Digital fabrication, rapid electronics, cloud services, virtual reality, synthetic data, and generative artificial intelligence have expanded prototyping capacity. AI tools can help generate interface alternatives, simulate conversations, summarize test transcripts, or produce code scaffolds. However, generated outputs may contain errors, bias, insecure code, copyright concerns, or fabricated evidence. Human review, traceability, and appropriate data governance remain essential.

Virtual and augmented reality can provide environmental fidelity for training, spatial design, and service simulation, but presence in a simulated environment may not reproduce real-world constraints. Digital twins and simulation can reduce physical testing, yet their conclusions depend on model assumptions and data quality. Automated analytics can identify patterns, but correlation should not be treated as causal validation without suitable design and interpretation.

Professional prototyping practice therefore combines speed with disciplined documentation. Teams should preserve version histories, test conditions, participant consent records, observed failures, decision rationales, and unresolved risks. These records support learning, handover, regulatory review, and accountability.

Best-Practice Principles

1. Prototype to answer a defined question, not merely to display activity.
2. Test the riskiest consequential assumptions early.
3. Match fidelity to the decision and the context of use.
4. Distinguish technical feasibility from customer desirability and economic viability.
5. Use behavioural and performance evidence where appropriate, not only stated preference.
6. Define measures, thresholds, and decision rules before testing where possible.
7. Increase commitment progressively as evidence improves.
8. Treat safety, privacy, accessibility, and fairness as design requirements.
9. Document limitations and avoid claiming more than the evidence supports.
10. Regard failure as useful when it produces credible learning at acceptable cost.

Chapter Summary

Product prototyping is the intentional creation of a representation or enactment for learning, communication, evaluation, or decision-making. Its purpose in entrepreneurship is to reduce uncertainty before major commitments are made. Prototypes range from sketches and mock-ups to proofs of concept, engineering prototypes, MVPs, pilots, and field trials. These forms are not stages that every product must follow mechanically; each serves different questions.

Fidelity should be selected according to the learning objective. Low-fidelity forms support rapid exploration, while high-fidelity forms support realistic evaluation of interaction, performance, integration, and context. Feasibility concerns whether a solution can be built and delivered; desirability concerns user value; viability concerns sustainability; usability concerns effectiveness, efficiency, and satisfaction; validation concerns whether the right solution is being built; and verification concerns conformity to requirements.

Effective prototyping begins with explicit assumptions, prioritizes high-consequence uncertainty, defines appropriate evidence and thresholds, and uses iterative decision-making. Ethical practice requires attention to safety, privacy, accessibility, transparency, inclusion, intellectual property, and the limits of generalization. In entrepreneurial development, the best prototype is not necessarily the most polished one, but the one that produces credible learning for the next important decision.

Key Terms

Prototype: A representation or enactment created to learn, communicate, evaluate, or decide.

Model: A simplified representation of an object, system, process, or relationship.

Mock-up: A representation emphasizing appearance, arrangement, or communication.

Wireframe: A simplified representation of interface structure and navigation.

Storyboard: A sequential representation of situations, actions, and outcomes.

Proof of concept: A limited demonstration that a critical principle can work.

Engineering prototype: A prototype used to investigate function, integration, performance, or manufacturability.

Minimum viable product: The smallest responsible offering that delivers meaningful value and enables learning.

Pilot: A limited implementation in a real or realistic operating environment.

Field trial: Evaluation under the conditions in which the product is expected to operate.

Fidelity: The degree and dimensions of resemblance between a prototype and its intended product or context.

Desirability: The extent to which users value and prefer a proposed solution.

Feasibility: The extent to which a solution can be built, delivered, operated, and maintained.

Viability: The extent to which an offering can be economically and institutionally sustained.

Usability: Effectiveness, efficiency, and satisfaction in a specified context of use.

Validation: Evidence that the appropriate product or solution is being developed.

Verification: Evidence that a product or component conforms to specified requirements.

Assumption: A proposition treated as true for planning purposes but requiring evidence.

Concierge prototype: A manually delivered service used to test value before automation.

Wizard-of-Oz prototype: An apparently automated interaction secretly supported by human operators.

Review Questions

Short Answer Questions

1. What is the defining purpose of a product prototype?
2. Distinguish a proof of concept from a minimum viable product.
3. What does fidelity mean in prototyping?
4. Explain the difference between validation and verification.
5. Why should entrepreneurs identify assumptions before building a prototype?

Long Answer Questions

1. Explain how prototyping reduces uncertainty in entrepreneurial product development.
2. Compare models, mock-ups, wireframes, storyboards, engineering prototypes, MVPs, and pilots.
3. Discuss how prototype fidelity should be selected for different learning objectives.
4. Explain desirability, feasibility, viability, and usability, and show why none alone establishes product success.
5. Evaluate the ethical and governance responsibilities involved in prototype testing.

Analytical / Application Questions

1. A startup has a sophisticated app design but no evidence that its proposed delivery process can operate profitably. Design a sequence of prototypes to test its most important assumptions.
2. A team reports that 90% of interview participants “liked” its proposed health device. Critically assess this evidence and propose stronger validation activities.
3. Design an MVP-like prototype for a university service of your choice. Specify its users, value proposition, prototype form, measures, ethical safeguards, and decision rule.

Multiple Choice Questions with Answers

Question 1

What is the primary purpose of a product prototype?

A. To guarantee commercial success

B. To create a final production version

C. To generate learning and evidence about a proposed solution

D. To replace all customer research

Correct Answer: C. To generate learning and evidence about a proposed solution

Question 2

Which prototype primarily tests whether a critical technical principle can work?

A. Proof of concept

B. Storyboard

C. Packaging mock-up

D. Market advertisement

Correct Answer: A. Proof of concept

Question 3

Which statement best describes an MVP?

A. The cheapest artifact regardless of quality

B. The smallest responsible offering that delivers value and enables learning

C. A laboratory demonstration with no users

D. A fully optimized and scalable product

Correct Answer: B. The smallest responsible offering that delivers value and enables learning

Question 4

A prototype has realistic screens but no working interaction. Which dimension is most likely high?

A. Visual fidelity

B. Operational fidelity

C. Technical reliability

D. Economic viability

Correct Answer: A. Visual fidelity

Question 5

What does feasibility primarily concern?

A. Whether users find a solution attractive

B. Whether a solution can be built and delivered within constraints

C. Whether the brand is memorable

D. Whether competitors use similar colours

Correct Answer: B. Whether a solution can be built and delivered within constraints

Question 6

What is the central question of validation?

A. Was the product built according to specifications?

B. Is the team building an appropriate solution for intended users and context?

C. Can the prototype be produced in one day?

D. Has the product received publicity?

Correct Answer: B. Is the team building an appropriate solution for intended users and context?

Question 7

Which approach is most appropriate for testing whether a service workflow functions in an actual organization?

A. A purely decorative render

B. A pilot

C. A logo sketch

D. A conceptual slogan

Correct Answer: B. A pilot

Question 8

Why can a high-fidelity prototype create design fixation?

A. It prevents any data collection

B. Its polish can make stakeholders overly attached to details

C. It always costs less than a sketch

D. It cannot represent user interaction

Correct Answer: B. Its polish can make stakeholders overly attached to details

Question 9

Which is an example of behavioural evidence?

A. A participant says the idea sounds useful

B. A participant completes the task and returns to use the service

C. The founder believes the market is large

D. A competitor has a similar product

Correct Answer: B. A participant completes the task and returns to use the service

Question 10

Which practice is most responsible when testing a prototype that collects personal data?

A. Collect all available data for future use

B. Avoid explaining data use to participants

C. Collect necessary data with appropriate transparency and protection

D. Assume prototypes are exempt from privacy obligations

Correct Answer: C. Collect necessary data with appropriate transparency and protection