🚴 E-Bike Usability Testing
OVERVIEW
As part of GM’s urban mobility initiative they had decided to manufacture an E-Bike to meet the needs of users in urban areas that don’t use personal vehicles to get around. This product was meant to be purchased online whereby it would be delivered to your residence.
A customer’s first hands-on-experience with the product is having to remove the bike from a large box which includes in addition to the bike - the pedals, a charging cable, tools for assembly and a Quick Reference Guide (QRG) that provides all the necessary assembly steps.
The goal of this particular project was to identify any usability issues associated with the QRG such that appropriate changes could be made to ensure a user-friendly, intuitive unboxing experience.
ROLE
Visual Design, Prototyping & Testing
May -July 2019
Vehicle manufacturing companies that hope to remain competitive in the transportation business will have to deliver mobility solutions beyond that of a personal vehicle. General Motors is no exception.
Background
The purpose of this project was to validate (or invalidate) the effectiveness of the Quick Reference Guide. To ensure that a customer has a pleasant, user-friendly unboxing experience is to ensure that the QRG accurately and concisely conveys the necessary assembly steps to the customer.
We conducted usability testing over the course of a two-day period whereby 14 total participants were tasked with unboxing and assembling GM’s eBike.
The Protocol
For this user-testing session to be credible we had to ensure that the experience we provided our testers very closely matched the experience customers would have at the time the bike was delivered to their doorstep. With that in mind, we contacted 14 internal GM employees of varying employment backgrounds for the purpose of representing the diversity of individuals who could purchase the bike. Each participant was granted an hour time-slot wherein they were presented with a large cardboard box containing everything it would, had it been shipped to their doorstep.
The participants were then asked to speak aloud their thoughts and frustrations as they progressed through the process of assembling the bike – with no further instructions given. As the bike was being assembled the team recorded observations to capture the quality of experience the participant had.
Observations & Insights
While one person from the team was in the room with the participant, two others were in another room affinity diagramming observations in real time. These observations are documented in the images below.
After the first round of testing was completed, our team identified the main issues to be:
Fastening the pedals. The QRG does not make it clear that the pedals are reverse threaded from one another and thus the left and right pedals must be fastened in opposite directions from each other. Many participants attempted to fasten the pedals in the incorrect direction. If enough force was applied, permanent damage could be done to the aluminum threading of the bike’s crank.
Recognition of handlebar clearance gap. There exists no indication in the QRG that a couple millimeter clearance gap must be present to allow for the handlebars to be rotated seamlessly without resistance. Failure to do so could result in the gridding of metals and the degradation of bike quality.
Bike control confusion. Participants consistently expressed the need for clearer diagrams, citing “pages that provide information on controls do not serve their purpose,” and “I’m confused about the diagram orientation, I would like to see it from the rider’s perspective.”
Mandatory app? With the emphasis the QRG places on app features, participants were led to believe it was a requirement as opposed to an added feature meant to enhance a rider’s overall experience.
Prototyping
The evening following our tests myself and another co-op student compiled the high priority insights gained throughout the day and took to Sketch to mock-up an improved version of the QRG; a version that was more intuitive to understand, and that provided only the most important details in a clear and concise manner. Some of the bigger changes made are documented below!
The original QRG failed to successfully communicate basic bike controls to the customer. The first iteration controls page provides a combination of bike and app controls. For individuals not interested in the ‘app’ component of the bike, upon seeing the left-side column of app related controls along with the app display, they often skipped past the page without recognizing the presence of basic bike controls.
To alleviate this issue the decision was made to split bike controls and app content into different pages. GM wants its customers to be aware that the app is merely value added, not required. By separating the information into two pages you give your customers who are not interested in the app the opportunity to skip past that information without missing crucial instruction on how to properly operate the basic bike controls. As a by-product of the decision to split the two topics, a more detailed breakdown of bike controls can be provided in the same amount of page real-estate occupied previously.
To prevent customer frustration associated with not understanding why fastening the left pedal using the “righty-tighty” method would not work, changes were made to the QRG that provided improved direction.
To alleviate any miscommunications associated with left pedal vs. right pedal instructions, we broke up the content into two distinct sections. While the steps of each respective section may be redundant, it was agreed that the benefits of doing so (decreased chance of customer miscommunication) outweighed the costs (potential damage to bike resulting from miscommunication).
Additionally, new pictures were taken that provide a more accurate representation of the pedal fastening process from each side of the bike. Arrows were included to indicate the direction the customer must rotate the wrench to correctly fasten the pedal. Direction of rotation was also explicitly stated in the numbered breakdown for both the left and right pedal.
The original QRG made no mention of the need for a clearance gap between the base of the handlebars and the point where it forks at the wheel. To ensure the user is capable of making a turn as they would on a regular bike, a 5mm gap must be accounted for to allow the handlebars to rotate without friction. To increase the awareness of the issue, a fourth instruction was added that speaks directly towards the necessary inclusion of the clearance gap (see step 2.).
The original QRG contained a total of three pages of app related content (how to download, app controls, pairing the tracker). The result of this surplus of information was the customer belief that the app was necessary for riding the bike, rather than the intended purpose of providing value added to the customer experience. To ensure that customers truly understood the app was merely added value we condensed all app related content to a single page. This page provided information on where to download the app, how to pair the app to your bike, and most importantly (from the perspective of the customer) what benefits the app provides to users.
We focussed on highlighting the capabilities of the app and how they might apply to the life of our customers, whether interested in distance metrics for exercise purposes or turn-by-turn navigation when exploring new places. Enough information to perhaps peak their interest but not overwhelm them.
Design Validation
With the revisions to the QRG in place, our team headed into the second day of testing with five key benchmarks for success. Based on the first day of testing, we identified the five largest issues customers experienced and placed emphasis on mitigating these issues through the changes made to the QRG.
Some key takeaways from this project are:
Always test. If you try to design a product without any consideration for your users and how they will interact with your product - you will get it wrong. Design is a constant iteration of improving the experience for the end user. Always find ways to collect and listen to your user’s feedback.
Work together. What was scary about this project was the fact that our test team wasn’t brought in to help until it was almost too late, until the only thing that could be changed was the QRG. It highlighted the importance of having the engineering and design teams working together throughout the entirety of a project.
Prototype to learn. We were operating on a very tight timeline when prototyping the updated version of the QRG, worrying about the exact details of things could have severely ate up valuable time. Focussing on providing just enough detail for us to learn something about how the changes made impacted our users was key in having a testable solution for the second round of tests.