Round 2 of Prototype Testing

After spending the past week improving our first paper prototype, today we have finally tested out our new updated version and gathered some useful feedback which would help guide us towards our high fidelity product.
We mostly focused on changing the sections that testers found confusing last week and used their feedback to build and improve on top of our first paper prototype since there was generally good feedback to suggest that we already had a solid structure.

The were a few recurring issues that users spotted and found confusing. These were:

  • The Hamburger icon and its use was not well identified.
  • It was not clear who testers were shopping for in capture mode.
  • Some feedback bars were mistaken for input buttons.
  • Some buttons broke the app navigation fluency.

We decided to look at each individual point separately to ensure that we could really focus on improving the problem that our users found difficult. We thought that this was the best way of approaching the task as we would not be distracted by the issues of other interface elements and could work on improving one aspect until it was perfected.

Analysing each problem that was reported helped us to come up with our current updated paper prototype which is starting to take shape and is getting closer to out final high fidelity prototype.

As well as getting external users to test our product, we also thought it would be beneficial to test the prototype among ourselves. From doing this, we found that the hamburger button was not really useful as it would only contain two buttons: a help section, and a button to update who you were shopping for. We realised that the hamburger icon did not directly convey this information and so decided to swap the hamburger icon with something that users would easily recognise as an ‘update member’ function:

WhatsApp Image 2016-11-15 at 14.25.32.jpeg

There was also an issue with the profile customisation page we found – specifically the allergy selection process. To improve the page, we tried to make the interface clearer. For instance, once the user selects their dietary requirements from the list, we had a box which contained their options. However, the placement of this box was confusing as many people thought this to be a button that could be interacted with. In order to resolve this, we moved the box just below the list so that the user would first see the list and then a clear feedback when they added their allergies.

WhatsApp Image 2016-11-15 at 14.25.32 (3).jpeg        WhatsApp Image 2016-11-15 at 14.25.32 (1).jpeg

Finally most testers found it difficult to understand who they were shopping for when they were on the camera section. To attempt to resolve this issue, we found a temporary solution before the second prototype test and then a final one after completing it.
The first solution would work together with the new swap member icon that we have just added;
when users open the icon, a list of active members would pop up with the option of adding new ones. The problem we encountered, was still the visibility of the icon;
a majority of our testers barely saw the new icon design and skipped over it.
The change we made after the second round of testing seemed to be the best option as users understood the section better. We added the icon next to the scanning button to make it more visible and user accessible. When you user clicks on the icon, a bar would pop up vertically along the screen capture and shows the current people you are shopping for and the option of adding more shoppers directly from the bar.

WhatsApp Image 2016-11-15 at 14.25.32 (2).jpeg

Advertisements

Round 1 of Prototype Testing

Earlier today we tested the paper prototype that we collectively designed to model our mobile app. We created a number of different tasks that we wanted the user to complete in order to help identify keys problems with the user interface. The areas we focused on were:

  • creating a new user account
  • adding food allergies of household members
  • scanning products to identify their allergy content

We performed testing with three people all who had different levels of experience with diet monitoring applications.

Overall, the impression that users gave us was quite positive. They were impressed with the simplicity of the app and the general ease of use for common tasks. However, one of the main areas which was identified as a weakness was in changing up the active users mid shop which was confusing for all of our users; they later told us that the “hamburger” wasn’t an obvious way to achieve this. Other things which were noted were that some elements such as info bars appeared to be tappable when in fact they were not.

We are going to use this feedback to make a number of changes including the following:

  • changing the hamburger icon to a “swap users” button
  • reposition some of the feedback bars so that it is less likely to be perceived as tappable
  • more visibility on the capture screen of who is being shopped for
  • relabelling of some buttons to make it clearer as where they take would take the user

We will perform another round of testing with these new changes before we move to the final stage of prototyping where we will produce a high-fidelity prototype.

Paper Prototypes 4/4 – Initial testing version

Having individually created paper prototypes for the project we decided to meet to discuss some of the pros and cons of our various individual designs. Based on upon our discussions we decided to create a new version which incorporated some the most sensible design concepts from each of prototype.

We started by creating wireframes on paper that highlighted the order that a user can perform certain actions. The wireframe is shown below:

We then went about creating the prototype that we will use on Monday to perform some initial testing with potential users of the product. The prototype is shown below:

Paper Prototypes 3/4 – Will’s version

 

For my version the Foodgies prototype I split into two parts: the on-boarding experience and the core functionality.

For the on-boarding experience I tried to keep it simple so that any new users would be able to sign up and get into the app quickly.

The design of the core functionality with a focus on keeping actions to the lower half of the screen so that all buttons/interactions can be accessed on one hand, for example, adding users for filtering, capture function, and menu settings are all on the lower middle/right.

Paper prototypes 2/4 – Andrea & Amrish’s version

Here the second of four posts regarding our paper prototype design! This was Andrea’s and Amrish’s.

We decided to split the paper prototype into two main sections:

  • App onboarding including login and signup.
  • App core features and scanning system.

We mostly used paper to create a quite interactive prototype.
Users have the ability to navigate back and forth in almost each part of the prototype.

App onboarding including login and sign up:

App core features and scanning system:

 

Paper prototypes 1/4 – Kevin & Dat’s version

 

14959096_10207650177991830_958663080_o

This will be the first of four posts where we present our paper prototypes!

During the paper prototyping stage, we decided to temporarily split our group up and come up with our own variations of what we envisioned Foodgies to look and function like. As we were working separately, we had the freedom to come up with different features which gave us a diverse set of results. This meant that in the final low-fi prototype that we made, we were able to choose the most appropriate app features and produce a model which we believed to have the best logic flow.

This was Kevin’s and Dat’s:
We used a mixture of post-it notes and paper for this low-fidelity prototype!

When building this prototype, we were aiming for a simple and instinctive navigation system. From our lectures we were made aware of the concept of ‘recognition rather than recall’ and this was something that we believed to be a major component to successful apps. Owing to this, we paid particular attention to the camera view and drew icons which we believed to be good metaphors for what they represented so that the affordances were intuitive.

Additionally, we placed emphasis on good user feedback so that when the user interacted with certain parts of the app (e.g. entering in email address and other details; or completing profile page), they would receive a clear response/message to their actions.

Product Requirements

Product and Scope

Our goal is to create a mobile application that allows users with specific dietary requirements (such as allergies) to streamline their shopping experience by allowing them to quickly find dietary information about potential product purchases.

This would be a cloud-based service and allow for multiple user profiles. An optional wearable gadget which will link to the app via Bluetooth would be used to augment the experience by providing an interface that at a glance will show a “yes/no” indicator whether the product that was scanned, fits their requirements.

Why build it?

1. There’s a gap in the market for an app that helps people with allergies
2. The allergy community is continuing to grow so there is a ever growing demand for a product like Foodgies

Who is it for?

1. Food allergy sufferers
2. People with food intolerances

Stakeholders

We have broken down our stakeholders into three categories:
Primary: Anyone involved in the creation of the App, Users with allergies, Parents/Guardians, Sitters
Secondary: People who want to add to database, groceries stores
Tertiary: Other companies offering a similar service, health service, app store hosts (those that will distribute our application), dietary experts and professionals

What does the market look like?

Competition: For this part of our research, we looked at similar products to Foodgies that were already out in the market. From our findings, we noticed that although there were mobile apps which had similar motivations to Foodgies, many lacked features and ultimately did not provide the sort of functionality users wanted. This was emphasised by the negative user reviews we found.
Substitute products: We found three mobile apps which we concluded were substitute products to Foodgies. They were: Ipiit, The Food Ambassador (free app), Non-GMO Project Shopping Guide (free app), NextNutro ($4.99 iOS, $2.99 Android). Out of these three mobile apps, Ipiit used similar features to what we are aiming for with Foodgies.

From the information we gathered, we learnt that applications existing in the market does not fully satisfy the needs of the user. We feel strongly that we can product a better product and we will use the short-comings from these existing products to create a dietary app that meets the full requirements of users who have allergies or dietary requirements.

Questionnaire

To gather feedback from potential users we devised a questionnaire using Google Forms. We distributed it in a number of different locations including on chat rooms and to friends and family. Unfortunately, we only received a total of ten responses, however there were some useful insights that we were able to gain from the responses.

The most common type of allergy/intolerance we found was lactose which was featured in 70% of the responses. This suggests that is could be important when developing the database to focus on building a archive of products that contain this substance.

The frequency with which people check labels seemed normally distributed with a slight tendency towards frequently checking labels. Interestingly though very few (only 2) respondents said that they looked at labels for the purpose of seeking allergy information with most mainly suggesting that they looked at them for “best before” dates. This potentially suggests that despite suffering from allergies people tend to either stick with what they know or go for products that they assume is safe.

Personas & Scenarios

After sending out our questionnaire to the public, we created some personas based off of the data we received. We decided to create three types of personas which we thought best represented the general user groups for Foodgies; these included: a person who was a vegetarian (Gia Stevens), a person who had allergies (Angelica To), and a person who did not have any specific dietary requirements or allergies (Jeremy Cow).

Click on each image to open up a larger view
These personas were made with Xtensio

gia-stevens

angelica-to

jeremy-cow

Use case for Foodgies

  1. The user needs to check the ingredients of the product they see
  2. They take out their phone and open the Foodgies app
  3. As they are a returning user, they will be confronted with the main menu screen
  4. From here they choose the ‘capture’ mode to start scanning products with the camera
  5. Foodgies:
    1. Recognises the product and indicates if it is suitable for the user based on their requirements they set beforehand. If they want more information, they can double tap on the object box which pops up after the product is recognised.
    2. There is an error in the capture process and Foodgies does not recognise the product; so the user uses the secondary scan function which is scanning the barcode. This will give the same indication of a green or red light to determine if the product is suitable for the user or not.
    3. The product is not in Foodgies’ database and so the product is unidentified. The user has the option to log a request for the item so that it can be added to the Foodgies app at a future update.
  6. The user retrieves the information they wanted to find and decides whether to purchase the product or not