How to create a prototype in a single sprint? A real-life example
Here, at Boldare we are no strangers to prototyping. In fact, our recent client was in a position where building a prototype was necessary. How did we use a prototype to help our client decide if their product idea is worth pursuing? This article will tell you all about it.
Table of contents
What is prototyping?
In terms of physical manufacturing, the idea of prototyping is pretty straightforward: to create a simple, physical prototype that would demonstrate the basic features of a product. But what about digital prototyping? In our experience:
the prototype is often a front, an interactive visualization or clickable trailer of the product – a means to test and validate the look and feel decided on so far, and the main business concept.
In some cases, it may involve putting the usual digital product design and development process on hold and focusing on getting the core features of the digital prototype done. And sometimes, there’s a need to create multiple prototypes. Each one helps our partners get closer to finding out if their product has the potential to become successful (source). For the sake of this article, we’ll be using the term “prototype” and “digital prototype” interchangeably.
How does prototyping work?
Prototyping and digital prototypes are tools that are used mainly to validate business hypotheses with potential target groups, or help to present the general idea of the product to possible investors during a business pitch. Either that way, they help to visualize the business idea that can later be transformed into a digital product or existing app feature.
While prototypes can be done even using a simple drawing on a restaurant napkin, in a digital product development process we use specific tools. That way prototypes can be clickable and can show up to a few screens with the initial idea of a design.
Is prototyping Agile?
The short answer is: Yes.
Building a sprint prototype allows for an informed discussion that often leads to changes in the functionality of the product. Changes that were not planned when the product idea was first conceived. In that sense, digital prototyping is very much Agile. But is it an essential part?
In digital product development, there is a concept called MVP - a minimum viable product. The MVP is essentially an early version of the product - which could be a mobile or a web application. It incorporates only its core features, both in terms of functionality and design. However, while there is a lot of commonalities between MVP and prototyping there are differences; the biggest one being:
MVP is always a software product that is released to the market in order to validate some business assumptions. A prototype is used to present or validate the idea for a digital product, thus it never gets released to the market - it’s simply not its role.
Once the prototype has served its purpose (like positive validation of an idea), developers can start building the actual product from scratch - into MVP, for example. It’s something that is worth keeping in mind, as the discussions on “Which is better: prototype vs MVP” are still very much alive.
Prototype - a real life example
Here, at Boldare, we are no strangers to prototyping. In fact, only recently we had a chance to create a working prototype in a single, week-long design sprint! If you want to find out more about the client and this real-life example of prototyping - just keep on reading!
The Client
Our client is a major international organization. While divided into separate entities, the organization has its representatives in almost 200 countries. It deals with all sorts of assignments: from administrative tasks, political meetings to logistics of large operations. We were approached by a representative of the division responsible for official statistics and data analysis.
The problem
The client often deals with queries like “calculate the inflation rate in country X”, or “estimate the damages caused by crisis Y”. While they have years of experience in what they do, they have recognized that there is room for improvement. The client saw their biggest problem as working with data from multiple sources.
As each report was a result of a joint effort, it was taking way too much time to gather the necessary information. Contacting separate departments requires time that could otherwise be spent more productively. Also, it makes it more difficult to present the data in a clear way. The different data sources had their own ways of presenting the information.
For example: remaking ten pie charts into a single, complex graph would be extremely time-consuming, making the process highly ineffective.
Proposed solution
Soon it became clear that the client’s specifications were too broad to start building a product right away. After further discussions, we proposed a digital product that does two things:
- gathers data from multiple sources. A so-called Data Storage location - a place where every team member can upload their data in a single format. No more email attachments, no more mismatching data sets. Also, in some cases, the data would upload automatically from external sources.
- presents data in a visual way. Our product would generate a Gallery of Reports - a website where data is presented using graphs, pie charts, etc. This component would look in a similar way to Chartipedia or Zadd. The idea is that anyone within the organization could share and present their data with a single link.
Data Storage was a component that needed to be tested by the users first. That’s where sprint prototype came into play. It is worth noting that, even at this stage our client was involved. In fact, building a prototype was something that was decided collectively: by the client himself and our team led by the Product Strategist.
Digital prototype as a part of the solution
Using a sprint prototype approach allowed us to test the flow of the product: how the application works and how it could be used. In this case, it meant the team could test the different ways of uploading data - both automatic and manual.
Before the start of the sprint, the team asked the client to show them an example of an assignment that their organization would normally complete. For the sake of argument, let’s say that the task was to “calculate the inflation rate in Poland in 2021”. The team asked the client how they would normally go about this task - which data sets they would use and what calculations they would make. The design of the prototype was based on the answers to these questions. The prototype followed the same procedure and it was expected to give the same result.
With that in mind, Boldare’s development team got to work. How did they do?
How rapid prototyping helped the client
Building a functional prototype took only two days! The reason why it was so quick is simple: our team used elements of existing products. The design sprint as a whole lasted seven working days. So in a meantime, the team could also work on the Gallery of Reports component.
Once the sprint was over, the prototype was presented to the client for testing. The client used the prototype to complete a single assignment; namely, to calculate the inflation rate in Poland in 2021. The task was completed successfully. But, how was it useful to the client?
It sparked a discussion on what the final product should look like. But this time, instead of explaining a general idea, the client could focus on specifics, like:
- which feature would become a priority?
- suggestions on how the data should be stored (revolving around ways to access the data and the specific file formats that would be used to save them).
Kickstarting an informed discussion like this could mean only one thing: the sprint prototype had served its purpose. But most of all, it confirmed one thing: that the client and our team agree on the proposed solution. Which was one of our goals all along!
Other benefits of prototyping
On top of this, the prototype real life example was a way to save money. How? It verified that the solution that we had proposed was satisfactory to the client. This was a good thing to happen before the client invested a significant amount of cash.
Developing an untested idea can often cost tens of thousands of dollars. In this case, the client invested only a fraction of their budget and received a definite confirmation that their idea was going to work. It was easy to verify since the product owner was going to be the end-user. Additionally, we gathered crucial insights that we used to create an MVP for that client later in the development process.
Now that the team and their client were on the same page, the project could move on to the next stage: building an MVP!
Share this article:
