HKSM

A prototype is a preliminary, low-to-high fidelity model of a product, service, or process used to explore requirements, test ideas, and gather stakeholder feedback before full-scale delivery. Prototypes reduce uncertainty and rework by enabling early evaluation of design, usability, and feasibility.

Key Points

• Prototypes are learning tools that make ideas tangible so stakeholders can validate needs and assumptions early.
• Common forms include sketches, wireframes, clickable mockups, physical models, and limited working builds.
• They can be throwaway (used to learn, then discarded) or evolutionary (incrementally refined toward the final solution).
• Each prototype should have a clear objective, timebox, and success criteria to focus analysis.
• Use rapid, iterative feedback cycles to refine requirements and reduce risks.
• Set expectations that a prototype is not the final product and may lack completeness or quality.

Purpose of Analysis

Use prototypes to clarify what stakeholders need, evaluate design choices, and test feasibility before committing significant cost and schedule. Analysis focuses on discovering gaps, conflicts, and quality expectations so the team can make informed decisions and prioritize value.

Method Steps

• Define the learning objective and scope for the prototype (what question must be answered).
• Select fidelity and approach: low vs high fidelity; throwaway vs evolutionary; physical vs digital.
• Plan evaluation: scenarios, acceptance criteria, metrics, and data to capture.
• Build the minimal prototype that is sufficient to test the objective within a fixed timebox.
• Facilitate stakeholder reviews and usability walkthroughs; observe and record feedback objectively.
• Test against criteria and scenarios; compare outcomes to hypotheses and constraints.
• Analyze findings; decide to iterate, pivot, or proceed; document decisions and rationale.
• Update requirements, backlog items, acceptance criteria, risks, and plans accordingly.

Inputs Needed

• Problem statement, business goals, and desired outcomes.
• Initial requirements or user stories, assumptions, and hypotheses.
• User personas, scenarios, and usage context.
• Constraints such as budget, timebox, technology, policies, and compliance needs.
• Design guidelines, standards, or architecture principles.
• Evaluation plan with success criteria and metrics.
• Tools, materials, and environments for building and testing.

Outputs Produced

• Prototype artifacts and any supporting notes or recordings.
• Validated, refined, or newly discovered requirements and acceptance criteria.
• Resolved questions, identified risks and issues, and mitigation actions.
• Updated backlog, priorities, and change requests as needed.
• Decision log entries capturing outcomes, trade-offs, and next steps.
• Lessons learned to improve future iterations and stakeholder engagement.

Interpretation Tips

• Focus on the learning objective; do not over-engineer the prototype.
• Include diverse stakeholders to reveal different perspectives and hidden requirements.
• Separate desirability, feasibility, and viability when interpreting feedback.
• Use objective measures where possible; avoid confirmation bias and anchoring.
• Trace each change request to evidence from the prototype session.
• Document what did not work and why; negative findings are valuable.

Example

A team designing a new onboarding process creates a clickable mockup of the forms and steps. Stakeholders test key scenarios and report confusion about navigation and excessive data fields. The team removes nonessential fields, clarifies labels, updates acceptance criteria, and plans a second iteration to test performance under load.

Pitfalls

• Treating the prototype as the final product and raising expectations prematurely.
• Lack of a clear objective or criteria, leading to unfocused feedback.
• Over-investing time and cost in high-fidelity builds before basics are validated.
• Ignoring nonfunctional needs such as accessibility, performance, and security.
• Gathering feedback from a narrow audience that does not represent real users.
• Failing to capture decisions and update requirements and risks after sessions.

PMP Example Question

During early requirements analysis, a team builds a clickable mockup to test navigation and collect user feedback. What is the primary benefit of this approach?

1. It provides a fully functional product that can be released quickly.
2. It enables early validation of requirements and reduces the risk of rework.
3. It guarantees stakeholder approval of the final design.
4. It eliminates the need for formal testing later in the project.

Correct Answer: B — It enables early validation of requirements and reduces the risk of rework.

Explanation: Prototypes make ideas tangible so stakeholders can test and refine requirements early. This reduces uncertainty and helps avoid costly changes later.