Case Study

Finding people nearby to run with

Building Funk Run for Android

“You know, it’d be a lot easier to get motivated to run if I could run with a group.”

-me, May 2017

Uncovering (stumbling upon) the people problem

I was lying on a friends living room floor contemplating finishing the last half of my evening run (the first half was running to my friends house). It was the first time I had ran in weeks and, given my allergy to any kind of cardio, the chances of me finishing the run didn’t look great.

“You know, it’d be a lot easier to get motivated to run if I could run with a group”, I defeatedly told my friend.

“Find some people to run with”, he responded.

But how? I occasionally ran with friends but busy schedules made it difficult to coordinate times. Not to mention most of my friends are in much better shape than I’m in so they don’t exactly enjoy running with me.

And that’s when it came to me. Give people a platform to find a group to run with. I grabbed a Chipotle napkin on my friends table, wrote down the words “group run”, and put it in my pocket.

…I asked my friend to drive me home.

Validating that is, indeed, a problem

For the next couple weeks I asked friends and family about their experience going for runs, staying motivated, and running with other people. I did not ask them what they thought of my solution or jump to calling it an app. I chose to focus on validating the people problem.

Validating the problem of staying motivated to run was easy; however, not everyone saw finding people to run with to be a problem because about half of the people I spoke with preferred or strongly preferred to run by themselves. Understandable.

The other ~half of people I spoke with regularly ran with or at least liked the idea of running with a group. When asked about the problems they encountered when finding a group to run with, most responded with pain in coordinating schedules, finding people that were in their endurance level, and generally not knowing the best platform for find groups to run with.

So I hit the interwebs in search of solutions to our problem. The highlights of what I found include Meetup groups, Facebook groups, Road Runners Club of America, and Run Club. Many of which had 3,000+ members in the San Francisco/Bay Area.

For a small personal project, I had seen enough to validate the problem.

Knowing once we’ve solved the problem

Since this was a small personal project from the start, I didn’t put much effort into defining success in a concrete way. I only knew that, should we solve this problem, people would easily and quickly find a group to run with through our platform and would return to do so multiple times per-month.

Placing bets (and what we hope to achieve by doing so)

Based on my talks with friends and family — err, I mean, my user research — I believed I had a solid starting point to develop hypotheses as to what a solution should include. Bets are written from the user’s perspective.

Bet 1: Immerse me into the action quickly.

When I first joined Yik Yak in 2014, the app had a three step onboarding flow — permission to use location, permission to send push notifications, and agree to Terms of Service/Community Rules. That’s it. No email, no phone number, no walk-through, etc. As we added more friction to the onboarding process (phone number verification, handles, etc.), we watched onboarding conversion decline. I wanted our group run solution to be as frictionless as possible in order to maximize onboarding conversions.

Bet 2: Show me the experience will be relatively safe.

A common concern in online-to-offline products is safety. I’ve long been inspired by how game-changing companies like Airbnb, Lyft, and Uber design trust into their experiences. Designing trust into our solution would help ease concern that the user’s safety may be in jeopardy by joining a run.

Bet 3: Let me go for a run now.

I wanted to encourage a level of spontaneity in the app while still allowing runners to schedule runs in advance (“Let me go for a run in the near-term” just didn’t have the same ring to it). By encouraging runners to run in the near-term, we minimize the chances that life gets in the way of the scheduled run which, in turn, maximizes the chance of the user going for the run. Going for a run = endorphins rushing = positive feelings toward our platform.

Bet 4: Place me in groups that match my endurance level.

If users joined group runs that severely outpaced or under-paced their level of intensity, I knew they wouldn’t return to the platform. It was important for us to match users with groups that fit their speed and endurance.

Bet 5: Put a memorable brand behind the product.

I wanted the app to be funky and took inspiration from the 70’s disco vibe and lava lamps. I named the app Funk Run and bought the domain funk.run (yes, it’s live). I thought the memorable brand would differentiate the product from existing solutions and further reenforce that the platform was a community of people with shared interests and values.

Designing around our bets

Flow & Wireframes

I rushed to get a prototype out quickly in order to (1) get feedback from potential users and (2) show Mike (the Android developer) I was serious about the project.

While I won’t cover every step in the process, here’s a look at a late-stage wireframing session after paper prototypes had been hashed out.

Special thanks to Svilen for inspiration!

Iterating based on feedback

After feedback from friends, family, and Mike, we were confident enough in our flow and wireframes to begin designing high-fidelity screens. Screen-by-screen, we designed the Funk Run experience in high resolution.

Once a few high-fidelity screens were made, we wasted no time getting user feedback. Here are two parts of the app where we found user feedback especially helpful in our iterations.

Permissions screen. The original iteration of the permissions (left) didn’t include why we wanted permissions. We found it was important to some users so we added a short description for each that was in-line with our brand (right).

Our first iteration didn’t explain why we needed the permission. User feedback led us to the second iteration.

Run cards. The most challenging piece of the project was communicating the platform’s value on our home screen. User feedback helped us understand just how important the home screen would in communicating what the platform does and what action the user should take to derive value.

A few iterations of the “run cards” — the preview of the group run shown on the home screen. The latest iteration shown bottom-right.

Throughout the course of several feedback → iterate → repeat sessions, we learned a few things that would prove key when communicating the product’s value and what actions the user should take to extract that value on the run cards (above):

• Showing a profile picture on the card communicates that an actual person organized that run.
• Showing a preview of the intended route of the run helps people decide if they want to run through certain parts of town (safety), see scenic views, or avoid large crowds.
• Emphasizing the CTA of quickest path to joining a run clearly communicates the next step.
• Displaying minutes per-mile pace lets runners measure intensity of a run. This is important information to know when deciding whether or not you can “hang” with the group.
• While creating a great brand around the platform was an objective, users prefer more obvious terms like “Join Run” over a more branded term like “Let’s Get Funky” or “Mild pace” over “Mildly funky”.

What we’re shipping

A few screens and flows we plan to ship, shown in the context of our bets:

Bet 1: Immerse me into the action quickly.

Bet 2: Show me the experience will be relatively safe.

We designed trust into the app by requiring every user to sign up through Facebook, showing profile pictures of the run organizer, and letting run organizers leave a personal note about the run.

Bet 3: Let me go for a run now.

Bet 4: Place me in groups that match my endurance level.

Bet 5: Put a memorable brand behind the product.

1: inspired by lava lamp and Tubik design

Reflection & next steps

It’s been a fun and stress-free environment so far and I’m excited to see the product launch. I’ve mentioned this a few times throughout the Case Study, but this project was always a side project meant to help Mike and I understand how one another work and help us grow our respective skill sets. And we might have even had a little fun along the way.

Next Steps

1. BUILD! We’ve made prototypes, tested with a dozen people , and spent hours iterating on our solution. Now it’s time to build. 😁
2. Define our user. I didn’t create a user persona at any point in the process and, at times, thought I lost focus on the user we were building for. Are we building for people that are having a hard time getting motivated to run (like me)? Are we building for avid runners to meet other avid runners? Both? I’d like to reevaluate and define who exactly our user is.
3. Learn and continue iterating. I’m excited to see how people use the app and start experimenting with a few iterations within the app. Specifically, I’m not convinced the run preview card is where it should be and would like to A/B test a few versions and see how each perform.
4. Get help with brand. Brand design certainly isn’t my greatest strength. And while I think this may be a later-stage thing, we could certainly use some help with iconography, illustrations, copy, and logo design.
5. Design for accessibility. While I couldn’t prioritize this at the stage we’re at, designing with hearing-impaired or visually-impaired runners is on our roadmap.

Thanks for reading! See more work at zackhargett.com or say hello: zackhargett@gmail.com.