The Design Thinking Process - Case: Citymapper

This article is part 1 of 3 of the UX/UI Bootcamp prework from Ironhack, that I am part of. This is the first article of (?)… Well, the truth is that I am an introspective person, not very talkative, and I have been avoiding opening a Medium account for a while. So let’s see where this will go!

The Context: Citymapper-Get me somewhere!

Citymapper is a mapping service application that provides transport options. The app integrates information from all the urban transport modes, including cycling, walking, driving and public transport.

Citymapper gives you the best route, with live timing, between two points of the city you are located.

The app gives you a travel combination using public transport and other modalities. It can be really useful when you are new to a city and doesn’t know how the ticket transport system works.

The Problem Statement:

Find out a solution to solve the problem for the different amount of public transport tickets that users have to purchase, from different channels, for each route that they are wiling to take.

This leads to many other issues such as ticket pricing, more rubbish, more paper that you don’t know where to find in your pockets, or bags, or purse, or, or, or…

The process of buying the tickets is quite stressful, having to take queues, waiting your turn to use the vending machines, that sometimes is not even working. This situation can be even worse when you are abroad and don’t know anyone or how to speak the local language.

First of all, I took some time to explore the App and understand its features and functionalities.

I identified other applications that provide the same/similar service:
Moovit, Cabify, Curb, EasyWay, OneBusAway.

The User-Understanding their Scenario:

To understand the users’ habits and thoughts, I conducted an interview session with 7 people. Some of them were residents, and the other two related their experience based on the time that they were traveling abroad.

I separated the audience into two groups:
-Residents
-Tourists (long stay / short stay)

The main reason for the session was to find out what is the main pain point that users experience while using the app. For that, I needed to elaborate a list of questions that would help me to have a clear idea about the users’ habits before, during, and after going to point A to point B.

Do they plan their route before leaving their home? Do they decide last minute? When do they use Citymapper?

Defining the problem -Insights from the Users:

• They don’t like to have many different tickets to the different transports that they are going to take.
• The users prefer to do all the actions related to buying tickets in only one place.
• They stated that they would like to sort out the tickets in few steps.
• 85% of the users use the mobile phone to do the transactions.

Ideating the Solution:

Once I had the users insights, I selected the main issue — few steps, easy busy access to the tickets needed — and started to brainstorm some solutions to that.

After some ideation time, I came up with the winner:

The idea was to reduce the amount of time that the user would need to stay connected and browsing the phone to sort out the ticket transactions.

This option does not exist in the Citymapper app nowadays.

The ideation started on the screen where the user has to select their preferred route.

Once they have selected the route, at the bottom of the screen the user can see how many tickets, types, and costs it is going to take them to go from point A to B (and C).

On the next screen, the user can select the preferred payment method:

1-Use their public transport card. (The route would be displayed again for the user after selecting this option).
2-Generate bar code to use on the Ticket Gate. (In this scenario, it is assumed that the bank details are linked with the app).
3-Select the option to go directly to the bank app and pay for the tickets there. Once the transaction has finished, a bar code would be displayed on the app screen.

Key learnings:

When I first started working on this, I had some “ideas” about some solutions that would work for the brief stated. But I came to the realization that I can never assume something and work with that bias, before have tested the product and interviewed some key users.
Analyzing the functionality of the app, exploring some benchmarking, and getting user’s insights are fundamental to the right direction of the product development.