Prototype Photos

The following are photos of our second prototype. The app only provides one sequence of tasks, which users must follow in order to arrive at a final restaurant decision.

Please view the photos starting from the first row, going from left to right and then proceed to the second row.

Briefing

Can’t decide where to eat as a group? Play Dedice --- An interactive social decision-making game for dining out. Dedice will help you decide with “dice”, but with a twist. The randomness is weighted, so instead of blindly choosing a restaurant, Dedice will pick a restaurant for you based on the weighted preferences of location, price, and cuisine type that each player individually bets on. It’s fair. It’s fun. It’s Dedice!

Scenario Tasks

1) Pick Criteria Choices: Pick a couple of choices for location and cuisine type.  You are all sharing one phone.

• For location: choose Kendall, Central, Harvard, and Chinatown. 
• For cuisine: choose American, Chinese, and Indian. 

...

4) Vote on Restaurant: Vote on the restaurant choice that you like the most.

Observations

First Prototype

Learnability

Betting concept was not completely clear

...

• Some users didn't notice or understand what individual transition labels (e.g., Person 1/3) in the betting rounds meant. This could have been caused by inconsistent terminology, as we used "Person" and "Player" (e.g., "How many players are in your group?" in initial screen) to refer to the same thing. 
• Some users didn't understand what the criteria labels (e.g., "Criteria 2/3)  in the betting rounds meant. We never explicitly referred to location, price, and cuisine as "criteria", so the word may have seemed random.
• The "+" button for adding criteria was placed on the top-left side of the screen, where the back arrow is usually placed. 
• The list of cuisine and location were not ordered in an obvious way (e.g. alphabetical).
• There was inconsistency between "Done" buttons and next arrows. 
• Many users didn't understand what the percentages meant on the choice wheel during the criteria decision rounds. 

Efficiency

Some convenience features were unnoticed (e.g., the "+" button on add-(location, cuisine, etc.) screens)

...

• Many users felt that there were too many criteria selection and criteria betting rounds. This made the decision-making process too long.
• Users had to perform some mental math to figure out how to distribute their 100 chips within and across criteria. 

Safety

Certain combinations of criteria have no restaurant choices

...

• The app did not inform users that their choices were not saved when they used up all their chips. One user kept betting chips and assumed his choices were being saved. 
• The app displays a list of restaurant choices to vote on before the final voting round to provide users with more information about the restaurants they will choose from. However, some users incorrectly thought that this was a list of final restaurant choices and did not bother to proceed to the final voting round that would generate a single restaurant choice. 

Second Prototype

Learnability

Betting concept was much more clear

• Better visual metaphor, more akin to a real gambling setup (e.g., craps or blackjack table, with spaces to place chips). 
•   affordance of dragging individual chips (as opposed to stack) more apparent. We provided "chips" for users to move at the bottom of the screen.
• Color-coded chips made the percentage labels on the choice wheel more meaningful. People mapped
• Explanatory labels ("Drag chips to choices above to show their relative importance to you") made the purpose of the betting task clearer.
• Users better realized that chips Users better realized that coins were split among the three criteria, because they were presented together all on one screen. 

...

• Same problems as with the first prototype.  We We should add full-screen indications that the app is switching between users, or from group to individual mode.

...

• The screen showing restaurant choices and providing restaurant info does not allow voting, and this was not clear. In the next iteration, we can combine these two screens into one. 
• It's not clear why the group suggestion-making interface exists: users . Users are allowed to make only one choice for each criterion, so it is not clear why the group can make an arbitrarily high number of suggestions. It is conceivable that the initial group selection stage could be removed entirely. 
• (Same as in prototype 1) Some screens use right-pointing arrows, and some screens use "Done" buttons.

Efficiency

Some convenience features were better noticed

...

• The restaurant choices/info screen and the restaurant voting screen are separate, when they could logically be combined: this results in more screen transitions than necessary.
• The process was shorter than for the first prototype, but is still too long. The initial phase of selecting criteria choices for location, price, and cuisine seemed long and may not even be necessary. For example, we can replace the list with an automatically generated list. This would skip the initial step and allow users to start off in the betting stage.

Safety

Certain combinations of criteria have no restaurant choices

...

• We informed users in the briefing that they were all sharing a phone. 
• We provided explanatory labels hinting at task purpose, so users were more likely to perform tasks properly (e.g. distribute betting among three criteria at first try instead of through trial and error).
• Users could actually see that they were betting on each of the three criteria, and they knew more easily that they were using coins for betting on all three criteria and that coins are shared among the three.

Prototype Iteration

These are the changes we made between the first and second prototypes: