A prototype demonstrates selected ideas under defined conditions. State which interactions work, what is simulated and which operational capabilities are absent. Explain the question it was built to explore and the evidence collected, if any. Keep visual polish, technical implementation and real-world readiness as separate claims rather than treating a successful demo as proof of deployment.
State the prototype’s question and kind
Prototypes vary from linked screens to working code with limited data and integration. Begin by explaining what kind you built and which uncertainty it addresses. A clickable flow may explore navigation, while a coded experiment may explore whether an interaction can work with a particular input. Neither automatically establishes that the whole service is usable, secure or ready for real information.
Label the context: personal exercise, coursework, commissioned exploration or an internal project that you are permitted to discuss. Identify your contribution and the date or stage shown. A reviewer should be able to understand the artifact without guessing whether it had real users, a client or a production release. Clear context makes the sample’s genuine evidence easier to assess.
Inventory what works and what is simulated
Walk through the main task and classify each step. Some controls may work, some may display a fixed result and some may be decorative. Explain those differences near the demonstration. If a form accepts input but does not save it, say so before asking the reader to try it. Do not allow the interface’s familiar appearance to imply a capability that is absent.
Consider operational features beyond the visible path: access control, storage, error handling, monitoring, accessibility, data protection and ongoing support. You do not need to implement all of them for an exploratory prototype, but their absence affects what the demo can establish. Avoid inviting real personal or confidential data into a sample that was designed only for invented input.
Separate demonstration from validation
A working interaction shows that a path can operate under the conditions demonstrated. It does not establish that intended users understand it or that it behaves reliably across environments. If you conducted a review or test, describe participants, tasks and limits at an appropriate level. If you only tested it yourself, label that inspection accurately rather than calling it user research.
Explain what the prototype helped you decide. Perhaps it exposed an ambiguous field, showed a layout constraint or clarified an integration question. These are useful outcomes even when the larger product was never built. Keep plans separate from findings: a future test, proposed integration or intended launch is not part of the completed evidence.
Close with a readiness boundary and the next necessary work. Name the important checks or capabilities required before a different kind of use. A personal demo may need permissioned data, access controls and a proper accessibility review before any pilot. The point is to demonstrate that you understand the gap, not to attach a generic disclaimer that leaves the reviewer unsure what the prototype actually does.
Fictional example: a simulated appointment flow
A fictional designer builds a clickable appointment-booking prototype. The screens let a reviewer choose a date and view a confirmation, but the slots are fixed and no appointment is stored. The portfolio labels it “Interaction prototype using invented availability.” A note beside the demo explains that it has no account system, live calendar integration or operational booking capability. The designer asks reviewers to explore the navigation rather than enter personal details.
The case study compares two confirmation layouts and explains why the chosen version keeps the selected date visible. No user test was conducted, so the choice is presented as a design rationale. The next step would test comprehension with representative participants before implementing real scheduling rules. The sample demonstrates a bounded interaction decision without claiming a functioning booking service or validated demand.
A checklist for your next step
- State the prototype type and question explored.
- Label simulated data, controls and outcomes.
- Identify missing operational capabilities.
- Describe testing at its actual scope.
- Name the next work required before broader use.
Common questions
Can a polished prototype be called a product?
Use wording that reflects its actual status. If it lacks operational capabilities or has not been released, call it a prototype or concept and explain what is implemented.
Should I list every missing feature?
Prioritize limitations that affect interpretation, safety of use or the central task. A reviewer needs to understand the readiness boundary without reading an exhaustive backlog of ideas.
Further reading
These primary resources provide related background. They do not validate the illustrative example or endorse AliveCV.
AI-assisted drafting and automated technical checks. Examples are illustrative; no independent expert review or real-world outcome validation is claimed. Read our editorial policy.