Prototyping Fundamentals

A prototype is a representation of an idea made in order to learn something. The key word is learn. A model built only to impress is a demonstration. A prototype is built to answer a question, such as whether people understand a navigation, whether a handle is comfortable or whether two parts fit together.

Researchers Stephanie Houde and Charles Hill proposed that a prototype can address three kinds of question: role, what the artefact does for the user in their life; look and feel, how it appears and is experienced; and implementation, how it works technically. A single prototype rarely answers all three, and trying to makes it slow and expensive.

Before building, write the question in one sentence. If you cannot, you are not ready to build. The question also tells you what to leave out. A prototype to test sequence does not need accurate colours, and one to test fit does not need a finished surface.

Prototypes also help the team. They make an idea concrete so that people stop arguing about different imagined versions. A rough object on a table is a shared reference that words alone cannot provide.

Fidelity describes how closely a prototype resembles the final thing in appearance, behaviour or material. Low fidelity prototypes such as paper sketches and cardboard models are quick and cheap. High fidelity prototypes such as interactive screens or machined parts are slow and expensive but closer to reality.

Match fidelity to the question and to the stage. Early on, the aim is to explore structure and concept, and low fidelity is ideal because people feel free to criticise and change it. Later, when details such as wording, finish or performance matter, higher fidelity is needed.

Higher fidelity has a cost beyond time. A polished prototype can anchor feedback on surface details such as colour or font, and signals that decisions are made. It also makes the team reluctant to change it because of the effort invested.

Fidelity is not one dimension. A prototype can have high fidelity in interaction and low in visual finish, or the reverse. Decide which dimensions the question needs and keep the others rough on purpose.

Fast methods keep the cost of learning low. Paper prototyping uses hand drawn screens or cut out parts that a person moves by hand to simulate interaction. Cardboard, foam core and tape make quick physical models of products and spaces. Wizard of Oz testing has a person behind the scenes simulating a system's responses.

Software based methods range from clickable image links to simple code. Linking static screens in a design tool gives a convincing sequence in an hour. Simple code, spreadsheets or no code tools can create working behaviour for tests that need real data or logic.

Choose the method by the question and the materials at hand. A service interaction might be prototyped by role play with printed props. A wearable might be prototyped with a sock and a lump of clay before any electronics. Resourcefulness matters more than equipment.

Set time limits. A prototype built in an hour forces focus on the question, while one allowed a week tends to grow in polish and scope. Stop when the prototype can answer the question.

A test needs a plan, however short. State what you want to learn, who will take part, what tasks they will attempt and how you will record results. A short script keeps sessions comparable and prevents the facilitator from drifting into explanations.

Choose participants who resemble real users. Five to eight people in a round commonly reveal the main problems, and repeated small rounds are more efficient than one large one. Include people with different abilities and experience where relevant.

Run the session so that the prototype is tested, not the person. Give tasks as scenarios, such as you need to book a table for Friday, and avoid instructions that name interface elements. Observe what happens and note hesitations and errors. Resist the urge to help.

Record in a consistent form: a simple table of task, outcome, observation and severity works. Review results with the team the same day while memory is fresh and agree on changes.

The point of testing is a better design. Findings should lead to decisions about what to change, what to keep and what to investigate further. Without that step, testing becomes a ritual.

Sort findings by severity and frequency. A problem that blocks the task and affects most participants is urgent. A cosmetic issue that one person mentioned can wait. Look for patterns rather than isolated remarks, and for the underlying cause rather than only the symptom.

Decide the next prototype. Sometimes the right step is to fix and retest. Sometimes the finding challenges the concept and calls for a different approach. Resist the urge to patch the existing prototype when the evidence says to start over.

Record decisions and their reasons. A short decision log noting what was learned and what was changed prevents the team from repeating old debates, and makes the story of the design clear to others.

Physical products, services, spaces and interfaces all follow the same basic loop of making something rough, putting it in front of people and learning. The materials differ, but the logic of cheap early tests carries across.

For products, foam, clay and 3D printing explore form, ergonomics and fit. For spaces, scale models and full size cardboard layouts let people walk through and feel proportion. For services, storyboards, role play and journey maps with simple props make intangible experiences testable. For interfaces, paper and linked screens test structure and flow.

Combining methods is common. A smart device might need a foam model for the form, a screen prototype for the interface and a role played service flow for onboarding. Treat these as parts of one learning plan.

Think about what each discipline can borrow. Interface designers can build physical props to test context of use. Product designers can use simple interactive mocks to test behaviour. Learning across disciplines widens the range of ways you can answer a question.