(Why) I, Prototype

Prototyping can be a very useful tool for (digital) product design. It can drastically improve communication and concept generation, while reducing misinterpretation and reducing risk. Prototyping, when used correctly, will save time, effort and money.

In my experience as a designer, design teacher and coach, students (and businesses for that matter) get "stuck" a lot. Students will come to me declaring they are now officially stuck, and need help to get unstuck. Companies, on a good day (for me), will do the same. The reason the students and companies get stuck is something happens to them that happens to all that are not fully aware of the difference between iterative design and the waterfall method. What? Let me explain.

Design always happens in some structured way. It does not really matter what you design, products, websites, apps or buildings, even if you are not aware of it, there is a method to the madness. Many books have been written about this, discussing the countless nuances in methodology, but none of these books is as informative as opening your eyes and seeing (aspiring) designers in action. Basically, there are two types of methods.

The first type is the waterfall method. This is the "old" way of designing things, and pretty much what I was drilled to do when I studying design. Explained in a simple way, you first analyse your design problem (what needs to be designed?), you then create a lot of ideas, choose some that you consider feasible, create concepts from them, choose the "best" concept and then turn this into a fully functional design. It is a process of diverging and converging. There is a lot more to it, but for the sake of this post, we will keep it simple.

A simple diagram of the waterfall method for a digital product.

The second type, now on the rise in both education and professional practice, is the iterative method, where you make shorter "design loops". Basically, you do very fast waterfalls, and test your design after each one. For example, say you would be the designer for Adobe's Photoshop. You could think out all of the functions the final product needs to have, and spend a long time creating all of these functions. This would be the waterfall method. However, you could also think: "What basic functions do I need to make a very first version that could be sold?", spend very little time making this product, and put it out into the world (as a free download, or get a test group to work with this first version for a while, for example). Now you would make a second version, optimizing the first one trough feedback, and adding some new functions, and so on until all functions have been added and tested. This would be the iterative method in a nutshell.

The benefits of the iterative method should be clear: The short feedback loop allows you to play into the needs of your target group and make adjustments quickly, instead of spending a lot of time and money on making a final product, only to find out on release you should have done some of the basics differently, resulting in painstaking code changes (in the Photoshop example), or a product that just doesn't sell due to an oversight in your target group's needs in case of physical product design.

So, what about prototyping?

What I tell the students that are "stuck" is that they slowly moved into a waterfall- part of their design process, and the chunk they are trying to solve is just too big, resulting in stagnation. You can compare it to the RAM on your computer filling up until everything just gets slow. What they need is output, to free up some of the RAM in their heads and get some feedback from the world.

I am a big fan of the iterative method. In my experience, prototyping can be a great catalyst for the iterative design method, and the two are a match made in heaven. Prototyping at a very early stage, and with very simple means, can really help students and businesses alike to not get stuck, and end up with a far better digital or physical product. Time to get specific.

Using the right type of prototyping at the right time is essential. Let's say we are creating a new app for smartphones. We can code the whole thing, and then test it to see if we have reached our goals. We can also just have an idea, and go straight into paper prototyping. We would just take some sheets of paper and draw up our idea. Try to do this in a way that you can easily test the idea later. For example, use printouts of the front of a smartphone on every piece of paper you use. Now use a new page for every screen, and cut out pieces of paper with pop-ups and state changes. When testing, you can put your full pages over the previous one when your test person clicks on a button that takes them to a new page, or put down the cut out piece of paper when, for example, the keyboard should pop up. It does not have to look fancy, you just want to test if the user understands how your app works, and if you meet their wishes concerning functionality.

Examples:
Paper prototype: Hanmail
Higher definition paper prototype & test

You can create the paper prototype the same day you come up with the idea for the app, it forces you to get specific about the functionality of the app instead of allowing "vagueness" and gives you quick feedback on your first idea. Also, it is very easy to make changes and test for a second time, change again, test again and so on. Without ever writing any code!

After your paper prototyping phase has left you with a version of your app that you are sure has the functions your target group is longing for, and the user interface is very clear and intuitive, you can now put your paper prototype into an actual smartphone, still without any coding skills required, and do some tests to see if the interface is still good when gestures (swipe, rotate, stretch, etc.) and transitions (fading into a new page or element, visibly moving to the lefft, right, top or bottom, etc) come into play. You can use software like POP to do this.

So, you started with a very simple (low definition) prototype. Images might just be quick doodles of what you expect them to be in the end, not all text will be fully defined. Try to slowly move to a more high-definition prototype, that will give you more information about things like text and imagery, informational hierarchy and so on. Always make sure you put the right amount of time into a prototype to get the information from the test you need at that point. Improve, test, improve, test...

Diagram of the iterative design, prototyping and feedback process, T.Zaki Warfell

Beside the generative aspect of prototyping, that is, creating newer and improved versions, there is also a clear communicative aspect to it. Explaining your idea trough words or pictures will never get the concept across like a prototype, even the simplest one, will. The final type of prototype I will discuss here today is mainly meant for communication: The video prototype.

Video prototype: Google Gesture

A video prototype lets you show off your concept to clients, teachers, or test groups, again, without having to create the entire product. Fake it 'till you make it. You will get great feedback on your concept because people really feel they have the full idea to comment on.

I hope you have enjoyed this quick insight into iterative design and prototyping.
If you are interested in prototyping or iterative design to speed up your design processes, here is some interesting reading/viewing material.

Prototyping: A practitioners guide, Todd Zaki Warfell
Video: Rocket Surgery Made Easy: Prototyping and Testing

Of course, you can always contact me trough info@sky-design.nl or by leaving me a message on LinkedIn.

Ir. Kai Giuseppin
Sky . Design