Concept Development and Prototyping

Introduction

Product discovery does not end when a team identifies a user problem. A problem statement is an interpretation of evidence; it is not yet a product. The next task is to develop possible responses to that problem, make selected responses tangible, and obtain evidence about their desirability, usability, feasibility, viability, and ethical acceptability.

Concept development and prototyping provide the bridge between insight and validated learning. Concept development expands the solution space before resources are committed. Prototyping creates representations of possible products or services so that users, stakeholders, designers, engineers, and commercial teams can inspect, challenge, and improve them. A prototype is therefore not simply a preliminary version of a product. It is an instrument for reducing uncertainty.

A mature product team treats prototypes as learning devices. The appropriate question is not “How polished is this prototype?” but “What important assumption is this prototype designed to test?”

Learning Objectives

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

1. Distinguish problem framing, solution concepts, prototypes, and products.
2. Generate alternative concepts using divergent methods.
3. Converge on concepts using explicit evidence and decision criteria.
4. Select an appropriate prototype fidelity for a learning objective.
5. Create sketches, storyboards, clickable prototypes, concierge services, and technical proofs of concept.
6. Design prototype tests that produce reliable and ethically obtained evidence.
7. Interpret prototype findings without overclaiming validation.
8. Manage the organizational, technical, ethical, and commercial implications of prototype decisions.

From Problem Insight to Solution Concept

A solution concept is a coherent proposition describing how a product, service, or experience could create value for a specified user in a particular context. It normally includes:

• a target user or segment;
• a situation, need, or job to be addressed;
• a proposed mechanism of value creation;
• an interaction or delivery model;
• assumptions about desirability, feasibility, viability, and risk.

For example, “an app for students” is not a sufficiently developed concept. “A mobile service that helps postgraduate students find quiet, available study spaces within ten minutes of campus by combining live occupancy reports with reservation slots” is more testable. It expresses a user, context, benefit, and mechanism.

A useful distinction is:

The distinction prevents premature commitment. Teams often jump from a compelling user statement to a single familiar solution. This is solution fixation: the tendency to defend the first plausible idea rather than compare alternatives.

Divergent Concept Development

Divergence seeks breadth before selection. Its purpose is not to produce random ideas but to expose different mechanisms, assumptions, and trade-offs. A strong divergent process includes individual thinking, group synthesis, and deliberate variation in the solution space.

Reframing and “How Might We” Questions

A “How might we?” question converts an observation into an opportunity without prescribing a solution. “How might we help commuters avoid delays?” permits information, routing, scheduling, infrastructure, and behavioural interventions. “How might we build a train-delay app?” prematurely narrows the space.

Good opportunity questions are:

• grounded in observed evidence;
• broad enough to permit multiple responses;
• narrow enough to guide action;
• neutral about the technology or business model;
• connected to a meaningful user outcome.

Analogy and Constraint-Based Ideation

Analogy transfers a principle from one domain to another. A healthcare appointment service might borrow queue visibility from air-traffic systems or progress feedback from parcel tracking. The analogy is useful only when the underlying mechanism, rather than the surface appearance, transfers.

Constraints can also improve creativity. A team may ask how the service would work with no smartphone, no human staff, or a five-minute interaction limit. Constraints reveal essential functions and alternative delivery models. They should be used to generate concepts, not to conceal impossible requirements.

Structured Ideation Methods

Common methods include:

• Brainwriting: participants independently record ideas before group discussion, reducing conformity and dominance effects.
• SCAMPER: concepts are examined through substitute, combine, adapt, modify, put to another use, eliminate, and reverse prompts.
• Concept combination: attributes such as user, channel, timing, incentive, and delivery mechanism are combined systematically.
• Crazy Eights: participants rapidly sketch several alternatives, emphasizing quantity and variation.
• Role-storming: participants generate ideas from the perspective of another user, stakeholder, or institution.
• Service blueprint ideation: front-stage and back-stage activities are redesigned together, exposing operational concepts that a screen-focused process might miss.

Divergence should include more than feature ideas. Teams should vary the value proposition, service model, channel, level of automation, revenue model, and operational process. A concept that changes only the interface may not address the underlying problem.

Convergent Concept Selection

Convergence reduces the number of concepts through explicit reasoning. It is not a vote for the most attractive sketch. A concept should be assessed against evidence, strategic intent, constraints, and the consequences of learning.

Selection Criteria

A practical concept assessment may consider:

1. Desirability: Will the target user perceive meaningful value and adopt the solution?
2. Usability: Can users understand and complete the relevant tasks?
3. Feasibility: Can the organization build and operate it with available capabilities?
4. Viability: Can it support an economically sustainable model?
5. Strategic fit: Does it advance the product and organizational strategy?
6. Risk and responsibility: Does it create legal, safety, privacy, accessibility, or reputational risks?
7. Learning value: Can the concept test an important uncertainty efficiently?

A weighted decision matrix can make assumptions visible. If concept score S_j is calculated as a weighted sum:

where w_i is the weight assigned to criterion i, r_ij is the rating of concept j on that criterion, and the weights sum to 1. Ratings must use a defined scale, such as 1 to 5. The score is meaningful only when criteria are clearly defined and ratings are supported by evidence. It is a prioritization aid, not an objective truth; false precision can result when uncertain judgments are presented as exact measurements.

For example, suppose a team weights desirability at 0.35, feasibility at 0.25, viability at 0.20, strategic fit at 0.10, and responsible design at 0.10. A concept rated 4, 3, 3, 5, and 4 respectively receives:

The result indicates relative priority under the stated assumptions. It does not establish that users will adopt the concept or that the business will succeed.

Assumption Mapping

Teams should identify what must be true for each concept to work. Assumptions can be classified as:

• Value assumptions: users experience a meaningful benefit.
• Adoption assumptions: users will change behaviour or switch from alternatives.
• Capability assumptions: the organization can deliver the experience.
• Economic assumptions: acquisition, service, and revenue economics are acceptable.
• Compliance assumptions: the concept can operate lawfully and fairly.

The riskiest assumption is not necessarily the most uncertain one; it is the uncertain assumption whose failure would materially invalidate the concept. This distinction helps teams prioritize learning.

A useful decision rule is to retain several concepts when uncertainty is high and prototype them cheaply, rather than forcing a single winner too early. Convergence can therefore be staged: narrow the field enough to invest in learning, then select after evidence is obtained.

Prototyping as an Evidence Strategy

A prototype is a selective representation. It includes some aspects of a proposed experience and excludes others. Every prototype has a purpose, audience, scope, fidelity, and learning question.

A prototype should specify:

• the assumption being tested;
• the behaviour or response that would constitute evidence;
• the target participants;
• the test context;
• the limits of what can be inferred;
• the decision that will follow.

For example, a prototype may test whether users understand a value proposition, not whether they will pay for a fully operational service. A successful usability session cannot prove market demand, technical scalability, or financial viability.

Fidelity

Fidelity refers to how closely a prototype represents the proposed product in appearance, interaction, content, data, speed, and operational realism. It is multidimensional. A prototype may have high visual fidelity but low data fidelity, or high service realism but no software interface.

The principle of minimum sufficient fidelity is valuable: use the least expensive representation capable of answering the current question. Increasing fidelity is justified when the unresolved uncertainty concerns details that low-fidelity representations cannot expose.

Core Prototype Forms

Sketches and Wireframes

Sketches externalize ideas quickly. They reveal hierarchy, sequence, information requirements, and alternative layouts. Annotated sketches should identify intended actions, system responses, content assumptions, and unresolved issues. They are especially useful in early workshops because they make revision inexpensive.

Wireframes provide greater structural clarity. They can describe screens, navigation, system states, empty states, errors, permissions, and edge cases without imitating final visual design. A professional wireframe process includes non-happy paths: failed payments, missing information, interrupted sessions, no results, and accessibility needs.

Storyboards

A storyboard represents an experience across time. It shows the user’s context before, during, and after interaction, including actors, environment, motivation, obstacles, and outcomes. Storyboards are particularly valuable for services, physical products, and behaviour-change concepts because the value may emerge from a sequence rather than a single interface.

A storyboard should not merely illustrate an idealized success path. It should make visible triggers, user effort, organizational actions, waiting periods, and recovery from failure.

Clickable Prototypes

Clickable prototypes connect screens or states to simulate a task. They can test navigation, comprehension, content sequencing, perceived confidence, and error recovery. They should contain realistic labels and representative content; placeholder text can produce misleading results.

A clickable prototype must distinguish simulated from functioning elements. Participants should not be deceived about whether a transaction, data submission, or account change is real. If a “reserve” button produces a simulated confirmation, the facilitator should explain the simulation at an appropriate point and protect participants from unintended commitments.

Concierge and Wizard-of-Oz Services

A concierge prototype delivers a service manually to a small number of users. A proposed automated meal-planning service, for example, might initially use a human nutritionist to prepare recommendations. The team tests whether the outcome is valuable before investing in automation.

A Wizard-of-Oz prototype presents an apparent automated interface while humans perform hidden operations. This can test the interaction and value proposition, but it requires careful disclosure, privacy protection, and an operational plan. It should not be used to misrepresent consequential decisions as algorithmically generated.

Concierge prototypes are especially useful when the product’s value depends on personalization, judgement, or an untested service workflow. Their limitation is that manual effort may not scale and may produce a better experience than the eventual system can deliver.

Technical Proofs of Concept

A technical proof of concept (PoC) investigates whether a critical technical mechanism is possible. It may test an application programming interface, latency, sensor accuracy, data pipeline, security control, model performance, or integration with an existing system.

A PoC is not a production system. It commonly omits maintainability, accessibility, monitoring, documentation, resilience, and security hardening. Teams should record the environment, data, assumptions, test conditions, failure modes, and unresolved engineering debt.

Technical feasibility should be tested in relation to the intended user outcome. A technically impressive demonstration is irrelevant if it does not solve the user’s problem or operate within acceptable cost, risk, and regulatory constraints.

Designing Prototype Tests

A prototype test is a research activity, not a demonstration. A basic test plan includes a research question, participant profile, recruitment method, scenario, tasks, prompts, measures, consent process, and decision rule.

Tasks and Scenarios

Tasks should describe a goal rather than prescribe interface actions. “Find and reserve a study space for tomorrow afternoon” is preferable to “tap the blue reservation button.” The latter tests whether participants follow instructions, not whether they can use the product naturally.

Scenarios should provide enough context to make the task meaningful without leading the participant toward the expected answer. Facilitators should ask participants to think aloud where appropriate, but should not overinterpret verbal confidence as evidence of actual behaviour.

Evidence and Interpretation

Evidence can be qualitative, behavioural, technical, or commercial. Examples include:

• observed task breakdowns;
• spontaneous questions and workarounds;
• completion or abandonment;
• time-on-task;
• error frequency;
• comprehension of the value proposition;
• willingness to undertake a meaningful next step;
• system latency or failure rate;
• operational effort and cost.

A small usability study can reveal severe interaction problems, but it cannot estimate population adoption reliably. Similarly, positive statements such as “I would use this” are weaker than observed behaviour, a realistic commitment, or payment under appropriate conditions.

Teams should separate observations, interpretations, and decisions. “Three participants searched for availability before reading the explanation” is an observation. “The explanation is unnecessary” is an interpretation. “Remove the explanation” is a decision. Keeping these categories separate reduces confirmation bias.

Applied Case: Campus Study Space Service

The following is an illustrative case.

Background

A university receives complaints that postgraduate students cannot reliably find quiet study space during assessment periods. Existing room-booking systems show scheduled reservations but not actual occupancy. Students walk between buildings, lose time, and sometimes occupy rooms intended for other groups.

Problem and Opportunity

Interviews and observation suggest that the immediate problem is not simply a shortage of rooms. Students lack timely confidence about where they can work, while facilities staff lack accurate information about use and abandonment. The opportunity question is: “How might we help students find appropriate study space with less wasted effort while improving visibility for facilities staff?”

Divergent Concepts

The team develops five concepts:

1. A live occupancy map based on room sensors.
2. A student reporting service allowing users to confirm whether rooms are occupied.
3. A reservation system with automatic release when users do not check in.
4. A staffed “study-space concierge” that recommends locations.
5. A demand-management service that recommends less busy times and buildings.

These concepts vary in technology, operational effort, privacy implications, and behavioural assumptions.

Assumption Analysis

The sensor concept depends on accurate detection, installation permission, maintenance, and acceptance of monitoring. The reporting concept depends on repeated student participation and protection against inaccurate or malicious reports. The check-in concept depends on users accepting location or identity controls. The concierge concept tests value with low technical risk but potentially high operating cost.

The team identifies two high-risk assumptions: students value reliable occupancy information enough to change behaviour, and a recommendation can be accurate without collecting excessive personal data.

Prototype Approach

First, the team creates paper sketches of four mobile flows and a storyboard showing a student arriving on campus, searching, receiving a recommendation, and reporting that a room is occupied. Five students compare the concepts and explain what would make them trust the information.

Second, a medium-fidelity clickable prototype tests three tasks: finding a room, understanding confidence indicators, and reporting a change. The prototype deliberately includes uncertainty labels such as “reported 12 minutes ago” rather than implying perfect real-time accuracy.

Third, a two-week concierge pilot uses facilities staff to publish verified room updates at selected times. The team measures repeated use, travel avoided, incorrect recommendations, staff effort, and student willingness to report changes.

Outcome

The study shows that students value confidence and recency more than a visually sophisticated map. A sensor-only approach is deferred because installation costs and privacy concerns are unresolved. The team selects a hybrid concept: scheduled facilities updates combined with low-friction student reports, accompanied by transparent confidence indicators. A later technical PoC investigates whether anonymous occupancy counts can be obtained without identifying individuals.

Learning Points

The team did not treat the most technologically advanced concept as the best concept. Low-fidelity work exposed trust requirements; the concierge pilot tested real behaviour; and the technical PoC was reserved for a specific feasibility uncertainty. The resulting product direction emerged through staged evidence rather than presentation quality.

Professional, Ethical, and Governance Considerations

Prototype work can create real effects. A “test” may collect personal data, influence decisions, consume staff time, or expose participants to risk. Product teams should therefore apply governance proportionate to the prototype.

Important practices include:

• obtain informed consent for research participation;
• collect only data needed for the learning objective;
• explain recording, observation, and data retention;
• avoid testing consequential decisions on vulnerable people without safeguards;
• provide accessible participation options;
• protect confidential concepts and participant identity;
• distinguish simulated from real transactions;
• assess bias in recruitment, data, and evaluation;
• document ownership and permitted use of research outputs;
• involve legal, security, safety, and compliance specialists when relevant.

AI-enabled prototypes require additional care. A generative system may produce plausible but incorrect content, reproduce bias, expose confidential prompts or data, or create an illusion of capability. Teams should label synthetic outputs, test representative edge cases, log important failures, and avoid using prototypes to make high-impact decisions until appropriate validation and governance exist. Human oversight is not a substitute for clear accountability.

Common Failure Modes and Best Practices

Failure Modes

Prototype as performance: Teams polish an artifact to secure approval rather than investigate uncertainty.

Single-concept fixation: The first idea becomes the solution before alternatives are considered.

Feature testing without context: Participants evaluate isolated functions without understanding the real situation of use.

Leading facilitation: Facilitators explain the intended path, generating compliance rather than learning.

False validation: Positive comments are treated as proof of adoption or commercial success.

Unrepresentative participants: Convenient colleagues stand in for target users with different needs or constraints.

Unmanaged prototype debt: Experimental code becomes production infrastructure without security, accessibility, or maintenance review.

Best Practices

1. State the learning objective before choosing the prototype form.
2. Generate multiple concepts that differ in mechanism, not merely appearance.
3. Make assumptions and decision criteria explicit.
4. Use the lowest fidelity capable of answering the question.
5. Test realistic tasks, contexts, content, and failure states.
6. Record observations separately from interpretations.
7. Combine user, operational, technical, and economic evidence.
8. Define what result would change the decision.
9. Treat privacy, accessibility, safety, and fairness as design requirements.
10. Increase fidelity only when remaining uncertainty justifies the cost.

Contemporary Developments

Distributed teams increasingly use collaborative whiteboards, remote clickable prototypes, synthetic data, and moderated or unmoderated digital tests. These tools improve speed and geographical reach, but they can exclude users with limited connectivity or assistive-technology needs. Remote research also reduces visibility into physical context and nonverbal cues.

Generative AI can accelerate alternative concept generation, create interface variants, simulate conversational flows, and identify possible edge cases. Its outputs should be treated as proposals, not evidence. Human research, domain expertise, copyright review, privacy protection, and bias assessment remain necessary. AI can expand divergence, but convergence must remain accountable to user evidence and organizational responsibility.

Chapter Summary

Concept development transforms user and market insights into alternative responses. Divergent methods broaden the solution space through reframing, analogy, structured ideation, constraints, and service analysis. Convergent methods compare concepts using desirability, usability, feasibility, viability, strategic fit, responsibility, and learning value.

A prototype is a purposeful representation used to reduce uncertainty. Sketches and wireframes explore structure; storyboards represent experiences across time; clickable prototypes test interaction; concierge and Wizard-of-Oz services test value and operations; and technical proofs of concept investigate critical feasibility questions. Fidelity should be increased only when lower-cost representations cannot answer the question.

Effective prototype testing uses realistic tasks, appropriate participants, explicit assumptions, ethical safeguards, and decision rules. Prototype evidence must be interpreted within its limits: usability evidence does not prove market demand, and technical feasibility does not prove user value. Professional product management integrates user, operational, technical, commercial, and responsible-design evidence into staged decisions.

Key Terms

Solution concept: A proposed way of creating value for a defined user in a particular context.

Divergence: Expansion of the solution space through generation of multiple alternatives.

Convergence: Reduction of alternatives using evidence, criteria, and judgement.

Solution fixation: Premature commitment to a familiar or initial solution.

Opportunity question: A neutral question that frames a space for possible responses.

Assumption: A belief that must be true for a concept to succeed.

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

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

Viability: The extent to which a solution can be economically sustainable.

Fidelity: The degree to which a prototype represents the intended product or service.

Low-fidelity prototype: A rough representation used to explore structure or direction.

Storyboard: A sequence of visual frames representing an experience over time.

Clickable prototype: An interactive representation connecting screens or states.

Concierge prototype: A manually delivered service used to test value and workflow.

Wizard-of-Oz prototype: An apparently automated experience operated partly by humans.

Technical proof of concept: An experiment investigating whether a critical technical mechanism works.

Weighted decision matrix: A structured comparison using criteria, weights, and ratings.

Prototype debt: Unresolved technical, operational, or governance weaknesses inherited from experimentation.

Learning objective: The specific uncertainty a prototype or test is intended to reduce.

Review Questions

Short Answer Questions

1. What distinguishes a solution concept from a prototype?
2. Why should teams generate multiple concepts before selecting one?
3. Define minimum sufficient fidelity.
4. What is the primary purpose of a technical proof of concept?
5. Why should prototype observations be separated from interpretations?

Long Answer Questions

1. Explain how divergent and convergent methods work together in concept development.
2. Compare sketches, storyboards, clickable prototypes, concierge services, and technical proofs of concept.
3. Discuss the strengths and limitations of weighted decision matrices.
4. Explain how a product team should design an ethical prototype test.
5. Discuss why successful usability testing cannot by itself establish product-market fit.

Analytical / Application Questions

1. A team wants to build an AI career-coaching application. Identify five critical assumptions and propose a prototype for testing each one.
2. A prototype receives enthusiastic feedback, but few participants complete the intended task without assistance. How should the team interpret the evidence and decide what to do next?
3. Design a staged concept-development and prototyping plan for a digital service that helps hospital visitors navigate large facilities. Address desirability, feasibility, privacy, accessibility, and operational risk.

Multiple Choice Questions with Answers

Question 1

Which activity is primarily divergent?

A. Ranking concepts against weighted criteria

B. Generating several alternative mechanisms for solving a problem

C. Selecting one concept for implementation

D. Estimating the cost of a chosen design

Correct Answer: B. Generating several alternative mechanisms for solving a problem

Question 2

What is the main purpose of a prototype?

A. To guarantee commercial success

B. To replace all product documentation

C. To reduce a specified uncertainty through evidence

D. To demonstrate that the final visual design is complete

Correct Answer: C. To reduce a specified uncertainty through evidence

Question 3

Which prototype is most suitable for testing whether a manually delivered service creates value before automation?

A. Concierge prototype

B. Static logo board

C. Technical performance benchmark

D. Database schema

Correct Answer: A. Concierge prototype

Question 4

In a weighted decision matrix, what does the weight represent?

A. The number of users recruited

B. The relative importance of a criterion

C. The prototype’s file size

D. The duration of a usability session

Correct Answer: B. The relative importance of a criterion

Question 5

Which statement about a technical proof of concept is correct?

A. It is necessarily production-ready

B. It primarily investigates whether a critical technical mechanism is possible

C. It proves that users will adopt the product

D. It eliminates the need for security review

Correct Answer: B. It primarily investigates whether a critical technical mechanism is possible

Question 6

A storyboard is especially useful when a concept’s value depends on:

A. Only the colour palette of a screen

B. A sequence of interactions and contextual events

C. Source-code maintainability alone

D. A final advertising campaign

Correct Answer: B. A sequence of interactions and contextual events

Question 7

Using the chapter’s weighted-score example, what is the score for ratings 4, 3, 3, 5, and 4 with weights 0.35, 0.25, 0.20, 0.10, and 0.10?

A. 2.95

B. 3.25

C. 3.65

D. 4.10

Correct Answer: C. 3.65

Question 8

Which is the strongest example of behavioural evidence?

A. A participant says the idea sounds interesting

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

C. A stakeholder says the interface looks modern

D. A facilitator predicts high adoption

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

Question 9

Why can high visual fidelity be risky early in discovery?

A. It always prevents user testing

B. It may create attachment and false confidence before key assumptions are tested

C. It makes all prototypes technically infeasible

D. It removes the need for alternative concepts

Correct Answer: B. It may create attachment and false confidence before key assumptions are tested

Question 10

Which practice is most appropriate for an AI-enabled prototype?

A. Treating generated outputs as validated evidence

B. Hiding that humans are operating an apparently automated service

C. Testing representative edge cases and clearly managing limitations

D. Collecting all available personal data for future use

Correct Answer: C. Testing representative edge cases and clearly managing limitations