UX Foundations Case Study materials

Problem identification, User Research, Solution, Persona, MVP feature list, User flow.

Problem

The problem that I had identified that I decided to solve for was actually part of the larger problem related to the cost of living in Vancouver. I wanted to develop a solution that would help decrease cost of living while improving quality of life through healthier meal options.

User Research

I interviewed 5 people and surveyed 18 to get an idea of my target market and what their interests, behaviours, demographics, pain points, goals, etc were to help me with formulating a solution.

My interview questions were as follows:

  1. How old are you?
  2. What is your current living situation like?
  3. What is your employment situation like?
  4. How often do you cook your own meals? How often do you eat out?
  5. Where do you look for recipes?
  6. What are the greatest challenges you face cooking/eating at home?
  7. Describe your shopping habits when going to the grocery store.
  8. Which grocery store do you shop at and why do you choose this store?
  9. What are your biggest pain-points with grocery shopping?
  10. What are your 3 favourite apps?
  11. What are your 3 favourite brands?
  12. How do you get around the city?

Through my surveys that I sent out I was also able to generate some graphs based on quantitative data that I had gathered:

The Solution

My findings indicated that my target market leads busy lifestyles and are tech savvy. Time is important to these people as well as price and convenience. The app I have decided that would solve for the pain points identified and be benefit my primary user’s life is one that is a cooking app. This app includes a combination of Recipe searching and meal planning, grocery shopping list creation, and grocery store location services. The idea is to make cooking at home and grocery shopping a streamlined process, which would suit a busy lifestyle.

Persona (rough draft)

Here is my persona for my app. The idea that I have for my app is an app that will make recipe finding and grocery shopping easier by being able to search and save recipes and having the ability to automatically generate grocery lists from those recipes. The app will also have the ability to find the nearest grocery store.

Feature List

I wanted to include many features in my app that would optimize the user experience. To decide which features would be included in my initial release and which could be banked for future development I created the following diagram.

Due to time restraints and scope required to design some of the features I wanted to include I made the decision that all of the above features could not be included in the initial beta release. I then took a look at the features that my Primary user would find the most valuable for their user experience and placed those at the top of each section. Based on that I came up with the following MVP feature list:

MVP Features

The app will be comprised of the following 4 sections for the initial beta release. Each section will have a few sub features to support the Primary feature.

  1. Recipes: recipe searching, recipe saving, and ability to enter recipes manually.
  2. Grocery Lists: ability to auto generate a list from a recipe, abilty to create a grocery list manually, ability to check off items completed, and the automatic saving of past lists.
  3. Grocery Store Optimization: GPS locate nearest grocery stores, ability to select a grocery store, and provide hours of operation and contact info of selected store.
  4. Profile creation (this is needed in order to save recipes and lists): prompted upon downloading the app to enter email, create password, and enter name. This information can be edited at any time via the profile section of the app.

User Flow (rough draft)

Drawn out version of User Flow for my app, outlining the primary user paths and alternate user paths. I will be creating a digitized version to update.

Wireframes and Paper Prototyping

After creating the user flow and making decisions about which features to include in my initial release I began drawing out wireframes and used those to create a paper prototype to test some functions of my app through usability testing.

My initial test was very broad as I wanted the user to navigate their way through an entire workflow the first senario I used was “Find a Recipe you like and use it to get the items you need”. The feedback I received from my initial test was that the question was too broad and there was some confusion as to how to reach the goal and at what point in the workflow the goal would be considered reached. The other issue my user found confusing was the hierarchy of the menu. I used this feedback to come up with a new set of questions and made some quick adjustments to the menu before running another test.

My second test subject was given the senario “You would like to make something delicious for dinner, use the app to find a recipe you like and make a shopping list.” He came up with the following flow:

The feedback I received from this flow was in regards to the auto-naming of the Recipe. This user suggested the default name should be the recipe name. They had also suggested that the “continue browsing” bring you back to the recipe list instead of just closing the shadow box (as the “x” in the top also accomplishes this feature) and once you click “continue browsing” you would still need to click the back arrow to go back to the recipe list.

The third subject was given the senario “You have already created a grocery list but have not yet picked up the items on it. Use the app to locate a store and complete the items on your list.” This is really a 2 part flow; my subject came up with the following:

Finding the store was easy for them. There was no confusion on how to use this part of the app and it was done quickly.
When it came time to pick up the items the user had suggestions in the naming conventions of the sub-menu for lists. The user got confused as to whether their list was an archived list or an in-progress or items still to pick up. They also suggested a split screen view similar to what the Notes feature for Apple has so you can actually see the quick view of the lists you have so you can easily select without having to go to a different screen. Another suggestion she had was to be able to move all uncompleted lists to completed from the in progress screen It would get annoying having to open up these lists and check off the items to close them if you don’t have all items checked off.

Mid-Fidelity Wireframes

The next step in my process was to take the low-fidelity wireframes and put them in sketch so that I could perform some User testing via inVision. Mid-Fidelity wireframes can be found here https://invis.io/FC8D00NEH . My ask was for users to run through a few tests.

  1. Sign in to the app, find a recipe, and use that recipe to create a shopping list.
  2. You are already at the grocery stoe, open the shopping list you had created and check off the items as you shop for them.

Some of the feedback I gathered included the following:

Buttons: “Try to have 2 button styles to start with — a primary action and a secondary action. Primary should carry more weight visually. Mock up all the states of each button style — default, focussed (by the tab key), hover, pressed (optional), disabled.
Decide what your primary action on the screen is, and use the primary button. Secondary actions should get the secondary button. 
Primary action should be used sparingly. One on the screen is best — If you find you have a good reason for a third button style you can design one that fits in with the other two. I try to stick to two though. The states are good because you have it ready if you need a disabled or focussed state later on. Its also important to think about states if you ever want to get your shit built by a developer.”

Browse Categories: “I clicked on “Browse categories” to get here but it seems more like browse recipes. Might either tweak the copy on the button or change this screen to so it’s more category centered.”

Recipe Hierarchy: “Hard to read these — I didn’t realize these were separate times. Mess around with proximity to create stronger or weaker relationships between things.”

There are more comments and you can read them all via the inVision link provided above. Below you will find a screenshot of a few of my mid-fidelity wireframes:

Measuring the User Experience

As I move on to develop more refined versions of my wireframes, the next goal is usability testing to determine how to make adjustments to my app to optimize the user experience.

Goals:

  1. Have the user run through a primary workflow without going off track.
  2. Sign up easily with little effort on their part.
  3. Move through the app seamlessly/continuous flow.

Hypotheses:

  1. Button color choice will guide the user through the Primary workflow at specific points in the app (when they are given a few choices but one is the Primary and the others are secondary workflows).
  2. Changing the labels in the Lists section to be more direct will result in less confusion (In-Progress to Shopping List in Progress, Archived to Archived Shopping Lists, Enter Manually to Manually Create List).
  3. Changing the feel, adding images (of recipes) and changing color scheme (warmer 4 color pallete) will effect the users overall happiness with the app.
  4. Having one click (Facebook/Twitter) sign up with result in more conversions.

Measurement:

Reflecting on the same number in the Hypotheses section above, I will measure using the following:

  1. Button Colors: A/B Test using different button colors with the same language in the same placement to see which one gets more clicks.
  2. Copy/Label Changes: Again, running an A/B test with the change in copy on the labels. I have already gathered some data through prototyping in which the user got confused at this point and strayed away from the desired Primary Workflow. Changing each of these labels separately while leaving all other elements the same as with the initial test will confirm or deny my hypothesis that a change to the language will have a positive outcome on the confusion factor.
  3. Visual Design (colors and images): This is a little different than the usual quantitive data measurements because it is not something that can be easily measured by A/B testing throughout the app. Once visual design elements are added I can run the primary user test alongside the primary user test with mid-fidelity wireframes. Running live testing is an easy way to gage user frustration or lack there of because it is a live experience. Conducting a short 1–10 happiness factor survey after the test will also help in confirming my results.
  4. One Click Sign-up: This is an easy one to test using A/B testing to track sign ups. I will have one sign up page which requires you enter your email and password manually. They other will have the option of entering tapping the Facebook or Twitter icon to automatically create a profile and sign into the app.

High-Fidelity Prototyping

To test my Hypothesis above I needed to create high-fidelity version of my app. At this point I have fully developed one user flow:

Sign up using social media—Search for a Recipe—Use the Recipe to Create a Shopping List.

In this case my prototype requires that the user search for “Healthy Pizza” and the option to choose is “Shrimp, Spinach, and Basil Pizza Bianca”. The ability to choose different options in my prototype and browse using the “Browse Categories” feature, as well as the ability to toggle between List and Gallery view will come at a later date.

This is a continual work in progress and my eventual goal is to build out the entire app, but for now the very basic workflow is visible in high-fidelity here: https://invis.io/4G8KQFY39

You can see a screenshot of a few of my screens below:

I have not had a chance to run usability testing on the high-fidelity version as of yet but did get some feedback from my presentation regarding the original red text on green background and its readability (does not pass accessibility guidelines). The original version had the tab text that was the “current tab” appearing in red. As a result of this feedback I have adjusted the tabs to be all the same color for now and will revisit this at a later date.

Conclusion

My main findings of this process is that I need more Time. Time to test, Time to research and Time to redevelop and test again. Developing an app is a learning process that involves constant review and there is always room for improvement. This is a constantly evolving learning process.

Coming into this program with a background in Visual Design, my current process of thinking and design was challenged in this process. As a Visual Designer often times my focus on what you think the audience will find appealing based on experience. My journey over the last 10 weeks has given me an understanding of the importance of making design decisions based on what the research and testing has confirmed the primary user finds valuable.

So my conclusion, in short, is that there isn’t one at this time, my process is ever evolving as my app and this project will well after the completion of this program.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.