Topic 6 — Wireframing and prototyping

Goal: Turn ideas into testable designs, from rough sketch to clickable prototype.

Lesson 6.1 — Why nobody starts with the pretty version

Tessa's first week at Wanderwell, the team got handed a problem: travelers were abandoning the trip-booking flow right at the payment step. Tessa, eight years of styling retail floors behind her and three months of UX training ahead, did what felt natural. She opened a fresh file and started picking colors, choosing a font, nudging a button until the corners felt right. Two days later she showed Marcus, her mentor and the lead product designer, a screen that looked polished and inviting.

He studied it for a moment. "It's lovely," he said. "But I have no idea if the flow works, and now neither of us wants to throw it away."

That last part stuck with her. She'd spent two days making something she was now attached to, before she'd answered a single real question about whether the design was right.

What Marcus was teaching her has a name: fidelity — how finished a design looks. Designers raise fidelity gradually, on purpose, because rough ideas are cheap to change and polished ones are expensive. The more craft you pour into a screen, the harder it gets to scrap it and try again. So you spend that craft last, once you actually know what you're building.

The shinier the design, the more it costs to be wrong. Stay rough until you're sure.

Lesson 6.2 — The ladder: sketch, wireframe, mockup, prototype

So if you don't start with the pretty version, what does the climb look like? Tessa learned it as four rungs, lowest fidelity to highest.

Sketches come first — quick drawings on paper or a whiteboard. No tool, no grid, no undo button to slow you down. This is the diverge step from the design process (Topic 3): you draw eight rough versions of the payment screen in ten minutes precisely because each one is almost free. Tessa was fast here — years of sketching store layouts on the back of receipts meant she could throw ideas onto paper while the engineers were still finding a pen.

Wireframes come next — clean but deliberately plain layouts, usually grey boxes and placeholder text. They show structure and content: what goes where, in what order, with no color, no real photos, no final fonts. A wireframe of the payment screen tells you the price summary sits above the card field and the "Pay now" button anchors the bottom. It tells you nothing about what blue the button is, and that's the point.

Mockups come after that — high-fidelity designs with the real colors, real fonts, real images. This is what the finished product will actually look like. Wanderwell's warm coral buttons and rounded photo cards live at this rung. (The visual craft that goes into mockups is its own Topic 8.)

Prototypes sit at the top — any of the above made clickable, so a person can move through the design as if it were real. We'll get to those shortly.

Rung	What it is	What it answers
Sketch	Rough paper/whiteboard drawing	"What are all the ways this could go?"
Wireframe	Plain grey-box layout	"Is the right stuff here, in a sensible order?"
Mockup	Full color, fonts, images	"Does it look and feel right?"
Prototype	Any of the above, clickable	"Can a real person get through it?"

The ladder isn't a rule you follow because a teacher said so. Each rung answers a different question, and climbing in order means you never polish a layout that was broken from the start.

Lesson 6.3 — Match the fidelity to the question

Here's the lesson that saved Tessa the most grief, and it took a meeting going sideways to teach it.

She brought a fully colored mockup of the new search screen to a review with Priya, the product manager, and Dev, the engineer who'd build it. Tessa wanted to know if the search filters made sense. Instead, the room spent twenty minutes on the color of the date picker. Nobody mentioned the filters at all.

The next week she brought the same screen as a grey wireframe. Same room, same people. This time Dev caught that the "sort by price" control was buried below the fold, and Priya realized the filter for trip length was missing entirely. The conversation landed exactly where she'd wanted it.

That contrast is the whole principle: match the fidelity to the question you're asking. Show someone a polished mockup and they fixate on the surface — "I don't like the blue." Show them a plain wireframe and they comment on the structure, because there's nothing else to react to. Low fidelity is a tool that aims people's attention at the thing you actually need feedback on.

Marcus put it to her like this: a wireframe doesn't look unfinished by accident. The greyness is a feature. It's how you protect the conversation from getting hijacked by details that don't matter yet.

Lesson 6.4 — The wireframe is the workhorse

If you remember one rung from this topic, make it this one.

The wireframe is the workhorse of UX. By stripping out color and style, it forces the designer, the PM, and the engineer to argue about the only things that matter early: Is the right information on this screen? Is it in a sensible order? Is the main action obvious? You can't hide a confusing layout behind a beautiful gradient when there is no gradient.

This is also where the work from earlier topics turns concrete. Remember the user flow from Topic 5 — the map of screens a traveler moves through to book a trip? Each box in that flow becomes a wireframe. The flow says "search, then results, then trip detail, then payment"; the wireframes say what each of those four screens actually contains.

And because a wireframe is fast and cheap — grey boxes, a few labels, twenty minutes of work — Tessa can build three versions of the results screen and throw two away without a flicker of regret. That's the quiet superpower: when a layout costs almost nothing, killing the weak ones doesn't hurt. She tried the trip results as a list, a grid, and a map-first view, decided the grid won, and deleted the other two before lunch. Getting the structure right at this stage, before any visual polish, is what prevents painful rework once real engineering time is on the line.

Lesson 6.5 — Making it clickable, no code required

A wireframe or mockup is still a static picture. A prototype is what you get when you connect those screens so a person can actually click through them — tap "Search," land on the results; tap a trip, land on its detail page. It behaves like the real product, even though not a line of real code exists behind it.

The part that surprised Tessa, coming from a non-technical background and braced for something hard: you build this without writing any code. In Figma (the tool that gets its own treatment in Topic 9), you switch to the Prototype tab, then drag a connection from a button on one screen to the frame you want it to open. Drag, drop, link — that's the whole motion. String enough of those links together and a flat set of screens becomes something a person can tap through. When it's ready, you click Share, copy the link, and send it — and the person opening it doesn't even need a Figma account to try it. (Prototyping is included on Figma's free plan, so the cost of learning this is zero.)

Why go to the trouble? Because a prototype lets you test the experience before anyone builds it. Tessa can hand a traveler her phone, say "book a trip to Lisbon for next month," and simply watch. Where do they pause? What do they tap that does nothing? Where do they sigh? Every hesitation is a flaw she's catching now, in a clickable mock, instead of three weeks after Dev has built it for real. That watching-someone-struggle step has a name and a topic of its own: usability testing, Topic 7. The prototype is the thing you put in front of them.

Worked example — The Lisbon checkout, four rungs in five days

Back to the problem Tessa started with: travelers bailing at the payment step. Watch the same screen climb the ladder.

Monday — sketches. Tessa fills a sheet with six rough versions of the payment screen: one shows the price first, one puts the card field up top, one splits it across two steps. Marcus circles two he likes. Total cost: a marker and twenty minutes.

Tuesday — wireframes. She turns the two survivors into grey-box wireframes and brings them to Priya and Dev. Because there's no color to argue about, Dev immediately spots the real problem: the original screen never showed the total until after you'd entered your card. People were bailing because they didn't trust a price they couldn't see. The fix is structural — move the total to the top — and it costs nothing to make.

Wednesday — prototype the wireframe. Tessa links the wireframe screens in Figma's Prototype tab and shares the link with Hannah, the UX researcher, who runs it past two travelers. Both relax once the total appears up front. The structure works.

Thursday — mockup. Now Tessa adds Wanderwell's coral, the rounded cards, and the real Lisbon photos. The pretty version comes last, built on a layout she already knows is sound.

Friday — clickable mockup. She prototypes the polished screens and hands them to Hannah for proper usability testing next week.

The flaw that was sinking the whole flow — a hidden total — got caught on Tuesday, in a grey box that cost nothing. Had Tessa started the way she did in week one, picking fonts first, that same flaw might have surfaced only after Dev had spent three weeks building the wrong layout. That five-day climb is the entire skill this topic exists to give you.