Sketch, test, repeat: a practical guide to lo-fi prototyping

Every product team eventually hits the same question: how do we know this idea actually works before we sink weeks into the polished version? The answer usually sits in a stack of paper sketches, sticky notes, or a rough Figma file, the humble low-fidelity prototype that lets real humans poke at an idea before it becomes sacred. In fast-moving studios in Sydney and Melbourne, where product squads juggle tight deadlines and AEDT collaboration calls, lo-fi testing has become the cheapest insurance a designer can buy.

This guide walks through the whole arc: choosing the right medium, drafting the bare flow, sketching screens, running the session, and reading what testers actually showed you. The aim is not pixel-perfect craft but clarity of intent, the kind that makes a Thursday-morning usability session in Brisbane or Adelaide worth the coffee budget.

Why bother with rough prototypes at all

Lo-fi prototypes compress a design problem into something a person can react to in five minutes. They invite mistakes. A tester in Parramatta will happily tear up a pencil sketch in a way they would never do to a sleekly rendered mockup, and that freedom is exactly what you want when you are still hunting for the right shape of an idea. The polish that arrives later often becomes a costume people hesitate to question.

The trade-off is also generous. A session with five or six participants, run over a long lunch in a coworking space on Bourke Street or during a quieter afternoon in Perth, usually surfaces ninety percent of the structural problems a product has. You can spend two hours of synthesis on the back of a tram and arrive at office the next morning with a sharper list of changes than a sprint of internal debate produces. Lo-fi is not a shortcut; it is a structured way to be wrong quickly and cheaply, which suits the pace of Australian studios juggling multiple clients.

Picking the right medium for your fidelity

Fidelity is a spectrum, not a switch. A napkin sketch is lo-fi. A clickable wireframe in Figma or Sketch is medium-fi. A coded prototype anchored to your real design system is high-fi. Each step costs more to build and harder to throw away, so choosing where to land on that spectrum is the first real decision your team makes.

A useful heuristic is to match fidelity to the question. If you are testing whether users understand a flow, paper sketches or even storyboards will do the job. If you need to validate information hierarchy on a dense screen, a medium-fi wireframe with realistic copy is fairer to testers. For something like an ambient display intended for a public space, the brief behind the socially responsive light display shows how even a light-driven concept benefits from a cheap mockup taped to a wall first.

Mapping the core flow before any drawing

Before a single screen exists, the path the user takes deserves its own rough draft. A flow map is just boxes, arrows, and a few decision points, drawn on the back of a printout or in a free tool like Whimsical. The goal is to flag dead ends, missing screens, and moments where the user has to guess what happens next. In Australian product culture, where many teams operate across AEST and AEDT and squeeze planning into a shared Notion page, this kind of shared flow document cuts down on the late-night Slack ping when someone in Darwin realises the checkout has no error state.

Walk the map as if you were the user, including the boring bits. Where do you land first? What nudges you forward? Where do you abandon? If you can sketch those moments on a single A4 page, you have a story worth testing. If you cannot, the gap is your first prototype.

Sketching screens that invite honest reactions

When the screens finally get drawn, keep them scrappy. Boxes for images, lines for text, circles for buttons. The rougher it looks, the easier it is for testers to focus on flow and intent rather than colour choices or icon polish. Melbourne-based UX practitioners often joke that a clean wireframe with the right word in the wrong place is more useful than a beautiful screen missing a word altogether.

Number screens so the order is obvious, even when you scatter them across a table. Use real content where it matters, even if it is rough. A fake headline about a Sydney ferry timetable will tell you more than a placeholder of lorem ipsum, because testers will read it and form opinions. Watch which screens get picked up and turned over, which ones get a squint, and which one gets pointed at as "this is where I got stuck." Those physical reactions are the data you came for, and they only surface when the drawing is loose enough to be questioned.

Running the session without leading the witness

The hardest part of usability testing is shutting up. Hand over the prototype, say "show me how you would book this", and then stay quiet. Resist the urge to apologise for missing buttons or unfinished labels. Those rough edges are features of the prototype, not flaws to apologise for, and a tester in Adelaide or Cairns will react to them just as a real customer would.

Take notes verbatim. If a tester says "I would expect this button to do something", write that down rather than translating it into design jargon. Capture the sequence step so you can pair the comment back to a flow later. If you are running multiple sessions, leave a small gap between them to compare patterns and flag anything you should probe in the next round. Even a handful of sessions, run carefully, will reveal whether the flow holds up or quietly falls apart.

Reading the signals and deciding what changes

Synthesis is where prototype testing earns its keep. Cluster the notes by screen, by task, or by friction. Look for repeated phrases, repeated hesitations, repeated smiles. A single confused tester is a hint; three testers stumbling in the same place is a fix that cannot wait. The real-time Twitter sentiment visualization shows how even data-driven interfaces benefit from this layered review: design choices are filtered through user reactions before a single line of code is committed.

The next round of changes is rarely "redraw the whole thing". It is usually two or three small fixes: clarify a label, swap the order of two steps, add one more screen. Lo-fi prototypes make those small changes fast, which is the whole point. The expensive redesign only arrives once the rough sketch has earned its shape.

If you are exploring ideas for projects of your own, the scholarship recipient's work featured on the journal offers a candid view of how emerging designers turn early prototypes into finished pieces worth showing off. Browse a couple of projects, sketch one of their core flows in twenty minutes, and see what the exercise reveals. Pick a paper notebook, draw your first flow, and book your first test session this week.