No Sweat

Case Studies by Danielle Caparas

No Sweat Case Study by Danielle Caparas
Creating an app from scratch.
February 1, 2017 - February 28, 2017
Role:
UX | UI Designer
No Sweat is a health food app made for those who focus more on what they eat instead of how many hours spent at the gym. To help organize and create meal plans and restrictions with the goals that you want to achieve on your health journey. We are here to help make being healthy easier.
Project Overview
I joined in with a team of two other UX | UI Designers to create an app for DevMountain Student Developers. With all three of us having experience in health, diet, and exercise. We decided to go forward and create an app for those who are looking for assistance on their journeys to living healthier.
"How can we convince people that healthy food is not only better for 
their health but also their pocket-books?"
Design Process
# 1. Building Empathy, Creating Assumptions
# 2. User Interviews, Research, Creative Brief
# 3. User Interview, Assessments, User Personas
# 4. Assessing MVPs, User Flow, User Sitemap
# 5. 10x10s, Low-Fidelity Sketches, InVision Prototype: Low-Fidelity Prototype
# 6. Implementing a Style Guide
# 7. Creating High Fidelity Mockups, High Fidelity Prototypes
# 8. Usability Testing
# 9. Assess Results, Refine Designs, Test-test-test!
#10. Project Results
Building Empathy
I like to begin my process by empathizing with our potential users. According to Psychology Today, Empathy is the experience of understanding another person’s thoughts, feelings, and condition from their point of view, rather than from your own. You try to imagine yourself in their place in order to understand what they are feeling or experiencing. I put myself in different situations and created assessments on how No Sweat can help those users. This helps me gather assumptions on the potential users we could target. It also gives me a handle on what I already know and what I need to find out. After this, I like to gather the team and share those thoughts. This is when we gather and finalize our assumptions and questions about our potential user.
Creating Assumptions
The UX | UI Team for this project include myself and two other designers, Stacy and Corey. This step is where we collaborate on our assumptions and create interview questions so that we may prove our assessments. With this, we create surveys and conduct user interviews.
This is a fun part of the user research side of things. I love going out into the field and engaging with users in the real world. I started at the mall, where there is a gym, athletic clothing stores, and of course the food court. I sought those who looked like they were not in a rush and asked politely if I could interview them on some of their health hobbies and backgrounds. I went on to the field for about an hour with a goal of gathering 10 responses. I managed to get 8 the first try and 4 more on my second round which only lasted 30 minutes. I met so many interesting people, all different and similar in interesting ways.
This is a method that is personal to my process and I urged other team members to do the same. It helps us really think out distinctly prioritize what our user interview questions should be.
According to Psychology Today, Empathy is the experience of understanding another person’s thoughts, feelings, and condition from their point of view, rather than from your own. You try to imagine yourself in their place in order to understand what they are feeling or experiencing.
User Interviews
I interviewed someone who is health conscious but has no time to really change his habits. A woman who always works and eats out almost every meal. Some college students, and even some instructors at DevMountain. 
During my interviews, I like to begin by creating a setting for my user to be comfortable and at ease in. I ask if it's ok to record the interview via video or audio. Breaking the ice is always important. I feel that a researcher can get better data when the interviewee is not stressed about "having the right answer". Reminding them that this is not a test. Here are some of the questions we went over during our interviews.
With all this info,  I jotted down who I think our focus users are, the users that our persona will represent. There was a lot of raw data that I had to turn into something that any design team could understand. This was a long section of the process only because I need that time to gather data that proves who my users are. I take my finding and go further... Yes. More research!
Research, research, research!
From there I took some time to research what it really is like to be healthy. I read articles that tell you what the certain person did for their health, from where they started, to when they felt accomplished. In this process, I stay balanced and equal. Just so that I don't sway towards any type of research and or persona. I also looked into statistics on how often people eat out vs cooking at home. I was quite curious about how much the average American wastes on throwing away unused groceries and products. How often users eat out, take leftovers home to eat them or throw them out.
Creating a Persona
"A persona is a representation of a type of customer. Personas answer the question, “Whom are we designing for?” and they help to align strategy and goals to specific user groups." - Greg Bernstein
I wanted to create a quick and easy, very simple persona. Something we can understand quickly and refer to when needed.
Mel is a 33-year-old female, a mother of 2. She works downtown at an app design agency, so she eats out for lunch most work days. Usually somewhere cheap and quick. Because of her family, she needs to budget all her food expenses. Mel does not exercise heavily, however, she walks a lot during the work days. She has never been unhealthy per se but she has never been super fit either. She always has her phone, especially for work. She uses a Mac at work and at home. Mel likes to cook dinners for her family and husband but may not have the time.
Creative Brief
The creative brief helps inform about the project in a quick and efficient way. Whoever needs to know details about No Sweat can be informed through this document. It is great practice for future teams and clients.
MVPs
The process of creating MVPs is something that the whole team should be a part of. First, we put together ideas on what the app could be no matter the bounds of time and resources. We put each idea on a sticky note and put them up on our wall. After this we evaluate the wall for similarities, this tells us what we are agreeing upon and gets out into the "possibly needed" pile. We create a pile for elements that would be a luxury to implement. however, it's important to know those elements even if they are just for fun.
The MVPs (minimum viable product) helped me establish the User Story Map. With this method, I was able to hone in on the app's categories and which features are most important.
We took our time with this process, in the middle of it, we seemed to have lost the sights of our focus goal as this can take hours. We had to take a step back and look at our key points on why we started this project, and that is to make being healthy simple and enjoyable. Our team then decided to focus more on eating out but still being healthy. Most adults with or without kids tend to eat out without even thinking twice about looking at what's healthy, so they just give up. We want to communicate with people, that you can eat at a place like McDonalds or Wendys and still be healthy.
I realized that this was my very first experience with scope creep. We needed to make it easier for anyone who wants to make healthy choices no matter where they are. We do this by providing the options available for users. Doesn't matter if they are eating in or out. 
We eventually get to a point where we can draw a line as to what we are going to implement. We had the idea to create a part of the app where it tells you healthy options for eating out and gives you assistance in your journey to cooking at home. In addition, if they were eating out, the app would provide healthy options specifically to the restaurant the user is at. After these exercise and further conversations with my team, we were ready to move forward. 
User Story Map
User Flow Diagram:
This is a very simplified example of one of many strings in my user flow diagrams.
10 x 10s & Sketching
Style Guide
InVision Prototype: Low-Fidelity Prototype
Marvel & QuckTime Player
User Testing
I conducted user tests on how the sections that I designed worked out for our users. I like to use the Low Fidelity Prototype because it helps me analyze the user with knowing that colors won't sway their opinions. I was only able to test 3 users not counting my classmates. It was humbling, you have to not protect your product but accept its flaws so that you can progress into a better flowing app.
I took these reactions and made changes to the lists and map view of our app. I added filters and made it so that searching doesn't feel as unnatural. These changes made the app flow better. I was able to make it look more appealing so that fingers want to touch the screen and proceed with their process.
InVision Prototype: High-Fidelity Mockup
User Testing
The Results
Design Toolkit
- Sketch
- Photoshop
- Illustrator
- InVision
- Trello
- Grammarly
- Google Docs
- Google Sheets
Back to Top