Prototyping in UX: Low to High Fidelity Explained

TL;DR: What You Will Learn

• Prototyping means building a testable model of your product before you commit to full development.
• Fidelity is how closely a prototype resembles the finished thing, from rough paper sketches to polished interactive mock-ups.
• Low fidelity fits early idea validation and flow testing; high fidelity fits usability testing, stakeholder buy-in, and developer handoff.
• Pick your fidelity level based on the question you need answered, not habit.

Why Prototype Before You Build

Every time I skip prototyping to save a week, I pay for it later with three weeks of rework. That is the hard lesson behind prototyping: it lets you find the flaws in a flow while they are still cheap to fix.

A prototype is not a finished product. It is a communication and de-risking tool, a rough draft of an experience you can test and argue over before a single developer writes production code.

The Cost of Fixing Problems Late Versus Early

Imagine a GovTech-style team building a new HDB service portal where residents apply for a flat renovation permit. If they discover only after public rollout that users cannot tell which documents to upload, the fix now means backend changes, retesting, and a confused public flooding the helpline.

Catch that same confusion in a clickable prototype during week two, and the fix is dragging a few boxes around in Figma.

The pattern is consistent across projects: the later a problem is found, the more layers of work sit on top of it. This isn’t just my own hard-won lesson. It’s a widely cited rule of thumb in usability research: reviewing the evidence on paper prototyping, Jakob Nielsen put the multiplier at roughly a hundred times, cheaper to fix a problem before any code exists than after the product has shipped (see Nielsen, “Paper Prototyping: Getting User Data Before You Code,” NN/g, 2003). Nielsen himself is careful to call this a rough estimate rather than a precise measurement, but it matches what I see on the ground. Changing a wireframe costs an afternoon; changing a live CPF-style transaction flow that thousands rely on costs meetings, code, and public trust.

Fixing a UX problem tends to get dramatically more expensive the closer you get to launch. Usability researchers have long put the multiplier in the range of tens to a hundred times between a paper sketch and a shipped product (NN/g, “Paper Prototyping: Getting User Data Before You Code”), even if the precise shape of that “curve” is more rule-of-thumb than hard science.

Prototypes as a Shared Language

The second reason I prototype is that words fail. When a client says “make it simple” and a developer says “that’s a two-week build”, they are usually picturing completely different things.

Todd Zaki Warfel, author of Prototyping: A Practitioner’s Guide, argues that prototypes do more than communicate a design; they can also help market a product, win internal buy-in, and test feasibility with a development team, which is exactly the alignment problem I keep running into. A prototype turns those abstract debates into something everyone can click through. Instead of arguing over a specification document, your stakeholders, developers, and the policy officer from a government agency can all react to the same screen.

This is also where understanding the difference between UI and UX matters, because a prototype lets you show how the flow behaves, not just how the buttons look. It becomes the single artefact that aligns a room full of people with different priorities.

Validating Assumptions With Real Users

The most dangerous phrase in any project meeting is “I think users will”. You are not your user, and neither is your director.

With a prototype, you can put that HDB permit flow in front of five actual residents and watch them get stuck. Watching a retiree hesitate at a jargon-heavy label tells you more than any internal opinion ever will.

That is the whole point of prototyping: you replace confident guesses with observed behaviour before you commit budget. You test the assumptions, kill the bad ideas early, and walk into development knowing the flow already works for the people who have to use it.

Understanding Prototype Fidelity as a Spectrum

When people hear the word prototyping, they often picture a polished, clickable screen that looks almost ready to ship. That instinct causes a lot of wasted effort, because higher fidelity is not automatically better.

Fidelity simply describes how closely your prototype resembles the final product. A napkin sketch is low fidelity. A pixel-perfect, interactive mockup that pulls in real product data is high fidelity.

Fidelity is Not One Dial, it is Several

Here is the part most beginners miss: fidelity is not a single slider. UX researcher Carolyn Snyder, whose book on paper prototyping is a standard reference in the field, developed this idea of fidelity as several independent dimensions, including look, interaction, and content, rather than one high-to-low scale. The version I use day-to-day looks like this:

• Visual detail: Rough boxes and greyscale versus real colours, fonts, and imagery.
• Content: Placeholder Lorem Ipsum versus actual product names, prices, and copy.
• Interactivity: A static image versus tappable buttons and screen transitions.
• Data realism: Dummy figures versus live or realistic sample data.

You might build something with high visual polish but zero interactivity, or a plain grey wireframe that is fully clickable. Matching the right mix to your question is the real skill.

A Tekka Market Vendor Going Online

Let me make this concrete. Imagine a spice and dried goods vendor at Tekka Market in Little India who wants to launch an e-commerce site to reach customers beyond Serangoon Road.

Early on, the only question is layout. Should the homepage lead with product categories, a promotion banner, or a simple search bar? A quick paper sketch answers that in ten minutes, and you can redraw it three times before your kopi goes cold.

At that stage, spending two days making it beautiful in Figma would be a mistake. You would be polishing a layout you might scrap.

Now fast forward. The vendor wants to apply for support or pitch to a family member who might invest in the business. Suddenly the audience changes.

Investors and non-technical stakeholders struggle to picture a business from grey boxes. Here you need a high-fidelity mockup with real product photos, actual Singapore dollar pricing, and a clickable checkout flow, because it sells the vision and earns buy-in.

A Simple Model for Choosing

So before you pick a fidelity level, ask three quick questions.

1. What is my goal? Testing a layout idea needs less fidelity than validating a purchase flow.
2. Who is the audience? Your design team reads wireframes fine; clients and investors need polish.
3. How much time do I have? Low fidelity buys speed and easy changes; high fidelity costs hours.

Think of low, mid, and high fidelity as points on a spectrum, not a ladder you must climb. You choose the point that answers the question in front of you, at the stage you are in.

Paper and Low-Fidelity Prototypes

When I want to test an idea fast, I reach for paper before I open any software. Paper and low-fidelity prototyping are the cheapest, quickest way to explore many ideas before you commit to a single direction.

Picture a polytechnic student design team briefed to redesign an NTUC-style service counter, the kind of self-help kiosk you see at a community club or a union member centre. Instead of jumping into Figma, they cover a table with A4 sheets and start sketching screens by hand.

Paper Sketches and Rapid Wireframing

The magic of paper is speed. In the time it takes to name a Figma layer, you can sketch three completely different counter flows and throw two of them away.

That disposability is the point. When a sketch costs thirty seconds, nobody clings to it, so the team argues about the flow rather than defending their pixels.

Once the strongest sketches emerge, I move to rough grayscale wireframes. I use grey boxes for images, horizontal text lines, and deliberately plain placeholder labels so the layout, not the styling, gets the attention. If you want to see how those same building blocks translate into a real tool later, the Figma design basics every beginner should master guide is where I usually point people.

What Low-fi is Good at, and its Limits

Low fidelity shines at answering big structural questions early:

• Does the overall flow make sense, from tapping the kiosk to collecting a queue ticket?
• Is the information architecture logical, or are important actions buried?
• Does the screen layout guide the eye to the primary action?

What it deliberately cannot tell you is anything about polish. Grayscale boxes and Lorem Ipsum text will not reveal whether your final colours work or whether a real font reads well on the kiosk screen.

That is a feature, not a flaw. Because the artefact looks unfinished, people feel free to say the flow is confusing without worrying they are insulting hours of careful visual work.

Running Quick Paper-based Tests

Testing on paper is refreshingly low-tech. I sit a real counter user in front of the sketches, name a task, and act as the “computer” by swapping sheets whenever they tap a button.

For the NTUC counter, I might ask a member to renew a benefit or check a claim, then watch where their finger hesitates. Every hesitation is a signal I can fix before anyone writes a line of code.

I keep a stack of blank paper beside me so I can redraw a screen mid-session and retest it in seconds. Invite honest feedback, iterate quickly, and only graduate to higher fidelity once the flow and structure genuinely hold up.

Moving to Interactive and Mid-Fidelity Prototypes

There comes a point in any project where static screens simply cannot answer your questions anymore. You can stare at a wireframe all day, but you will never know if someone can actually move through a task until they can tap and see the screen respond.

That is the leap prototyping makes when you go from paper or flat screens to something clickable.

From Static Screens to a Clickable Flow

Mid-fidelity is where structure starts to feel real. You keep the visuals plain, mostly greys, placeholder text, and simple shapes, but you add hotspots, linked frames, and basic transitions so a tester can move from one screen to the next.

Think of it as a rehearsal. The set is not painted yet, but the actors know where to walk.

Imagine you are designing a SimplyGo top-up flow. In a static wireframe, you can only point at where the top-up button sits, but in a mid-fidelity prototype your tester taps that button, chooses an amount, confirms payment, and lands on a success screen.

Suddenly you learn whether people expect a confirmation before payment, or whether they hesitate because the amount options are not clear. A flat drawing hides all of that.

Linking Frames in Figma

Most teams I work with build these flows in Figma because linking frames is quick and low commitment. You draw your screens, then drag a connection from a button to the next frame and pick a transition like instant, dissolve, or slide.

If you have never done this before, a step-by-step Figma tutorial for beginners walks you through creating frames and wiring up your first hotspots without touching a single line of code.

The same tool scales from a solo designer to a whole team, which is part of what Figma is used for in design teams on real projects. Other tools such as Adobe XD or ProtoPie do similar things, so pick whatever your team already uses.

What Interactivity Reveals

Here is the honest part. Interactivity exposes problems that a beautiful static screen will happily cover up.

When you prototype a food delivery flow and ask someone to order lunch from a hawker stall, the gaps appear fast:

• Dead ends, where a tester taps a button and nothing happens because you forgot to link the frame.
• Confusing back behaviour, where the back arrow drops them somewhere unexpected instead of the previous step.
• Unclear next steps, where the person pauses because they cannot tell what the primary action is.

Mid-fidelity prototypes are for testing flow, not polish. Resist the urge to add real colours and photos too early, because that pulls testers into commenting on looks instead of whether they could finish the task.

Keep it grey, keep it clickable, and let the navigation do the talking.

Building High-Fidelity Prototypes

A high-fidelity prototype is the closest you can get to the real product without writing code. When I hand one over, it looks, reads, and behaves so much like the finished thing that people forget it is a mock-up.

That realism comes from a few things working together: real visual design instead of grey boxes, actual copy rather than lorem ipsum, believable data, and micro-interactions that respond the way the live product would. A button does not just sit there; it hovers, presses, and transitions to the next screen.

Picture a team at a bank like DBS refining a PayNow transfer screen. For a final round of testing, they might mock up a realistic account balance display, a polished confirmation animation, and a clear error state for an unregistered mobile number. That is high-fidelity prototyping in practice: near-production quality so testers react as they would in real life.

When High-fi is Worth the Effort

High-fi is expensive to make, so I only reach for it when the payoff justifies the hours.

• Stakeholder sign-off: A polished screen wins approval faster than a wireframe when a senior manager needs to see the finished vision.
• Detailed usability testing: Subtle issues, like whether users trust a confirmation screen enough to tap send, only surface when the design looks trustworthy.
• Developer reference: Engineers can pull exact spacing, colours, and states straight from your file, which cuts back-and-forth during the build.

For that PayNow screen, the team would want testers focused on whether the flow feels safe, not distracted by placeholder text. Only high-fi gets you that.

Tools and Techniques

Figma is where I do most of my high-fi work. A few features do the heavy lifting.

Components let you build a button or input field once, then reuse it everywhere so a single change updates the whole file. Variables let you swap themes, text, or states without duplicating screens, which is a lifesaver when you are showing a filled versus empty balance.

Smart animate and prototype interactions handle the micro-interactions: a slide-in confirmation, a loading spinner, a field that shakes on error. If you want to move faster, the Figma AI features that speed up design work can help you generate content and variations without doing every step by hand.

The Risks of Polishing Too Soon

The biggest trap I see is over-investing before you have validated the idea. Spending a week perfecting a PayNow screen that fails the concept test is a week wasted.

The other trap is mistaking polish for correctness. A beautiful prototype can still be wrong, and glossy visuals often stop stakeholders from questioning the underlying flow.

So never jump straight to high-fidelity. Test the rough idea with a paper sketch or a clickable low-fi prototype first, then invest in polish only once you are confident the structure holds. High-fi is the final coat of paint, not the foundation.

Testing Prototypes With Real Users

A prototype only earns its keep when you put it in front of someone who is not you. I have watched teams fall in love with a design, then watch a first-time user hesitate on the very screen everyone assumed was obvious.

That gap between what we intended and what people actually do is the whole point of prototyping. Testing turns a mockup into a learning tool.

Matching Test Method To Fidelity

Match the method to what your prototype can actually do. A paper walkthrough works when you want to check flow and information order, where you shuffle sketched screens by hand as the user makes choices.

A clickable Figma prototype supports a moderated test where people tap real elements, so you can catch confusing labels, dead ends, and unclear buttons. Do not run a high-effort usability lab on a rough sketch, and do not rely on paper when you need to test micro-interactions or copy.

Low-fidelity prototypes still yield valid insights. Users will tell you a whole task makes no sense long before you have coded a single button.

Writing Task-Based Scenarios

The words you use shape the results. Give people a realistic goal, not a click instruction.

Say, “You have just moved house and need to update your address for a government service. Show me how you would do that.” Never say “Click the blue Update Address button at the top right”, because that answers the very question you are testing.

Avoid leading questions during the session too. Instead of “Was that easy?”, ask “What were you expecting to happen there?” and then stay quiet and let them work.

Imagine recruiting five representative users to test a new government service prototype, sitting at a local hawker centre or community club so you reach people who are not tech insiders. Five is not an arbitrary number: it comes from the Nielsen Norman Group’s widely cited rule of thumb that testing with five users tends to surface around 85% of a design’s usability problems (Nielsen, “Why You Only Need to Test with 5 Users,” NN/g), a heuristic, not a guarantee, since the real number shifts with how consistent your users and tasks are. Steve Krug, author of Don’t Make Me Think, makes a similar practical case that three or four participants per round is usually enough, since each additional tester tends to repeat what earlier ones already showed you. That mix of ages and comfort levels surfaces problems a room of designers never would.

Handle any participant data in a PDPA-compliant way. Get clear consent before recording, explain how you will use the notes, collect only what you need, and store or delete recordings responsibly.

Capturing And Prioritising Findings

Capture observations as you go, ideally with a second person taking notes so the moderator can focus on the user. Write down what people did, not just what they said, because behaviour is more honest than opinion.

Afterwards, cluster the findings and prioritise by severity and frequency. Fix the issue that blocked three of five users first, then the smaller annoyances.

Then change the prototype and test again. Testing early and often beats one big test at the end, because each small round is cheap to act on and you avoid discovering a fatal flaw after everything is built.

This iterative habit is also something interviewers probe for, so it helps to review the UX designer interview questions hiring managers ask and be ready to describe a real test-and-iterate loop you have run.

Handing Off Prototypes to Developers

Once your high-fidelity prototyping work has been validated with real users, it stops being a design artefact and becomes the blueprint for the build. This is the moment when a beautiful prototype either saves your team weeks or quietly causes months of rework.

I have seen too many projects where the design looked polished in Figma but fell apart the moment a developer asked, “What happens when this list is empty?” Handoff is about answering those questions before they cost you.

What Developers Actually Need

A developer cannot read your mind, so your prototype has to carry the intent for you. That means going far beyond the happy path screens you demoed to stakeholders.

At minimum, a solid handoff should document these things:

• Precise specs and spacing, so padding and margins are not guessed
• Every component state: default, hover, focus, disabled, loading, and error
• Interaction notes describing transitions, timing, and what triggers what
• Design tokens for colour, typography and spacing so values stay consistent
• Edge cases and empty states, like a search with zero results
• Content rules for long text, truncation and localisation

Using Figma to Make The Handoff Clear

Figma gives you the tools to turn this into a shared reference rather than a folder of screenshots. A well-prepared Figma file becomes the single source of truth for both designers and developers.

Turn on Dev Mode and let developers inspect measurements, copy CSS values, and pull spacing directly from the layers. Use redlines and annotations to explain the tricky parts, and add sticky notes for edge cases like what the dashboard shows a brand new user with no data yet.

If you are building a component library, starting from one of the best Figma templates to kickstart your designs can save you from redrawing states you will need for handoff later.

Why this Matters for a Singapore SME

Picture a local retail SME funding a new e-commerce site through the Enterprise Singapore Productivity Solutions Grant (PSG). The build is outsourced to an external vendor who bills by the hour.

Every unclear screen becomes an email thread, and every email thread becomes a change request. Without a documented prototype, the vendor guesses, gets it wrong, and the SME pays for the correction.

I always tell teams in this position to treat the prototype as the contract. When the checkout error state, the out-of-stock message, and the mobile spacing are all annotated in Figma, the vendor has nothing to guess.

Keep updating that one file as decisions change, so nobody ships an outdated version. Align designers and developers around it early, and almost nothing gets lost in translation.

Choosing the Right Fidelity for Your Project

After years of running prototyping sessions, I have learned that the biggest mistake is not choosing badly; it is not choosing deliberately at all. Fidelity is a lever you pull to answer a specific question, not a badge of how serious your project is.

So before you open Figma or reach for a marker, ask yourself one thing: what am I actually trying to learn right now?

A Question-driven Decision Framework

The fastest way to pick fidelity is to match it to the question you are asking, not to how far along you feel.

• Low fidelity for early exploration: use it when you are still deciding what to build, sketching flows, or comparing two layouts on paper or a whiteboard.
• Mid fidelity for flow validation: use it when the concept is settled, and you need to check that people can move through the journey without getting lost.
• High fidelity for sign-off and usability testing: use it when you need stakeholder buy-in, realistic user reactions, or a spec developers can build from.

Layer in your constraints. A tight budget and a two-week timeline push you towards lower fidelity for longer. A conservative audience, say senior management at a bank, may need a polished mockup before they can react at all.

A Lean Singapore Startup Scenario

Picture a two-person startup building an MVP and preparing a pitch for an SGInnovate-style investor session. Money is tight, and the deadline is in three weeks.

They do not have the runway to make every screen pixel perfect, and they should not try. Instead, they decide fidelity screen by screen based on what the pitch needs to prove.

The hero flow, the one moment that shows the product’s core value, gets high fidelity with real branding and micro-interactions, because investors will judge the vision on it. The settings page, the account screen, and the empty states stay low fidelity or even greyboxed, because nobody is deciding to fund based on a password reset flow.

That mix tells a coherent story without burning weeks polishing screens no one will scrutinise.

Two Mistakes to Avoid

The most common trap I see is polishing too early. Once a prototype looks finished, people critique colours and fonts instead of the flow, and you lose the honest feedback that low fidelity invites.

The opposite mistake is skipping low fidelity entirely and jumping straight to high fidelity, which locks in decisions before you have pressure-tested them.

Treat fidelity as a deliberate, question-driven choice, and you spend your limited hours where they change the outcome.

Conclusion

Remember the opening pain: a team ships a feature, then discovers users cannot find the button or misunderstand the flow, and now the fix costs weeks of engineering time instead of five minutes with a pencil.

That is exactly what prototyping prevents. It de-risks your product by surfacing problems while they are still cheap to fix, long before a single line of production code gets written.

The key mindset shift I want you to leave with is this: fidelity is a spectrum you choose deliberately, not a ladder you must climb. You do not always start at paper and grind your way up to a pixel-perfect Figma file.

Instead, you pick the fidelity that answers the question in front of you. Testing whether a checkout flow makes sense? A rough paper sketch is enough. Validating micro-interactions or handing off to developers? Now higher fidelity earns its keep.

Starting low and raising fidelity only as your questions demand is what saves you both time and money.

So here is my challenge for you today: grab a sheet of paper and sketch your next idea right now. Do not wait for the perfect tool. The habit of thinking through interfaces on paper is worth more than any software.

If you want to build these skills properly, with hands-on practice and structured feedback, I would encourage you to enrol in the WSQ User Experience & User Interface (UX/UI) Design Essentials course.

It is SkillsFuture-supported and designed to take you from sketching to testable prototypes, which is the natural next step once you have caught the prototyping bug.