Did you know that a school app can look finished in a presentation and still be impossible to use? A beautiful screenshot may show a button labelled “Book a Slot”, yet there may be no booking action behind it. The problem is often not a missing line of code. The problem starts when a team calls a mockup, a wireframe and a prototype the same thing.
Here is the immediately useful answer. A wireframe describes the arrangement and priority of content and controls. A visual mockup shows a proposed appearance, including typography, colour and visual detail. A prototype is a representation used to explore or test a design, sometimes with clickable interactions and sometimes with a person simulating responses. Knowing which one the team has made prevents it from promising a working feature it has not built or tested.
These distinctions matter to secondary students planning digital school projects, JC students preparing design proposals, and adults reviewing apps for their families. Vocabulary makes unfinished design work honest, helps people ask the right questions and lets teams progress from ideas to evidence without confusing a drawing with a tested service.
The classroom library app that appeared finished
Imagine three fictional Secondary 2 students preparing a phone app to help classmates find books for a reading challenge. One pupil sketches three rectangles labelled Search, Saved and Book Details. Another adds polished colours and a school-style logo. A third connects the Search button to a page showing invented titles. They proudly say, “Our app is finished.” But nobody has checked whether a student can locate a book, distinguish availability from reservation or complete a task without explanation.
All three pieces of work have value. The original sketch is a low-detail wireframe, which asks where information belongs. The polished screen is a visual mockup, which asks how the design communicates visually. The connected sequence is an interactive prototype, which asks how a user travels through a proposed task. None alone proves that a real library catalogue, authentication system or reservation database exists. A truthful project report should describe exactly what can and cannot happen.
Four design words that do different work
A wireframe is typically concerned with structure: navigation placement, a search field, a result list, filters and the order in which information appears. It can be drawn with a pencil or made digitally. Its job is not to display every final colour or photo. A mockup usually presents a more developed visual composition; it can be static even when the finished product will have active controls. Designers use terminology flexibly, so a project brief should explain what its version contains.
A prototype is made for exploring an idea or testing a task. It may consist of paper screens changed by a facilitator, clickable frames that simulate a journey, or a coded demonstration of a limited workflow. It need not include real data or all final features. A production app is deployed software whose behaviour, data, security and accessibility must be examined under real operating conditions. A prototype can help us make a production app better; it is not automatically that app.
Two more terms explain what the prototype is for. Fidelity means how closely the representation resembles the intended experience in a chosen respect. Interactivity describes whether and how the representation responds to actions. These are not identical. A low-fidelity paper prototype can be highly useful for a real task test, while a beautiful high-fidelity static mockup may have no working navigation at all.
The vocabulary of action
Useful verb–noun pairings include sketch a wireframe, review a mockup, link prototype screens, observe a user task, record a navigation error and revise the flow. Notice how each verb suggests a different piece of evidence. We can inspect a wireframe, compare a mockup with design requirements, and watch a learner attempt a task with a prototype. We should not call every one of those activities a usability test.
The mechanism: move from a promise to a testable task
Begin with the user’s need instead of the decoration. Our fictional pupil wants to find an available fiction book suitable for a reading challenge. Write the task in ordinary language: “Find a book by topic and learn whether it is available.” Next identify the information required: topic, title, author, availability status and a route back to results. Only then draw where the search controls and book information might appear.
The wireframe can expose a question the team missed: if the app lists a book as “available”, does that refer to an actual library copy or invented demonstration data? The mockup can expose another issue: a grey status label may be hard to distinguish from an unavailable one. The prototype can expose a third: after viewing a book, the learner may not know how to return to the search results. Each deliverable makes a different uncertainty visible.
Nielsen Norman Group explains that wireflows combine wireframe-style screens with a simplified task flow. They are useful when a few screens change dynamically during interaction. That insight is valuable for student teams: sometimes a single attractive page tells us almost nothing about what happens after the user presses a button. Connecting screens with labelled arrows may reveal missing steps before any programming begins.
A worked project example: compare three outputs
Let the task be “Find and save a Science reference book”. The wireframe uses simple boxes for Search, Results, Details and Saved Items. Under each box students write the essential fields, not decorative text. The mockup applies readable text sizes, colour, contrast, and a consistent visual language to those same screens. The prototype connects Search to Results, Results to Details, and a Save action to a changed Saved Items screen.
Now give a classmate one instruction: “You want a book about plants. Show me how you would save it.” Do not tell the classmate where the Save button is. If they cannot find it, record where they looked, which label confused them and what they expected to happen. That observation is more informative than counting how many friends say the design looks nice. It tests a task, not a fashion preference.
Suppose a fictional trial involves five volunteers. Three successfully save the book without hints; two need the facilitator to point out the Save label. We can report “three of five completed this demonstration task without help”, or 3 ÷ 5 = 60%. We cannot claim that 60% of all school students will succeed, because these five invented volunteers are not a representative study. The example teaches the denominator and the limit of a conclusion.
Change the context: suppose the button says “Bookmark” and two students think it only remembers the page, not the book. That is a vocabulary problem inside the interface. The design team can test “Save Book” against “Bookmark” with comparable task instructions, then describe observations without declaring a universal winner. The words on the button are part of the technology. They influence what the user expects to happen.
Why a clickable button is not the same as a working service
A prototype button can change the visible screen even though no real booking or saving takes place. It might simulate data and store nothing after the session. That is acceptable if the team says so. It is misleading if the group presents the simulation as a functioning library booking system. Separate three claims: “the button is visible”, “the screen responds in a test prototype” and “the production service securely records a real transaction”. They require different evidence.
An accessibility concern also changes the test. Can a keyboard-only learner navigate the task? Are controls named meaningfully? Does colour alone carry status information? A mockup helps examine appearance but cannot establish full keyboard or screen-reader behaviour. A functioning prototype can reveal some interaction problems, yet real accessibility testing of the implemented product may still be necessary. The task and the evidence must remain aligned.
The Nielsen Norman Group guide to low- and high-fidelity prototypes explains that both static and interactive representations can be useful, and that a paper prototype may be tested with a person acting as the computer. This is an important correction to a classroom misconception: “prototype” does not mean “coded”, and “low-fidelity” does not mean “unprofessional”. The appropriate form depends on what the team needs to learn.
What parents, teachers and students can check
A teacher can ask each team to label the evidence on its presentation slide: wireframe, static visual mockup, clickable prototype, or implemented feature. This prevents accidental overclaiming and makes assessment fairer. A student can add a brief statement under a demonstration: “The catalogue entries are invented; the prototype demonstrates navigation but does not connect to an actual library.” That limitation makes the project more credible, not less.
A parent viewing a child’s school project can ask, “What question was this version designed to answer?” If the child says the mockup helped choose text size, follow up on readability. If the child says the prototype helped test whether classmates could find the next step, ask what happened during the test. The emphasis moves from admiring the artefact to understanding the reasoning that produced it.
For a student exploring design, computing or communication careers, these words also become collaboration tools. A designer, developer, tester and project manager may all review the same screen while needing different evidence. Describing the work precisely reduces confusion: a request to “update the mockup” need not imply “change the production database”. This is one way vocabulary supports reliable handoffs.
Misconceptions and a repair for each
Misconception: “A mockup is a prototype.” Repair: ask whether the artefact is primarily a static visual proposal or a representation designed to test a task; acknowledge that some teams use the words differently, and define your own deliverable. Misconception: “A high-fidelity screen is ready to deploy.” Repair: list what remains untested: actual data, error handling, security, accessibility and real usage.
Misconception: “A low-fidelity prototype is not useful.” Repair: try a paper test of the book-search route before coding. Misconception: “One successful demonstration proves a design is easy.” Repair: describe exactly who attempted what task, what help they received and which difficulties appeared. A single demonstration can reveal a problem; it cannot reliably estimate how common it is.
A diagnostic exercise with answers
A group shows a polished image of a login screen. It has the school’s colours, a username field and a Login button, but clicking does nothing. Which label is more accurate: production app, interactive prototype or static mockup? Answer: static mockup. It communicates visual appearance, not implemented login behaviour. The correct question is whether the picture meets layout, language and accessibility goals appropriate for that stage.
A different group presents three pencil sketches. A facilitator swaps each paper screen whenever a classmate taps a paper button. Is this a prototype? Answer: yes. Its interactive response is simulated by a person. It can reveal misunderstanding of navigation labels even though no code exists. The team should state that it is a low-fidelity paper prototype and explain the test procedure.
Finally, a team builds a clickable prototype with buttons that always show a “Saved!” confirmation, even when no title has been selected. What does the failure show? Answer: the prototype omits or mishandles an important condition. A useful next version should define when Save is valid, what feedback appears on success and how users recover from an invalid action. The distinction is not only between screens; it is between promises and correctly specified behaviour.
Changed-context transfer: a science-project dashboard
Now consider a different project: a dashboard displaying plant-growth measurements. A wireframe can locate the date filter and chart legend. A mockup can make the graph readable and distinguish units visually. A prototype can test whether a learner can select a date range and inspect the corresponding values. An implemented dashboard must use actual recorded data and handle empty or missing observations honestly. The same three design words transfer, but the scientific quality questions change.
Try the task yourself. Write the question you want the dashboard to answer. Identify which parts can be checked by a layout drawing, which need visual review, which require an interaction test and which demand implemented data validation. Explain why a fake chart is acceptable inside a labelled demonstration but not as evidence of real plant growth. A student who can make that distinction understands more than interface vocabulary.
Frequently asked questions
Is a wireframe always black and white? No. Simple monochrome sketches are common because they keep attention on structure, but colour is not the defining condition.
Must a prototype be clickable? No. Paper prototypes can be tested with a facilitator simulating the system; interactive digital prototypes are another option.
Can a mockup show realistic text and images? Yes. Its value is often in communicating visual appearance and content hierarchy. Realistic appearance does not prove that linked functions exist.
Does using AI to generate screens make them production-ready? No. Generated output still requires human review, task testing, accessibility checks and implementation-specific validation. A plausible rendering is a proposal, not evidence of reliable operation.
When can a school team say a feature works? Specify what was implemented, the context and the test performed. “The sample Save action works within our prototype” is a narrower and more defensible claim than “the library booking service works for everyone.”
The bigger lesson: precise words make design decisions testable
Wireframe, mockup and prototype are useful because they give each stage of a design a distinct question. Where does information belong? How should it appear? What happens when someone tries a task? What can the implemented product actually do? The vocabulary protects a team against building on an untested assumption, and it helps pupils explain genuine progress without pretending a sketch is a finished system.
For further learning, visit the verified Vocabulary Meaning and Precision Hub or the Vocabulary Learning Hub. Primary design references reviewed 28 October 2026: Nielsen Norman Group on prototype fidelity and testing and Nielsen Norman Group on wireflows and user tasks. All student scenarios in this article are teaching examples, not records of actual pupil performance.