Fresh Byte Wellesley

Brainstorming

Our initial design direction came from our general preconceptions of the Wellesley Fresh App as well as from some interviews with Wellesley students. We wanted to improve the existing interface by making it more easy to use, accessible, and effiecint.

We each came up with some sample user groups within the Wellesley population and interviewed students that fit in each of those groups. Among those interviews there were common threads, which we as a team decided to focus on for the main direction of our project.

Contextual Inquiry

For the contextual inquiry part of the investigation, we each interviewed different Wellesley students. From those interviews, we were able to come up with some main takeaways:

Personas

Ivy is the "average" Wellesley student that uses the Wellesley Fresh app everyday to decide where she wants to eat. She enjoys having social lunches and dinners so she would often like to confer with her friends about where to eat. She eats healthy had has no food restrictions or allergies. She usually checks the menus on her mobile since it is more accessible and efficient.

Our team decided on this persona because she is a good representation of the user population we want to target with our user focused design of the Wellesley Fresh App.

Task Analysis

Our team came up with three main tasks the users would want to use the app for. One is to check the menus for a specific dining hall. Another common task a user might want to use the app for is checking the menus for nutritional information for food restrictions. Our last task was checking the app for general information on any of the dining halls or cafés.

With each of these tasks, we mapped out the details and steps a user would have to take to be able to complete the task. This process allowed us to gain a better idea of the flow of our final app design.

Domain Analysis

These are the areas we want to target with our final app design:

Scenario 1

Ivy is taking a MIT class that meets from 4-6pm. She took the 7 bus from MIT and made it back to campus around 7:30. She didn’t have dinner yet so she is very hungry and did not have time to eat earlier while at MIT. Ivy knows that the normal operating hours for the dining halls is from 5-7 so she is looking for a dining hall that is open late. Since she is a sophomore, she doesn’t know the hours of operation for the dining halls that have late night.

She uses her phone to open the app to read about the general information about the dining halls to learn about which has late night and how long they are open till. The app tells her that Lulu and Stone Davis are open for late night from 8-10pm, so she knows that she can get off at the Lulu bus stop and get food pretty quickly.

Scenario 2

During the week, Ivy prefers to eat lunch with her friends. She wants to find a place to eat that works for everyone that is also close to the academic quad as she has class in Pendleton in 45 minutes. She wants to look at several dining hall’s food options to see which one has the best food.

She decides to look only at the menus for Tower and Lulu as those are the closest and most convenient. She takes a screenshot of the Tower menu and the Lulu menu and sends both to her friends’ group chat. After one of her friends notes that Tower has Chicken parm, her friends unanimously agree to go to Tower.

In Class Design

We came up with two different design directions in P2. Design 1 focused more on the feature of comparing menues of different dining halls. Design 2 was similar in structure, with a more detailed feedback page and a different flow of inserting data.

Our team decided to follow more along the lines of Design 1 in order to have a design that better suits our persona. However, we are pulling some elements from Design 2 like the more detailed feedback page. Our final design direction is to have the app focused on simplifying the navigation and the comparison of menus across dining halls.

Risky Interactions

1. One risky interaction is the frequently used feature of the Wellesley W in the top left corner of the app screen. The user has to use that icon many times in order to navigate through the app and sometimes is the only way of navigating back.

2. Another risky interaction is having to choose the date first as users might frequently be looking the day of. However this could also be from the novelty effect because after long time usage of the app, the flow of input should be more routine.

High Fidelity Prototype

The next step in the process was to iterate over our first prototype. We decided to refine our original prototype and create a new version. In this version, we changed the flow of the app. Choosing a date was a bit confusing in the first interation of the prototype, so in this version the prototype skips the step of choosing a date and goes directly to the menus for the current day.

Usability Testing

Our team created three user tests on the second iteration of our prototype. Each of these tests had the same three tasks, same required user demographic, and some post-task questionnaire.

Task 1: Check the breakfast menu for Bates Dining Hall.
Task 2: Check the dinner hours for Bates Dining Hall.
You know you have a lot of homework, so you want to plan ahead for dinner. You want to make sure Bates is open at 5 o'clock pm today.
Task 3: Write a Review.
You just finished eating dinner at Bates and noticed that some of the meat was undercooked. You feel rude telling the chefs directly, so you use FreshByte App to leave an anonymous review.

User Demographic:
Age: 18-25
Web Expertise: Average
Language: English

Post-Task Questionnaire:
1. What frustrated you the most about this app?
2. If you had a magic wand, how would you improve this app?
3. What did you like about this app?
4. How likely are you to recommend this app to a friend or colleague (0 = Not at all likely and 10 = Very Likely)

Usability Testing Takeaways

Overall, users agreed that the site was functional, simple, and served its purpose of helping students to navigate their dining options. Features users liked about the app included that the hours and menus were easy to find in the dropdown, the little icons indicating dietary restrictions, and being able to see the menus for different days. However, there were also many critiques, which are outlined below:

“Cookie Cutter Website”:Two users critiqued the site for being overly simplistic and generic. One user said, “the site seems a little bland,” and another user said it looks like a “cookie cutter website,” citing the color scheme and the lack of images. The first user suggested adding a mission statement on the landing page, and the second user recommended adding more pictures of the dining halls and the food, and also perhaps personalizing the experience more.

The “General” Section: Several issues were brought up in relation to the “general section.” User 1 said that it was “confusing,” and that all the options (Write a Review, Dining Hall Guidelines, etc) should be listed directly in the main hamburger menu, rather than hidden in the obscure “General” section. Another user wishes there was a simple “back” button for forms pages in the General section, so that they could easily return to other pages in the section.

Not fully functional: The remainder of the comments were about the site not being a fully functional prototype. For example, users were frustrated that they couldn’t select the dates on the calendar, and that not all the tabs or dropdowns opened up.

Final Iteration

After collecting all the feedback from the user testing, we were able to compile a list of three key recommendations to implement in our final iteration of the prototype.
Change 1: A way to backtrack from the form pages
Change 2: Implement more screens of the app
Change 3: Add more photos and make the app more specific to Wellesley.

In implementing these changes, we were able to create our final iteration of the prototype which can be found here: PROTOTYPE

Group Reflection

From this project, our team has learned a lot about the steps involved in creating a good user designed app. We also learned a lot about working as a team, especially the difficulties that come from working remotely from different time zones. We found it very helpful to keep in constant contact via Facebook, which also helped us coordinate weekly Zoom calls to go over the work that we completed and needed to finish. It was difficult to find time to meet with everyone’s very different schedules and timezones, but we were able to still find some times that worked for everyone. If we could take this project forward, we would want to be able to implement a working prototype of the app, that is not on InVision, one that we can release to Wellesley students. Due to COVID-19, a lot of unexpected difficulties arose, such as delegating work evenly and coding remotely. However this experience has taught us a lot about how to successfully work as a team, in person and remotely.