Prototyping for Different Audiences

1 minute read


The power of prototyping cannot be underestimated. I prototype using paper, Invision/Sketch and sometimes using code - it all depends on the audience and the problem at hand. Below you'll find a little more insight into my prototyping methods.

Draft version of a recent high fidelity design

What I did


1. Align business requirements with user needs

Product owners presented me with specific product needs which I'd then question in order to get to grips with the "why" factor. This is the most powerful question type you can ask a stakeholder about a given scenario. Ask a user "why" they do something rather than "how" or "what" they do and you'll get closer to the user's needs and jobs they need to get done. It cuts to the chase as to what really matters to them. More often than not, their needs align with those of the business.

process image

A typical whiteboard where I'd work out a specific interaction flow for a user type while ensuring business requirements are met.

2. Choose an appropriate prototyping method

A lot of my work is based around prototyping to various stakeholders. The level of fidelity usually depends on the type of people that I'm sharing it with and/or the relationship I have with the individual/s who interact with it. When sharing internally, I love to paper prototype but have also done this with users just after a testing session. Being part of a small team, I needed to maximise the impact of carrying out user testing.

Below you'll find an example of a paper prototype which evolved into something more high fidelity over time.

An example of a prototype evolving over time (from whiteboarding interaction flows, to paper to high fidelity). Details were added after various stages of feedback.

3. Adjust and enhance its level of fidelity

As user satisfaction increases, so too should the level of detail contained in the prototype.

It is very important to acknowledge how different user types may perceive your designs. It's not just a case of "some will like and some will not." Different user types will have different goals when engaging with your system. The structure of content and layout may look perfect to one user and be completely irrelevant to another. It's critical for a team to acknowledge this before proceeding on a "one size fits all" - great it it does, but assumptions should be avoided where possible.


What I learned