P3: Paper Prototypes
Bake & Barter is an application designed to facilitate the baking process at Wellesley College. Baking, or cooking, on campus can be really difficult because you often do not have the ingredients or supplies that you need, you do not have a good way to dispose of leftovers, and you may not have the baking knowledge that you need. A baking culture does not exist at Wellesley, and there is currently no way for student bakers to connect with each other.
The goal of Bake & Barter is to serve as a resource to connect bakers and create a baking community. Once bakers are connected, they can share ingredients, supplies, recipes, and advice. Ideally, Bake & Barter will be used to enhance the student baking experience at Wellesley.
The following tasks were used with our non-class users. They were revised after our initial pilot testing.
Search for eggs. Filter by price. Select barter. Complete exchange.
Search for a recipe, specifically a dessert recipe.
You receive a notification. Reply to the message from Lender Laura.
You’ll be posting ingredients and supplies. You will be posting eggs for $2 and a baking sheet for barter.
Update your profile. Change your dorm and picture.
Observations and Resolutions
During our pilot testing with fellow CS220 students, we provided users with tasks that directly corresponded to the tasks within our three scenarios. However, this choice meant that some individual sub-tasks (such as posting or looking for an item) were being completed in multiple tasks given to users. We realized that by giving users multiple sub-tasks at the same, our users were occasionally confused about what we wanted them to do. Therefore, we revised the tasks that we gave to users, as included in the section above. These revised tasks were simpler, and did not contain nested sub-tasks. They do not correspond directly to any one scenario, but collectively encompass all tasks needed to complete our scenarios. Because we revised these tasks, the pilot observations below are not organized by task like the non-class user observations.
The following observations have been grouped by similarity:
- After users posted an item, it was unclear to which screen the application would take them. Several users also wanted to receive feedback that their item was successfully posted.
- Resolution: After posting an item, users will be directed to their profile, where they can see the successfully posted item. We will attempt to use styling to highlight the new item.
- When looking at search results, users wanted to be able to see more item information on the results page. Specifically, users wanted to be able to see the type of trade requested for the item (free, barter, cash), and also wanted to see the poster’s name.
- Resolution: We changed the way that items are displayed on user's profiles and on the search results. Search results now also include the name of the poster, and all places where an item is displayed also now display the preferred offer type. If the offer type is cash, the amount is displayed.
- When searching for a recipe, one user initially chose the “I Want” button instead of the “Recipe Box”. However, one she opened the “Recipe Box” the process of searching for an ingredient was clear.
- When the users were instructed to edit their profile, we realized that we had not included an “edit” button on their profile page.
- Resolution: We included a settings wheel icon on both the profile and on the items on a user's profile. This way the user can edit their profile or their items that they have posted.
- While the users knew to message sellers to complete exchanges, users were confused about the functionality of our messaging. Questions about push notifications, linked inboxes to Wellesley emails, and the format of the email page were asked.
- Resolution: We added a message inbox, as well as a bottom nav icon that takes users to their inbox. When they recieve new messages, the icon will display a notification with the number of messages. Messaging will be internal to the app and will not be linked to Wellesley Gmail.
- Our users had difficulty with our navigational system.
- Most users could not identify our “cupcake house” as the home button. Once we explained it, they were able to use it.
- Users persistently looked for a back button, which was not included in our original design. The lack of a forward button was also mentioned.
- One user expressed concern about our labeling of the main home screen buttons.
- Resolution: The header of our application displays our app name, and acts as a way to navigate back to the home screen. A bottom nav was incorporated, which allowed users to go back, forward, home, and to messages. We maintained the cupcake house, but streamlined the design to focus on the door (because investigation into common representations of home icons showed that the prominent distinctive feature seemed to be the presence of the door). Non-class users found this navigation system to be much easier to manage.
Overall, our pilot testing identified several major flaws of our initial design. Our navigational system proved to be difficult for almost all of the users, and prompted the most critiques.
The following observations have been grouped by task:Task 1
- Users knew to use the “I Want” button.
- Users could search for eggs, but had problems filtering the results for barter items. Some users did not immediately notice the filter option. Our filter was labeled “price”, which confused the users. One user commented that they weren’t sure if “price” literally referred to “price”, or rather the “mode of exchange”.
- Resolution: This seemed to be a labelling issue. Users did not consider "barter" or "free" to be prices, and thus shyed away from selecting "filter by price". We have chosen instead to use the language "filter by preferred offer type", which is slightly longer, but more understandable.
- Once the results were filtered, the users had no problems selecting an item.
- Users knew to automatically message the poster to coordinate the item exchange.
- All users successfully completed this task.
- Ae user commented that they wanted scroll functionality to look through more results.
- Users immediately went to the message button (envelope icon) after receiving the push notification.
- Users also correctly selected the unread conversation.
- Users consistently posted their first item successfully, including changing the requested form of exchange.
- After posting their first item, users had difficulty posting the second. The application brought users to their profile, which contained all their posted items. One user knew to navigate “Home” to start the process again, but the other users did not realize this. Users also tried to use the back button to post a second item.
- Resolution: One solution would be to add a "post item" button to a user's profile, however, we have not decided on whether this is the best course of action to deal with this issue.
- Users updated their profile with few or no problems.
- Users all used the gear icon to access editing.
- Users weren’t sure if their changes had been saved.
- Resolution: We are adding a popup notification telling users that their changes have been saved.
- One user found that it was difficult to tell which fields could be edited.
- Resolution: This was an issue mainly because of the way in which it was drawn in our paper prototype. It will be significantly clearer once it is implemented.
- One user was confused about the set-up of our editing process. Regardless of the gear icon clicked, the user was allowed to edit all the information. When the user clicked on the gear near the contact information, seeing that the recipes could also be edited temporarily confused her.
- Resolution: When users click the gear icon on the profile (next to a user's name) they will be taken to a simplified, editable profile page without their items. When they click the gear icon on an item, they will be taken to a page similar to the initial post item page, which will allow them to update an item or delete it.
Overall, our prototype testing went fairly smoothly. However, some general concerns and issues were brought to our attention.
- The feature that our users struggled with the most was filtering the search results. Using the filter options, the labeling of the filter options, and the positioning of the filter options may have contributing to this confusion.
- A second feature that needs to be improved is our editing functionality. As explained under Task 5, our current design was confusing.
- Users seemed like they could benefit from additional feedback, such as after posting an item. Users may also benefit from additional labeling, such as on the profile to potentially eliminate the confusion that arose when users were brought there after posting an item.
- While users were able to navigate our application much more efficiently than during our pilot testing, one of the users still had difficulty identifying our home button. Our home button was not salient enough, and we need to make sure that its purpose is more effectively conveyed to our users.
- Resolution: One possibility to improve the salience of our home button is to use a popup description the first time the user uses the application. Another option is to main the door on the "cupcake house" darker and more prominent. While the non-class users were able to recognize our revised home button better than our pilot users, if the problem doesn't improve fully we may need to utilize a standard home icon.
After our pilot testing, we made several changes to our design before testing with our non-class users. The changes we made included:
- Putting an “Edit” button on the profile page.
- Providing more control and feedback for users when they posted items by allowing them to enter specific cash prices, and by using a confirmation window.
- Revising the look of our messaging system to more closely reflect native iOS messaging. We designed an inbox page where users could select which message to view.
- Changing the labels on some buttons, such as our push notification options.
- Providing more information on the search results page. Several users had wanted to view the type of exchange requested, as well as the poster, so this information was included in the results.
- Creating a filter option for the search results by either “price” (a term we had initially used to refer to mode of exchange) or by “location”.
The most substantial changes that we made to our design were to our navigational system.
- Simplifying our home button by eliminating several of the “frosting” lines to make the cupcake house clearer and more understandable.
- Introducing a back button, which was previously missing, as well as a forward button.
- Deciding that after users posted an item, the application would take them to their profile.
- Implementing a bottom navigation instead of a top navigation. This decision allowed us to position the back and forward buttons, the home button, and the messaging button all along the bottom. We only left the application’s name in the header. We wanted to make sure that all of our navigation was in the same location, which prompted the move to a bottom navigation because there was not enough space in the header.