By Aaron Heskes

Prototyping isn’t only done in the final stages of development of a product. In fact, prototyping becomes relevant very early on as a way of testing conclusions which in turn shapes the direction of conceptual development.

A prototype replicates a use case scenario. By allowing users to interact with an experimental situation, it allows designers to evaluate how those changes affect task completion.

Everything we’ve talked about so far gives us the background knowledge to start posing meaningful questions. By creating personas, we can develop empathy for the users of the product. Personas neatly assemble information about the users which may have an external effect on how they use the product or service. The key to discovering the reasons why people don’t interact effectively with a product lies in developing that sense of empathy for individual restrictions and needs. If you attended the gown workshop, you’ll understand that although all gowns serve that same purpose, every model had constraints that required the function of each gown to serve their personal physicality.

The degree to which a prototype can replicate the change in how a product can be used however goes well beyond physical constraints. Another aspect to consider is how one’s background affects their understanding of what a gown is, how it should be put on and where they feel comfortable wearing that garment.

System mapping graphically can allow us to picture the logistics of how a product interacts with a group of users. It answers the question, “what does everyone have to do (individually) to accomplish the greater goal?”, and for that matter “How do each individual’s goals relate to the greater goal?”.

Using what we know about a system/service/product, we can begin to ideate. The best place to begin ideating is at an area of friction and discomfort. Consider the points of contact between people. Think about what information must be exchanged in those interactions. What is each user expected to know, and what might be unfamiliar to a first-time user?

What is the purpose of each step the user is expected to go through? If certain existing aspects seem awkward, think about why more direct methods haven’t been put in place already.

How you replicate change to test for results varies by the nature of the entity you’re changing. For example, a team working on a software based application might hand draw the layout of a new interface and ask someone to complete a task by treating the paper like the surface of a tablet. As the subject interacts with the paper interface, the operators go through the pages accordingly to replicate the experience of navigating the app.

This method of testing is popular as a quick, low fidelity solution. It’s called the “Wizard of Oz Method” because the operators manually respond to the user’s input, giving the illusion that it’s a working product.


Low fidelity mockups are great because they can answer questions early on concerning what might be a good or bad change. They are also easy to change because they take such little time to produce. Although nicer mockups present a more realistic vision to the test user, team members might become attached to weak ideas early on if they spend too much time developing that idea before having any feedback that proves the validity of the change. There’s always time for nice mockups later.

At this point, it doesn’t matter how pretty your prototype looks. Think about what the problem is that you’re solving for. How do you expect the changes you make to affect the use case, and how are you replicating that change and testing for results?