Today I created and tested my first paper prototype. We ( me and my other two team members) spent three hours with glue, sticky notes, chart paper, colored pencils and other office supplies to create a working prototype for Unicorn Tea Bubbles, which serves bubble tea of different flavors and customisations.
We started out by determining our platform – did we want this to be an application stored on the user’s phone or would it be a tablet installed in a kiosk at the shop. This would affect a lot of interactions such as storing favorite drinks and personalization of the application. We decided to build for a kiosk as none of us had worked with a public interface before.
The next step was to identify the set of tasks that the user might want to enact.
- Select a pre-built drink
- Build his/her own drink
- Change quantity of drink
- Add more drinks to the order
- Pay for drink
- Add tip
This task list guided our sketches of the interface. We worked out what information would be present on which screen, followed by the sequence of the screens. This forced us to think about navigation – should it be forced ( where the user can go only back and forward) or free flowing? Since the interface we were designing was exploratory ( the flavors would appear only on the flavors screen and not beforehand) we decided to do a mixture of free-flowing and forced. We added a ‘Next’ and ‘Back’ button, in addition to the button for ‘Cart’ and ‘Home’.
It was then time to design the visual aesthetics and proportions for each screen. Keeping the fun, light, playful theme of the company in mind, we decided to add animation to the screen (the cup fills with a different color at each section depending on selection, see picture below).
Once we had decided the screen layouts, we built the paper prototypes and tested it out on three users. The process involved giving them a specific task of ordering a tea with x flavor, y bubbles, z size. We split the team into facilitator, observer, and helper. I played the role of the observer.
All three users forgot to press the ‘Next’ button, often waiting for the screen to change on its own. This is probably a result of our conditioning as users when screens ‘understand’ when to change. The second point we observed was an issue with the wording ‘Customize your drink’. The task listed it as ‘build your own drink’ so non-native speakers had difficulty in identifying the correct button. A more glaring gap we discovered during this exercise was that we didn’t offer any method of editing a drink. The user had to delete the current drink and rebuild the entire order.
Thus, we ended up discovering feature gaps, wording confusion and navigation problems in addition to small changes suggested by our users.
This whole exercise helped me understand the value of reiteration. We iterated over our design after each test users and we could still come up with new flaws in our design with the next user. The flaws did become smaller and finer over the course. Thus, we constantly improved our design.
I wonder how many testers are too many though? At what point do the changes stop becoming improvement and start becoming personalization? Also, should the suggestion be weighted by the number of users who suggested them? If everyone has a problem with an element then it needs to change but what if only 30% of the people have a problem? I guess I’ll know this with practice!