Why we all need to prototype?
From low to high fidelity, prototypes are the inexpensive solution forms for discussing ideas effectively, whether you are a designer or not.
We have all been there, discussing an idea about a feature with different stakeholders is always a challenging task. While trying to pitch the idea, there are always misunderstandings need to be solved within the group you are presenting.
Bringing everyone on the same page and managing a discussion is a hard job because every discipline has its own perspective and thus, different approaches to the problem. Engineers think like an engineer, managers think like a manager, and designers think like a designer. Even we are establishing mechanisms to work together and understand each other well, there will be always grey areas that need to be described explicitly. Writing Confluence pages to draft, communicating over issue cards, talking over Slack threads, and making Zoom calls can help. However while talking on the abstract concepts, it’s easy to lose the connection between things and forget them. That’s why we see the same questions are asked over and over again, by different colleagues in different times, even if they had been answered many times before. In order to glue all discussions and align things, there is another well established vessel that could help us: The prototype.
Each one of us knows how applications work and it’s easy to see the flaws or improvement points. Making prototypes as a primary vessel to connect all the dots around, to hold the discussion sound, and to keep the story in track, help us to achieve healthy conversations, to the point, and even faster.
The prototypes can be low fidelity, that’s alright, you can save time, nice. Or it can be high fidelity, you will see everything in action without spending efforts on development, an inexpensive working application. Choice depends on the situation you are in or the story you are trying to tell and this article covers when and how they improve your workflow and increase the productivity.
See if the idea is working or not
Both low and high fidelity can help
If you want to tell an idea easily, it’s always easy to draw wireframe prototype on paper. Don’t overthink it, don’t try to decorate things, draw the main sections of the pages alongside with the new additions and changes. If you have a wall next to you, stick them to a wall in sequence. Establish the story over them and make everyone at the same page. If you are working remotely, you can use Figma or Mural boards and collaborate on the same file in a video call. (Still don’t overthink, don’t need to know how to draw with these apps, take a photo of your wireframe papers).
When you share the prototype with the audience, they can grasp the whole concept easily because they are seeng a real thing. While protoype make alignment easy, it opens up wiser questions thet you didn’t think also.
Demonstrate the value
Making a prototype is actually a window to a possible future. As an inexpensive method, everyone can see what can be done in future. Generally, when new ideas for the application are seemed as too abstract to grasp and that’s way it’s hard to give attention to details. This makes the idea vulnerable to questions and it starts to deteriorate.
On the other hand, a well established prototype shows the value and future opportunities. It allows specific questions be asked. This way, for instance, backend engineers can think about the required efforts, things to do, if it’s possibble or not.
One of the main prototyping methods is a dark horse. When the ideas aren’t enough to solve problems, when you need radical changes or shifts, you may want to try crazy ideas. It’s obvious to see that you can’t build all of these, instead you can create dark horse prototypes to see the value. Dark horse prototyping lets everyone to see radically improved solutions as real one while not sacrificing valuable time to development to try.
Guide engineering
After design is finalised and engineering starts to work on the project, they need guidence. As a complete guidence, prototype shows how app behaves. and show things that you cannot describe it enough with documents or over slack channels. At any time, dev team can look at the prototype to be clear about the newborn questions, again and again.
If the project is large and have many people and teams working for it, it becomes harder to keep things together. Work is divided into many pieces in different project teams. I’ve seen this in many project, even decisions made, things may not work as expected and needs new decisions. Communicating over prototype gives everyone chance to recall the aim in the first place. Sticking to the very idea reflecting in one clear aim, over the prototype, prevents things to go wrong ways.
Use it in user testing
If you are a designer, designing only key-screens prevents designers to see the whole process. It also prevents customers to understand the changes while you want to use them in user testing sessions. In order to get a real feedback by seeing them how to find out the things you need to provide a well working observable and usable prototype. Giving the real, eliminates the possible misunderstandings and provides and experience nearly identical to what you’ll have in the future.
To conclude, to create products with stellar ideas fast, you need a prototype in every step of your process whether you are guiding your engineers or just explaining the idea to the audience. It’s the best way to keep ideas and discussions healthy by saving time and nest way to see the realisation of the idea itself.
