Proof of Concepts and Prototypes in Product Design

Oliver Bailey

By Oliver Bailey

Client Partner

The lines are often blurred between PoCs and prototypes; with organisations looking to jump straight into prototyping or using a prototype for PoC purposes. Either way, it’s important to understand the values of them both as separate tools so that when rolling products out quickly their effectiveness isn’t lost.

There is a number of reasons why we invest in Proof of Concepts;

  1. To test feasibility; the idea may require a new technology approach or a change of business process - we need to test that the technology is capable or that the process is able to change. The PoC may be less visual - it’s more about a test and learn approach; did we achieve the outcome we hoped for?
  2. Depending on the format of the PoC, it’s likely we’ll develop a better understanding of the risks; for example if the PoC is testing an API - the risk may be that it’s slow, or a business process could easily become overloaded and hinder the customer experience.
    It also enables us to consider the approach and therefore cost implications in more detail; the effort, dependencies and partners required to bring an MVP to market.
  3. To demonstrate the idea; it could take any format, but often the PoC is a slide deck or an explainer video; the format allows demonstration of the concept in an easily digestible manner to get buy-in. It’s also a great tool for getting team alignment across the org.

In a nutshell, the PoC is usually one of the first tasks we undertake as part of the design process; it allows us to answer any unknowns, understand any potential blockers and get buy-in before investing in any further design or testing.

So what is a prototype?

The prototype is an early version of the potential product and therefore requires more investment to get to than a PoC. There are a number of reasons we build prototypes;

  1. To test usability early on in the design phase; clickable wireframes or visual designs of key components and user journeys are usually built with simple functionality and tested with the prospective users. This allows us to change, adapt and evolve the product functionality without impacting the technology too much.
  2. Quite often we will create a prototype to further demonstrate the product - perhaps to unlock the next round of funding. Most recently we’ve been designing slide decks around key component designs for this purpose, but the prototype can take other formats too.This is usually where people mistake PoCs and prototypes; quite often we see clients wanting to jump straight to this deliverable without any of the thinking or research that goes into validating the idea.
  3. Often we need to gauge demand or generate awareness of the product; it might be a more developed walkthrough video or a sales deck. One of the most famous examples of this is Dropbox, who launched a landing page with a product walkthrough video - they used email captures to judge demand for the service.
We use a prototype once a lot of the thinking has been completed; we know the problems we are trying to solve and have a view on the solution - this is about testing that view.

To summarise, the risk of jumping straight into a prototype in the first stage of a product roadmap is that not only has feasibility been missed, but the thinking that the PoC helps validate is not there. So building a prototype could be a costly experiment.

If you need help developing your ideas or reacting to change, I’d be happy to discuss an approach. Over the last 3 years we’ve designed PoCs and prototypes for organisations such as House of Fraser, Electrical Safety First, Brother, LV= and Thomas Cook.

 

Absurd workshop