UX/UI Case Study | The Pedaler
--
Overview
Timeframe: 4 Weeks
My Role: Lead UX Designer/Solo UI Designer
The Team: Adam (UX/UI) and Annie (UX)
Tools: Sketch, InVision, Illustrator, Photoshop
Deliverables: Mobile Application Design (high-fidelity prototype)
UX Methods: Research, Competitive analysis, Surveys, Interviews, Contextual Inquiry, Affinity Diagrams, Personas, User Scenario, User Flows, Content Audits, Feature Matrix, Lo-Fi & Mid-Fi Prototyping, User Testing
UI Methods: Domain Research, Typography, Illustrations, Visual Language, Colour theory, Style Tiles, High-Fidelity Prototyping
Introduction
Getting lost seems to be a regular occurence that happens to most people when it comes to exploring a new place. Finding a way to solve this problem with navigation apps such as Google maps and Apple maps was a leap in technology advancement. Since these Navigation apps were developed, they have become a huge part of everyday life in the average citizen.
“What if you could make a company specific navigation app that improves upon industry leading navigation apps”?
With this question, I now introduce The Pedaler.
About the Pedaler
The Pedaler is a bike rental shop that offers guided cycling tours, and self guided cycling tours around Victoria, BC.
The Problem
Our client, Charles, came to us in our first client meeting with a problem that he needed solved through an app.
His current problem is that when he sends his customers off on The Pedaler’s custom self-guided tours, they often get lost. This is because he has a current physical map system in place to go along with a long list of directions and google street view images of difficult turns. He gives this to the customer, and then he spends 10 minutes explaining the route to them which is very time consuming. During our first client meeting, he told us that his current process was very frustrating to the customer and they often complain about getting lost. Not only do they get lost, but they don’t like the inconvenience of having to pullover on their bike and having to pull out a big map and a long list of directions to find where they are and where to go. They would just like to enjoy their tour of beautiful Victoria without the hassle.
Goals
Charles informed us that he hoped to get a navigation app designed for The Pedaler so that he could finally eliminate this problem.
Charles is planning to have phones mounted on The Pedaler’s bikes so that the app will be ready to navigate as soon as the customer leaves the shop. All the maps for each route will be downloaded to the phone so that a phone plan is not required.
Why not Google Maps? - You might be thinking, “Why doesn’t Charles just use Google Maps”? Our UX team asked him why he doesn’t just use Google Maps and he said he doesn’t want his route to be publicized and shared on Google Maps because that defeats the purpose of The Pedaler’s custom routes. He also stated he wants an app thats branded with The Pedaler to add value to his company.
With that, we realized we wanted to take on the challenge of branding a navigation app for The Pedaler as well as trying to improve upon current navigation apps.
Following our client meeting, we went more into depth with the overall goals
UX Design Process
This will be the process to which led to the final high fidelity prototype of the app.
Research
Domain Research
We began by looking into various navigation apps such as Google maps, Apple maps, BikeMap, and others to get a brief overview of how their app functions. We collaboratively pinpointed any common or interesting features that Annie and I noticed.
Competitive/Comparative Analysis
We gained a good understanding of the features on these navigation apps and what they had in common through our domain research. Following that, we put together a chart to show what feature each app had. We then figured out a niche that The Pedaler navigation app could fit into that none of the other apps provided.
The custom notifications for turns feature niche was a key finding we found from our contextual inquiry which I will get into later on in the case study.
Survey Results
Following Domain research, we brainstormed the best questions to ask and conducted a survey directed to both cyclists and tourists. We did this to learn more about their self-navigation habits and factors they find important.
Total Survey Respondents: 14
Key Questions
- How do you primarily check for directions while self navigating?
- When planning a bike route or trail, which details do you find most important?
- How would you like to receive directions while self-navigating? (ie. reading, audio, or visual cues)
Key Findings
From this question, we figured out that majority of drivers/cyclists will pull over to check directions. We also found that fewer people preferred to listen for audio directions, as they found it unreliable due to the risk of mishearing, misinterpreting, or receiving them too late. This was an important piece of information because we got a better idea of the users navigation habits.
With this response we figured out that elevation, distance, and duration was most important to the cyclist. This was a key piece of data for our design because we could then include the most important details so the user isn’t overwhelmed by details.
Contextual Inquiry
After developing our survey we went into our contextual inquiries this is where we conducted interviews with business owners, cyclists, and tourists. We went to City Cycle who offers similar services to The Pedaler. We also went to Ezee riders who offers electric bike rentals. Unfortunately, we were unable to go to the pedaler in Victoria due to travel constraints.
For our interviews, we asked similar questions as our survey for validation in our survey findings. We would ask these questions to cyclists.
We asked the owner of City Cycle more about their business.
Key Findings
The Owner of City Cycle found that:
- Majority of bike rental customers were tourists with friends or family
- If people get lost it’s rare but when do they call the shop
- City Cycle has the same physical map service as The Pedaler in place
Tourists and Cyclists found that:
- They miss directions while cycling with their current self-guided navigation method due to late warning
- The most important features were elevation, duration, distance, and surface type
- 90% of all customers were tourists
Based on these findings, we had validation that elevation, duration, and distance were an important feature to include on our route. We then had to figure out the best way to notify our user so that they don’t miss their turn. This is because missing turns because of late notifications was a common response from most self-navigation app users.
MVP
Following the research phase and our second meeting with Charles, we developed an MVP which is a minimal viable product. The MVP has just the core features that allow the product to be deployed, and no more. We do this to get a base of what we are designing for.
Planning
Affinity Diagramming
Affinity diagram is a method that we used to gather all of our data points from the survey, interview, contextual inquiry, and grouped them to find patterns and themes.
We then to related all of our ideas to our user persona.
Here we collected all of the data and summarized our data into key findings. This was based on our research demographic, pain points, goals, needs, and existing and potential features of favourite navigation apps. We then used this data to create our user persona.
Persona
Based on our data and research we developed a user persona. Jacob is a tourist from Seattle, WA. He is currently on vacation in Victoria with his girlfriend and looking to learn about the city through activity.
Key Goals
- Wants to learn about Victoria at his own pace
- Wants to bond and get activity with his girlfriend
Key Pain points
- Afraid of getting lost
- Can’t hear audio self-navigating on his bike
Feature List and Matrixes
Based on our overall research, we affinity diagrammed a feature list matrix and started organizing the features into categories of what’s needed, nice to have, and not needed.
User Scenario
A user scenario is a snippet that describes context, reason and motivation of a particular user persona having a need to use your product.
This gives us a better idea of the situation for how our user, Jacob, would be using The Pedaler app.
User Flow
We then created our user flow based on the data we collected which is a screen to screen flow of how the app is going to work. This gave us the foundation for the design of the app.
Design and Testing
Low-Fidelity Paper Prototyping
Important Design Decision
From the survey and interview data, we knew that cyclists frequently miss their turns because they’re either going too fast or they simply can’t hear speech directions. We decided to include three different variations of more audible notification dings.
- The first notification ding when you hit an 100 meter radius (one block) of the turn
- The second ding when you have to turn at that moment
- The third ding when you have missed a turn
Rough Paper Prototype
We first started out by getting our flow on to a really rough paper prototype.
We then cleaned them up into testable clean paper prototypes.
Paper Prototype Design
We decided to implement a custom notification system for difficult turns that cyclists frequently miss during their ride. This was because Charles currently provides google street view images of specific difficult turns. This is where a bulk of his customers get lost at.
Paper Prototype Testing
User Testing Tasks
We gave the user six tasks to do while testing. All of these were influential in the design of the app as we wanted to make the users experience as seamless as possible.
We originally had a bar for the user to scroll up for more details, but through testing, it wasn’t obvious enough for the user. We added an arrow for the user to tap for expandable details. This got positive reactions from testing.
Final Paper Prototype
Mid-Fidelity Sketch
Design Progression
We began digitizing our Low-fidelity prototypes into Mid-Fidelity screens on Sketch. We decided to remove speed, time elapsed, and distance elapsed because even though we saw it on other bike navigation apps such as BikeMap there wasn’t enough data from our surveys and interviews that justified that design decision.
From data we could justify that estimated time and distance of the route were most important, but we decided to hide it in the scroll up details because through testing it distracted the users from navigating. It also steered away from the MVP which is getting from point A to point B without getting lost.
Another improvement we included from testing was to integrate colour changes to increase visibility of important notifications. Users found that this grabbed their attention more.
Finally, we added information that gives you information about the landmark at the end of your route.
Usability Testing Key Findings
- Extra elements take away from the navigation aspect.
- Hiding unnecessary details from the live navigation, to increase focus on navigational features such as the map and turn by turn directions.
- Increased visibility for directions using colour changes, popups, and audio
- Adding a pause button to allow users to stop during their ride to look at other interesting sites.
- Adding a custom notification feature to highlight difficult turns, to further prevent the user from missing them.
User Interface Design
After the final Mid-fidelity prototype was finished, I decided to take it upon myself to explore the user interface design.
Mood and Colour Palette
Being the fact that the project goal of The Pedaler app is for the user not get lost, I chose a colour palette that is calming yet gives an exploratory mood to the user.
Purple: represents relaxation and serenity
Blue: represents exploration and reliability
Voice and Tone
Giving the user a sense of curiosity and excitement was important with the voice and tone. I also wanted to give the user a feeling of accomplishment being the fact that they just biked a long way to their destination.
The choice of the rounded style gave the user a sense of welcome and friendliness with the app.
Typography
With the typography, I wanted it to be clean, and legible for the user because they will be looking at their phone from a distance on a bicycle. This is why I went with Open Sans and Proxima Nova as the header and body.
Since The Pedaler brand is already established and on their shop. Charles informed me that he did not want to rebrand. This is why I stuck with the current logo in Oleo script. To make the logo stand out and not flat, I added a shadow to it, this made the logo more appealing.
Illustrations
To give the app more life and appeal, I decided to add location and biking illustrations. I intended for these illustrations to give the mood of explore and activity to the user.
High-Fidelity Prototype
Future Considerations of the App
- Add colour coated lines of specific surface types (ie. Shared road, dirt road, single road) in the map overview. This gives the user a better idea of what to expect along their route.
- Add a popup that shows construction ahead so that the user is more aware.
- Add an educational and historic aspect to the landmark information.
- Add a landscape mode so the user can turn the phone and get a wider view.
Conclusion
Overall, I had a great experience working on this navigation app and I would enjoy working on more activity oriented projects in the future. Our client, Charles Horn, was great and fun to work with. We hope to stop by The Pedaler and take a tour one day.
