Think about the last time you tried to describe a complex or an abstract concept using words. You may have been talking about an idea you dreamt up, an innovative device you’ve never seen before, or even a meme. Whether it was a professional or trivial subject matter, and regardless of how eloquent you are, you’d probably find it easier (and quicker) to get your point across with an image rather than a couple (or more likely a dozen) of sentences.
Believe us or not, the “a picture is worth a thousand words” rule applies to business and software development as well. How come? Think of building a digital product. With your concept defined, you could take a risk and proceed straight to the development phase. But you could also turn the idea into an interactive prototype before actually getting down to code. This way, you’d test some hypotheses, get early feedback, and make changes without putting a significant amount of resources at risk.
You know where we’re heading now, don’t you? In this article, we’re going to prove that Tom and David Kelley, the founders of IDEO, didn’t claim that “a prototype is worth a thousand meetings” for nothing. We’ll explain what a prototype is, how it differs from a PoC and an MVP, how ventures can benefit from prototyping, and much more. Ready to go on this journey with us?
What is a prototype?
According to the Cambridge Dictionary definition, a prototype is “the first example of something, such as a machine or other industrial product, from which all later forms are developed”. This explanation holds true also for software development, whereby prototyping is a common method of testing the waters before committing to building a full-blown digital product.
Since it processes no real data and involves no code, a prototype is not yet the functional version of your application. It’s more of a clickable or an interactive model of the product that focuses on the look and feel. As such, it serves validation of the assumptions underpinning your general business idea as well as initiating the feedback loop early on.
If we were to give you our own definition, we’d say that
a prototype is an early visualization of the product that gives us a more or less real-life experience of your application and provides a means for us to verify whether certain features and the designed user flow make sense.
How is a prototype different from a PoC and an MVP?
Now you’re probably thinking to yourself Wait a minute, isn't a Minimum Viable Product all about validating your business idea? And what about a Proof of Concept? And you’re absolutely right: broadly speaking, all three serve some form of testing or verification. In practice, however, each of them has its own place in the software development process.
Let’s begin with the one that tends to be more confusing, a Proof of Concept. Much like a prototype, it’s not yet even a version of the product. It’s rather an exercise in an idea’s feasibility that focuses on the workability of certain solutions – especially if they’re highly disruptive. Another similarity to a prototype lies in the PoC’s potential to raise seed money and obtain the approval of the project stakeholders.
The difference between the Proof of Concept and a prototype, however, is that the former doesn’t take design into consideration and can’t be shown to the users. Furthermore, conducted at the very beginning of the software development process, a PoC tells us nothing about the prospective user interaction.
The contrast between a Minimum Viable Product and a prototype is more striking. If the former is the first part of the successful movie series, the latter is a trailer which – although not revealing – tests the audience’s reactions. As the name suggests, an MVP is the minimum version of the finished product that can be released to the market. It’s functional, based on code, and although it may be limited, it must be polished enough to attract real customers.
So while a prototype is disposable once it gives you a sneak peek into user interactions, a Minimum Viable Product is ready to improve and evolve into further interactions of your application.
How can a prototype benefit your business?
Is prototyping an essential part of the software development process? Let’s be honest here: not always. If your goal is to build an application that’s just like a dozen others on the market, let’s say another simple e-commerce, there’s no point in reinventing the wheel. But there’s a number of scenarios in which prototyping will make sense. Think of a brand new idea for an application or a disruptive new feature that can be added to an already existing solution. If that’s the case, creating a prototype will let you enjoy some (if not all) of the following benefits:
- Focusing on users and their needs
In 2019, 25% of users abandoned an application after one use and only 32% liked the product enough to keep it installed longer and launch it over 11 times.
Wouldn’t it be splendid if your application not only excited but actually endeared its target audience? One of the ways to achieve this goal is to create a prototype in the first place. This way, you’ll find out how the prospective users interact with your product, what they demand from it, and how big its potential for longevity is.
- Getting stakeholders and investors on your side
There’s no denying that humans are visual creatures – so if you’re about to pitch an angel investor, it’s usually better to do this using not only words but also pictures. Sometimes a mockup will be enough, sometimes it’ll make more sense to prototype a single functionality. Either way, an interactive trailer of your product will show your knowledge and dedication.
- Saving time and money
Have you heard about the “fail fast, fail cheap” rule? Of course, everybody wants to be successful but that’s not always possible – and usually, failure is the best lesson one can get on the road to success. Starting with a prototype gives you a chance to validate some assumptions and steer the project in the right direction. To quote Eric Ries:
Sure, you could take a longer time to build a more perfect prototype – but doing so would only slow down the learning process. That may not matter if you’re on the right path, but let’s face it – not every idea is a winner. Whether you’re taking a risk on a bold idea, or you're just not sure, it’s better to find out early. Wasting time on the wrong thing is a major bummer. But perhaps the biggest problem is that the longer you spend working on something, whether it’s a prototype or a real product – the more attached you’ll become, and the less likely you’ll be to take negative test results to heart.
As you can see, both low and high-fidelity prototypes will save you from failing miserably and increase your chances of long-term success.
The sky's the limit: types of prototypes
So far, we’ve made it clear that a prototype is a draft of your product with no engineering behind it and that it can be highly advantageous to your venture. At this point, however, we need to stress one more thing: when it comes to the form and the complexity of a prototype, the only thing that limits you is your imagination (and budget). In this part of the article, we’re going to discuss the most frequently used types of prototypes.
Wireframes and mockup
Let’s begin with static elements that can be linked together to make up interactive prototypes of different fidelity: wireframes and mockups.
A wireframe is a low-fidelity representation of a product structure. As a simple pen and paper or digital sketch using no more colors than black, white, and some shades of grey, it informs us about the general layout of the app, the elements of the interface, and the connection between them. It can’t go into too much detail but it has to be comprehensive enough to represent the idea behind the application well. In this regard, a wireframe is like a map: it has to show the streets and the landmarks, but not necessarily all the trees in a park.
Fragment of a wireframe for one of our projects
Wireframes can serve to document the project. After all, they organize content in a clear way and lend themselves to notes about designed interactions. Moreover, they are a great tool for teamwork, especially when it comes to facilitating cooperation between designers and developers in the early stages of the software development process.
A mockup, on the other hand, is a high fidelity representation of the product’s design, including colors, typography, icons, etc. In other words, it’s the epitome of the application's visual identity. With all its complexity, a mockup gives a deep insight into what the product will look like and may constitute a significant part of the pitch deck.
Think of the early version of your digital product as a human being. A wireframe is the skeleton and muscles which, when stimulated, have the potential to move. A mockup is a skin, the hair, the eyes – everything that gives the body a distinct look. Both, however, make up nothing more than an inanimate dummy. What we need now is the spark of life that will cause it to move. And that's where a prototype steps in.
Pen and paper prototype
It’s the most basic solution one can think of, isn’t it? All it calls for is a piece of paper, some pens or pencils, and a touch of creativity that lies dormant in every one of us.
Although it may seem trivial for some, pen and paper prototyping comes with a wide range of advantages:
- It’s fun. Nothing breaks the ice during the first meetings with clients like drawing together. It’s engaging and calls for no advanced skills.
- It’s fast. Remember how we said that a picture is worth a thousand words? So is the simple drawing of what we mean by a given functionality or interaction. As it doesn’t take much time to create, a pen and paper prototype is also easy to improve or even throw away and replace with a different drawing.
- It’s cheap. All because you don’t need any special equipment or software for early-stage conceptualizing with this method. And if anything goes wrong, there are no regrets – you haven’t invested much into a sketch, have you?
- It works. In spite of being relatively simple, a paper prototype does indeed show the core elements of the interface and makes moving them possible. As such, it elicits feedback and allows to implement changes to the product idea at the very early stage of conceptualization.
Of course, the pen and paper prototyping has its flaws: it’s often inaccurate, needs clarification, and requires a great dose of imagination. At the same time, however, it can work miracles during brainstorming sessions and product design workshops.
The pen and paper prototype discussed above is the subtype of low-fidelity prototyping, so we’ll be brief in this paragraph. Lo-fi prototypes convey the key information about the product. Rather than colorful designs and meaningful content, they display shapes, hierarchy, and basic interactions. Just like wireframes and paper prototypes, they are invaluable in stimulating group work as well as clarifying and documenting ideas.
The simplicity of the low-fidelity prototypes, however, might be problematic at times. The participants of usability tests are usually attentive to details and inquisitive: even when advised to focus on certain elements only, they tend to pay attention to all parts of the prototype. As a result, they may end up fixating on the copy that doesn’t make much sense or the buttons that are not clickable yet. Thus, if we wish to conduct usability tests, the lo-fi prototypes might not be the most accurate way to do so.
On the other side of the spectrum lie the high-fidelity prototypes that not only feel but also look almost like the finished product. Their design is realistic and the content within is meaningful – sometimes to the point when a user doesn’t notice it’s just a prototype until they try to interact with it in the more complex ways.
The advantages of the hi-fi prototyping are as follows:
- Clarity. Being aesthetically pleasing, high-fidelity prototypes showcase design expertise and engagement. As such, they can be presented to all stakeholders, including potential investors, in an attempt to get them excited about the project and raise more capital for development.
- Conclusive results. A hi-fi prototype is as realistic as a prototype can get. In practice, it means that participants of the usability tests will treat it as an ordinary application and behave naturally. This, in turn, will give us honest feedback and point to the major pain points.
The major cons of hi-fi prototyping, however, is the investment you have to make. On the one hand, high fidelity calls for pixel perfect design created with branding or even an entire marketing strategy in mind. On the other hand, if it’s supposed to mimic the behavior of a fully-fledged product, it may require the involvement of developers. And if that’s the case, the failure may turn out quite pricey.
|lo-fi prototype||hi-fi prototype|
|looks like||a simple black and white sketch of the app’s interface||a nearly finished version of the product|
gives a realistic look and feel
requires further clarification
|time and budget-consuming|
pen and paper
You have my sword, my bow, and my axe: a few words on prototyping tools
In the case of the paper prototype, the choice of tools is simple: you need something to draw on and with. With digital prototypes, however, things get a bit more complicated.
There’s literally a myriad of prototyping tools on the market and there are nearly as many reasons for deciding on this and not that one. Among some of the most common factors, we can distinguish:
- the complexity of the project and previously used tools (if applicable),
- required level of fidelity,
- ease of collaboration with teammates and the client.
With so many prototyping tools available, let us cherry-pick the ones we like the most.
First on our list, Axure RP “lets you quickly make rich, functional prototypes so you can make informed choices even on your most urgent project”. The tool allows creating click-through wireframes as well as interactive prototypes. It fits complex projects which require a great deal of structure and smooth organization.
Shareable prototype made with Axure
Sketch and Figma
Another prototyping tool worth considering is Sketch. Although it is primarily focused on design, it also facilitates testing product ideas and getting feedback on them. All thanks to the possibility of setting starting points, linking artboards, defining clickable areas with hotspots, etc. Once you have that covered, just share the link to the Sketch prototype with the test participants or the developers.
When discussing Sketch, it would be a shame not to mention Figma as well. Both are similar in features and the general feel – what makes the latter stand out, however, is the way in which it facilitates teamwork. The designers using Figma can see and comment on what their teammates are doing, which reduces the risk of either of them straying from the design path. Both Sketch and Figma will work great for projects requiring the big picture perspective.
Framer and UXPin
Finally, there are also some complex tools like Framer or UXPin which bridge the gap between design and development. Imagine wanting to enrich an already existing application with a revolutionary feature that requires prototyping. Using other tools, the designer would have to first find the old mockups or even draw wireframes from scratch. With Framer, it’s simple: the developer sends the product design the code, certain functionality is mocked and sent back to the dev who may polish it, et voilà!
Similar is the case of UXPin which, unlike the above-mentioned tools that “fake interactions”, fills the design with interactive stateful components and actual production code. This way, UXPin brings a prototype one step closer to a real application and facilitates cooperation between designers and developers.
How to build a prototype: firsthand experience and tips from Merixstudio
If you’re reading this paragraph, it means that you’ve arrived at a thorough understanding of what a prototype is (and what it’s not), the benefits of prototyping, the pros and cons of both low and high-fidelity prototypes, as well as the features that make particular prototyping tools special. You’re ready to take one step further and see how all we’ve said so far translates into practice. Because at the end of the day, all that matters is the ability to put the building blocks together so that they form a well-structured process.
Before we delve into our prototyping process, let us briefly refer to a design sprint. The framework originated at Google Ventures as a means to align teams in terms of product vision and project goals. Then, it was popularized by Jake Knapp in his book “Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days” and soon gained ground in the product design world. In short, a design sprint is
a design thinking method used to solve complex problems throughout co-creation, rapid prototyping, and qualitative testing with targeted users.
It comprises five stages during which the team is bound to progress from a problem to a solution by means of asking questions, testing hypotheses, and finding answers.
The reason why we’re mentioning this framework here is that Merixstudio’s tried and tested prototyping process is inspired by the design spring. How exactly?
- Drafting scenario
When discussing the product design process, we stated that a great part of it takes place during the workshop – and the same is true for prototyping. Our goal at this point is to get to know the product inside out. We ask questions about the needs of both the client and the app’s target audience. These insights help us brainstorm solutions and suggest optimal user journeys, processes, and information flows. This stage of our process is the equivalent of problem framing and discovery within a design sprint.
Now’s the time to visualize the ideas and transform them into static views. At this point, it’s worth indicating how different elements of the wireframes will interact with each other. Although it might not seem obvious, the key thing is to ensure close collaboration between designers and developers already at this stage. Doing so, we’ll prevent the discrepancies between the design and the tech solutions (often limited by the budget) from appearing later on.
With the ideas structured, we can get down to business. Close cooperation between design and development teams is still advisable if we don’t want to risk creating a prototype that’s out of touch with reality. It’ll prove beneficial also if we’re prototyping a new functionality which is yet to enrich an existing product.
Here comes the moment of truth. Depending on the project and client’s resources, usability testing may take a wide range of forms: from simple online interviews involving screen sharing to in-depth examinations. The more data we gather at this point, the better we’ll be able to plan the next steps.
To prototype, or not to prototype
That is the question… that has no universal answer. As we stated above, simple solutions rarely call for checking usability before getting down to development. In other cases, however, prototyping can be a source of invaluable insights on user behavior and a means to support your venture. To make the most of it, we recommend bearing in mind the following best practices:
You don’t need to walk the prototyping path alone. Get in touch with our product design team for some expert advice.