Hannah Kimura

Appearance

Project 6: User Testing & Final Release ​

Table of Contents:

  1. User testing reports
  2. Opportunities for improvement
  3. Design revisions

User testing reports ​

User Test 1: Client ​

The first tester we had was a college student who did not have previous experience using a food pantry, but has used similar interfaces to order food online before. They were able to easily log in, update their eligibility information, and find a pantry. However, while they were updating the annual income field, they noted that they interpreted the red highlight that indicates that a field is required as indicating that their input was not an accepted type. They also looked through all of the pantries to see which one had the most items before continuing to place an order from a specific pantry. Once they were in the pantry storefront, it was unclear to them how to request a new item. They assumed that they would need to click the Request Item button to start a request and then a popup would appear, instead of filling out the form at the top of the page and simply clicking the request button. Overall, they mentioned that their experience using other online ordering systems made this a straightforward experience. However, it seems that there were pain points, particularly when the user is entering input types that they may not have encountered before on a website (i.e. whether to include a $ with annual income, and entering a barcode to request an item).

User Test 2: Administrator ​

The second tester we had was a college student who has had experience using other inventory software, but not for food pantries. They were easily able to log in, update opening hours and eligibility requirements. There were some small issues when it came to adding, updating, and deleting an inventory item. While adding an item, the tester was confused about the meaning of the drop date, particularly because the expiration date came before the drop date in the form, so the tester thought that the item was deleted after the drop date. Then, while updating an item, they returned to the add form at the top of the screen. This seemed to be because the form did not clear after submission, so they assumed the state was still controlled by that form. They had no problems removing the item, fulfilling an order, or updating a restock request. The main problems that surfaced during this session were similar to those in the first test in that they all arose during the data input process.

User Test 3: Client ​

When logging in, the tester typed in her password wrong multiple times, and this made me realize that there was no way to access your password if you truly forgot it. It would be nice to add a forgot password part, where your password can be sent to your email or something. When I had the tester update her annual income, I noticed she was confused when she input the update and pressed enter. Rather than reloading to show you your new stats, it turns red. Even though the information does update on the backend, it doesn’t make it clear to the user that it is updated. The task that the tester struggled with most was inputting a request for an out of stock food item. Her initial thought was to go to the request tab to do this, but in our design the request tab only shows you any requests you have already submitted. Right now, you have to go to the map, select the pantry, and then you can make a request. A design revision could be to add making requests in the request tab, so it is more intuitive on where to find this. In addition, when a request is made, you still stay in the shop, and are just shown a message saying the request was made. The tester added takis 10 times because she wasn’t sure if the request really went through. To fix this, I would reroute to the requests tab once a request is made. Finally, since the request functionality is within the part of the interface where you make an order, we need to update the instructions to make it known that requests are only used for out of stock items. When I first instructed the tester to make an order, she thought she had to input the barcode for each item that she wanted into the requests part.

User Test 4: Administrator ​

Our last user test aimed to get more granular information on the UX of the admin panel. We noticed three primary issues. The first was in the information form. The testee expected if one inputed multiple new values, they could press one of the submit buttons and all the revisions would go through. When they did so and only saw one of the values changed, they were confused and realized they had to go back. Making the change of information form to update all values inputted would expedite the process and fit our users' intuitions. Another issue involved reactive design, specifically for deleting particular items in the inventory. When the user deleted an item, they paused and seemed confused when the item was still on screen. When asked, they thought the item was still in the inventory since it was still visible. In general, there could be more responsive design for the inventory actions, and this was a core thing that caused quite a bit of confusion from the user. Finally, when adding an item, there was very little clarity on what drop meant. My user genuinely thought drop meant expire, and since it was the first field to input and expiry date felt more relevant, they simply filled in the expiry date in that section. Better clarity and labeling of the fields of our concepts would likely ease this issue and ensure less extra exposition is necessary.

Opportunities for improvement ​

  1. Lack of Information (Linguistic, Major): For users who may not have used an inventory system before, it is hard to decipher how specific components of a concept may work. For example, users who are not familiar with streetwear may not understand the concept of 'dropping' an item. To help users understand how each component of a concept functions, particularly for the Expiring Item concept, information icons on the creation form could provide information on how each field impacts the concept's use when hovered over. This would help bridge the linguistic gap between users' existing knowledge and concepts they have not seen before.

  2. Unexpected Input Types (Linguistic, Moderate): Users have pre-existing notions of what types of data an input will accept. This becomes particularly pressing in our user profiles and pantry profiles, because expressing food pantry eligibility requirements necessitates unique input structures. For example, SNAP eligibility is represented using a slider, while income is represented as a textbox. During user tests, we noticed that at least one user was confused that income was a textbox instead of a dropdown for different income categories. Particularly because these inputs are uniquely typed, it makes sense to add more restrictions on user behavior, such as turning the textbox into a number-typed input or dropdown to prevent misinterpretation.

  3. Efficient Update Forms (Physical, Moderate): When updating user or pantry information, users expect to be able to update multiple fields at the same time. Currently, when they input a field and submit, it takes them to a new page verifying the submit. It would be better to keep them on the same page and allow them to submit updates to multiple fields with one button request, as our user tests concluded this was an intuitive action to have.

  4. Responsive Expiring Item Design (Linguistic, Moderate): Though the number in cart changes when you add or remove items, there is no clear indication the item itself was added. Users had very little clarity on if they successfully added an item unless they checked the small cart number at the top, which they are unlikely to do. Better indications that they successfully clicked the add button and it added something would be helpful at mitigating user confusion and preventing incorrect order submissions.

Design revisions ​

  1. During implementation, we realized that the inventory class was effectively a state on each expiring item. Instead, we decided to give each expiring item an administrator, and an additional state of status which is Unreleased, Claimable, Ordered, Used, and Expired, which were previously managed by the inventory concept. This also meant that we discarded the pantry statistics dashboard feature.

  2. We also realized that the map feature made more sense as a sync than a concept, since we want the maps for users to dynamically update based on changes to eligibility information, meaning that the locations should be refreshed each time and eliminating the need to save locations across sessions. Thus, the map is now a sync that the frontend can call each time the corresponding Vue component is accessed.

  3. While implementing the frontend for ordering, we realized that while our original route to get orderable quantities and barcodes requested the pantry account’s username, this data wasn’t already exposed on the frontend to the user, and would require an additional request. To fix this, and make the backend functionality accessible to users more cohesive, we changed the route to take the pantry administrator ID instead of pantry administrator username.

  4. For the time being, we struggled with implementing the map, and fell back to the list of food pantries by city, as we said we might in assignment 3. Since users can still view pantries by location, this does not significantly impact usability. However, the link in the navbar was still called Map, and should be renamed to Pantries so that it does not imply any non-existent features.

  5. Although we postponed the request feature from assignment 5, we were able to complete it for assignment 6. We also had a user who was confused about the purpose of the request box and a different user who expected the form to appear differently, so it may make more sense to have a button that says Request an out of stock item, and then have a popup form that disappears when a request has been submitted.