The prototype gamut

If you’ve been following along this week, you’ll know that we’ve already discussed the dangers of the proof of concept and an alternative approach to reducing technical risk using tracer bullet development to build a walking skeleton.

However, none of these approaches are at all useful for another key risk of any project: that our products can be used by users, help them achieve their goals, and make them better versions of themselves (to paraphrase the Jobs To Be Done credo).

I was a user researcher in the early days of my software career, and I have an educational background in psychology. As any psychology student knows, learning about sound experimental methodology in cognitive and social sciences is a foundational part of that education.

So it bothers me when software teams build prototypes before developing a clear design for the experiment that they are carrying out.

I’m not suggesting that all user research studies should be designed to include control groups, double-blind participant allocation, etc. This is not a clinical trial. Most user research studies involving prototypes will be observational, eliciting qualitative data.

But it is important that prototypes are created to satisfy the needs of examining a small set of specific hypotheses. We want to do that as cheaply and quickly as possible, so that we can get high-quality feedback to rapidly inform iterations in design and product direction.

This is why there are many forms of prototype for digital products, and so many tools, SaaS products, plug-ins and component libraries. They all aim for a different balance of the fidelity / speed / cost trade-off.

On one end of the spectrum, hand-sketched paper prototypes can be drawn up in minutes, and focus the attention of research participants on interactions and data structures rather than aesthetic concerns.

On the other hand, high-fidelity prototypes can be useful for testing highly dynamic interfaces that are otherwise impossible to address in lower fidelity prototypes. More recently, open source component libraries are great for this. Bigger companies are also using their own in-house design systems and component libraries to speed prototyping.

The key here is to choose the cheapest and quickest form of prototype that will reliably and validly test our hypotheses. The Nielsen Norman Group site has a great round up of the trade-offs in involved in using different UX prototypes, which includes some questions we can ask ourselves to make an appropriate choice.

Much of this work falls within the remit of the UX researcher and design, of course. But having worked as researcher, interaction designer and developer at different points in my career, I’m a big believer in lots of collaboration at this stage.

We might not have a dedicated researcher on our team, either. If we don’t, we can still make the case for doing user research. It doesn’t need to be expensive or time consuming. Do it well and it will pay for itself many times over. Much of the challenge and cost in user research is getting access to users, not building prototypes.

We spoke about the danger of a runaway proof of concept two days ago. The same thing can happen with research prototypes too, if we make them too high-fidelity, and entertain the idea that building the rest of the product involves simply ‘plugging it in to the back-end’.

So, it’s important that we are clear about the goals of the research up front, and clear about what will happen to any research materials afterwards. It’s fine to re-use prototype work across different studies, but it should be known to all that they were designed purely for the purposes of research and are not 60% of a production application.

Of course, in collaborating with designers and researchers on prototypes, we can learn a lot about how the production system might be built, but we should assume that none of the actual code or assets can be ported over.

All the best,

– Jim