Prototyping 101 – What, why, when and how?
Prototyping has been a popular term among product managers and tech community in general for many years. Interest in prototyping and software prototyping, according to Google Trends, was at its peak from 2004-2006 worldwide. However, these keywords have enjoyed constant popularity ever since.
Interested in joining our team? Click on the link and apply!
1. Head of Product / TOTAL GROSS SALARY: 4.000-5.300 EUR
2. Product Manager / TOTAL GROSS SALARY: 2.000-2.600 EUR
You might be wondering why there are so many different terms used when it comes to prototyping. At least once in your life, you probably came across your colleagues mentioning sketches, wireframes, mockups, and prototypes. I hope that, with this article, you will gain a better understanding of the differences between all these terms.
What is a prototype?
If we had to define a prototype in one sentence, we could say that prototyping is a process of creating an early representation of a product we are about to build. Shortly, a prototype can be considered an early iteration of a product which showcases all the core features that the actual product is going to have. It is important that a prototype is understandable for all stakeholders – including the product and project managers, the design team, the client, or the product owner, the development team, and others.
As you have probably noticed, there are several different types of a prototype. The main criterion for classification of a prototype is the level of precision in which the prototype was made. Therefore, there are two different types of prototypes – one is a low fidelity prototype, and the other is a high fidelity prototype.
The difference between low fidelity prototype and high fidelity prototype
When it comes to a low fidelity prototype, we use hand-drawn sketches and basic wireframes that only showcase the basic structure and most essential features of a product we want to build. There are no specific details, such as colors, styles, and actual content in terms of copy and imagery.
On the other hand, for the high-fidelity prototype, we use mockups and prototypes. Although it might seem confusing, there are differences between these two terms – a mockup is an enriched low-fidelity prototype that contains additional information about the colors, fonts, images, and other content. A good mockup should clearly visualize the final look of a product.
The prototype is the most detailed and, on top of all the information that the mockup provides, adds additional information about the way the product will perform – including interactions and animations. Using a prototype helps your stakeholders see how the product will perform, without implementing the functionalities.
What is prototyping used for?
You know that they say that a picture is worth a thousand words. If we put that statement in the context of prototyping, we can conclude that a good prototype will prevent you from going back and forth on numerous meetings.
There are several other reasons why we need prototyping. Firstly, prototyping (both low-fidelity and high-fidelity) gives all stakeholders a clear understanding of what was envisioned for the product to look like. When we are all looking at the same thing, it is way harder to misunderstand each other in comparison to using just words to depict our ideas and intentions.
Additionally, prototyping allows you to receive feedback in the earliest phases of product development. Even more importantly, it allows you to pivot your ideas based on this feedback. Let’s say you have an indecisive client, or you are developing a startup on an unsaturated and unexplored market – your decisions will change, there will be a lot of ad hoc ones and you will have to quickly adjust your product to be in accordance with your learnings about the market and your (potential) users.
With a high-fidelity prototype, you will be able to test your product among a small sample of potential users. This gives you the opportunity to collect feedback, test the user flow and use this information to improve your product before it gets developed and officially reaches the market.
Finally, prototyping is a great approach to getting your ideas validated from either the client or the product owner, before you and your team spend a lot of time on development – only to figure out a certain feature is no longer relevant.
When to use prototyping?
Although we might now understand the importance of prototyping, this question often continues to linger. My personal recommendation on when to start using low-fidelity or high-fidelity prototypes would be – as soon as possible.
By starting to sketch your ideas right at the beginning, we prevent misunderstanding between stakeholders and portray our ideas in a clearer manner.
For every project that we do in today’s incredibly fast paced IT industry, we want to prevent late feedback and changing things when they are already implemented. Therefore, it is extremely important to have a proper understanding of our product right away and establish a common ground on what the product should look like between each other.
Of course, prototyping will never act as a firewall and protect you from all change requests. They always happen and are a part of a natural flow for everyone who must quickly adjust to the market and pivot initial ideas. However, at least we will save some time and money on unnecessary mistakes caused by the lack of precise communication in the first place.
How to create a prototype?
There are many different tools on the market that can assist you in creating wireframes, mockups, and prototypes. In Speck, we use Balsamiq, but the following tips apply for any tools you are using!
Naming your wireframes
When you have a lot of wireframes for many different screens and features, it can be easy to find yourself in a huge mess. Therefore, it is useful to establish a convention on how you will name and organize your files.
One approach would be to showcase the flow of an entire feature in a single wireframe. For example, if you would like to showcase the Checkout process for your e-commerce mobile app, you can have all the screens related to this process in a single wireframe file named “Checkout”. This approach is often recommended for mobile devices, as the wireframes have smaller dimensions and there is no need to separate each step in its own file.
The second approach would be to use the naming conventions and have each screen in a separate wireframe file. You can choose the naming convention which works the best for you, but we would suggest showcasing the name of the feature and a number or a name that describes a single step in the flow of this feature. For example, if you have created wireframes for each step of the checkout process of your e-commerce mobile app, your wireframe files could be named “Checkout-Cart”, “Checkout-Shipping”, “Checkout-Payment” and “Checkout-Success”.
Using predefined components
If you want to quickly create multiple wireframes, but you find yourself repeatedly copy-pasting the same elements, most of the wireframing tools will allow you group certain elements or save them to a library of components, so you can always reuse it later.
Once you build a library with your own components and templates (i.e. contact forms, navigation, grids, buttons, containers), you will find yourself saving up a lot of time when building new screens.
Portray your ideas more thoroughly by using comments
Another very useful feature that you can find in wireframing tools, such as Balsamiq, is the ability to add comments and additional descriptions for different parts of your prototype.
If you feel like a wireframe doesn’t describe your idea in enough detail and there are some things that you simply need to use the words for, you can add comments to explain what exactly you meant. This can also be used when you want to explain how something should work, or you don’t want to forget how something needs to look once in development.
Don’t reinvent the wheel
Although wireframing tools provide us with a lot of features, there are some things that we still need to remember ourselves.
When creating the wireframes, we should always make sure to keep in mind how the elements will be arranged on real-life screens of desktop and mobile devices – this depends on what we are trying to build. A good approach would be to always use grids and arrange your components accordingly.
Another important thing is to always think about how the wireframes will later be shaped into a final product. Even though we are mostly working with low-fidelity prototypes, we need to make sure that our prototype is helpful for designers and developers who will be working on the final product. Make sure the interface is intuitive and follows common good practices in UX, validate if the user flow makes sense and check if the elements are spaced apart enough for touchscreens.