Rapid Prototyping: Developing a fitness idea into a mobile app
When given a topic of fitness by my partner to work on as my project 1 in General Assembly. I didn’t have a clue how to work on it as the topic “Fitness” is so general.
Linking to the materials we have learnt in our first week, I started working in this sequence (a little haphazardly since some concepts are still relatively new).
(1) Topic map of fitness: What type of topic to talk about on fitness? A few items highlighted were “Exercise”, “Diet”, “Food”, “Motivation to exercise”, “Type of exercises”, “Frequency of exercising”.
(2) Working on the questions for user interview to ensure that questions are not leading, compound or close ended questions. I realised that all users defined fitness as physical well being/ being physically fit. As such, I refined my interview questions and narrowed down my questions to exercises.
(3) Process of interview and refining
During the process of interviewing, I found a range of answers from regular exercisers who exercise almost everyday without fail to those who did not exercise at all.
I further refined my target group to be people in 20s-30s who does some form of exercise. I encountered many of them exercising casually, some with target in mind (to run 5km or at least 30 mins) and with some who simply just want to feel like they have done some physical workout (I just run until I feel I am too tired to go on. While most casual exercisers could not keep up to their targets, I also found some casual exercisers who were able to keep to their schedule and both of them have a close companion to motivate them.
(4) The concept of affinity mapping is simple but to identify the patterns is hard. I struggled with affinity mapping as I started grouping answers from interviews based on my questions and did not think that the findings were conclusive or in depth enough. Looking through more examples from the internet, checking through with my teacher assistant, I was able to refine further on the groupings down to 4 main categories.
A. I prefer to have a friend to workout with.
B. I have difficulty staying committed to my exercise.
C. I don’t feel motivated to exercise.
D. I don’t set exercise days or targets.
(5) Working out a specific problem statement and solution statement. I gave emphasis to make my problem statement to be specific and simple. With affinity mapping narrow down the categories, I chose to work on the problem of not meeting exercise targets due to a lack of companion in user’s exercise routines.
Problem Statement: I don’t have a companion to motivate me to keep to my exercise targets.
Solution statement: I would like to have a companion to motivate me to keep to my exercise targets.
While most users who exercises casually but fall short of their exercise targets wants to have a companion, they are unable to do so as their friends have conflicting schedules and were not able to schedule a common time to exercise. Also, some does their exercise in an ad-hoc manner — when they feel like heading out to exercise, they exercise.
As such, I considered for 2 group of casual exercisers — (A) Have a close friend he/she can confide to and work with to motivate one another; (B) No friend but still able to get value from the app by having the app “bot” to be his/her companion.
Another area that I considered was linking to simply a close friend rather than strangers as findings from the interviews showed that a companions are usually close friends or kins (eg Dad, girlfriend) rather than a group of friends or even stranger. I considered linking to a couple of friends but dropped it as the target group had difficulty finding even a friend to workout with, less say for a group of friends. One companion will be a good starting point.
(6) Creating a step by step user flow. By using an end-to-end approach of a user using the app, I was mapping the screen flows for me to work on my prototype.
(7) Created a paper prototype first, followed by the digital prototype in Invision. With the paper prototype, I tested it with 2 users. Interesting I found out that casual exercisers do not want to define their exercises goals in detail. (Eg being more lean, gaining muscles, losing weight) It takes away their attention to the main problem of not exercising enough.
In the digital prototype, I removed the “What are your goals” flow.
The end product — an app called FitnessAlly: Linking your friend or allow Fitness Ally to be your fitness companion to a fitter, healthier you.
Digital prototype link: https://invis.io/KABVVGXRP
This prototype brought to you by InVisionAppinvis.io
(1) Leading questions are always lurking nearby.
We often seek to validate our hypothesis and subconsciously hold interviews with leading questions for the sake of getting the validation.
Few way I found out to improve avoiding leading questions are:
A. Craft your interview questions and stick to them (of course, don’t just read out like a robot to your users).
B. Record your interview and review later to refine your questions. This helped me greatly as I cringe when I hear my own voice and cringe again when I realise I gave a leading question or prompting users for a specific direction.
(2) Trusting my interview details and spending time to find out the inherent issue. During user interview, there was a sense of uncertainty on whether there is sufficient information to synthesise any findings. With the awareness of not giving leading questions and gather interview details,I realised the importance of spending time to understand the true or inherent pain points rather than the problems that are sitting on the surface.
When asked further details asked from my interviewees, I realised that most of them are not motivated because there was no social engagement in their exercise patterns.
(3) Keeping things simple. This includes keeping problem statements and solution simple, removing features that are good to have and cover the ones that fits to the solution.
(4) Rapid prototyping and iterations are better than a hi fidelity prototype.
With the first paper prototype, I got to understand from my two users that they did not want to define their exercise goals further and does not feel that there is a value to having the exercise goals screen. If I were to repeat the process again, I will give extra emphasis to doing up a paper prototype so that I can test out the idea quickly to users and refine the features after getting their feedback.
(5) There is a purpose to every screen and interaction.
Every screen or buttons should be on the app for a reason. Not to put in screens or sign up users when there is no need for your solution.
(6) Prepare, prepare, prepare.
Buffer your time and work towards key milestones to ensure you have time to prepare for the presentation, be mindful to keep to 5 minutes during presentation and have your screens ready to show to everyone!
I did my due diligence but fell short by over-presenting! I will definitely be more mindful in my future presentations to get my words more succinct.
(1) Spend more time on my paper prototype rather than creating a relatively hi fidelity prototype.
(2) Refining the app so that the idea and solution is simple and directly solve user’s issue.
(3)Test and iterate further. With just 2 users testing on the app, it was inconclusive whether the 2 users will prefer having one friend as the main motivation driver or to have multiple friends. Also, to consider new features such as alternative exercise by identifying the weather for scheduled workout days. Eg if you wanted to swim on Wednesday but weather forecast is gloomy, the app will be able to suggest something indoor to allow you to continue your exercise schedule.
It has been fun, stressful and rather intense week to work on the first project. The practise on a UX process is invaluable and helps all of us in the class to sharpen our skills. I look forward to future challenges while learning to keep to my time better, focus on getting valuable interviews and iterations, especially on paper prototype and finally, to present in a more succinct manner!