Let’s talk about prototypes

Last December 4th, Elleva (@elleva.me / @macaetech) promoted a course at Macae Startup program, a government program that support small companies to become self-sufficient. The idea is to motivate Macae’s citizens to become successful entrepreneurs capable of create new jobs and improve the city’s economy.

Once again, I joined this group to share part of my experience in software development using prototypes, especially paper prototype. And in this post, I’ll share my presentation content.

I believe that every recently graduated system analyst / developer goes through the same mistake: to think that all users in the world will love what he/she coded. And when the first frustration comes, immediately the thought is “what can I do to do it right next time?”. And then… the noob dev decides to create a prototype using a programming language. And once again… it fails and the frustration of throw everything away is so huge that the noob dev tries to save anything, even if it is not appropriated according to the user’s opinion.

Yes, I’ve already been this noob dev😊 but… one day, I was presented to the wireframes world and… THE PAPER PROTOTYPE! That’s what this post is about! How prototypes can effectively make you save money, time and help you validate UX and requirements? In a cheap way :O

First things first: What is a prototype?

Prototypes are a simplified representation of a project. It is a very popular tool in engineering, car production and decoration projects.

In terms of software, it is a representation of what will be developed. As software requirements validation requires a high abstraction ability, prototypes may turn the conversation between user / IT analyst much clearer and straighter than using only written documents and imagination.

Software prototypes types

Personally, I consider that there are 3 types of software prototypes: high-fidelity, avarage fidelity and low fidelity. Some authors consider that avarage and low-fidelity prototypes are the same. Let’s see more details about each one and then you can take your own conclusions :)

• High-fidelity

These prototypes are close to the final solution (in terms of front-end — they’re created using HTML, javascript, photoshop…). It’s obvious that this approach doesn’t demand any abstraction skills from the users, but generally front-end tasks demand a lot of time ($$$) and creativity. Invest in high fidelity prototypes too soon is risky, since the user can say “I didn’t like these cards… I want to see all data in tables”. And in cases like this, the entire prototype must be discarded.

A pretty good example of high-fidelity prototype application is when an aviation company decided to develop a new feature for their mobile app. They created a high-fidelity prototype and did several interviews with the passengers, trying to get feedback about the experience, the content… and checking if it was built to be easy to any person. This new feature was about baggage tracking. I was interviewed by this company at the airport and the use of high-fidelity prototype made me agree to spend some minutes in the interview. Imagine if the aviation employee showed me a bunch of papers. Certainly, I wouldn’t accept to be interviewed.

• Average fidelity

These prototypes are also called wireframes. Tools like Balsamiq creates digital prototypes without too many interface details, just the essential to understand the requirements and validate usability.

This kind of prototype is perfect for validation in videoconferences and as it works like drag-and-drop, it’s easy to refine it during a meeting.

• Low fidelity

This kind of prototype doesn’t demand any tool or programming language. It is totally hand-made. Generally it is the cheapest kind of prototype.

You may think that it is not effective or professional. But this approach got so many adopters that it evolved to a very popular technique called Paper Prototype.

Paper prototype

Paper prototypes are hand-made prototypes that are prepared to answer to any user’s action. It’s perfect to validate how your user will deal with the interface and, since it really looks like a scratch, the user feels free and comfortable to deny it or give an honest feedback.

This video shows an example of paper prototype applied at Pinterest Mobile App Redesign. The results use to be so surprising that you can find examples of paper prototype for games and wearables.

Why paper prototype?

• It’s fun!
• It’s fast to be created and incremented
• Low cost
• Low commitment (if it is denied, you won’t feel sorry to throw it away)
• Honest feedback (as it is just a scratch, the user will feel free to say that he didn’t like it)
• Anyone can help to create the prototype, since it is drawings.
• Trade-off: It must be presential

Tips to do powerful prototypes.

• Define a clear target
• Don’t put so much effort in let your prototype beautiful (honest feedback, remember?)
• 1 sketch / software function
• Mobile-first (when appliable)
• When using paper prototypes, caution with colors (use colors to focus in specific buttons, for example)
• Save your prototypes (when using paper prototypes, take pictures of everything, create videos…) — they will be part of your software documentation and will support the developers

Conclusion

In my opinion, IT professionals don’t take advantage of all benefits prototypes provide. In my experience in scrum teams, every time we decide to don’t validate something with prototypes, the users have a lot of questions, difficulties and ask for changes at the final product.

In the other hand, when we create prototypes and increment them gradually after some meetings, the final product is well accepted by the users, they don’t ask for changes and, eventually, we code less, since the users give up on some features that they realize they don’t need them.