Welcome to TasteBuds! TasteBuds is a mobile social web-application focusing on trying to enhance the Wellesley College students’ dining experiences. The application has a number of features that promote this more social approach to dining including: checking in, reviewing food, sending messages, checking menus, being notified when a food you like or would like to avoid is being served, etc. Have a good time eating and socializing with your buds!
Pilot User Summary:
Pilot users found that some of our application’s features were unclear, and two in particular stood out. One was that on the messages page, the purpose of the “refresh locations” button was confusing because it wasn’t intuitive that it would update with a list of dining halls ranked by dietary preferences and restrictions. Another was that some users would try to find their friends on their Buds page to send a message rather than going to the messages option on the menu bar. From there, they were confused about the time stamps of when their friends checked into a dining hall.
User Testing Summary:
After changing our application’s list of dining hall rankings in the messages page to automatically update with preferences as soon as the user entered a friend’s name rather than using a button, we found that users were still confused about the list of dining halls. They thought that the radio buttons were there for them to select a dining hall, and thought that they could even select a dining hall before typing in their friends’ names. Additionally, some users tapped the Check In button rather than the Menus button to check a dining hall’s menus.
Pilot User 1:
- User was confused about the difference between starting a group message through “New Message” and “Group”
- Suggested giving allergy cautions instead of greying out options
Pilot User 2:
- Hesitated before finding the Menus button on the menu bar
- Confused about swipe left/right vs. scroll up/down
- User included where to go in the message area instead of using suggestions
- Suggested having location+time priorities instead of just dietary restrictions
- Suggested combining check in/status and photo options all in one
- Suggested having dining hall locations refresh upon typing in friends’ names
Pilot User 3:
- User indicated that it was clear how to post a status- similar to Facebook
- Suggested showing meals according to time (ie breakfast in the morning, dinner at night).
- Confused about “refresh locations” button
Pilot User 4:
- On Tower menu page, scroll vs. clicking unclear
- Tried to find friends first on Buds page to send message
- Unclear about “refresh locations” button
- User was confused about checking menus and checking in features (use of the word “check”?)
- Confused about where to find menus (menu button not clear)
- Confused about how to send a message- user went to buds page
- Didn’t set time in messages
- Made use of the “timed” check-in option before posting
- No “find menu” confusion
- Ranked dining halls in messages unclear
- Didn’t set time in messages
- No menu/check-in confusion
- Made use of “timed” check-in option before posting
- No confusion about checking for dinner within menus page
- Click message icon on bottom to send message (didn’t go to buds page)
- Confusion on messages page- looked for existing message rather than writing a new one
- Ranked dining halls in messages unclear- didn’t realize that options came up automatically and tried to select one.
- Didn’t notice the warnings next to dining hall rankings
One of the main things we changed was on the homepage users used to be able to post a status, check in to the dining hall, and post a picture, however this caused some confusion amongst our pilot users who thought that checking in needed to be more like a status post negating the need for statuses. In the new version of our homepage the top menu bar only includes a check in and share photo options. By changing these features we also needed to change our tasks, our first task was to post a status onto the budfeed, but after editing the homepage status no longer existed and so the task was changed to checking in to the dining hall.
Pilot users were also confused by the buds page, particularly the timestamp of when their buds last checked into a dining hall. We addressed this problem by making two changes. First in the check in option on the homepage, we allowed users to specify the amount of time they were going to be at the dining hall. This would be reflected in their friends’ bud page. Secondly the timestamp no longer says the time of check in but the remaining time before the user’s bud leaves the dining hall.
Another change that we made was on the New Messages page. We moved the dining hall options and time specifications above the message text input box. The list of dining halls will update immediately after the user specifies the recipients of the message. Originally dining halls that were serving food that someone in the group was allergic to would be greyed out and unselectable, however some of the pilot users pointed out that they would like the option to still go to those dining halls with their friend and that there are other foods available. In our edited version we allow users to select those options but give a clear warning.
The bottom menu when the tab is selected should be a different color to draw the user’s attention to the page they are on and help with the readability. In the new messages page, it was not clear that they have to set the time of the meetup. Additionally, above the list of dining halls, we would add a description saying “Dining hall recommendations based on group preferences” because we discovered that some users thought they should just choose a dining hall since they were unaware that the application would automatically update and rank the list of dining halls. Another way to help users become familiar with and learn to use the application’s features is to give new users a short tour after they make their account.