Why Create a Prototype, and How to Do It Right
Prototyping is the most crucial step in the whole software development process, and the most underappreciated one at the same time. Do you need it? Definitely! But why? Find the answers in the article!
While developers fully understand the necessity and importance of prototyping, sometimes clients have trouble understanding its full potential. Well, here we go!
What is a prototype?
And what do a BMW car and your fitness app, for example, have in common?
They both started with a prototype.
A prototype is a rough implementation of a future product. It is a skeleton, a basic structure of the future product that shows its main functions.
All product companies create prototypes (well, at least most of them do). Giants of the automobile industry like BMW never start new production without this ‘draft’ stage. The first prototype of a car could be made from anything, like wood, clay, or Play-Doh. It usually looks kind of strange and sometimes very different from the finished car. But as designers get rid of the functional and design mistakes made in this initial stage, the prototype gradually turns into the version that will be launched down the assembly line.
In the tech sphere, a prototype is typically called wireframe – it looks like black-and-white screenshots with no design elements, showing only the product’s main functional blocks. Like the prototype for a car, it becomes better and better with each step, until it comes together as a clickable version with the basic functions of the future app.
Why is it essential?
The main aim of the prototyping stage is to make mistakes. Literally, the more mistakes, the better – because if you make mistakes at this point, you won’t make them later.
Fixing some mistakes in later development stages might mean rebuilding the app’s entire architecture (and paying developers three times as much), while at the prototyping stage the same problems can be easily solved with just a few quick clicks by the designer in Sketch or Invision.
What the prototype MUST NOT be
It must NOT be beautiful. And we really mean it! No colors, no pictures, no animations, no fancy design elements. Just a set of black-and-white squares put in the correct order.
There are two reasons for that.
The first one – design, even a simple one, takes time. At this initial stage, time can be invested much more wisely – for example, by doing research about the industry or testing the first screens on potential users. In the end, it’s information like this that is crucial for the success of the final product (and not the color of some squares).
The second reason (and the most important one) – all the embellishments just distract you from the future product itself. While you are being captivated by the incredible screen animations, you probably won’t notice that the app is just plain hard to use. And if it’s hard to use, people won’t like it, even if a nice animation of a cat is hidden in there somewhere.
But then what IS a good prototype?
It's easy. The prototype must:
- …be functional.
- …have the correct user flow.
- …show how the product will work.
And don’t forget that the wireframe must speak for itself to new users. If they need detailed explanations of how to use it, then it is a bad prototype. The perfect prototype – a clear and simple structure whose use is obvious from the first sight.
How do we build prototypes here at Yellow?
1. We talk
We talk with the client a lot. And then we talk again. And then some more – because that's the only way to see and feel what the client sees their product and what they want to get in the end.
Different members of our team join the conversation at different stages, which allows us to accurately determine the client’s needs – so calls with project managers, CTO, developers, and designers help us to stay on the same page with the client and see clearly what needs to be done.
2. We draw
When we get all the necessary information, we create one to three main screens with the most important elements of the future app, and then show this first variant to the client. The client gives us feedback, and we, in turn, redo the prototype to fit the comments. The process repeats, the number of main screens can grow up to five or even ten units, and after even more edits we come to a version that completely suits both the client and our team.
3. We test
After the first five to ten main screens are done, it’s the best time to show them to test users. Test groups are an extremely important source of information because the feedback they give can play a decisive role at this point. It’s always a good idea to test the prototype with the future target audience – to put it simply if it’s an app for future moms or teenagers, it’s better to test it with future moms or teenagers.
But if that’s hard or impossible to do – no problem. Show it to friends, neighbors, relatives. It’s still much better than nothing and the value of that feedback is hard to overestimate.
3. We draw (again)
After completing "the skeleton of the skeleton," our team draws the rest of the screens. In general, the prototype contains from 30 to 50 screens, which are done quickly enough, because we already have the core.
4. We build
After all the necessary screens are ready, we assemble them into a clickable prototype. This prototype shows most clearly and accurately how the application will work. This means that test groups can give the most complete feedback for further work on the product.
The most important point here – building a prototype is a joint effort of the client and our team (project manager, developers, CTO, business analytics). Each contributes a share of their ideas and expertise to the project in order to see the result from the largest possible number of perspectives.
How long will it take?
Terms are usually specific for each project. It depends on the complexity of the task, the degree of client’s involvement in the process, and many other factors. But on average, creating a prototype takes from three to six weeks.
And some more advantages of prototyping
Doing a wireframe is the cheapest and most effective way to test our company with literally no risk for the client at all.
It’s the first stage of working on a product, so no strings are attached. Clients can see how we work, and feel whether they like working with us, and if not – just take the ready wireframe and do the product with somebody else (although we’ve never had cases like that). All the intellectual property belongs to the client, so it’s as simple as that.
Since a well-done wireframe is also a good specification for the future product itself, in the end the client has all the data to create the design, make all the necessary estimates, and build the app’s architecture.
Because we don’t charge much for the wireframe (although it sometimes requires hours and hours of work by the whole team), it is beneficial for the client and totally risk-free. Because in the end, we do not sell a couple of black-and-white screens – we sell our expertise, our experience, and the professionalism of each member of our team.
To sum it up
We hope that this information was useful. If you have any other questions (or want to build a prototype?), please feel free to contact us.
Get weekly updates on the newest design stories, case studies and tips right in your mailbox.
Seriously, what is so special about container orchestration tools? Let’s unpack Kubernetes and see what it has in store.
Let’s figure out why you should never neglect load testing in your projects and when it’s the best time to embark on it.
With this article, we are launching a series of stories casting light on the ups and downs behind StickerBox. Spoiler: with all the downs, we made it!