CASH RUN APPS
Cash Run App
This project started off with many different ideas to design a new health tracker app. There are also an abundance of health tracker apps that monitors different parameters, such as medical health, workouts, running, diet, and more. I had some ideas and assumptions of what I thought users needed in a health tracker app. I needed to ask users questions as the initial step to the process of identifying a problem and then developing an app to solve the issue. I needed some questions answered to narrow down what type of health tracking app I was going to design.
What problem am I solving?
In my research I interviewed five different users ranging from the ages of 22–35. I began asking generalized questions regarding health, exercise, and health tracker apps.
The following questions were asked:
How important is health and exercise?
How often do you exercise?
How do you stay healthy and what types of exercise do you prefer?
What types of health tracker apps are being used and why?
What are the positives and negatives of these health tracker apps?
What are the things you would want in a health tracker app?
Trends Indentified
I compiled all my answers and wrote them all on post it notes. I placed each user answer on the wall for comparison. Stepping back from the data, I began to notice similar trends and affinities. I regrouped the data again according to their common pain points.
Research
My data revealed that everyone uses a health tracker in a form of a running app for the IOS device. Everyone answered that they wish the app could accurately record miles, distance, time and calories burned. These answers were good to know but I was not interested in trying to design another running app that just improved on what running apps already did. I needed to dig deeper to solve the bigger problem. One of the first questions I asked was, how often do they run? As it turned out, this simple question became the biggest problem of all users.
Problem Identified
On analysis of the data collected through interviews of the five users, I have concluded that
lthough a person has the desire to regularly run in attempts to be healthy, the person lacks motivation due to a busy daily lifestyle.
Users were telling me that they try to exercise 3 to 4 times a week but cannot find the time.
Another user said they rarely exercise at all because of school.
The Solution
I propose an app on that creates a regular weekly running schedule encouraging a user to remain motivated to run while maintaining their other daily commitments.
The motivation to run will be enhanced through financial rewards.
Design: Features
The second feature is the running schedule entered by the user. The user must select four days of the week to run. Once the the schedule is confirmed, the user is not permitted to make alterations.
The third feature is the payment or investment. The user confirms they will invest $100 to keep them accountable for keeping their run schedule.
The fourth feature will be the goal selection. The user can decide how far they will want to run. Each goal is attached with a dollar amount they can be rewarded back. The farther distance they run, the higher dollar amount they are rewarded. If a user misses out on a run well, they simply miss the opportunity to win back all of their own money that was invested.
The fifth feature is the tracking of time, distance and calories burned. This is pretty much standard with all running apps. This app will look different in that on the running map you are running towards your dollar goal.
The final feature of the app is the completion of the goal and showing the user they have just won X amount of money back to them. Eventually if they complete all of their goals they basically ran for free and invested in a healthy run.
Design: Wireframe Sketches
My initial sketches were complex filled with different options and steps leading to more unnecessary steps. I asked my fellow peers for criticism, questioning if they could understand the concept I was portraying on my sketches. A majority did find them busy and cluttered so I had to scale back on some of the features and rework the flow of the design.
Design: 1st Iteration
I was ready to prototype my app for a IOS device using the software POP — Prototyping On Paper. I made sure to test the app and not my users. I created 13 frames for my first prototype design. I tested my app on 4 different users and observed them while they attempted use it. I found one user asking me “how is this charging me?” Another user got stuck on the time scheduling page. There was confusion as to how many days they had to select to run. Another user chose to invest first and go straight to the goal selection making the user skip their run scheduling.
Design: Discovered Pain Points
• Users found the running schedule difficult to follow.
• Confusion of buttons disrupting the flow of the app.
• User was confused how they were charged.
Design: 2nd Iteration
I realized that my app was a little flawed and not my users. I needed to make it clear and simple for the users to understand and enjoy. Little work on the user is required in order to ensure a well designed app. I figured out three minor hiccups in my app.
Design: 1st Iteration
I added a clear preface to the app. Registration and credit card information is needed to start. Credit card info stored on the app is how they will invest.
Redesigned the flow of the app to guide the user in a more direct path instead of giving them options out of sequence.
Use only 10 frames and make the user select fewer options. This solved the run schedule page.
Final Thoughts
During my first attempted interviews, I felt confused and unsure of the type of questions I should be asking to be able to obtain enough information to identify a problem. I needed to dig and probe my users. I had to be reminded to ask “why” questions. If I did not ask why the user did not run as often as they would like a week, I would have never come up with the concept for my app. The problem was not the running apps but the frequency and motivation in running. I made bad assumptions that got me nowhere in my research. I realized that I should not design what users tell me they want. I should be designing to what the user needs. This can be difficult since the user may not be able to clearly see what they need. It’s like when I want to drink a sugary soda when I’m thirsty, but my wife insists I drink water because that’s what I really need. Overall, this was a great learning experience and I look forward to future projects.
