Group Members:

Brian Bell

David Kim

Justin Merritt

Problem Statement:

Going out to eat with other people can be a challenge in itself. Coordinating people’s culinary preferences, schedules, and locations is a hassle for any group of friends who just want the simple pleasure of having a meal together.

Specifically, we have identified three problems associated with forming a group to go out to eat.

    1.  It is difficult to tell who among your friends is willing to go out to eat.

    2.  It is difficult to tell when your friends are available to eat.

    3.  It is difficult to tell where your friends want to go out to eat.

We aim to create a mobile / web application user interface that simultaneously solves all of the above problems.

GR1 - User/Task Analysis

GR2 - Designs

GR3 - Paper Prototyping

GR4 - Computer Prototyping

GR6 - User Testing

  • No labels

6 Comments

  1. Not really a stretch idea but hopeful for a stretch design! Would have liked to see finer resolution of analysis per each user group. While characteristics of students and professionals may overlap, their incentives and perspectives are also very different, which should be noted. The task analysis is meant to understand tasks users have to accomplish from a higher level, not necessarily exactly how they should interact with the UI since this limits your creativity with your eventual UI designs. . No evidence of any interviews with representative users. Decent presentation, although would suggest making different headers different sizes to help convey hierarchy of report better.

    1. GR1 revised:

      Much better demonstration of insight and understanding of different types of users and their tasks involved.

  2. GR2:

    Invite, respond, select, broadcast Interesting diversity of designs, especially for date picking. Good insights on pros/cons of each design (for instance implicitly pointing out how second design doesn't really seem to deal with conflicts). Good side-by-side presentation of images and text. Good overall presentation, an "overview" paragraph for each design would have been helpful to point out rationale and focus.

  3. GR3:

    Good job exploring various ways to interact with your UI. Would have liked to see raw notes of observations. Not clear 6 users were tested.

  4. gr4:

    "Wiki presentation
    : Not enough detail as to what is shallow and not. 
    Fidelity: UI looks great so far, especially on phone!
    Usability: Confusing what highlighting of ""Family Dinner"" or ""Oishii"" buttons do, and why it's mutually exclusive. ""Create new meal"" button on home dashboard should be differentiated more to be easier to find. No ""save"" or ""submit"" button feels weird during input of event parameters. Also, expecting ""next"" button to advance to screens. 
    "
    "Wiki presentation

    : Not enough detail as to what is shallow and not. 

    Fidelity: UI looks great so far, especially on phone!

    Usability: Confusing what highlighting of ""Family Dinner"" or ""Oishii"" buttons do, and why it's mutually exclusive. ""Create new meal"" button on home dashboard should be differentiated more to be easier to find. No ""save"" or ""submit"" button feels weird during input of event parameters. Also, expecting ""next"" button to advance to screens. 

    "

  5. GR6: not clear how many users were tested. Otherwise, a thoughtful report. In general, while your final implementation does fit the definition of usable, it mysteriously comes up somewhat short for a "delightful" user experience (perhaps it could be attributed to the long wait times between screens). Nevertheless, I hope this was a great learning experience to understand exactly how important it is to include users early and often!