UX Design, UX ResearcH | Georgia tech | sketch, invision studio | 2019
This project was the jumping off point of my time in GaTech's MS HCI program and was a learning experience of working within interdisciplinary teams. Being the only one on the team with previous design experience, I quickly recognized the value in advocating for the design process and was able to steer the team to a viable solution.
Easing the learning curve of bicycle maintenance.
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.
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 plan development and carrying out the user testing activities. All work and artifacts shown are my own.
Explore opportunities to reduce the learning of bicycle repair, so that cyclists new to maintenance may continue their journey without delay.
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.
Questions were focused around understanding individual experiences of dealing with bicycle mechanical issues while en route.
Cyclists of all experience levels lack basic maintenance habits
A lack of accessible resources is a common factor that inhibits cyclists performing their own maintenance
Visual assets and tutorials tend to be preferred
New cyclists tend to rely on others (friends and professionals) more than their own capabilities
Affinity modeling helped to make sense of the mountains of data we had accrued, and resulted in deeper learnings about our user group.
YouTube and visual resources are preferred over text-based resources
Bike shops are perceived to be too expensive, leading to an apprehension to visit them
Other's experience (be it friends or professionals) is more valued than strangers
Cyclists would be more apt to learn preventative maintenance if it was more accessible to them
Affinity modeling informed our initial set of pain points and user definition.
Cyclists lack the resources to adequately perform bicycle maintenance
Many cyclists simply don't have the tools they need for basic bicycle repair and maintenance.
Those unfamiliar with maintenance rely and depend on others with more experience
Insecurity is common among those unfamiliar with maintenance, with many concerns that they might make a problem worse if they attempt to fix anything themselves.
Community resources are not readily available
Though repair stations exist, they can be difficult to find and the tools may be broken or missing.
Users feel helpless when they are unable to perform maintenance tasks themselves
Feelings of insecurity and frustration are likely to occur when a cyclist begins to fix a problem without guidance, or are unsuccessful in their attempt.
Instruction guides don’t directly correlate to the user’s own bike components or situation
Though instruction guides exist, both in the form of manuals and YouTube videos, it is likely that the repair process with not align with the cyclist's own bicycle.
Leonard the leisurely
"I like to take time to explore my neighborhood"
Eve the exerciser
"I enjoy running errands on my bike"
Pete the professional
"Get me there as quickly as possible"
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.
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 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.
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.
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 intuitively understand how to use this app because it is likely they will not frequently use it, and will therefore not commit it to memory.
Repair Station Locator
Those new to maintenance indicated a reliance on others, be it friends, professionals, or online tutorials, to initially diagnose the issue.
This feature implies a way to prompt the user to indicate what is currently wrong with their bicycle. Functionality must appeal to the user's (presumably) frustrated state of mind.
Many survey and interview participants indicated they don't entirely understand the components of their bicycle, which is another reason they rely on visual assets to help guide them through the repair process. Including a way to easily recognize the part, be it through computer vision or other recognition capability.
This feature implies the necessity for a smart phone with camera functionality, and the dual ability to recognize the part "in the moment" or to be used as a resource for looking up a part.
The most critical function includes walking the user through the repair process. Guidance will ideally ease the trouble of diagnosing and repairing a bicycle if the user is stuck, and might include connecting to a service professional or an automated system that walks the user through the steps.
This feature implies the integration of a guided tutorial or connection to a service professional.
To mitigate a potential lack of resources, repair stations will be discoverable within the user's route.
This feature implies working with a location-based service to accurately locate and guide the user to a repair station.
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.
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.
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.
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.
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
trust in others
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
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.
Life Cycle: Gig Service
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.
Looking for something specific?
You might find it here!
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.
Designed and built by Benton Humphreys. © 2020