Prototypes

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.

AI for Project Managers — Build Plans Faster, Lead Better

Turn messy inputs into structured project plans in minutes. If you are a project manager tired of spending hours on documentation, this course shows you how to use AI to work faster while staying fully in control.

This is not a generic AI course. You will learn how to use AI as a practical co-pilot to build real project artifacts—charters, WBS, schedules, risk registers, and executive reports—using structured, reliable prompt frameworks.

You will also learn how to keep your project aligned across scope, schedule, cost, and risk, and how to interpret performance data like Earned Value Management to support better decisions and communication.

Everything is designed for immediate use. You get ready-to-use prompt templates and workflows you can apply right away in your projects. Watch the video to see how it works and start building your first AI-supported project plan.

Explore the Course


Build the Sprint Reporting System, Not Another Prompt

AI Systems with Claude is our own course for Scrum Masters and Agile Project Managers, taught against one running project across eight teaching sections. You build five working systems and keep them: the sprint report machine, the retro intelligence system, the stakeholder comms engine, the backlog health monitor, and the risk and dependency tracker. Direct from HK School of Management and Technology, not on Udemy.

See What Is Included