What is a prototype?

What does prototype mean?

In UX design, a prototype is a test version of a screen or flow that is finished enough to show to users.

Kara Pernice of NN/g describes the prototype as a hypothesis. I like this definition because it names the prototype’s real job: testing an assumption.

A wireframe shows the skeleton of a screen. The prototype sets that skeleton in motion. It also shows what happens when you press a button.

The difference between low and high fidelity

Fidelity is how closely the prototype resembles the finished product. Pernice looks at it on three axes. The first is interactivity, the second visual design, the third content and navigation hierarchy. A prototype can have high fidelity on one axis and low on another.

Axis	Low fidelity	High fidelity
Interactivity	Not clickable. A person changes the screens by hand.	Links and menus work, and the response comes right away.
Visual	A rough sketch or wireframe.	Layout, spacing and hierarchy close to the live product.
Content	Summary text or placeholders.	The full content of the finished design.

The article calls the person who changes the screens in low-fidelity tests the “computer”. With a paper prototype, they sit next to the test table, out of the user’s sight. With the Wizard of Oz method, they control the screen from another room.

When to use which?

If the idea isn’t clear yet, start with low fidelity. Preparation is short, and you can even change it during the session. According to Pernice, users criticise a rough design more freely.

Once the flow is settled, move to high fidelity. Here the system responds quickly and realistically, and users believe they are using real software. You can test the workflow and the UI components together.

The price of high fidelity is time. According to Pernice, the more work goes into a design, the harder it is to let go of it if it doesn’t work.

Four things decide the choice: the goal of the test, how finished the design is, the tools available and the resources.

Pernice considers the Wizard of Oz method especially useful for AI-based systems. A person behind the scenes gives the system’s answers.

Example: a three-screen bill payment prototype

The small prototype below imitates paying a water bill in a city utility’s app. It doesn’t actually pay anything. Use the buttons, or Tab and Enter, to get to the next screen.

Try it

1. Screen 1 / 3

   Water bill

   Account number: 1234567
   Due: November 15.

   View bill

2. Screen 2 / 3

   Confirm payment

   Amount: $41.25
   Card: saved card.

   Pay

3. Screen 3 / 3

   Payment received

   The receipt has been sent to your email address.

   Start over

A clickable prototype with three screens: bill, confirmation, receipt. If JavaScript is off, the three screens are shown one below the other.

This example has high fidelity in interactivity and medium fidelity visually. The question I want to test is simple: does the user see the amount before pressing “Pay”? That needs neither colour nor a logo.

The most common prototype mistake in my audits: polishing every screen before the test. The team busies itself with colours and icons, and the real question never gets tested. Write down the question first, and choose the fidelity after.

Why it matters

According to Pernice, testing the finished product is risky. Ripping out code is very expensive; throwing away a prototype is cheap.

The prototype is the material for usability tests and is rebuilt in every round of user-centred design. Don’t confuse the prototype with the MVP. The MVP is the working product that goes to real users; the prototype is a draft for testing.

If you want to get from prototype to live product in two weeks, there is the Design & Ship Sprint.