Timeline:
February - March 2022 (7 weeks)
Role:
Personal project to ship an MVP. I worked directly with an engineer to build the product and sought feedback from designers on content + visuals
TL;DR
Problem: Turba started as a personal problem: cyclists like me had no platform to get requisite info on group rides.
Process: I completed an end-to-end product cycle to ship an MVP. I worked directly with an engineer and sought feedback from my design mentors (Meta, Intuit). I made multiple interactive prototypes, performed user interviews/audits, authored a content style guideline.
Solution: A simple, mobile-first website solely focused on allowing users to create and share group ride profiles.
Results: After receiving positive user feedback, partnered with an engineer to the build the MVP. Halfway through development of the MVP, Strava (the leader in the space), released a feature called Club Events which mirrored Turba’s functionality. I cut the cord on development, learned valuable lessons, but most importantly got validation of product market fit.
PROBLEM
Cyclists need a platform to create, access info, and share group rides on.
As an avid cyclist, I’ve gone on and organized many bike rides of all kinds. They’ve been organized in all types of ways (text, social media, and word of mouth). Each of these avenues has had its downfalls, whether it be hunting down information, or inability to share ride details with others easily. This sparked the question - how might I enable cyclists to have a streamlined way of organizing, finding, and sharing rides? So cyclists could focus less on logistics and more on riding.
COMPETITIVE ANALYSIS
The competition either lacked the ability to plan + share events or address a totally different target customer.
Over two weeks, I personally created, led, and joined group bike rides using numerous services with the goal of understanding both the process of creating and joining a group ride. I learned that the simplicity of messages was great, the events UI on Facebook provided needed structure, and the sports specificity of Strava was a plus. That led me to think, could all these aspects somehow coexist together?
USER INTERVIEWS
Interviewees were 3x more likely to go on group rides if logistics, expectations, and info were streamlined in one place.
I sought further feedback and insights from interviews with fellow cyclists. This included group ride leaders of local cycling clubs, cycling friends, and strangers on the golden gate bridge (man on the street? More like man on the bike). With over 60 interviews spanning over group rides, zooms, and cups of coffee, I asked questions to understand people’s experiences planning, joining, and sharing group rides.
Interview Questions:
Tell me about the last group ride you went on?
How do you find information on group rides around you?
What would you change about finding and organizing group rides?
What essential information do you need to know before a group ride?
What stops you from going on more group rides?
An interview about cycling, while cycling 🚴♀️ 🚴♂️
MAIN TAKEAWAY
What often stops cyclists on going on group rides is difficulty finding logistical + detailed expectations.
A whopping 88% of interviewees stated that they had trouble finding accurate and readily available information for group rides. Those who were able to find enough sufficient information (usually meeting time + location, mileage, details on pace and distance) for group rides often had to dig through 2-3 different sources to find holistic group ride information.
DATA POINTS
INSIGHTS
USER PERSONA
I created user personas to bring life to + define target users.
Why make personas? I decided to create two personas (group ride leaders + people who join group rides) in order to understand other cyclists and other pain points that would be outside of my own experience. As a cyclist, it was easy to lean on my own experiences. Through making personas and imagining other users + their pain points, I was able to broaden my view and empathize with the user.
PROPOSED DIRECTIONS
To find and create or simply just create group ride profiles? That’s the question.
One idea brought up in a substantial amount of interviews was the idea of not only being able to create, view, and share group ride profiles, but to be able to have a platform to find them as well. People especially wanted to find rides that suited their parameters (schedule, pace).
I decided to first explore the feasibility of the latter (creating and finding group rides) by exploring different mediums which included a mobile app, website, and even slack bot/messaging add ons. I created lo-fi wireframes, and interactive prototypes using keynote to test the idea.
Why mobile? Based off of user interviews, 80% of interviewees said that they access directions, info, and updates on group rides on their phones, often when en route to the ride.
I made a clickable prototype in keynote and had cyclists interact with it on their phones to give feedback on the concept.
Feedback + learnings from the prototype:
People thought that speed/pace was vague. Instead people wanted the addition of a ride description, where topics such as pace, skill level, other details could be discussed.
Some were worried about the safety + privacy of creating a group ride. Would creating a ride make their ride public? Or could they make a private group ride profile?
Interviewees thought that a mobile app was too constraining + had too many steps (sign up, logging in, compatibility, etc.).
Mistake: I strayed too far from initial objectives by trying to build too much. Instead I should have focused on simplicity + achievability.
PIVOT: PRIORITIZING CREATING, VIEWING, SHARING RIDES
Narrowing the scope to the minimal fundamentals: Creating, viewing, and sharing group rides…via a webapp/website.
Through prototyping and receiving feedback, I realized that I aimed to solve too complex of a problem. Not only did the social aspect of finding rides bring up privacy + safety concerns, but the sheer amount of features/breadth brought up issues of substantial development time + cost and endless edge cases to account for. I took this as a learning opportunity to press the reset button and solve the problem as simply as possible.
Why a webapp/website?
Comparatively to a iOS and/or Android app, a website’s development + upkeep are cheaper and less sophisticated, yet can be just as effective at solving the problem.
A website can be accessed by nearly all users and by different devices.
Less development time = quicker to market + real user interaction + shorter feedback loops.
BUILDING WORKING PROTOTYPES
Utilizing my website to build ride profiles for real users and real rides.
I began researching ways where I could get real cyclists creating “group ride profiles” for real rides without coding a single line. I explored options such as webflow, zapier, and others, but realized that I could use my own site (yes, the one where you’re on) to create lower fidelity ride profiles for cyclists/users.
I used Squarespace’s form feature to create input fields to mimic the feel of how a working product would eventually feel (Click here to access the live form page). I personally would (in real time), create a ride profile page on my website according to their responses (which were sent via email). See an actual ride page below (Click here to view the live ride page for Husky Cycling).
FEEDBACK ON PROTOTYPE
Viewers and creators alike loved the organization of information but ride creators wished it was an automated process.
Good news 🥳 ! Over the span of a few days, I had piloted a large handful of rides and iterated the design of each page to understand how ride info could be organized and displayed. More importantly, people were going on real rides, and sharing them within group chats + social media.
Seeing this made me so happy 🥲
DESIGN LEARNINGS
While the feedback was extremely positive, some design feedback was given to be considered in subsequent builds.
STARTING DEVELOPMENT
Deciding to put “code to computer” + building the MVP
After receiving positive user feedback and iterating, I decided to go ahead and start mocking up wireframes and eventually a Figma for the website. During the entire time, I was in contact with a developer to understand how feasible building each feature would be. I also built designs and sought feedback on my visuals + content design decisions. I made product decisions based on minimizing cost, getting to market ASAP, and creating the simplest MVP to ship.
PRODUCT DESIGN DECISIONS
4 major decisions + improvements during product development
SOLUTION
Centralization of information + Ease of sharing are 🔑
CLOSING THE PAGE ON TURBA
Strava beats me to the punch 🥊 and the cord is cut on Turba.
Midway through March, Strava launched a product called “Club Events”. The product virtually does what Turba does but has more built in features. As the largest player in the sector, Strava already owns the majority of their users’ lifecycle + loyalty and data (importantly integration of its users’ routes). I decided that it was best to save my own resources (financial and time) and halt Turba’s development. Turba was halfway through development and just a few weeks from launching at this point in time.
CONCLUSIONS + THINGS LEARNED
What I’m grateful for and what I’d do differently next time 🙏 🧠
Being that this was my first full “startup project” with no product and little design experience, I’m immensely grateful for what I learned through the challenges of owning the entire process. I’m especially grateful for friends such as Jen, Sabrina, and Ryan for giving me advice, feedback, and teaching me about content design principles. Special shout-out to Peter for encouraging me to treat this as a real product rather than a hypothetical product and constantly reminding me of engineering tradeoffs/complexities.
Invite failure with humility: With little experience in product or design, there were many times I felt stuck or discouraged during. Whether it be learning that building a feature is too time consuming/expensive to build or struggling with Figma. Towards the end of the project, I realized that all these moments of disappointment taught me something new and forced me to adapt.
Focusing on the essentials: Although I had a rough idea of what an MVP looked like when I started, this project forced me to really consider every small detail and focus on the essentials. Learning how to differentiate between was a “nice to have” and what was an “essential” was a difficult but rewarding learning experience. Trimming off the fat, per se.
Spending more time at each step to research: During this project, I optimized my feedback loops and process with the goal of launching an MVP as efficiently as possible. If I had more resources or was spread less thin, I’d take more time to dive into research, slowing down, and exploring even more options + possibilities. I do acknowledge it was a trade-off that had to be made given the project’s goals.
Listening to users + data rather than personal intuition: Sure, there is a certain amount of personal intuition that is needed to make decisions. But data and user feedback is paramount. At times it was tough to balance what I thought (especially as a user of the product) was best for the product and what user feedback showed. Designing and creating a product is grounded in taking a step back, empathizing, and following the data.
Saying goodbye is sometimes necessary: It’s easy to get attached to something you’ve put blood, sweat, and tears into, only to make the decision that it’s the best to pull the plug. Although it wasn’t the way I wanted it to go down, I understood that I put my best foot forward, learned an incredible amount, and that this is reality. Sometimes it’s bad timing, lack of resources, or just a race. I’ll be back up and at ‘em.
See all notes for the engineer and feedback from designers in the Figma file.