Bobby Reyes
Experience Designer


iOS App

Stridekick is a device-agnostic platform, allowing people with fitness trackers and smartwatches to engage in online fitness challenges through it's web and smartphone applications.


User Research


Information Architecture



User Interface Design




During my time at Stridekick as a UX/UI Designer, I worked on multiple products that were both consumer-facing and B2B. As part of the in-house design team, I helped create shared component libraries, conducted customer interviews, and designed user interfaces for various products.

My experience at Stridekick gave me an opportunity to work on many features and collaborate in an agile environment. While touching every stage of the design process, beginning at the discovery phase to completed user interfaces. These products and features were shipped and iterated on to create an ideal experience for our users and customers.

Friends Feature
Phone Interviews
In Person Interviews
Usability Tests

Competitive Analysis

To address the given challenge of implementing business-driven features for Stridekick, during my process I started with audits of various applications from the fitness industry. My aim was to gather insights, strategies, and best practices when it comes to user-centered design.

There were numerous products that inhabited the same space as we did. As I researched, patterns started to emerge that helped determine what were common conventions users were already familiar with.

Competitors included Fitbit, Garmin and Apple. They all offered similar features but one of our advantages was that our platform wasn't reliant on users owning a specific device. Our platform was device agnostic meaning just about anyone could play, unlike the competition.  


At the discovery phase of each project, I conducted user interviews in order to get a better understanding of their problems. This was a very important part of the process because we got to learn how our products were being used. While also learning people's pain points when interacting with them. This gave us important insights into how we could design better experiences.

Digging into the why was very important because we were ultimately trying to help people change their behavior. This is a very hard thing to do, so we needed to learn what motivated people to take action and stick to a routine. The more people we interviewed and the more iterations we made to our products. We started to see patterns emerge about the people we were servicing.


Our Fitness Profiles

After interviews and research, a pattern emerged among the companies and people who engaged with our platform. Similar types of profiles began popping up and they became recognizable time and time again. Based on this information we were able to develop four user profiles.

We referred to these profiles throughout the entire product development process. It gave us insight into our users behaviors, motivations, and how we could help them achieve their goals.

As a team we knew the importance of empathy and how forces could derail the best laid out plans when it came to fitness. But this also helped us understand that we are each on our own path with different goals and motivators.

User Journey

Interviewing customers and mapping their journeys was a great way to uncover insights into why they chose to interact with Stridekick rather than the competitors. What it revealed was that people have different needs when it comes to choosing a fitness device or app. Price, style, and usability were all very important factors but what pushed people to download Stridekick was being able to connect with friends and family that owned different devices. It didn't matter if you owned a Fitbit or an Apple Watch because, on a device-agnostic platform like Stridekick, anyone could play.

For a user trying to purchase a fitness device, the following details may be true:

  • Context: Users want a way to get healthier and feel a fitness device will help kick start their journey. 

  • Motivation: They want support and accountability that will give them the ability to reach their fitness goal.

  • Pain Points: “Staying motivated is hard but having friends hold you accountable really helps get me moving.”

  • Mental Models: “I want to become healthier and connect with my friends who have different devices."



One of the most popular features that I worked on exclusively during my time at Stridekick was the 'friends' feature. When I began the redesign of version one, users could only view how many steps their friends had taken at certain time intervals. But as we continued to utilize more API'S and pull in more data we were able to display metrics like miles and active minutes.

This also meant we could explore how we could display data and utilizing React Native libraries like D3 which gave our users a better visual experience. Eventually, we added the ability for users to compare their stats with each other over various time intervals. Because our users wanted to see how they compared with each other outside of step challenges.



We were very fortunate to have a user base that wanted to talk with us and contribute to the evolution of Stridekick. After interviewing users it became very apparent how important the friend's feature was to people in keeping them motivated.

I also utilize Intercom to gather qualitative feedback from our users about the current friend's feature. One huge insight that emerged was that users valued their friends and wanted to see their activity. They also wanted to compare each other stats without having to create an individual challenge.


Before I could get into the nitty-gritty of the design process I needed to see where this updated feature would fit. I had to take our existing information architecture into account and how users would typically organize information. Based on the research it was made clear that the logical place for the compare feature to live was inside the friend's section as opposed to the user profile. 


User flow

Since we were allowing users to compare themselves with friends I needed to understand how they would navigate to and through this feature. I wanted to make sure that we had a clear route for our users to accomplish their goal. So I created a user flow before jumping into sketching.



Once the user flows were defined I started my design process with sketches of the new user interface. This allowed me to iterate through many design options quickly.

Due to best practices, we settled on a version that would display a bar graph and a line graph. Line graphs track changes over short and long periods of time. This would work well for users when shorter changes exist. The bar graphs would be used to compare metrics between different users or when changes were larger over time.



After settling on a version I dove into creating low fidelity wireframes for testing purposes. I did usability testing with 3 people and paid close attention to how they went about comparing friends and selecting time intervals.

The testing proved to be useful as I learned people really enjoyed the ability to compare their friends. Also, it was good to see them move through the new flow pretty easily.

But the biggest pain point had to do with navigating through various time intervals. The way you would interact with this component was not intuitive for some. Users also wanted a way to access their closets friends in a quick way.

Based on the feedback I created another iteration of the design but upped the fidelity of the wireframes so I could move forward with the visual mockups.


UI Design

After doing usability testing on the mid-fidelity wireframes I started designing the screens in Sketch. I learned through earlier testing that the decision to utilize segmented controls really helped users find what they needed. 

But there were still some unknowns as I got rid of the compare button that was so prominent in the first iteration. Having the button placed where it was, worked well when a user had a few friends but not when they had over 30. Also, the users now would have to touch the row to reveal the additional actions they could take.

Once the UI was complete I created an interactive prototype do additional testing to learn more. 

*Below you can click through the final prototype of the friend's feature.

What I learned

What I learned at Stridekick

Since I tested early on during the wireframe stage there were not many additional things that needed to be updated. The 5 users I tested with were able to move through the flow easily. The addition of the favorite feature was well-received because now users could access their favorite friends easily. I tweaked how some of the metrics were displayed in the modal which now included 30-day and the all-time average.

Of the 5 users I tested, 3 had difficulty in figuring out how to compare friends. I would have like to test a few more users for that particular interaction. For a future iteration, I would have liked to have added an icon to let users know they could tap on a row to make it collapse.

*Due to time constraints, favoriting friends was not shipped in this iteration.