The product:

The service is launched and consists of a bike repair platform that facilitates bike pick-up and bike drop-off services between users and repair shops. It is also a bike ecosystem that provides rental bikes and a bike repair subscription model.

Project duration:

December 2021

The problem: 

Interview data suggests users are confused by the check-out steps and user flow. There are too many and too complex choices during the checkout steps. Some users have also found non-intended ways to interact with the checkout process.

The goal:
A rework of the user flow for the main service. To make it user-centered and user-friendly through a data-driven design process.

Reduce user drop offs and remove unintended ways of interactions with the interface.

My role:

Generalist UX designer helping to develop
a bike service platform

Responsibilities:

User Research, Wireframing, Prototyping, Testing, Interviews & Stakeholder Consultation

BACKGROUND RESEARCH

To make a good product it was beneficial to first understand the competition from a UX perspective. What user needs are already being solved out there, how good are those solutions, and what niches can be identified? I began with a UX competition audit matrix. This became the foundation for understanding the new field I would work in, and identifying the target audiences.

The matrix laid ground for an audit summary report, which revealed several unexpected discoveries. It made clear that the design decisions the competition made were fitting for the niches they owned. A design consists of many parts, and these parts cannot simply be imitated if one aims to improve the user experience for one's own users. For example, some companies catered to sport cyclists by providing high end, powerful aesthetics and a bike passport feature (which required extra set up from the users, but added the benefit of tracking the repair history for each bike). This might be a need for professional bikers, with expensive and resalable bikes. Another company only offered home visits.

Even though they all solve the same need, it affects the whole design. For example, the main competitor offered family repair subscription plans, as well as the choice of which repair person to hire for the home visit. Ensuring the user experience to be like a home visit from the family's own personal home doctor, which has a personal touch to it. These repairmen aren’t from a brick and mortar repair shop, they are rather bike enthusiasts that can offer light repair only. This personal touch shines through the branding and copy all the way, and works great in synergy.

Each step above is a whole other way of solving the same user need; Our company offered a repair service that provided pick up and delivery of the bike, to and from third party brick and mortar shops.

Some companies used mobile apps whilst others used web apps. A mobile app for a repair service works great since it can easily support attachments of both photos and voice messages. On the other hand, the target audience for bike repairs is broad, and its users are not always comfortable with downloading apps. Bike repair service is in itself also at most a seasonal need, rather than being a daily need, concluded from customer data. Mobile apps also bind up much-needed storage space for a user, which can cause users to frequently reinstall every time their repair needs reemerge. A web app, which we went with, will lessen such frictions in the user experience.

ANALYTIC TOOLS

Analytic tools were used to observe how users interacted with the service steps. These tools revealed that users dropped off from the user flow when encountering complex choices in the service steps. Users did not know what products to add to their cart, since they had no expert knowledge of the field.

Users also found unintended ways to interact with the same service. The intended way is that users either let the repair shop decide what repairs are needed, or that users themselves decide and gather everything into a shopping cart. Some users tried to mix these two options into the same cart, causing unnecessary confusion and fees.

Data revealed that 91% of users visited the site on mobile devices, ensuring a mobile-first design.

USER INTERVIEWS

Structured user interviews were conducted to examine the user experience. Focused questions were formulated to gain insights into what user needs were not being met, as well as if the current features of the repair service were even needed or wanted by its users.

One observed theme was that all interview subjects preferred to give a description of the bike problem to a repair shop, and for the repair shop to then make repair decisions. An alternative way to order repair in the current design is that the users gather bike parts and specific service packages into a shopping cart themselves. Both of these methods were currently supported in the user flow, and users often dropped off from the user flow after seeing the overwhelming complexity and amount of choices they could make. Some users even tried to mix these two options into the same cart — an unintended feature which caused unnecessary confusion and fees for them.

The insight was: Removing or hiding complex choices in the service selection step from a default user flow will reduce steps and decisions a user needs to look through to complete an order. This should reduce drop off.

A current feature in the checkout process is that the user must decide which brick and mortar shop will carry out the repair for them. Interviews revealed that no user found this feature and choice of any importance to their needs. Furthermore, observations from analytic tools revealed that users often dropped off the user flow after being stuck in this very same decision step.

The insight was: Removing this workshop choice in the service selection step from a default user flow will reduce the number of steps and decisions a user needs to look through to complete an order, which should reduce drop off.

PERSONA: SARA

Problem statement:

Sara is a busy city-dwelling knowledge worker, who needs to bike for work and picking up her children. She needs a bike repaired because she is unable to transport it in a broken state to a repairer

Persona made from data

A persona expresses a user’s needs for the company. All design decisions should focus on solving user needs. Thus I created a Persona from data gathered through interviews on the street, rather than with customers. This since I wanted to know the needs of all bike users, rather than the needs of only those who are able to complete and order with our service. This persona also had the unexpected effect of making me very happy, and aided me when empathizing with the users.

ANALYSING USER FLOW

The current design was evaluated by a heuristic evaluation method, systematically examining the interface and judging its compliance with recognized usability principles. Observations were gathered and became guiding in the new design. The main take away was that the current user flow had too many paths and methods of interaction, causing unintended outcomes in edge case scenarios. The evaluation did make it clear for me what the current problems were, but it required creativity to know how to solve them. The path we took was to reduce and streamline the user flow in key areas, and by constraining the amount and complexity of choices in the service step.

Almost no user used the custom service features. They simply wanted to describe the problem, drop the bike off and wait for consultation. The idea became that by breaking away the Check my bike feature into a default user flow, users will more likely spot it, be less confused, and become less overwhelmed since they never have to interact with lists of repair parts at all.

Step 1 Select your bike typ

Step 2 Choose service type

Step 3 State your repair need in text

Step 4 Attach optional voice messages & photos

Step 5 Book pick up & Delivery

Step 6 Review order, Confirm & Pay

Prototypes were used for user testing to gather data for further refining of the design before developer hand off. This saves time and resources before implementation

User testing was conducted with screen sharing tools, and by following specific set up scenarios through dialogue which guided users

All font, element and component state color contrasts pass WCAG 2.1 web accessibility standards.

Extra supporting icons help with easier navigation, and reduce cognitive load

What I learned:

A UX competition audit was a speedy way for me to learn the field and target audience I would work with. It helped me to know what and how user needs are currently being solved. In contrast, interviews with both customers and non-customers helped me to understand what needs are not being currently solved, and what problems the current design is causing them.

A structured analysis of the current design through a heuristic evaluation method was a reliable way for me to spot potential for even further improvement in the design. All this ground work was valuable for refining the design before user testing began. These tests, in turn, were important in confirming that the user flow improvements made users finish the user flow faster and with less confusion.

Impact: 

This new, data guided design was successful in solving much of the user confusion during user tests.

However, the design has yet to be practically implemented. Thus its effects on, for example, drop off rates have yet to be observed and measured.

The next step should be to ensure that there are analytic tools in place for measuring relevant user interactions before and after major changes to the user flow. All goals in an organization must be measurable, else they are no true goals.

Implementation of the design and measuring of analytic tool data to examine if user drop off was successfully reduced.

Follow up interviews should be conducted regularly. This generates insight into the user needs, which can then guide design decisions. Another positive side effect of user interviews is that users expressed that they made them feel valued and important.