This week, in teams of three, we were tasked with designing and testing a tablet application for ordering coffee at the MHCID Studio cafe. The app had to support the following:
- multiple drinks options in multiple sizes
- a confirmation of each drink before adding to the current order
- an option to modify a drink order
- calculation and display the price of each drink combination & total order
- issue a confirmation of the total order before finally sending it to the barista
With these criteria in hand, our team began to quickly sketch both the user flows and basic UI designs we imagined. This helped us to build consensus around what we each envisioned. We chose a focus on the specific scenario of ordering drinks after getting situated at a table rather than at the register.
After our initial sketches, we began building and testing our paper prototype.
What I learned from the process:
- Just start… the quicker you have something out of your head into the world in the form of something tangible, others can react and provide feedback. Showing provides a richer experience than telling.
- You should alway be thinking about scale and information hierarchy. In most cases, you’ll have limited screen real estate, so there are always tradeoffs in terms of what can be shown at each step. It’s necessary to think about the goal you want to accomplish at each step of the process.
- Labels matter. “Add” versus “Confirm” mean very different things to users. For example, even though we intended for “Add” to mean that the user was confirming and adding their drink choice to their overall order, users were interpreting “Add” as increasing the quantity of the same drink choice to their order. These are subtle, but important difference. We were able to adjust along the way.
- The most challenging thing about paper prototyping was staying organized during the testing process and recreating simultaneous actions so that the testing experience could actually simulate the intended interactions. It was also challenging to replicate some dynamic interactions such as swiping and scrolling at such a low fidelity.
Pros & Cons of Paper Prototyping:
- Paper prototyping allows you to incorporate feedback immediately. There were certain points in the interaction that we realized users were struggling, so we were able to quickly change the interaction and retest.
- Paper prototyping is fast. In a matter of a couple hours we were able to create & test multiple ideas.
- Paper prototyping is cheap. With just some basic office supplies - paper, pens, postits, markers, you can design and test an application.
- Paper prototyping is fun. The process itself helps you think through the process. Often times, you don’t realize there is a gap in your thinking until you put it out there and are able to reflect back on it.
- Paper prototyping encourages collaboration. Since the barrier to participate is low, it’s easy to get anyone involved in the process.
- Paper prototyping can be applied to many different platforms - smart watch, smart phone, tablet, or desktop.
- Some interactions are just difficult to replicate in an elegant fashion using paper prototypes.
- It is difficult to share with people that are not physically present.
Overall, paper prototyping is extremely useful in the design process. It provides a quick and dirty way to get your ideas out quickly, so that you can test, update, modify and iterate quickly at a low cost. There are also many different kinds of paper prototyping techniques, your imagination is the limit. There isn’t a right or wrong way to prototype as long as you are learning something in the process that is leading you closer to what you set out to accomplish. Personally, I found it extremely helpful to also see what other teams were working on and the techniques they used because each approached the challenge differently.