Since our last post on our paper prototypes a lot has happened. In the session of week 4, we tested version 2, started on version 3 and tested it. Afterwards we had another two tests of version 3.
Ladies and gentlemen, I give you the third version of the “Cook Dish” scenario:
We will explain the scenario while going over the changes since version 2:
- On the first screen of the scenario, instead of an empty page with a search box, we added some suggestions.
- The second screen remained untouched.
- We moved the choice for a meeting time to a separate screen. This makes room for more information on the selected dish, e.g. ingredients or, in a later stage, nutritional value.
- The next screen allows for the choice of a meeting time. Instead of choosing a particular time, the user can now pick some hour-long time slots. This makes it easier to find a timing that works for everyone. We also added the choice for a date: today or tomorrow. More options could result in essential ingredients being lost.
- The next two screens are used to select partners to cook and eat with. They weren’t changed (much). Professor Duval gave us a tip: if an ingredient can’t be found, the user could post that on Facebook. This would allow him to find the missing ingredient, and it might attract new users. We will keep that in mind for the next version.
- Well, this is awkward…
- On the last screen, the user can choose a time slot if more than one are still possible (after the invitees had their pick). The location is shown, as well as what the user should bring. We also included a check box to add the appointment to the users calendar.
We tested the new design with 5 test subjects, the full test results and evaluations are in a separate blog post. They seemed to understand what was meant with the time slots, but didn’t always select all of their available time slots. They all appreciated the “Add to calendar” option, so that’s a keeper.
This will probably be our last version on paper. We started with some screens for other scenarios (managing “My Fridge”), but since speed will be of the essence there (adding and removing ingredients will probably be something the user want’s to finish asap) we decided to skip the rest of the paper prototyping for these scenarios.