Conclusions and Recommendations

We conclude that some of the features evaluated worked well, though concerns exist regarding inter-user trust and community navigation.

While there was no significant difference between the level of details in food and profile posts, participants were slightly more inclined to trust another user based on profile rather than food post. In other words, the evidence shows that a user puts higher emphasis on a profile than a food post, which is something we did not anticipate.

In the apartment layout, participants took more time to scan for targets and perform scrolling gestures both vertically and horizontally, as indicated by the significant effect the layout had on time. Interestingly, we found an interaction effect when analyzing layout and task, indicating that tasks which include explicit spatial (apartment floor) information might not be hindered as much.

In regards to our interface design, we acknowledge that there are some factors that could have affected the results in our experiments. One major factor could have been that the contrast between low and high levels of information was not high enough. As such, participants may have been unable to indicate a clear preference and chose arbitrarily which one they trusted more. In the second experiment, it is unclear whether the difficulty in performing the task was a scrolling problem, or a visual issue (e.g pictures were too small).

The concept presented here is still worth exploring given these conclusions, though future designs would have to address several serious issues.

In terms of promoting trust, it might make sense to make interface adjustments that emphasize the seller and their history. One specific recommendation might be to make certain (or all) fields in profiles required. Another might be to set a standard to check a user’s history, such as a background check or a food safety inspection. It might also be worthwhile to consider these in context with features that promote user trust, such as their effect on our messaging system.

With regards to main page layout, future design steps would have to address the issues reported with gestures and overload of information on screen. Specifically, this might involve considering pinch gestures for navigation and collapsible map “pins”. Alternatively, we might recommend the use of a hybrid interface. This would combine the map with the simplicity of a list, which might be sorted (e.g. using a recommendation system) to complement the spatial info.

Reflection

Prior to creating the interactive system, the field study was beneficial in identifying issues with some assumptions that we had. Initially, we felt that our system would be used by anybody within a close-knit community. To our surprise, the young adults in our study were pretty vocal about how they didn’t enjoy or cared little about interacting with their neighbors. After realizing this, we shifted our user group to an older age group that were more open to sharing and interacting with their neighbors. In addition, we realized that we had to put a higher importance on trust as multiple participants expressed their concerns for trusting food made by others. Use of an affinity diagram allowed us to easily identify rich patterns in this data.

Using different levels of prototypes greatly helped us in designing and shaping our experiments. With the low fidelity prototype that we created, we were able to quickly evaluate our conceptual ideas and see if it worked with minimal effort. Additionally, after getting feedback, we were able to quickly make changes and adjust features to test. After the low fidelity prototype, we were able to pinpoint areas of our overall prototype to test, such as creating timed trials in our medium fidelity prototype to test searching and browsing tasks to collect quantitative data.

Pilot testing was another great method that we learned through class, and after performing our study, we realized the significance of conducting such tests. Not only did pilot testing allow us to reveal functional issues of our prototype, it also allowed us to figure out a better way to gather qualitative data. To elaborate, we found some frames in our prototype that did not transition appropriately given the user’s input, and this would have affected our first participant’s results. Furthermore, we discovered that using a semi-structured interview style to gather qualitative data was better than giving the participant a survey to fill out.

In terms of analysis, we felt that using ANOVA testing in R studio allowed us to clearly see the differences in our findings and helped us visualize our collected data.

However, like most things in life, there were aspects in our study that did not go as we planned. When we designed our medium fidelity prototype, we had planned to use a touchscreen device to conduct the experiments, however, with the COVID-19 pandemic, we had to hastily adjust our experiments to make everything virtual. Given that we could not control the environment of our experiment, many factors could have affected our results, such as the different devices that the participants used, the internet speeds, etc.

Additionally, if we had more time to run our experiment with a larger group, we may have been able to collect more substantial data that could possibly change our results  and have more accurate conclusions.

Rationale of Medium Fidelity Prototyping Approach

Our prototype consists of three parts: a showcase of screens and interactions (mostly horizontal in scope), prepared trials in which users choose amongst trustworthy food postings, and prepared trials in which users search amongst active postings/people. The horizontal implementation serves to motivate why users might accomplish the latter two tasks, but the bulk of the prototyping effort was to support evaluating design alternatives for these tasks.

We chose this approach in order to validate certain ideas we proposed in our low-fi prototype. We wanted to test (1) what form the information on a food listing or profile should take in order to maximize a user’s trust and (2) whether making the physical layout of the building salient in the app is a good practice in terms of both efficiency and preference. As such, we decided to forego prototyping features such as text field entry or realistic progression through order creation (which would involve taking pictures of food).

To address (1), we decided to allow users to cycle through scrollable profiles and food listings in order to make more direct comparisons. As this task is largely one of visual appraisal, it was important that the features of these screens (e.g. user pictures, bios, food pictures) appeared to be realistic and differed only in information we intended to manipulate. To address (2), we fleshed out two different versions of a home screen. The ‘list layout’ was created to condense info as much as possible for efficiency’s sake, whereas the ‘apartment layout’ was made to reflect the spatial layout of the apartment. We would like to advance the latter as a way to better support thinking of the building in terms of floors, doors, and neighbours inside them. We imagine stereotypical ‘apartment life’ tasks (e.g. grabbing food from the first floor on the way out) might be best supported in this layout. With that being said, it introduces a lot of clutter. To this end, we prototyped multiple trials for two different search tasks within each layout. As we also aim to ask about preference, we decided both layouts would have realistic food and profile pictures. The apartment layout would also be displayed over a small building to better communicate what exactly users were scrolling through.

We chose to prototype in an iPad frame in Figma in order to best reflect the sort of touchscreen interaction we expect of the final interface (ideal for timing tasks) without significant effort programming for iOS or Android. This tool best supported mocking up screens and overlays for the horizontal prototype, generating believable pictures using plug-ins, displaying profiles in a slideshow-y manner for experiment 1, and mocking up rearranged test trials with time delays for experiment 2.

Prototype Demonstrations

The following is a video demo showcasing features implemented:

To serve our experimental goals, we have separate playable pages in the Figma prototype consisting of sequences of trials. These can all be played in different orders to easily implement counterbalancing. In experiment 1, users tap through a food post with a description and list of tags (left) into one with a longer description and comprehensive list of ingredients (right).

Users also tap through profiles with notable differences in bio length, app experience, profile picture, mutual friends list, and trophies.

In experiment 2, users are asked to find and tap a specific food or browse for and tap a hungry person on a given floor. We prototyped a progression through trials on each layout for each task. New targets are provided in each task in order to factor out memorization, and rearranged in order to cover a reasonable horizontal span of the lists (left) and horizontal and vertical span of the building (right).

The practice trial for each interface begins with a blinking overlay indicating scrolling directions (visible in video). Trials are separated by a timed instance of the following screen:

Further Updated Task Examples

1. Tony – the time-constrained salaryman

Tony is living in a studio apartment with his girlfriend. Both he and his girlfriend work full-time and often work overtime as well. This leaves him with minimal time to buy groceries and prepare food for him and his girlfriend. Tony doesn’t want to keep ordering food delivery from restaurants as the delivery fees and bills are stacking up, and the restaurant foods are too salty and greasy for his liking. However, food delivery is the most convenient and time saving compared with his other options of buying groceries and cooking or eating out at restaurants.

2. Adam – the new cook in town

Adam recently moved from Port Moody to Vancouver to be closer to his new workplace. One of Adam’s hobbies is cooking as it allows him to try food from various cuisines. Living with his family allowed him to cook multiple dishes at a time since he would always have people to share his food with him. This is now an issue for Adam since he lives alone, he finds it hard to adjust his cooking style to cook just one portion. He is constantly finding himself with too many leftovers and feels that the leftovers are preventing him from cooking and trying new dishes. Unfortunately, since Adam is new to his condo, he hasn’t found anyone to share his food with yet.

3. John & Mary – the generous neighbours

John and Mary have been living in the neighbourhood for over 20 years with their 3 children. They own a 5 bedroom house and they are also renting out their basement suite. Currently, Mary prepares meals for her family as well as the tenant. To do this, she has to go grocery shopping twice a week. Mary loves to cook and experiment with cooking new recipes, however, she often makes too much and her fridge is filled with leftovers. Her family is sick of eating the same foods for days until they finish the leftovers, otherwise the extra food will go in the trash. Mary wishes she knew more neighbours that she could share her food with.

Low-Fidelity Prototype Demonstration

Our lo-fi prototype design centers around supporting the user’s ability to act as both a food provider (Adam & some of the John/Mary task example) and receiver (Tony task example) in their neighbourhood groups (in this case, an apartment-specific group). As such, our prototype maintains a mostly horizontal scope in order to reflect a breadth of features. It was also decided that the interface will be a mobile app in order to leverage certain hardware features (assume the following images are on a tablet).

The sign-up process for a group includes both profile creation and a verification or invitation process. Household allergens are also specified here. There is a balance to strike between in-group intimacy and privacy of user information that might look like what we would expect of a private Facebook group dedicated to the apartment, so in this specific example, the group would require some Location ID (given by an admin or creator) to verify you live at a given apartment number.

The main screen, from which users are able to take any number of actions, is a spatial layout of the whole neighbourhood at a glance. Neighbours that have marked themselves as hungry and neighbours that have posted food listings are both indicated in multiple ways.

Sufficiently crowded floors might warrant zooming into a hallway view.

A hungry user such as Tony might select “I’m Hungry!” from the main page to indicate he is looking for food. This can be a simple toggle, or it can involve visiting this page and scheduling a future time Tony knows he won’t be able to cook for himself.

A hungry user such as Tony might also just select the Pasta he sees on the main page, bringing up this box. A name, a price (if not free), pictures, serving size, kitchenware requirements, and tags all provide some insight into the dish.

The requesting process takes place in messages, with links to the relevant food item. This process is very importantly conversational. It allows flexible conversation about things such as allergies or pickup times, but differentiates itself from something like Facebook Messenger with important guidance prompts at different food-sharing steps. These include the ability to call food providers without needing to share phone numbers and bookkeeping of things on loan (such as Tupperware).

Profiles might also be accessed from either messages, listings, or the main screen. Neighbors can be “starred” to save for quick access in other contexts. Some additional incentive to share food, and, on a related note, some additional incentive to choose trusted cooks (as opposed to our previous review/rating system ideas) might arise from the use of a medal system and count of dishes shared.

Sharing food, like in the Adam or John/Mary task examples, is initiated from the neighbourhood page. This opens up a box designed with efficient entry in mind–listing food should not be another chore on top of making it. This is supported by features such as tapping common/suggested tags and taking pictures from the device camera.

Once completed, a food posting can be shared in one of two ways: 1. As a message to a specific person. This is something John & Mary might like to do, having established themselves in their community and having starred a certain person they know likes their leftovers. 2. As a posting to the neighbourhood group. This better supports Adam’s task example, where it would really just be nice if he met anyone who wanted some food.

The messaging function, now initiated by Jorge (who would like some skewers), has guidance prompts for the food provider role as well. It prompts the cook to mark dishes as safe for household-specified allergens allergens (and possibly communicate back and forth if there is any confusion).

And ultimately let the recipient know they can come over and receive food!

Additional Information about Prototype

All three of our task examples were supported to some extent. In support of Tony, we had to evaluate the task of seeking food from users who had already posted up available dishes. Conversely, we had to evaluate the ability to list available food to everyone else in the area. To further support both Adam and John and Mary, we wanted to demonstrate how a food listing can be efficiently communicated to existing friends.

For this prototype, we made sure to focus on a horizontal scope in order to gain insight into which tasks might be the hardest for users. We aimed to reflect a breadth of buying/selling behaviours without focusing on details such as how the main page is updated with new users or detailed walkthrough of a payment system.

One major design decision we had to make was how we wanted to display other users, how much info should be visible at first glance, and the layout of users. Two of our ideas aimed to have our main page focus on showing a portion of all neighbors at a time and a status of whether they are looking or giving out food. To simplify this prototype, we assumed that this instance was used in an apartment, as it showed the best alignment with our ideas and that if it worked well it can easily be tweaked to include houses on a map. Our first idea was to have the main screen mimic a scrollable hallway that would extend to include all users, and our second idea was to provide a spatial layout of all users that represented the floors each user was on.We ended up utilizing both layouts based on whether the user wanted a wider view or narrower view of other users.  

While we hope to explore and evaluate more methods to establish trust between users and create connections in our experimental methods, we chose to display the amount of meals a user has given out as an indication for trust and safety. We also allow for food listings to include information that might be relevant to whether recipients are comfortable requesting a dish (e.g. pictures of the final product, tagging dish as leftovers).

For a form of communication, we chose a simple messenger application akin to Facebook Messenger or WhatsApp because it has shown to be the most common interface for text communication. However, we decided to embed it with prompts and allergy acknowledgements in hopes of creating a streamlined but communicative buying and selling process that is safe.

Walkthrough Report

For our cognitive walkthrough, we asked the user to perform a series of tasks, playing as both a provider and a recipient. These tasks included: signing up, listing food available for sharing, messaging potential buyers or sellers, and browsing and scheduling for a pickup. The overall process was quite smooth however, there were a few areas where the user was confused about. 

The first main area of confusion was in the signup page where the user had to enter a location ID and an occupancy amount. For location ID, the user did not know what to enter and needed an explanation as to what it was. This confusion could be because of the naming convention or the lack of information or “help guide” as to what the location ID was and how the user could get it. After entering an ID, there was a pop up that said “verification” and the user was confused as to whether it was a button they needed to click for additional verification or if it was a message. This confusion could be reduced by perhaps changing the lettering to “verified” with a check mark in the front. Additionally, the user was confused about the “occupancy” field and needed further explanation as well.

Another point of confusion was during the task of browsing for food to purchase. The spatial layout on the homepage with the layout of the apartment building with floors was confusing for the user as they did not know where to press or how to browse. They skipped using the spatial layout and browsed for food using the image layout on the side as it was more familiar for them. We had to explain the spatial layout to them before they understood what it was and how they could browse with it. This may be a problem area that we need to focus on and figure out which layout would be better to perform the browsing task.

The task of listing available food to share, messaging potential buyers or sellers, and browsing/scheduling for pickup went smoothly. This is possibly because we used very standard layouts for these tasks and mimicked existing applications. For the listing food to share and scheduling for pickup screen layouts, we mimicked current food delivery applications. For the messaging task, we mimicked the social media app, Facebook Messenger. Since the user was familiar with the layouts already, they were able to successfully complete these tasks without issue.

The walkthrough covered all three of our task examples. For Tony, we incorporated the browsing and pickup of food, for both Adam and John/Mary, we incorporated listing available food for pickup as well as contacting potential buyers through messaging.

Proposed Goal(s) of Experiment

• Evaluate what features of a posting can help increase trust for a potential consumer
• Evaluate whether users prefer having an interface that allows them to scroll through a list of available items or an interface that shows all the users registered for the apartment with their current status
• Evaluate the best way to facilitate conversation between the two parties

One takeaway we gathered from our field study was that participants who have little interaction with their neighbors generally have a lower level of trust with one another. Our first goal is to help us understand what kind of information should be shared to increase trust between users. We will be evaluating this goal through analyzing multiple features such as, attaching pictures of the food in the posting versus not attaching a picture, viewing an user with a completed profile versus a partially completed profile. 

Our second goal is to help us better understand how to design our main page in order to maximize the user experience and better display information to the user. A design option we have is to list the items that are available on the main page. Although this option helps users to efficiently see what items are offered at that moment, we feel that this layout hinders the ability to include a community aspect to the application which was one of our original intentions. Our solution to implement this aspect is to create an interface that shows which users are registered in their building alongside their current status. 

Our third goal is to better evaluate how users want to communicate with one another. Since we want to increase trust between parties, we plan on including a feature that allows users to easily converse with one another either through call or text.