Home
A 2013 study compared two cohorts of engineering students on a design challenge. One group was told to build a single prototype while the other was told to build as many as possible. The study found that team that was allowed to build numerous prototypes were significantly more satisfied with their final result and had showed greater improvement between iterations. [1]
Think of prototyping as a form of front-loading. By shifting key learning processes from the future into the present, teams are able to create more context about their products which helps inform future decisions.
Beyond the learning outcomes, the building of a prototype forces the individual to explicitly articulate what’s going on in their heads and bring at least part of it into reality. So the process of designing and building a prototype as a team helps increase mutually shared knowledge, and lays common ground around what the project is ultimately trying to achieve.
Everything starts with a revelation. It might be a tiny hunch, a fleeting insight, or an off-hand comment overheard at the pub. However subtle it might be, there’s always a moment that sparks a question - can a situation be improved and if so, how?
Despite it being crucial, the journey to revelation is far from straightforward. And most of us can’t afford to simply sit around and wait for divine intervention. According to journalist and author, Warren Berger, insatiable curiosity is the key to revelation. Meaning the mere act of inquiry can foster new ideas and potential solutions.
Among design thinkers, the quest to revelation is called divergence. It’s the part of the process when we open ourselves up to inspiration by letting our minds wander freely. We do this by exploring all potential ideas that come up, without judgement so as not to prematurely shut them down.
Sometimes we don't exactly know what we’re looking for, or we roughly know what we want to achieve but just can't visualise it yet. This is called a "fuzzy goal". Dave Gray, author of Gamestorming, [2] describes fuzzy goals as having a certain emotional, sensory and progressive nature to them.
What Gray means is that a good fuzzy goal should be aligned with people's passions, while tangible enough that it can be described or at least visualised in some way. But a fuzzy goal is also somewhat of a moving target, which means teams can't simply project manage their way there. That’s why prototypes are such a useful first step when it comes to bringing fuzzy goals to life.
There are two types of prototypes; technical and experience prototypes. Technical prototypes seek to inform its builders on the viability of the thing being created, and whether it will be able to achieve a desired outcome (e.g., can I pair my bluetooth keyboard to my mobile app?).
A technical prototype is useful when a team is trying to build something that it never has before, as opposed to trying to improve on an existing process through speed, efficiency, or cost. When building a technical prototype, the first question should be, "if this thing could exist, how would I go about building it?"
An experience prototype, on the other hand, is less about whether something is possible and more about whether an experience is pleasant. So, experience prototypes are more useful for situations when a team isn’t sure how an idea is going to resonate with people - whether it "feels" right.
The process of creation is very alluring, and it’s tempting to fall into the belief that creation merely for its own sake is good enough. This is a common pitfall prototyping can help teams avoid, as it forces creators to make sure that they’re creating for the right reasons.
Consider what’s at the core of your revelation and hypothesis, and ask yourself what the simplest route to validating whether or not you’re on the right path would be.
While working on your prototype, also ask yourself:
When entrepreneur Gagan Biyani first had the idea for his course marketplace startup, Maven, the first thing he needed to find out was whether consumers would be willing to pay a significant premium for cohort-based courses over video-based ones. [3]
His prototype was simple: a single test course with an established teacher. Running a single course meant they wouldn't have to commit to building the whole platform before testing the core concept. And by using an established creator with a pre-existing audience, the team wouldn’t have to worry about their marketing funnel for the one course either.
The mobile app team at the Financial Times similarly uses a prototyping approach when testing new feature ideas. To find out whether a feature is easily understood and has an improved user experience, the team uses a different approval framework that frees them from their usual process.
"To validate all these feature ideas we needed to make fast releases and run a lot of A/B tests,” FT software engineer, Charlotte Payne remarked, “We decided that our implementations had to be quick, dirty, and easy to remove." [4].
So, they decided to forgo writing unit tests, to only use one core reviewer (instead of the usual two), and to spend less time planning out each feature in detail, thereby giving the developer more agency to use their best judgement when implementing the feature.
By temporarily suspending their standard modus-operandi, they were able to dramatically increase their learning speed and take in the real-world user insights.
In the final act, the prototype must prove itself worthy in an ultimate trial. Will it vindicate its creators after being subjected to the scrutiny of the big bad world?
When it comes to experience prototypes, there may be a million things missing from the experience you trial. So, it’s important you think about which metrics matter most in helping you confirm your hypothesis - that’s the part you should test out.
For Biyani, his Maven prototype proved to be successful, as after running the one-off course, he was confident his hunch about cohort-based courses being worth a premium price was correct.
But in the process of executing his prototype, he also gained new insights around the community aspect of cohort-based courses that he didn’t anticipate. These insights proved to be crucial in eventually helping him shape his product and business strategy, exemplifying the added benefits of prototyping.
Not only do the metrics you choose factor in massively to the success of your prototype, but in larger organisations it’s also crucial for these metrics to align with how other teams in the business operate.
In the early days of Pinterest, its growth team was focused on getting as many new users as possible, while the product team focused on monthly active users (MAUs). [5] This differing focus meant there was a disconnect between growth and product departments, and it was harming the site’s growth.
So, the product team shifted their focus to New Weekly Active Pinners instead (people who pinned an image to a board) as this was a core user interaction on the platform. "Now, it wasn’t just about getting new users to sign up, it was about making sure they had a great experience from sign-up to first home feed that set them up for long-term success on Pinterest." then product manager, Sarah Tavel said in a blog.[6]
Technical prototypes are usually much easier to quantify because, if you succeeded in building one, that usually means it's technically possible. So with these prototypes, it's important to make sure the test fulfils as many criterias as possible. Always be thinking of new ways you can further probe it to get the maximum learning value out of the process.
With technical prototypes, it’s good consider how well the innovation would scale as the product grows. Will the solution still work with 10x or 100x the initial load? Is there a way to test this and get definitive numbers? The prototype itself doesn’t need to fulfil all these criteria but it can give you insights that will later assist when it’s time to engineer for those scenarios.
Gauging the demand for a new product feature can also be discovered through prototyping. When the FT mobile app team wanted to know if their readers would be interested in playing in-app games, they deployed a common type of prototype to find out - the fake door test.
The team added the option to play three different games on the bottom of their homepage. However, if a user clicked one of the games, it would redirect them to a page where the developers came clean about the fact that the game didn’t exist…yet. The page also gave the user the opportunity to provide feedback on their interest in in-app games (and potentially vent about being misled).
"...However, we received over 2000 survey responses and very few (about 1%) complained about the approach,” said then app project manager, Simi Agbaje. “The vast majority enthusiastically told us about why they wanted games in our app. This helped us validate the potential value of games for habit formation quickly and with minimal build effort. For more technically complex features like this, fake door tests provide a ‘cheap’ way to confirm there is user value before taking on the complexity." [7]
Remember, if you’re presenting ideas to a small group, there are many ways to capture their feedback. You can use "likes" in the form of physical or virtual dot voting, acquiring improvements, ideas, and questions that come up from people using the app.
