Paper prototyping: The saga continues

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:

The third version of the “Cook dish” scenario

The third version of the “Cook dish” scenario

We will explain the scenario while going over the changes since version 2:

  1. On the first screen of the scenario, instead of an empty page with a search box, we added some suggestions.
  2. The second screen remained untouched.
  3. 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.
  4. 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.
  5. 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.
  6. Well, this is awkward…
  7. 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.

Advertisements

7 comments

  1. Are the fifth and sixth screen actually the same but with in the sixth there are two persons invited? ‘Cause otherwise it looks very confusing.

    The “Continue anyway” solution is a good idea, I think, otherwise you would get a lot of frustrating users that cannot continue use the app when they do not need a particular ingredient. For the problem that a user cannot choose which ingredients to use: you could add a database of ingredients, then a user could create a recipe himself and add ingredients from this list. But of course I understand this is an extra feature that can be added later on.

    1. Indeed, the fifth and sixth drawing are not really separate screens. They show one screen in two different phases: no one invited and Freddy invited.

  2. Something I’ve also replied to another team’s blog: maybe next time you should follow a more scientific approach of your test (stating the goal, method, etc. – as in the slides). Just saying because the prof expects us to do it more like that 😉

      1. We were going to link to that post for the full test results, but it seems like we forgot to do that. Post updated, thanks for reminding us. 😛

Comments are closed.