Week 1 – Paper Prototyping A Coffee Ordering Tablet App
In week 1 of the HCID 510 Prototyping Studio class, we were given the following creative brief for a paper prototyping exercise:
- Allow the following drinks to be chosen (all the rest are completely ridiculous):
- Espresso ($1.50)
- Macchiato ($1.75)
- Cappuccino ($2.00)
- Allow (although this pains me greatly) the following sizes:
- Normale (base price)
- Grande (add $1.00)
- Gigante (add $5.00, this should be vietato)
- Do not, under any circumstances, allow heinous substances like caramel or white chocolate (what is that, anyway?) to be added to a perfectly good coffee. Issue a severe admonishment in that case, clear the current order, and force the user to start over. Mamma mia!
- Allow multiple drinks to be ordered with a single submission.
- Request a confirmation of each drink before adding it to the current order. (If you have time, you can allow modifying a drink order.)
- Calculate and display the total amount of each drink and of the total order.
- Issue a confirmation of the total order before finally sending it to the barista.
Our group, which consisted of Nina W., Alma E., and myself, began the the prototyping process by brainstorming and sketching/mapping out the user flow (or one could call it a primitive version of the customer experience journey map) for the tablet app. Once we have the high-level draft of the user flow, we immediately dived into paper prototyping. We started by creating a few tablet/iPad templates on a few sheets of legal size printing paper and various application elements such as icons, menus, buttons, toggles, and windows using Post-it notes.
Wherever possible, we tried to make these paper & Post-it components re-usable and created a few duplicate copies.
Given that this is a mobile application, we established a few principles in our design considerations from the onset: simplicity, clarity, and speed. We wanted to take users/customers through the ordering process with as few screens as possible. Nina came up with the idea of the pop-over menu upon clicking on any of the drink selections in order to select the drink size. This eliminated the need for a dedicated screen just for selecting the drink size.
Once we had the design for the initial drink selection screen, the rest of the screens came together rather quickly. The re-usable paper components really helped us iterate through ideas quickly and enabled us to redesign screens and re-arrange controls on the fly. 30 minutes after, we had created the rest of screens for the entire user flow:
We ran the initial prototype design through a round of user-testing with our class TA and she was able to quickly identified a problem with ordering multiple quantities of a same drink. Our design required the customers to repeat the same ordering process (going back to the homepage, selecting the desire drink type & size, and adding to the order) to add the same drink each time. We gave the user interaction some further consideration and iterated a couple of different approaches and finally settled with a scroll-menu for selecting different quantities for any given drink.
We conducted another 5-6 rounds of user testing with the modified prototype design and was further helped to see the confusion that some users had around the checkout and confirmation sections of the app. We were able able to make some quick enhancements by re-thinking the screens, re-arranging the paper app components, and re-validating the changes with further testing. We were very satisfied with our final design by the end of the class.
Here are a few things that I learned through this prototyping exercise:
- Based on the feedback we received, we should’ve given the medium (in this case, a tablet) format some further consideration and leverage the screen real-estate better.
- Paper prototyping was very effective in allowing us to iterate through and validate different design approaches rapidly.
- While it may be somewhat cumbersome in needing to create multiples of the same paper components, it still requires less time and effort than other higher fidelity prototypes.
- It’s difficult to anticipate the various combinations/permutations of user scenarios. However, each round of user testing provided us with further insights into what user cases/scenarios we should focus on.
- There seem to be two types of user testing: one type that provides the users pre-defined/scripted tasks and another type that gives the users the freedom to test the prototype however they want. Both are useful in providing specific insights to the design.
- Paper prototyping has a very low learning curve and requires low-cost materials. Any team can easily adopt this practice in the initial stage of the design process.
- Paper prototyping seems very effective specially for software and application design. I definitely would like to make paper prototyping a part of my design toolbox.
Here is to more happy paper prototyping in the future!