Theory
Do not build the thing to test the thing
Here is a tempting mistake: to find out if FestConnect's new registration screen works, just BUILD it: code it, style it, ship it, see what happens.
And if it is wrong? You have wasted weeks, and now the fix means rewriting real code.
Architects do not construct a building to discover the rooms are in the wrong place: they draw BLUEPRINTS first. Designers do the same with wireframes (the blueprint) and prototypes (the clickable draft), testing the idea CHEAPLY before a line of code exists.
Theory
Wireframe: the skeletal blueprint
A wireframe is a low-fidelity, skeletal layout of a screen: it shows WHERE things go (structure, content, hierarchy) WITHOUT visual detail: no real colours, fonts or images, just grey boxes, placeholder text and labels.
Why strip out the visuals? To focus attention on what matters FIRST: layout and flow. A wireframe of FestConnect's registration screen answers 'is the form in a sensible order? is the button where users expect?' without anyone arguing about the shade of blue yet.
Fidelity is the amount of detail: low-fi (rough boxes, fast, cheap) versus high-fi (detailed, near-final looking). Start low.
Theory
Prototype: the clickable draft
A wireframe is static. A prototype is interactive: a clickable model that SIMULATES how the product works, so you can TEST the flow with real users before building.
Forms of prototype:
- paper prototype: screens drawn on paper; a human 'plays computer', swapping sheets as the user 'taps': astonishingly effective and nearly free
- digital prototype: made in a design tool (Figma is a common one), clickable on a real device
You hand a prototype to 5 first-years, say 'register for Garba Night', and WATCH (usability testing, Unit 2): catching flow problems while they cost minutes to fix, not weeks.
At a glance
The fidelity ladder (cheap to expensive)
| Stage | What it is | Cost to change |
|---|---|---|
| Sketch | Rough hand-drawn ideas | Seconds |
| Low-fi wireframe | Grey boxes + labels, structure only | Minutes |
| Prototype | Clickable model of the flow | Low |
| High-fi mockup | Full visual design, near-final look | Higher |
| Built product | Real coded product | Highest |
Quiz
Why deliberately keep early wireframes low-fidelity (grey boxes, no colour) instead of making them polished?
- Because designers cannot make polished work yet
- To focus feedback on structure and flow, keep changes cheap, and because people critique rough work more honestly
- Low-fi wireframes are the final deliverable to developers
- Colour is never used in any design
- To hide the design from users
Show the answer
To focus feedback on structure and flow, keep changes cheap, and because people critique rough work more honestly
Low fidelity is a deliberate choice with 3 payoffs: it keeps attention on layout and flow (not the shade of a button), it is cheap to change (the cost-of-change curve), and: subtly important: people critique ROUGH work more honestly, whereas a polished mockup looks 'finished' and discourages the very criticism you need. Option A insults the intent (it is strategic, not a limitation). Option C is false: wireframes precede high-fi design and build. Option D over-generalises (colour matters, just later). Option E inverts the purpose (you SHOW low-fi work to gather feedback). Rough on purpose, to learn cheaply.
Think first
The polished-mockup trap
You show a stakeholder a beautiful, finished-looking mockup and ask for feedback. Why might you get LESS useful criticism than if you had shown grey boxes? Then tap.
Show the answer
A polished mockup LOOKS done, so people assume the big decisions are settled and hesitate to suggest fundamental changes: 'it looks finished, I don't want to make them redo it'. They nitpick small things (a colour, a word) instead of questioning the structure. Grey-box wireframes signal 'this is rough, still being figured out', which INVITES honest structural feedback: 'actually the whole flow is backwards'. This is why designers show low-fi work early precisely to provoke deep critique. The counter-intuitive rule: the rougher the artefact, the braver and more useful the feedback. Fidelity signals how open you are to change.
Watch out
Wireframe/prototype slips
Building before wireframing: coding to test an idea wastes weeks; sketch and prototype first (cost-of-change).
Polishing too early: high fidelity too soon suppresses honest feedback and wastes effort on visuals that may get cut.
Wireframe vs prototype confusion: a wireframe is a STATIC layout; a prototype is INTERACTIVE (clickable, testable).
Skipping the user test: a prototype exists to be TESTED with real users, not just admired internally.
Theory
Structure sketched, now the paths
Wireframes lay out each screen; prototypes link them into flows. The one structural piece left in this unit is how users MOVE between those screens: NAVIGATION: the menus, tabs, links and breadcrumbs that are the visible expression of the information architecture you built two lessons ago. Navigation systems close Unit 3, and then Unit 4 finally makes it all LOOK good: typography, colour and visual design.
Summary
Key takeaways
- A wireframe is a low-fidelity skeletal layout: structure and content placement, no visual detail (grey boxes, labels).
- A prototype is an interactive/clickable model that simulates the product to test flows with users.
- Fidelity is the level of detail: low-fi (rough, fast, cheap) vs high-fi (detailed, near-final).
- Prototypes can be paper (a human plays computer) or digital (tools like Figma).
- The ladder: sketch -> wireframe -> prototype -> high-fi mockup -> built product, rising in cost.
- Keep early work low-fi: it focuses feedback on structure, stays cheap to change, and invites honest critique.
- Memory hook: draw the blueprint before you build the building.