GR6: User Testing
Design
In the end, we decided that the white pane layout best illustrated our step-by-step food ordering process. We grouped together all of the pre-order steps on one page to really show how few steps the user needs to take in order to get begin a food order. Lastly, we decided to put food in the background, because not only will it spark an unsure user's appetite, but if this were a small business, we could use this as advertising space for restaurants in the area (they could send us high-resolution photographs of their menu items, pay a small sum of money, and we could "feature" these food items).
For this panel, we knew we had to implement some sort of search and ordering, as there are many restaurants in a given delivery area. However, our computer prototype exposed some design problems that had gone unnoticed. For example, we wanted to highlight the background of selected restaurants, as well as dynamically highlight restaurants when the user hovered over them. However, we never made a distinction between hovering over a selected restaurant or hovering over an unselected restaurant. So, in our final product, we chose two distinct highlighting values. In addition, we also noticed that on the food-ordering sites we were using, restaurants were often listed under multiple categories. Therefore, we made the decision that if a user selected, for example, "Chicago Pizza" under the pizza category, the corresponding "Chicago Pizza" in the American category was also selected.
For this panel, we wanted give the users the flexibility of either inviting Facebook friends or sending a mass e-mail out to a list (or inviting non-Facebook friends). Who is logged in is prominently displayed so there is little chance for a mistake. In addition, the "Add Friends" box for Facebook utilizes the exact Facebook way of filtering/choosing friends, so this offers users a familiar experience. We direct people to enter friends' emails with a grayed out cue in the correct box.
Though there were suggestions to cut this panel and merge it with the add friends panel, we decided to keep this panel both to avoid clustering and to provide the users with a fairly large and obvious continue button. In addition, the third panel was more aesthetically pleasing with regards to the overall layout.
If the initial user didn't narrow down restaurant selection to one restaurant, this page is the next one that comes up. We debated a lot over how the site would behave depending on how many restaurants the organizer selected. In the end, we decided that if the user selected only one restaurant, then they would be taken directly to the ordering page. Otherwise, they would be brought to this voting page setup.
We initially had two radically different ideas regarding the voting system. One was very similar to how Doodle operates, with a binary voting system (the one we ended up choosing). The other was a "up-vote" "down-vote" system similar to reddit. We eventually decided to incorporate the Doodle system, as it was the most straight forward for the users. In addition, this part was the most difficult to display using our layout. During our computer prototype, we only showed two restaurant possibilities. As one of our classmates pointed out, this design wasn't feasible for scaling. In the end, we decided to implement a scrolling display. Unfortunately, this does cause a significant decrease in visibility. However, we want to give our users the most flexibility in restaurant selection (ie, not limit to only 5), and given this, a user can ultimately select all 30+ restaurants, we needed to have some sort of scrolling display. Lastly, only the organizer can see the "choose" buttons, so there is little in the way of confusion.
This was also another box that we had some trouble designing, as there wasn't enough room on the screen for both aspects. We wanted the social aspect of the chat box, but at the same time, the organization aspect of the order box was also necessary. However, we realized that people probably wouldn't be analyzing their total cost and talking to people at the same time for the most part. Therefore, we combined the two into one tabbed box that defaults to the chat. In addition, we also send order messages to the chat box ("foo has ordered bar") to alert others that there are orders taking place, as during the paper prototype testing we found that some people didn't quite understand that everything about this site is social (including the ordering), so we wanted to take no chances with someone not seeing who has ordered what.
Because restaurant menus have such a wide range of sizes, we also had some difficulty designing how to display menus. We wanted to utilized the predetermined categories, but we were unsure how to display the menu in a way that was aesthetically pleasing with respect to the rest of our site. Eventually, we decided to do the tabs on the side of the panel, with the items on the right (with dropdown accordion for options). However, after the computer prototype we later found that we still had a size issue (and a color issue). Therefore, we changed the background to its current color (white), and added a hover background color for the items. As for the size, we also fixed this one with scroll bars for menu items and menu categories where needed.
In addition, during paper prototyping, users were having trouble figuring out when their friends were done ordering, and many often pushed the order before their friends had finished ordering. Therefore, we decided that we needed a means to make it very visible when someone is done ordering. Therefore, we added this bottom paned with icons for each person. Initially for the computer prototype, the bar was subtle and contained all of the Facebook photos of the people in the order and grayed out text that turned white when the person finished. However, users of this prototype pointed out that there was nothing to draw their eyes down to that part of the screen, and that the change was far too subtle. Therefore, we changed it to the current red X/green checkmark.
Implementation
Outline:
Implementation
Ruby on Rails
Problems:
Campus Foods/Foodler problems
Multi-user syncing problems
Consistency problems
Evaluation
Briefing
Hungr is a way to order food with friends. It allows you to arrange a group order collaboratively, giving your friends input into choosing the restaurant and allowing them to order their own food.
Tasks
One user was told to create an order and invite their friends to order "Asian" food. The other two users were told to accept the invitation.
No other information was provided.
Issues (in mostly chronological order)
Problem: User wanted to enter more than one email at once on the invite screen.
Severity: Cosmetic
Solution: Allow entering multiple e-mails at once, separated by spaces or semicolons. Indicate as such on the interface.
Problem: On the first, organizational page, the current restaurant selections are hidden by scrolling or searching.
Severity: Major
Solution: Allocate (dynamically) a box beneath the search section that displays current restaurant selections at all times.
Problem: A user was unsure that their votes on the restaurant selection page were being propagated to the other users (and didn't notice the other users' votes appearing). "How do I vote?" she said, after clicking a few of the checkboxen. The other users were able to identify the process, though, so this is possibly due to unfamiliarity with "web 2.0" interfaces.
Severity: Minor
Solution: Indicate other users' votes through color changes and on the voting panel and the count on the bottom. Do the same thing for your votes. Hope that this conveys the information.
Problem: Users are unable to indicate that they are done with voting.
Severity: Minor
Solution: Add a button to allow users to show that they are done (more on this later).
Problem: Users are sometimes unsure what happened when the screen transitions from one section (e.g. voting) to the next (e.g. ordering) through an event outside their control. This happens when the organizer chooses a restaurant.
Severity: Minor
Solution: Add a modal div explaining to users why they are transitioning. Announce the restaurant choice in that div.
Problem: There is minimal feedback when ordering items. This increases the chance of mistakes.
Severity: Major
Solution: Provide an "active" style for the menu items such that it is obvious when one has purchased them. Also indicate it on the order/chat tabs, possibly with a number indicator on the order tab.
Problem: The name for the current user (the one you are, e.g. "cmerrill") is displayed when ordering items, but "You:" is displayed when chatting. This is inconsistent and possibly confusing.
Severity: Cosmetic
Solution: Either show the username for both actions, or show "You" for both. Just be consistent.
Problem: It wasn't obvious to most of the users what the icons in the bottom left (the "done icons") were meant to indicate until they noticed one of them change to a check mark.
Severity: Major
Solution: Possibly place a user list on the right, rather than the bottom, and make the icons higher-contrast so that the X's and check marks are more clear.
Problem: Organizers were unsure as to how they could indicate that they were done.
Severity: Cosmetic
Solution: Replace the organizer's done icon with a different one, e.g. an "O" or a crown, to make it distinct that they have control over the whole thing and don't need to indicate when they're done.
Reflection
From this project, we learned a great deal about the design process. Initially, we had many problems adhering to the prescribed process. We often found ourselves arguing about later details in the earlier assignments. For example, we were discussing implementation during GR1, and fonts and aesthetics during GR2 (as well as GR3). In addition, we were often reluctant to scrap already made ideas early on (though in the end, we did change our entire project idea after GR1, which was honestly one of the best design decisions we made). Once we focused on the current tasks, however, the design process ran smoothly and there were far less tensions among the group.
In addition, given that we were implementing a multiuser interface, most prototypes were very difficult. We had many problems simulating multiple users during the paper prototype (and never quite found a way to do so effectively). Therefore, most users didn't fully understand the social premise, so we didn't get as much useful feedback as we could have from our paper prototype (other than the fact that we weren't very good at representing multiple users). Therefore, during our computer prototype, we had to spend a great deal of extra time simulating multiple users. However, this time, that decision paid off, and we gathered a lot more useful feedback from our computer prototype. However, we were still hindered by our lack of menus and pricing, so we got a lot of feedback about our quickly thrown together menu simulation.
Lastly, our final product had many issues due to trying to synchronize multiple users. In a more ideal world, we would have had more foresight into the potential problems and had allotted more time for solving these problems.
If we were to do this again, we would put a great deal more time towards providing more representative simulations of our project, so reviewers/testers can put more time into reviewing our ideas, rather than our faults in our simulation. In addition, we would have been more productive had we embraced the design process more. Therefore, if we were to do this again, it would be more beneficial for us to follow the prescribed plan rather than to argue about details too early. As we later found out, it most important to have a solid, well thought out, and documented plan from the first GRs.