Prototypes & User Experience

You’ve got prioritised features and clear stories. Now comes a tempting mistake: building the real thing straight away. Before you spend weeks of engineering time, there is a far cheaper way to find out whether your idea actually works for people — the prototype. And the thing you’re testing with it is the user experience: not just how the product looks, but how it feels to use. This lesson is about both, and why the two together save enormous amounts of wasted effort.

The core idea is simple. It is much cheaper to fix a bad idea on paper than in code. A prototype lets you put something in front of real people early, while changing it still costs almost nothing.

A cheap fake before the expensive real thing

A prototype is a rough, fake version of a product made to test an idea, not to ship it. It can be as simple as sketches on paper or clickable screens that look real but do nothing underneath. The finished product comes later — fully built, reliable, and used for real. The whole point of a prototype is to learn before you commit.

What a prototype is — and why rough is the point

People new to prototypes often try to make them too good. They polish the visuals, wire up real data, and suddenly they’ve spent two weeks building something that was meant to take two hours. The roughness is a feature, not a flaw. A sketchy prototype invites honest feedback — people happily criticise something that obviously isn’t finished. Show them something polished and they assume it’s decided, so they hold back the very feedback you need.

Prototypes also come in levels of fidelity. A low-fidelity prototype might be hand-drawn boxes showing the order of screens. A high-fidelity one looks almost real but still has nothing working behind it. Both are fakes on purpose. The question a prototype answers is never “is this finished?” but “are we even heading in the right direction?”

User experience is how it feels, not just how it looks

User experience (UX) is the whole experience of using a product: how easy it is to understand, how quickly someone can do what they came to do, how it makes them feel along the way. Looks are part of it, but only part. A beautiful screen that confuses people is bad UX. A plain screen that lets someone finish in five seconds is good UX.

Consider a parcel-tracking page. Good UX is landing on it and instantly seeing “Out for delivery, arriving by 6pm” in big, clear text. Bad UX is a gorgeous animated map that makes you hunt for the one fact you actually wanted. Same information, very different experience — because UX is measured by how well the product serves the person’s real goal, not by how impressive it looks in a screenshot.

If a user needs the manual to do the obvious thing, the experience is broken — no matter how good it looks.

Testing UX with a prototype

This is where the two ideas meet. You use a prototype to test the user experience before building anything real. Put a clickable fake in front of five people, give them a task — “find out when your parcel arrives” — and watch where they hesitate, tap the wrong thing, or give up. Every confusion you catch on a prototype is a confusion you don’t ship to thousands of real customers. Watching a single person stumble teaches you more than a dozen meetings arguing about what users “probably” want.

Spot it: good UX or bad UX

Read each scenario and decide — good user experience or bad? Tap a card to check.

Sort the insights

Drag each testing insight into the category it belongs: something to fix now or something that looks nice but doesn’t matter.

How to use it

When someone proposes building a feature, ask the cheap question first: “Can we fake this and test it before we build it?” Reach for a prototype — even paper sketches — and put it in front of a few real people instead of debating in a room. As you watch them, judge the user experience by what they actually do, not by what the screen looks like. If three out of five people can’t find the delivery time, the problem is real, and you found it for the price of an afternoon rather than a release. And when a teammate insists the design is “obviously clear,” the kindest, most persuasive reply is, “Let’s hand it to one real person and watch.” A few minutes of watching settles arguments that hours of opinion never will.