Final reflection

After 6 different assignments over the course of 8 weeks, I got to learn and practice many prototyping techniques, ranging from lo-fi, such as paper, audio or wizard of oz prototyping, to hi-fi, like wireframing and a/b testing. This course helped me understand each method better, so I can easily figure out when and where they would best fit and what are their strengths and weaknesses.

Starting with the lo-fi prototypes, they require minimal resources to be made, so they’re a great fit in the initial phases of the designing process.

Paper prototyping

For the paper prototyping the only tools necessary were a few sheets of paper, pens and scissors. In a few minutes I already had a few screens designed for my smartphone app, and the smartwatch version took even less. This is a great way of just sketching ideas so you can rapidly test it with users, and also quickly going through different possible layouts to get a better idea of what you want to build on. The only downsides of it is that people interact differently with paper rather than actual screens, and the paper prototype may not fully reflect its digital version, both in terms of interactivity and level of detail.

Audio prototyping

The audio prototyping was a bit harder for me, as I did it for the first time during the course, but even so it didn’t take me more than half an hour to find and record the desired sounds around my house using the Voice Memo app on my phone, and another hour to select the version of each sound I wanted and edit it using Adobe Audition on my laptop (but there are many free alternatives out there, such as Audacity, or FL Studio). Like paper prototyping, it uses minimal resources, both in terms of time and money, and the tools needed are a phone, a laptop and the software. Testing it may be quite odd, as in my case some of the sounds were played while the user was supposed to be running, and this thing cannot be simulated during a user test, and this would be the only downside of it. Another thing that can be odd is that I went on and recorded my own sounds, while on a real project I will probably buy access to a sound library to work with. Although audio prototyping it’s also a lo-fi prototyping method, I see it being used further down the road than paper prototyping, say, after you have your first version of the digital wireframes in place, in order to get the most optimal results.

Wizard of Oz

I decided to also include Wizard of Oz prototyping in the lo-fi category because in almost all of the cases it is used in the very early stages of the design process, to test possible ideas with a fraction of the costs. For this assignment I decide to use Processing to develop the prototype, which took me about an hour, and then Microsoft Teams to test it. Its advantage is that you can easily communicate your idea to the users and have it tested, in a much quicker manner and minimal risks, as there won’t be much effort and time put into it, while having the possibility to generate crucial feedback on the idea. The only possible con, similar to the other lo-fi techniques would be that the prototype may not fully reflect the idea, as an early prototype leaves room for interpretation, but as someone used to say (that I can’t really remember now) – if they like the idea when it’s poorly made (e.g. paper prototype) they will love it once it’s well made (or something similar to that, anyway).

Wireframing

Moving to hi-fi prototyping, I will start with wireframing, which in my opinion comes right after paper prototyping in the design process. Usually the next step after you decide on a version of the paper design is to start transcribing it into the digital wireframes. For my wireframes I decided to use Sketch as a design tool (and Adobe Illustrator to create the backgrounds) as it was the one I used the least out of the big 3 (Figma, XD and Sketch). The first version of my wireframes was ready after about 20 mins, while the 2nd version took somewhere around 40 mins, as it had added visuals. Wireframing is about the closest you will usually get to the final product without having to code, and while keeping costs (again, both monetary and time-wise) to a minimum. It has lots of advantages as it is an amazing resource for testing and receiving feedback, while being so close to the final product makes the feedback received, in my opinion, more relevant than say, paper prototyping. Also, depending on the complexity of the app you are trying to prototype, and the size of your team, wireframing an app or an website can take from 20-30 mins up to a few days, which although may seem like a lot, it’s much faster and cheaper than coding the app. Being digital also means that changes can usually be easily introduced to the wireframes. Its biggest disadvantage is that when using tools such as Figma, XD, Balsamiq or Sketch, even though visually the app may look close to final, when testing the prototype it still lacks that final, functional feel that an app has because of the limitations of such tools.

Microinteractions

There are also solutions for this, such as using FramerX or my personal preference, ProtoPie. This amazing app allows you to import your screens from the big 3 wireframing tools, so you can easily add microinteractions, conditions and variables in order to make it perform like a real app. It also supports json animations, sounds, and the use of your phone’s sensors to help you achieve that final feel that other tools leave you short of. In my prototype I decided to make use of animations for loading screens, sound and vibration to signal success, variables for remembering information input by the user (such as name or email) to be displayed later on, and conditions to set when, why and how any of it happens.

Microinteractions require a bit more time and effort than simple wireframing, but it can definitely be worth it, as it allows for more relevant and complex feedback on possible functionalities of your product, and another very important aspect that is usually overlooked – how does the product make the user feel.

A/B Testing

I left A/B testing at the end because although some designers use it at the same point in the design process as the wireframes, in order to test which layout or version works best, in most cases it is used by designers when redesigning a product, which I consider outside the initial design process, as when redesigning you don’t always need to go through the whole design process again (e.g. Google’s test in May 2019 to see if icons would help on the top nav bar of their search results page)

Conclusion

Overall, I believe I have learned a lot of new stuff during this course, new techniques but also got familiarized with new tools that I am sure I will use heavily throughout my career. I appreciated each and every assignment but I feel the paper prototyping assignment alone was not that helpful, as we previously did more complex paper prototyping as part of our Project Bespoke Design. Although it proved to be a foundation for the Audio prototyping assignment, that made it a bit more helpful than having it by itself. I do feel that audio prototyping could have been better paired with wireframing because that would allow for better testing both the wireframes and the audio feedback offered by the app, and that in itself would allow for more relevant feedback. Another suggestion would be though, if the paper prototyping and audio prototyping should be connected, the topic for the app should be something more static that would offer a more natural environment to test the app. This way the audio and paper prototype may be tested simultaneously.