Transport for London/Santander Cycles
Simplifying + streamlining the hiring and journey planning experience
Client
TFL/ Santander Cycles
Role
UX/UI Designer
Sector
Travel & Transport
Duration
2 week design sprint
Overview
Concept team project to create/redesign a mobile app for TFL/Santander cycles. TFL’s goal is to increase ridership of their bikes particularly during peak times to decrease traffic congestion on the road and increase revenue to the city.
I worked in a team to create a working high fidelity prototype of a native mobile app which has an onboarding process, journey planner, bike hiring system, reward system and payment portal.
My role
This was a group project with 2 other UX/UI designers where we followed the design thinking “double diamond” approach. We conducted our own user interviews, user testing and synthesised our results together.
I took the lead on the UI design and style guide but also had a hand in as much of the UX processes including, user research, personas, onboarding, feature prioritisation, wireframes and the final prototype.
Empathise
How does the app function currently?
To start our research we decided to take a look at the current state of the mobile app, to understand how it works. We then hired a bike using the app, reviewed the app's functionality, and took into account areas of confusion. The main areas for user pain points were during the registration/signing in, the payment portal and also when planning a journey. We also took a look at user reviews on the app store. 4 clear highlights from the reviews were; hiring frustrations, lengthy-signup registration form, bad journey planner, poor usability.
What are users saying?
We also set out to conduct user interviews with users and non users of the ride sharing platform to understand why users don’t use the platform, what issues are present on the current platform and how do users think the platform could be improved. We interviewed 8 people aged between 20 - 30.
We aimed to find out:
1. How and why users use ride sharing platforms.
2. How users travel around London during peak hours.
3. Users current knowledge of the London cycle network.
4. Experiences users had when hiring a Santander Cycle.
5. What barriers/safety issues users had when cycling in London.
2. How users travel around London during peak hours.
3. Users current knowledge of the London cycle network.
4. Experiences users had when hiring a Santander Cycle.
5. What barriers/safety issues users had when cycling in London.
The results we got back showed that users had issues with:
• Proximity - Bikes are limited to docking stations
• Payment process - Tedious payment process
• Hiring - There are bugs in the process and it is an unclear user journey
• Journey Planning - dysfunctional journey planning feature
• Payment process - Tedious payment process
• Hiring - There are bugs in the process and it is an unclear user journey
• Journey Planning - dysfunctional journey planning feature
We completed an Affinity Map exercise to synthesise our findings
Conducting an affinity map in our user research allowed us to distill a wealth of qualitative data into key insights, visually organising user sentiments, pain points, and preferences.
What are our competitors doing?
We also reviewed competitor apps to understand what they did well and how they tackled user issues. We looked at their registering and signing in process, selection and hiring functionality, onboarding and safety features and also how users pay.
We created a feature matrix to compare and contrast features of competitor apps. This helped us later on in the project with feature prioritisation.
We created a feature matrix to compare and contrast features of competitor apps. This helped us later on in the project with feature prioritisation.
Define
Meet Marcus
To better define our target user, we created “Marcus”, a persona that reflected our research findings.
Marcus’ Problem Statement
'Marcus wants a fast hiring process in as little steps as possible so he can step off the overground train and get on a bike to work when he feels the need to bike.'
User Journey for Marcus
Ideate
HMW Questions
We completed a ”How might we?” exercise where we thought of 10 of our own then brought them together to decide on just one.
The most true and concise one we went for was 'How might we provide Marcus with an intuitive on-trend bike hiring service that encourages him to hire Santander bicycles instead of using public transport.'
The most true and concise one we went for was 'How might we provide Marcus with an intuitive on-trend bike hiring service that encourages him to hire Santander bicycles instead of using public transport.'
Low - Mid Fidelity Wireframes
Following our finding we began a short sketching session to get our ideas onto paper. Many of our ideas were similar, so we decided to jump straight into low fidelity wireframes as we were conscious of time.
User testing
After completing our wireframes we conducted a number of moderated and unmoderated usability tests, to review how users interacted with our app. With our unmoderated tests we found that on average users scored 4.7 out of 5 (5 being very satisfied) on our version of the app. Users also gave us ideas on how to iterate the app further.
Feature priority matrix
We also conducted moderated tests with users and also our stakeholders at Santander. This gave us many key insights which we put into an affinity map. We then used a feature priority matrix to decide which feature iterations we wanted to focus on for the final prototype.
Iterations
There were many iterations we made to the app, these involved bug fixing, accessibility issues and also navigation issues.
UI design + style guide
For the UI design of the app we wanted to keep the element of simplicity throughout and also keep consistency with other London transport methods. When deciding colour we decided that a green/turquoise was a good idea for a colour change as we wanted the app to reflect greener travel around London but also keep accessibility in mind for readability.
Deliver
High - fidelity wireframes + prototype.
As part of the project we created high-fidelity wireframes and a working prototype for the stakeholders to use and try.
Conclusion
As this was my first group project I found it very useful to understand the dynamics of a design team and also how to work and take on specific design roles in a team. I had a great time working with two other talented designers and enjoyed all parts of the project. We managed to fulfil the design brief by providing a clear way for users to hire bikes bikes and plan their journey. By simplifying the user journey we believe that it increases ridership due to accessibility, which fulfils the goal of increasing revenue and reducing road congestion.
Don’t be afraid to ask for help - In my team I was working with two other very talented designers. I found it useful to ask them for their opinions, and also tips on how to be a better designer. I was able to learn a lot from the perspectives and knowledge of others.
Delegation & sharing tasks - As this project was the first group project we had faced, it was important that we all took on specific roles/tasks. It was important that we shared the work between us so that one of us wouldn’t become too stressed with the workload.
Be Organised - As we were working on the project together and communicating with each other almost every minute, it was important to stay organised. This involved naming and grouping all of our layers, positioning layers correctly on our pages and also sticking to our plans and tasks. By doing so this made it easy to delegate and share tasks, as we all knew what was happening throughout all of our project.
Delegation & sharing tasks - As this project was the first group project we had faced, it was important that we all took on specific roles/tasks. It was important that we shared the work between us so that one of us wouldn’t become too stressed with the workload.
Be Organised - As we were working on the project together and communicating with each other almost every minute, it was important to stay organised. This involved naming and grouping all of our layers, positioning layers correctly on our pages and also sticking to our plans and tasks. By doing so this made it easy to delegate and share tasks, as we all knew what was happening throughout all of our project.
More work