SHERPAAn application that helps cyclists perform maintenance and repair tasks
Role I conducted user experience research to guide design decisions and provided technical expertise to judge the feasibility of features.
Team Benton Humphreys, Varnit Jain, Kevin Key, Yunfei Wang Timeline Aug 2019 - Dec 2019
Interviews and Online Surveys
The first step in our research process was to talk to users about their bicycle riding and maintenance habits. We interviewed users and created an online survey to get data from a wide demographic. We were interested in their frustrations and motivations.
After concluding our two research methods, we decided to use affinity modeling to combine the information we had gathered to find common themes and pain points. We turned the survey data and interview answers into high quality notes and created the affinity model found below. After completing the affinity model, we added our own design ideas and questions to areas we found relevant to help with concept generation.
While we liked the ideas and thought were very relevant, we realized we had not given enough importance to our user’s pain points by going straight to design ideas. We decided to go back to the affinity model to find common problems found from our research and then developed those into seven pain points that represent our user group.
Our users are adults who commute by bicycle within urban areas that are unfamiliar with basic bicycle maintenance. In the interest of bringing our user to life, we will be focusing on different types of users by way of a diverse set of personas. These personas are further represented in our use-case scenarios to help personalize and describe our concepts.
After noting down the pain points, we weighed each design idea based on relevance, feasibility, and creativity to weed out ineffectual ideas. Once we had a list of features, we decided to group our design ideas into broader categories based on similar topics. We came up with the following themes:
Post analyses of all themes, we focused on three design directions which solved most of the pain points. We ensured that each design direction was varied and targetted a unique yet overlapping set of user groups.
After we had all of our themes, we further analyzed them based on how many pain points they tackled. Once we had the top three themes decided, we further refined them into concepts by naming them, determining the specific features and functionality of each, and creating brief scenarios to explain their particular use cases.
Concept 1: Sherpa
Sherpa is a mobile application that provides the user with step-by-step guidance for diagnosing and fixing common maintenance issues. 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 an onscreen “drawing” feature.
- Self Sufficiency
- Trust in Others
- Cost Efficient
Concept 2: NorthStar
Northstar is a concept that redefines what a public-use bicycle repair station can be . It provides users with free-to-use tools, resources, and 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 available tools/resource.
- Community Resources
- Self Sufficiency
Concept 3: LifeCycle
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 more suitable location.
- Gig Economy
- Emergency Situations
To test our design ideas, we created another survey to reach out to a wider audience. To achieve the same, we shared the survey not only to bicycling communities but also on famous facebook, reddit pages. This survey focused on Learnability, Efficiency, Memorability, Errors, Satisfaction as well as feature level evaluations. We wanted to know which features seemed attractive and useful to users and which ones felt obsolete to them. We received 44 responses and evaluated which features overcame initial pain points and were appreciated by the users.
Our final solution contains most parts of Concept 1 - Sherpa and one part of Concept 2 - NorthStar. We realized that not a lot of users will want to pay for an expert's advice, they would rather take their bicycle to the shop; so we removed the expert advice feature. We also noticed that users do not carry tools all the time so we integrated the Repair Station Locator feature from NorthStart to display public repair stations.
1. User Profile
The user can set up a custom profile that will allow them to track their use of the app, maintain a maintenance schedule, and connect to the activity app “Strava.”
2. Bicycle Selection
This details the type of bicycle(s) that the user has, and allows them to input custom components. As repairs might be different based on the type of bicycle a user has, a “bicycle profile” can be created.
3. Diagnostic Tool
The diagnostic tool is a feature which helps users determine the problem with their bicycle. Once the option is selected, the user will be prompted with a series of questions.
4. Repair Guide
Once the user knows the problem with their bicycle, they will use the repair guide to perform repairs. The repair guide is a step by step process that tells users what to do. The repair guide has two audio elements: (1) An audio guide which speaks the step that is to be performed (2) Once the step is completed, the user can speak “Next” which moves the system to the next repair step.
5. Part Identification
The part identification tool is used when the user can not recognize a certain part mentioned in the repair guide. Sherpa uses augmented reality to help the user identify the part. The feasibility of the augmented reality tool is supported by the fact that all bike manufacturers have 3D models of their bicycles which can be leveraged to support this tool.
6. Repair Station Locator
The repair station Locator is used in cases when the user doesn’t have the required tools to perform the repair process. The application also shows a list of tools available at any given repair station so that users can decide if a particular repair station has all the tools they need or not.
Due to limited time and resources, we had to perform a discount evaluation, we chose to do the Usability Expert Review, but with the inclusion of task-based evaluation to make the review more holistic. Each session involved two to three people: the evaluator, the facilitator, and an additional note taker. We created a high fidelity prototype (shown below) to test our proposed solution. We split our evaluation into two parts, the usability expert review and task-based evaluation.
Participants- Five HCI cohorts who have been trained to evaluate a design considering usability specifications
Usability Expert Review
We decided this evaluation method should be completed first because it is a hierarchical process that will quickly reveal obvious flaws in our design . Also given the scope of this project, it is much less resource-intensive compared to usability testing with our user group. Each evaluator had to consider the system for the usability specifications- Consistency, Customizability, Recoversability, Observability, and Responsiveness.
After the usability expert review section was complete the evaluators moved onto the task-based evaluation. The evaluators went through each task described above and again were instructed to think aloud to describe their thought process. We asked questions from the participant after each task and avoided giving instructions during the task. After the final task was completed the participants were asked a few questions to further evaluate the design. We asked our participants three tasks that a typical user would perform:
- Task 1: Diagnose your flat tire
- Task 2: Find a nearby repair station
- Task 3: Complete the repair process
We used the qualitative data to rank the priority of issues that need to be addressed. We received the following scored on a scale of 1-5:
(1 = highly disagree, 5 = highly agree)
Once we compiled the qualitative data, we could see the changes that needed to be made on a whole as well as individual level. We saw that some areas (like Consistency) required a more work than others and our evaluation method enabled us to get not only task specific but also screen specific feedback.
We found some general problems including the overall flow of the system and repair process, the ambiguity of icons and button layout, and visual inconsistency within the visual interface design. The feedback from experts suggests that there is a problem with information hierarchy where the whole application feels disconnected and some features are misplaced within the application. At the same time, even the overall flow is clear when experts were given several tasks to complete, there were issues about interaction (highly depending on prototyping tool) that cause problems on responsiveness and recoverability of the system. Apart from all the issues mentioned above, we found that the level of usability and visual representation was satisfactory and the task flow is easy to follow.
The data from the evaluation of the prototype was used inform ongoing refinement of the design. Overall, we found participant reception to our prototype to be positive, and most issues could be solved with simple changes.