Class Project: Running Buddy
This project was done as a part of an upper-level undergraduate course in User Experience Design in the Human Centered Design & Engineering program at the University of Washington during Spring of 2021.
The project was centered around the idea of helping people find motivation to start exercising, specifically running. One of the largest difficulties that people must overcome when they begin running is finding the inspiration to do it often. My group and I believe we can create an application that will contain features that will benefit our users and have them continue running for a longer period.
Overview
Timeframe: 3 months
Role: UX/UI Designer
Tools: Figma, Slack, Trello, Google Docs
Team Members: Danny Truong, Alfie Aguilar Vidrio, Woo Young Kim, Joseph Kang
Interviews (User Research)
Before we started anything, we knew it was essential, in application design, to conduct user research in order to accurately evaluate the needs of our target audience. After many discussions, we decided to focus primarily on college students due to our lack of user groups and time. Each of the group members agreed to interview at least one person with some experience in running. Doing these interviews will help us create our user personas and user journey maps, which humanizes the design process and creates a better and more user-considerate applications.
After these interviews, we recorded the characteristics, goals, and pains of the interviewees while running. A brief description of each of the interviewees is listed below.
Interviewee 1 (D1):
A sophomore at the University of Washington majoring in Computer Science, D1 has plenty of experience running at a high level. He did track and cross country in high school, and runs every day independently. He's a high level runner who wants to run and meet with new friends.
Interviewee 2 (P1):
A sophomore at Georgia Tech majoring in Mechanical Engineering, P1 has an average experience running consistently for the past year or so. He runs around 3 times a week by himself and runs around his school track most times. He has been looking for ways to become more motivated in his running.
Interviewee 3 (A1):
A sophomore at the University of Washington majoring in Business. A1 used to run frequently during her high school years because of track and continued jogging during her college years. However, ever since COVID started, she’s been running only twice a week. She believes that she is not an experienced runner since she runs for fun. She enjoys running around her neighborhood, but is always cautious of everything around her.
Interviewee 4 (H1):
A recent graduate of University of Colorado, who majored in finance and is currently working at a bank. She is an inexperienced runner who is trying to run more often; she currently only runs a few times per month. She is concerned about her safety when running and prefers to run in the mornings for this reason (when there are many people around). She enjoys being out in nature and would like to explore Colorado more. She does not enjoy running indoors in gyms or on tracks.
The results of the interviews were taken and consolidated into general characteristics, goals, and pains that most, if not all, of our interviewees experienced or felt.
Results (Characteristics, Goals, Pains)
Characteristics:
• Student~21 years old
• Prefers to run outside
• Competitively motivated
• Enjoys running solo
Goals:
• Wants to beat his personal record, improve his time
• Explore new places to run
• Hard to find people with similar level of experience
Pains:
• Worried about the COVID-19 pandemic (masks, vaccinations)
• Lots of apps don’t include data useful to him
User Personas
User personas help communicate user behavior patterns and needs in a way that humanizes the hypothetical end-users. This is meant to provide a “person” to empathize with during the design process. These personas help us make decisions based on what would be best for "Ana" and "Matthew", instead of relying on our personal opinions to make decisions.
Our questions during the user research interviews were specifically chosen to provide information for the personas – e.g., each interviewee’s running experience. Once collected, we looked for trends and similarities in the data. Each persona is an amalgamation of different, but real, characteristics from each interviewee.
User Journey Map
To further explore and empathize with the user’s needs, we created an experience map, or user journey map, to follow one of our personas–Ana–through a typical run. Our journey map of Ana allow us to discuss and outline a hypothetical user's emotions, decisions, and interactions and help us identify pain points in the user experience.
Being unable to find friends willing to go on a run was an issue brought multiple times during the user interviews we conducted, and we felt that it would also be an issue that Ana would have based on the attributes we gave her. The user journey allowed us to identify specific issues we needed to address while designing a solution.
Design Requirements
Once we identified our persona's (user) pain points, personal desires, and needs, we were able to map out what information and capabilities our app would need in order for our users to accomplish their goals and stay motivated.
• Discover and introduce new running locations
• Provide accountability for running commitments with other runners
• Communicate user preferences with other runners
• Organize and schedule runs with other runners
• Allow runners to contact each other through the platform and send friend requests
Storyboards
Storyboards allow the designers to create narratives that show a variety of users interacting and using our application. We created storyboards to help us plan out what we want to implement into our application and see how our users respond to those features.
After coming up with the design requirements for our application, designing storyboards were made easier. We now have some idea of what we want our application to do. However, now we have to figure out what additional features we want to include for each main functionality, which is where the information architecture comes along.
Wireframes
With the information architecture completed, we developed wireframes as a draft for what our application layout would be and what pathways a typical user would need to take to get from point A to point B.
Path 1: Find a Running Buddy
The first feature of this app will include the ability to find a buddy to run with!
From the home page, you can click on the 'Find a Buddy' tab and then filter by your preferences, followed by requesting a buddy on their profile page.
Path 2: Find Trails for Running
The second feature allows users to find trails and bookmark the ones that the user likes!
From the home page, you can click on the 'My Trails' tab and then either find new trails by using the search function or to view your existing bookmarks!
Path 3: Running Analytics
The third path is the ability to see feedback and analysis on your tracked runs!
From the home page, you can click on the 'Tracked Runs' tab and then have the application analyze your current run with any of your past runs. The application also allows the user to share their runs so that their friends can see them as well!
Low-Fidelity Prototype and Design System
After figuring out the potential layout for the wireframes, we decided to create a low-fidelity prototype so that we can present it to our future users to test the accessibility and usability of the application. Additionally, we also decided it was time for us to discuss the overall look of our platform and how we wanted our application to be portrayed.
Low-Fidelity Prototype
A low-fidelity prototype allows us to brainstorm and test out any design ideas that we want to implement into the application before it is finalized.
Figuring out the layout of these screens was made possible because of the informational architecture we did previously. With the low-fidelity prototype, our team can conduct an experience evaluation to test out the functionality of the application to ensure that all the interactions make sense.
Design System
During the development of our low-fidelity prototype, our team also focused on creating a design system that not only looked visually appealing but also ensured optimal color contrast for a seamless user experience. To achieve this, we engaged in a collaborative process where each team member contributed ideas on color palettes until we arrived at a consensus. Once the colors were selected, I helped design some of the headers, footers, and buttons for the application.
Experience Evaluation
After creating our low-fidelity prototype and design system, we wanted feedback on our pathways and the user interactions for them. Each of the group members had to find a potential user and have them try the prototype. We presented them with 3 tasks and observed their reactions and how they navigated around the application.
Below will mention the demographic of our users, the questions and tasks that occurred during the testing, and any key takeaways.
PT 1: Megan S.
Age: 22
Occupation: Business student entering the workforce
Tech. Literacy: Average
Relationship: Best Friend
PT 2: Vincent L.
Age: 20
Occupation: Student
Tech. Literacy: Above Average
Relationship: Friend
PT 3: NAME (Anonymous)
Age: 20
Occupation: College Student
Tech. Literacy: High
Relationship: Friend
PT 4: Gizelle A.
Age: 18
Occupation: Student
Tech. Literacy: Above Average
Relationship: Sister
Questions and Tasks
Task 1: Add/find a running buddy
Starting from the home screen, navigate through the app until you are able to find your friend, Jake Farm, and request him to be your running buddy.
Task 2: Share your run
Starting from the home screen, find your past running analytics and share your data with your friend, Jake Farm.
Task 3: Bookmark a running trail
Starting from the home screen, find a running trail that you like, Green Lake park, and bookmark it so that you can come back to it later.
Key Takeaways
• Users reported that the 'My Trails' page is too confusing. For example, the fact that we went into 'MY' trails to find NEW trails was not intuitive
- A recommendation was made to make that pathway more straightforward or intuitive.
• Participants reported that the menu tab on the bottom bar was confusing and needed to be more simple and intuitive.
High-Fidelity Prototype
A high-fidelity wireframe is a complete version of an application with all the screens and interactions finalized. Usually, high-fidelity would require us to code our product, but due to time constraints, we only had to time finalize the look of our application and the general functionality of each interaction. Our high-fidelity prototype was able to incorporate all of our ideas from the other steps into a functioning product. We were able to include the ability to request a running buddy for runners, to find new trails that are safe and near, and to analyze detailed information in regard to your running.
Having the experience evaluation prior to our high-fidelity allowed us to see whether our pathways on the application made sense to our users before we finalized everything. For our final task, we will write a reflection based on our experiences and thoughts throughout this whole application-creating experience.
Reflection
One of the greatest challenges that happened during this project was having to do everything (learning from class, conducting user research, and testing the prototypes) all online. There are a lot of difficulties that come with doing everything online, such as finding people to interview and test with. Doing interviews online, in particular, was a pretty strange experience because it's very easy to miss some of the body language that people give off when they're providing us with responses. In addition, the class was also very demanding at times. We would have weeks where the workload was relatively small and other weeks where we had two, even three assignments due at once. These problems were only exacerbated by the fact that everything was online.
If we had more time, we would like to add additional features that would allow a safer experience for users within the community and within their individual physiology. This idea came from a feedback from one of our classmates during our presentation who expressed concern over harassment or assault during meetups between buddies. Furthermore, another classmate brought up an additional feature that could be added to the app where a runner can self-monitor and record their injuries so that they can keep track of their conditions and look back on records to see if they should rest or run on a certain day.
One of the most surprising aspects of the design process came when we were working on creating high-fidelity mockups of the app's interface. Although we ended with around 15 screens for our low-fi prototype, many of the pathways that we designed ended up requiring multiple versions in order to function effectively as a responsive prototype. The "leave review" pathway of the app, for example, ended up having 4 screens instead of the single screen originally planned.
In regard to the team, we were all able to contribute equally to accomplish each task given to us during the process of creating our mobile application. Even when we were all busy with our everyday life, we still found time to come together and complete each task with the utmost quality. We all learned something new during the whole three-month process of working on this project. We learned to overcome any challenges and adapt to any possible situation that might occur. Normally, this class would have been taught in person. However, due to COVID, we are meeting through Zoom. Everything had to be accomplished online, from user interviews to our experience evaluations. Yet, with that going on, we still persevered through each task and were able to create an application that is easily accessible, easy to use, and easy to comprehend.
Thank you!
