2019
Sherpa
Mobile app designed to train cyclists new to maintenance, and ease the learning curve of repair.
Sector
Health & Fitness
TEAM
Varnit Jain
Kevin Key
Yunfei Wang
Benton Humphreys
My roleS
Design team lead
SKILLS
Observation
User testing
Wireframing
Prototyping
The challenge
Mechanical problems with bicycles are bound to happen sooner or later. Though many issues can be solved with a quick fix, a surprising percentage of cyclists are unaware of how to perform basic maintenance, which can lead them to spending more time and money than is necessary to fix their bicycle. Further, they will inevitably be delayed en route to wherever they are going.
My role
The team worked to explore a solution for cyclists new to bicycle maintenance, so that they would be able to return to their journey as quickly as possible.

I was responsible for leading the design of this project, including design decision-making and artifact creation for user testing. Additionally, I assisted with the research and user testing. All work and artifacts shown are my own work.
The goal
Explore opportunities to reduce the learning of bicycle repair, so that cyclists new to maintenance may continue their journey without delay.
1
Understand
Online surveys
As a starting point for understanding and narrowing our target user group, we fielded an online survey. We were able to reach a large number of participants and learned high-level characteristics of our users, including maintenance habits and familiarity.
67 respondents shed light on the general landscape of cyclists' maintenance habits, comfort and familiarity with repairs, and how these metrics related to demographics.
Interviews
We then used results from the surveys to generate questions for a brief interview. Questions were focused around understanding individual experiences of dealing with bicycle mechanical issues while en route.
Participants were sourced organically. 5 cyclists provided deep and rich qualitative data on their own experiences with bicycle maintenance.
Affinity modelling
After concluding initial research, we decided to use affinity modeling to synthesize the information we had gathered to find common themes and pain points. We turned the survey data and interview answers into high quality notes for modeling and created the affinity model found below.
Affinity modeling helped to make sense of the mountains of data we had accrued, and resulted in deeper learnings about our user group.
2
Identify
Pain points
The affinity model revealed several distinct themes about our users, which informed the pain points listed below. These pain points served as the basis for brainstorming, and were used a point of reference to validate or justify certain directions, concepts, and features, throughout the design process.
Affinity modeling revealed common themes, namely pain points and areas for opportunity, for our user group.
1
Users lack the resources (e.g. space and tools) to adequately perform bicycle maintenance
2
Those unfamiliar with maintenance rely and depend on others with more experience
3
Community resources are not readily available
Users feel helpless when they are unable to perform maintenance tasks themselves
4
5
Instruction guides don’t directly correlate to the user’s own bike components or situation
6
They have difficulty performing maintenance tasks for the first time
7
Community resources are not readily available
User needs
The pain points and opportunities fed into defining a first pass of user needs, which were geared towards promoting speed and efficiency, and reducing the learning curve for our target user group.
User Needs [         ] to Promote Self-Sufficiency
Personas
Personas helped define our target user group even further, and served as a common point of reference for ongoing design decisions.
3
Ideate
Brainstorming
To facilitate idea generation we brainstormed ideas based on the 7 discovered pain points and the resulting user needs, then grouped similar ideas under umbrella categories. These umbrella categories served as the basis for very distinct ideas, which were then defined further and are presented below.
Diverse thinking approaches in our group led to more unique potential solutions.
Resulting concepts
The second part of the brainstorm consisted of mixing and matching the various features and concepts we had come up with during the first part of the brainstorm. We honed in on ideas that would best promote independence and self-sufficiency for our users, those that would leverage community resources, and those that appealed to a "gig-economy" approach.
Sherpa: Repair App
Northstar: Interactive Kiosk
Life Cycle: "Gig" Service
Personas Targeted:
Sherpa is a mobile application that provides the user with step-by-step guidance for diagnosing and fixing common maintenance issues. The app utilizes the phone’s camera to recognize parts, and prompts the user with questions to help them discover and fix the problem.
Personas Targeted:
Northstar is a concept that redefines what a public-use bicycle repair station can be. It provides users with free-to-use tools and resources that they might otherwise not have access to, and is offered at various locations within urban settings. It is similar in concept to existing repair stations, but has the added element of an interactive screen that can guide users through general repair processes.
Life Cycle is a “gig-economy” service that connects users with nearby bicycle repair technicians. It is a pay-per-use service that can help a user who does not know how to repair their bike connect with someone who does. In the event of an emergency maintenance situation, the user has the option to request a pick up from a certified bicycle technician.
Personas Targeted:
self-sufficiency
trust in others
cost efficiency
self-sufficiency
community resources
convenience
gig-economy
emergency situations

Click to enlarge.
4
User Feedback
Online survey, round 2
We fielded these 3 concepts to users via online survey, and received valuable feedback that informed a refined concept direction. We were able to "mix and match" features from each of the concepts to define a new approach that better targeted the original pain points and user needs.
Overall, users preferred to remain self-sufficient, but most still lacked the necessary resources to perform maintenance themselves.
Identifying core features
From the online feedback we were able to narrow down our concept scope. Users noted that they found "Sherpa" to be the most valuable, and we chose to develop a refined concept using this concept as a basis. Additionally, we generated a lot of valuable feature-specific feedback that was incorporated into the final direction.
Users must inherently know how to use this app, as they will likely not frequently use it, and therefore will not commit much to memory.
Diagnosis Tool
Part Identification
Repair Guide
Repair Station Locator
5
Concept Refinement
Information architecture
I began to structure the information architecture from a high-level, using the defined features as a starting point. To minimize ambiguity, the tasks of each feature would belong on separate pages, but would be discoverable on the home page for quick access.
Though the "Diagnosis," "Repair Station Locator," and "Begin Repair" functions are the most important functionalities of the system, users aren't likely to use one feature more than the other, therefore, all of these are given equal hierarchy.
Quick interactive prototypes
I built the initial wireframes mid-fidelity in order to have a second round of feedback with them before producing anything that might look too "final," which might dissuade our users from giving appropriate feedback.
Though the "Diagnosis," "Repair Station Locator," and "Begin Repair" functions are the most important functionalities of the system, users aren't likely to use one feature more than the other, therefore, all of these are given equal hierarchy.
Mockups
I generated screen mockups for the home page while taking an initial pass at the wireframes. Each concept represents a different method for the user to select the bicycle they want to perform the diagnosis or repair on. The user can create bicycle profiles on a separate page, and utilize these profiles to have more targeted repair processes.
Mockups remained minimal and non-distracting, with the intention of allowing the user to focus on the task at hand and not the interface.
Home page alternatives
Given that use of this app is likely to be infrequent, they probably won't select a bicycle prior to beginning a ride. For this reason, visual priority was given to the bicycle selection feature. While in the app, users can quickly cycle through their bicycle profiles before beginning diagnosis or repair. It would be a time-consuming error to begin a diagnosis or repair, only to discover that the bicycle you were working on isn't the correct one.
Bicycle profile

The user can access the their bicycle profiles simply by tapping on the image of the activated bicycle on the home screen. Here, they are presented with data specific to their bicycles (e.g. manufacturer and model), which they can modify as needed. Further, they can input custom components. This information will better inform the diagnosis and repair processes, and present information that is more pertinent to their use case.
User profile
The user can customize their account by including personal information. This is accessed by tapping the profile icon. Additionally, the user can link their Strava account, which will automatically populate information like miles ridden per bike, and upcoming maintenance tasks.
Diagnose, repair, find a repair station
The main value of the app is with the diagnosis, repair, and repair station locator functions. These are presented in a similar visual hierarchy, as it isn't likely that users will choose one option over another with great frequency.
Sherpa: Repair Guide
self-sufficiency
trust in others
cost efficiency
customized experience*
Sherpa is a mobile application that provides the user with step-by-step guidance for diagnosing and fixing common maintenance issues. The user has the option to use a standard version of the app, which will offer guidance based on the type of bicycle they select (e.g. mountain bicycle, or road bicycle), but it will not be specific to the make or model of the bicycle. The app will use the phone’s camera and computer vision to recognize parts, and prompt the user with questions to help them discover and fix the problem. If the user cannot diagnose or fix the problem themselves, they can use a paid function to connect with an expert, who will be available by video stream and/or an onscreen “drawing” feature.
Northstar: Interactive Kiosk
self-sufficiency
community resources
Northstar is a concept that redefines what a public-use bicycle repair station can be. It provides users with free-to-use tools and resources that they might otherwise not have access to, and is offered at various locations within urban settings. It is similar in concept to existing repair stations, but has the added element of an interactive screen that can guide users through general repair processes. It is designed to be integrated with Google Maps to make discovering repair station locations more accessible. Further, it leverages community input in the form of users reporting issues that inform others of the repair stations availability.
Personas Targeted:
Life Cycle: Gig Service
convenience
gig-economy
emergency situations
Life Cycle is a “gig-economy” service that connects users with nearby bicycle repair technicians. It is a pay-per-use service that can help a user who does not know how to repair their bike connect with someone who does. In the event of an emergency maintenance situation, the user has the option to request a pick up from a certified bicycle technician, who will attempt to fix the bicycle on location, or transport it (and the user, if necessary) to a better location.
Personas Targeted:
6
User Testing & Next Steps
Task-based analysis, results
We sourced 5 participants to take part in a task-based analysis. Participants were prompted to complete 3 tasks in sequence, given little instruction other than the tasks themselves. After noting how well participants completed the tasks, they were given a followup interview and asked to rank the prototype across the metrics of: consistency, customizability, recoverability, observability, and responsiveness.
Looking for something specific?
You might find it here!