Prototyping has become one of our go-to techniques in ensuring that we are building the right thing. Aimed at quickly and cheaply gathering feedback or information to support a future investment or decision.
Prototyping is a valuable tool that can support a wide range of business decisions. However, there are still many missed opportunities to utilise it for reducing both financial and reputational risk.
This article outlines some of the use cases for prototyping, as well as some reflections as practitioners of various prototyping techniques such as:
- Wireframing
- Visual mockups
- Technical spikes
- Proof of concepts
- Rapid (throwaway) prototypes
- Iterative prototypes
If you would like a free one hour consultation to learn how prototyping could work for your business please reach out to us via our Contact Us page or on LinkedIn.
Prototyping (at least in software development) is a basic model of the intended product. It serves as a tangible representation that allows stakeholders to visualise and interact with the software in its early stages.
The driving principle behind our work is to ensure we build the right thing. Rapid (cheap) prototyping is pivotal to helping us achieve this - we get quick and iterative feedback from users and stakeholders to ensure we are tackling the right problems and designing the right solutions to address these.
There are different levels of prototype, from rough pen and paper wireframes through to fully interactive working software. The right approach very much depends on your context and the questions you are trying to answer.
Here are a few different heuristics and considerations we use to inform the prototyping approach.
Are you testing for engagement or market fit?
Perhaps you are a start up looking to pivot on your initial product or service offering, a large enterprise looking to expand across your vertical, or a public sector organisation looking to deliver more value to your end users. Prototyping is a crucial step in validating whether there is a genuine need for a solution.
While you have likely already had feedback or market signals that indicate there is a problem to be solved, getting a prototype in front of potential customers helps answer questions such as:
- Does the solution display inherent value for people to want to adopt it?
- Have you missed some key needs?
- Will someone actually pay for this?
Are you addressing technical uncertainty?
Sometimes you have validated that a solution is needed, but there are doubts about how to build it. It could be because it is suited to technology that is new to your organisation, or there are concerns about performance at scale, or greater certainty is required on delivery timelines.
MadeCurious recently ran our own technical prototyping week where we assessed the suitability of new front-end component libraries. This helped us quickly answer questions the team had about integration and flexibility by trialing the different options within a small prototype app.
There is a tendency to pressure engineering teams to give us answers and “certainty” without the opportunity to first do some deep thinking. A technical prototype is a great way to do this thinking in context.
Are you trying to achieve internal buy in?
Sometimes you have validated that a solution is valuable, the design is intuitive, and technology approach is feasible. However, you may need to convince others in your organisation to proceed. This often means influencing senior management or executives who have not been close to the problem.
An interactive prototype is a great addition to a business case. It can really help people to quickly understand the context of both the problem and solution space, and provide further evidence that key questions have been addressed prior to further investment being made.
That a picture tells a thousand words is a well trodden cliche, yet it is surprising how often the written word is relied on solely for socialising a business case. This has been a key lesson in why prototyping is such a useful tool across so many business contexts.
Reflection 1: We generally need a visualisation to provide constructive feedback
A common trap I’ve fallen into is spending so much time on a problem that you forget that not everyone has been mulling over the same thing. So I can end up inadvertently assuming the person I’m speaking with has the same background and context.
This can be confounded when talking about possible digital solutions or new processes too.
You will get far more constructive feedback on a solution idea if the person you are speaking with is able to see examples of the solution. Having a visual representation means you are not relying on words that could be misinterpreted, or imagination to convey the ideas. This allows people to immediately poke holes in your thinking which, while sometimes confronting, is exactly what you want!
Reflection 2: Prototyping reduces reputational risk!
Some customers we have worked with are reluctant to get feedback from impacted parties or potential users until the product or service is “just right”. This is slightly more prevalent in public sector organisations.
These customers perceive it as risky to get ideas out there too early - potentially setting expectations of a commitment to a particular service or product. And I get this. From a human perspective putting your idea out there can sometimes be a scary, ego-bruising experience. From a business perspective, setting false expectations and perceived under-delivery is a sure fire way to diminish trust and harm your brand.
But getting fast feedback is a way to reduce reputation risk, not increase it. The quicker you learn that your solution is missing a market need, or that it is not technically feasible to deliver with the budget your organisation has, the earlier you can pivot.
Far greater reputational risk lies in committing to a solution only to discover millions of dollars later that it wasn’t the right thing in the first place!
And there are definitely interview techniques for helping manage expectations during any prototype feedback sessions to mitigate risk of over commitment.
Reflection 3: Test the solution works in actual context
We are big fans of the tool Figma for visual design and rapid prototyping. When I first saw how easy it would be to create realistic, interactive examples, I thought this was going to enable us to get really precise feedback from users.
However, what I found is that it was really useful to get feedback from users when iterating on an existing solution that the users were familiar with - they know how things work can therefore easily engage with the high fidelity prototype. This tends to be a lot harder for new solutions. People will tell you how they think they will use something, but unless you are actually getting them to use the prototype to achieve their goal their feedback is misleading.
What we were still missing was the actual interaction and intention to complete a task, rather than the illusions of task completion. And while we still love Figma, we needed a way to incorporate genuine interaction into our prototypes.
This led us to invest further into our Application Framework to quickly spin up fully functional prototypes that allow users to complete a task or workflow. We recently rapidly built two successful prototypes in the freshwater management and traffic management domains.
Case studies
Recently the MadeCurious Application Framework enabled us to rapidly create two fully interactive prototypes for two local government organisations.
While the freshwater management and traffic management domains are quite different, the goals were the same: learn whether the proposed solutions met the needs of users, and could fit seamlessly into the organisations’ existing digital ecosystems.
With a quick design phase to understand the problem space we could turn each functional prototype around in under two weeks. Each prototype enabled an end-to-end workflow, and included rich spatial tooling.
MadeCurious facilitated testing sessions with users to explore the solution’s ease of use and whether the functionality helped users achieve the actual jobs they need to do. This qualitative feedback, coupled with quantitative analytics under the hood, really built a rich picture of what users actually needed, not just what they told us what they thought they needed.
Another major benefit of these prototypes is that real data is captured and stored. Even if the real product is built using a different technology stack, the underlying data can be migrated, meaning you can start capturing new information from the outset.
Conclusion
While prototyping is a well recognised tool in product development, there are still far greater opportunities for organisations of all shapes to adopt it in order to build more valuable products and services and reduce cost and risk.
If you would like to learn more about how MadeCurious can help you quickly validate your thinking with prototyping then please reach out for a free consultation.
