atom: Cycling App

atom: Cycling App

With Atom, my team and I sought to provide a mobile space for cyclists to set aspirations and work towards achieving their goals. With this project we would run the whole process of mobile app development, from conception to a final prototype.

Table of Contents

Starting Out.

TEAM:
Lucas Bauer
Justin Chung
Andrew Mayfield
Kevin Vicente-Gonzales

The prospect of a fitness app is an intriguing one. There is no shortage of such apps spotting various mobile app stores, each catering to its own niche in the world of exercise. My team and I decided to challenge ourselves. We sought to create an app that could stand apart from the well-established fitness trackers, by crafting something simultaneously comprehensive and fully committed to the experience of the end user. I love solving a good design challenge, and my team was right there with me.

The vast majority of fitness tracking apps are unsurprisingly running related, considering the ease with which one can step outside and commence a jog. This style of app had therefore been handled thoroughly, with the popular apps garnering large attention from the running crowd. What we did not realize was how seemingly untapped the cycling market was on the app front. This appeared to be the route for us to take, so we did.

Competitive Audits.

Before doing anything, my team sought out app competitors to compare and contrast features both prominent and minute on both iOS and Android operating systems. Each member of the team researched at least one fitness tracking app thoroughly, writing down notes as we went. These notes were then transformed into a list of pros and cons.

After looking through the features of what we considered to be our main competitors, we created some preliminary personas based on how we believed users would want to utilize the end product. These two user profiles were informed by our limited research and knowledge gathered whilst making our decision to create a cycling mobile app and our competitive analysis. We used these false profiles to decide what we should look for in our interviewees and what types of questions to ask them.

In order to learn as much information as possible about the needs of all cyclists, we needed to engage in some interviews. But before we could start performing interviews, we first needed to establish our list of questions and write up a consent form to be submitted to the Institutional Review Board (IRB) for approval. After our documents came back approved, my team and I began conducting interviews.

Prepping For Interviews.

The Interviews.

We began our research with a couple of interviews from convenience samples. One of these initial interviewees was selected at random on the Kennesaw State University Marietta Campus, and the other works for the university’s Sports and Recreation Department in the main office. Each interview was conducted by two team members: one to conduct the interview and one to take notes. The resulting notes were collected in a spreadsheet, and then pared down for concise review.

We were later able to conduct three more interviews. Two of these were held with employees of Kennesaw State University Sports and Recreation’s "Outdoor Adventures”, and one was with a student employee of the Bike Shop in the Recreation Center. Our goal was to have interviews with cyclists of varying degrees of experience, and we accomplished that. As with the initial interviews, each of these was conducted in teams of two.

After completing out interviews, we transformed our information into thick descriptions one to two paragraphs in length. This particular part of the process would allow us to better encapsulate the routines of our five interviewees regarding their cycling habits and to further understand their goals. The individuals were given placeholder names as to not display the real names of our participants.

Interview Descriptions.

Affinity Mapping.

After gathering all of our interview information, our next step was to create an affinity map. We began this process by handing out Post-Its to the four team members. We pulled up our previously composed interview descriptions on the television where we could all see them, and began to write down words that came to mind.

A four minute timer told us that we were done, and we organized the resulting notes on a large whiteboard. This initial round created multiple categories, so we held a few more jot sessions to flesh out each category individually. Once each category was finished, we worked together to organize the words within each category. The final affinity map would then be utilized to craft our new personas.

Crafting Personas.

Following the careful curation of our affinity map, we decided on what our final three personas would be. We believed that our primary user would be an experienced cyclist with some mountain biking experience who bikes regularly for general fitness and competition, that our secondary user would be a moderately experienced cyclist who bikes to stay fit and healthy and focuses on fitting their bike in their normal schedule, and that our tertiary user would be a new mountain biker who bikes for pleasure and is looking for new trails.

We fleshed these ideas out more with basic descriptions of the users’ motives and aspirations whilst using our mobile app.

Context Scenarios.

Now that our personas were created, we needed to create basic scenarios for each persona based on what we believed would be their most utilized features of the cycling app. We set a timer for five minutes and quickly jotted down a basic outline for each individual persona’s context scenario. We then expanded on the outlines to create full stories.

Deciding on Features.

In order to decide on what features would be important to our app, we referenced not only our persona descriptions and context scenarios, but also the features of our competitors as outlined in our competitive audit. Cross-referencing our persona information with the pros and cons discovered through our audit helped us define the most important features for our users.

Key Path Validation Scenarios.

Our context scenarios were then utilized to create a keypath scenario: how the primary function of our application would flow. Each team member took a few minutes to sketch out how we believe this flow would go. Together we decided that our primary task was to view a map and route, based on the most recurring needs of our personas. Thus, our app would put this feature up-front for the easiest possible access.

We simultaneously began working on our validation scenarios. These scenarios would be centered around achieving secondary tasks such as viewing your profile or accepting a challenge from a friend.

Noticing the correlating elements in each of our keypath and validation scenarios, we were finally able to decide on the way the app would flow.

Wireframing.

The next step was to begin our wireframing based on the data collected from our various scenarios. Lucas used dot paper to sketch out the various pages, as the rest of us fed input. Together we worked on implementing as many features as possible, while also trying to keep the design from becoming too overwhelmingly clustered.

Then we brought the page design and flow concepts from the page into Adobe Xd. This final mock-up would then be utilized in the creation of the prototype.

Our First Prototype.

While the wireframing process was imperative to deciding on the structure of the final app, the prototyping is where the design would begin to be implemented. Our team needed to decide how we wanted the final application to look and feel, and these decisions would be made through color choice, fonts used, icon art, and various interactive elements.

We chose a singular color with which to begin our prototyping phase; a very bright blue verging on purple. As we would later find out, while very attractive on its own, this color did not play well with others.

We established a semi-style guide that included potential colors, our font choices which included various weights of the Circular font, and parameters regarding the spacing of certain items from page to page.

Each team member worked on a portion of the app prototype, my personal contribution being the design and function of the feed page. Afterwards, the pages were adjusted slightly to retain style coherence for user testing purposes.

Testing Prep.

Next it was time to begin our user testing process. Before commencing the with actual procedure of questioning participants, we needed to establish a list of scenarios for the users to fulfill as a test of the prototype’s main functions on its 5 main pages.

Tasks:

Ride Page - filter rides to 3 miles and above. Select 4-mile route. Favorite route. Find more information about the route. Exit route. *hit ride icon

 Challenges Page - Check out more info on the Iron Lungs Challenge and delete the Marathoner challenge

 Profile Page - Go to the profile page. Find most recent activity. Find detail stats  

 Groups Page - Browse through some groups and then try to find a group in Smyrna.

 Feed Page - Find more info about a Bike Roswell! Mayor’s Ride. Find more information about the challenge.

 After setting the tasks, we compiled a brief list of questions that would be given to the users after they completed the test. These questions would be utilized to glean additional insight on the beliefs the user held post-test regarding the state of the prototype and help us decide what could be done to improve existing features.

 1.    What is the standout feature of the app?

2.    How do you feel about the color scheme?

3.    Did the content of the page match the icon of the page?

4.    Was there anything you felt was missing?

5.    Was there anything you felt was unnecessary?

We also decided to perform a System Usability Scale (SUS) alongside our test to get a set of quantitative data as well. This test would provide us with a number on the scale from 0-100 and give us a numeric goal to achieve by the end of our testing and refining iteration process.

Usability Testing.

We began our usability testing on the Kennesaw State University main campus during the National Convention for Undergraduate Research (NCUR) where we expected many people would be happy to participate in our research project. We were able to gather three NCUR participants for testing and two interaction designers from our major. We believed this blend of researchers and people from our field would yield the best possible results.

During the tests Lucas was charged as the moderator, me as the observer/note-taker, and Kevin and Justin worked as questionnaire and SUS handlers/distributors. The notes I gathered are as follows:

Participant 1:

  • Filters were found easily, but closing them was difficult

  • Clicked “Quit” to close out of the Iron Lungs Challenge.

  • Preferred the gray version of the Feed page.

Participant 2:

  • Had trouble with the filters. Wanted to tap outside of the box to exit rather than clicking the filter button again.

  • Noted that the route wasn’t still highlighted after exiting its information page.

  • The “Share” button was ambiguous in meaning.

  • Also used “Quit” to exit the challenge.

  • The difference between Feed elements is confusing.

Participant 3:

  • Pulling up more information on the route was unclear. Had to be shown the process.

  • Unsure of where the “Share” button would lead.

  • Feed page is confusing. Achievements look like advertisements.

Participant 4:

  • Opened the “More” filter page to choose distance.

  • Did not know what “Quit” did. Expressed that they believed it could either close out of the pop-up or completely end the challenge.

  • The purpose of the “Share” button was clear to them.

  • Purple makes the Feed stand out, but the Events look kind of like advertisements.

Participant 5:

  • Navigated pretty fluidly, but as seen with others, flaws in the flow of the prototype were prevalent.

  • Reiterated the concerns regarding the naming conventions “Share” and “Quit”.

  • Liked the idea of transforming the feed into a more recognized style a la Facebook or Instagram.

After the test was completed, the questionnaires and SUS tests were administered by Kevin and Justin.

After we completed our 5 usability tests and collected all of our data, it was time to take what we’d learned about our prototype and make changes accordingly.

Notable issues regarding the prototype included the naming of “Share” and “Quit” being too ambiguous, the Feed appearing to be rife with advertisements from multiple angles, some issues with the color choices, and some minor quirks with the filter feature on our Ride page.

For the most part, navigation seemed to come intuitively to our participants as they generally had low to no difficulty completing the prompted tasks. We began to implement these changes to create a second prototype.