Results of Session 4 (and beyond)

Based on the test results from the previous session, we had a third version of the paper prototype ready to go at the start of the 4th session.

Paper prototype: iteration 3

Goal: We want to know if our users are able to quickly find a dish, select time slots and find cooking partners. Finding a dish, as we learned from the previous two iterations, was easy. Selecting time and place on the other hand needed some refinement.

Method: We ask our test users to fulfill a certain goal by thinking aloud. The goal is to make spaghetti this evening. Unfortunately you don’t have all the ingredients so you have to find partners who you can cook with on Social Fridge. You also have soccer practice that evening between nine and ten.

Rationale: We could of course implement the whole thing and then observe people testing it, but you know the story. So no real other alternatives so far and Paper Prototyping just seems the way to go for now (cheap, fast and easy to modify, etc.).

Who, what, where: We got several testers from the same class room, of course following the same (HCI) course. This week (on Tuesday) we had two more people testing our third version from the foyer of building 200A (who don’t follow the course). All subjects were students, except maybe for professor Duval,  at the CW Department and male.

Results: A selection of useful observations:

  • People couldn’t find Spaghetti Bolognaise in the suggestion list.
  • People picked too few available slots, when only the 21-22 slot (soccer) should was unavailable.
  • One subject thought he could choose multiple time slots on the last screen.
  • One subject chose “Add Dish” at first to make spaghetti, but it’s already in the application.
  • The inital list of ingredients for spaghetti was clear for everyone. “V” = I have this in my fridge, “X” = I don’t have this in my fridge.
  • Finding and inviting partners went quite smooth for most of the test users.

Conclusion: These are our main remarks:

  • Choosing time slots is tricky. We want the user to select as many time slots as possible to increase his chances of finding available cooking partners. A default chosen “V” or  a default unchosen “X”? On the other hand, if a time slot is mistakenly picked, the user might have to blow off the meeting after inviting people. A three state switch also belongs to the possibilities, which has an extra initial state “?” that makes the user explicitly decide for each time slot.
  • Replying to invites can take a while. And our test persons weren’t always aware of whether the ones they invited had confirmed or not. So users should probably get a notification when a partner replies.
  • Being limited to the proposed ingredients is unhandy. This goes both ways: not being able to ask for extra ingredients you want to use and not being able to continue if not all ingredients are available. We won’t solve the first issue (yet). The second one can be solved by adding a button “Continue Anyway” or by allowing the user to post his request on Facebook.
  • The final screen might be a bit confusing in terms of picking a final and single time slot to meet/cook.
  • Everybody liked the “Add to calendar” option.

Next up: digital prototype

Our next goal is to build a digital prototype, which Mattias started working on this week. We’ve already got the login with Facebook working, go check it out!



Comments are closed.