Creating a feature for a public transit app (or: my first design challenge as an aspiring UX/UI Designer)
Hey everyone, I am a participant of the upcoming UX/UI Bootcamp cohort at Ironhack starting in May 2022. My target is to become an UX/UI Designer with a focus on finance and crypto-currencies. In preparation of the bootcamp, I am very excited to share with you my first challenge from the field of Design Thinking.
My task is to create a feature for a public transit app that solves the pain of having to purchase different public transport tickets by different channels. I have chosen the App Citymapper. Citymappers goal is to provide best possible customer experiences when using public or private urban modes of transport, as walking, cycling and driving for all major cities of the world. It has a mobile App, real-time routing, generates accurate mobility information, ticketing services and APIs and SDKs for companies and mobility operators to run smarter cities. Citymapper startet in 2011 in London and covers now all major cities in Europe, US and Canada and is expanding in more cities worldwide. By the way: You can vote for the next city to launch.
In this article I will walk you through these 4 steps:
- 1. What is the main problem I am trying to solve?
- 2. What were the main problems I have found when interviewing users?
- 3. How do I plan to solve this problem? (Here I am going to share my rough pen&paper prototype.)
- 4. I will share a few key things that I have learned throughout this process.
- What is the main problem I am trying to solve?
There are usually too many different kinds of public transport tickets available that can make the purchasing process overwhelming and frustrating. Tickets can come in paper or plastic cards or one has to buy different tickets to come from A to B. Not to mention the different options with time slots, age of passengers, quantity of passengers to name just a few. If you got used to your local public transport system, it seems to be more easy going, but it can become a real pain when you are abroad. My task is now to create a feature for the Citymapper App that solves the pain of having to purchase different public transport tickets by different channels.
2. What were the main problems I have found when interviewing users
I have interviewed 5 people that are using public transport in different cities. 4 of them have experiences with ticket systems worldwide and there is only 1 person that has used public transport only within Germany.
I have asked people from an age 28–83 to cover needs from different age and capabilities as good as possible. The interview was about 45 minutes each and had a focus on their concerns with public transport and ticketing. Main concerns were about too many ticket options, vending machines that provide a not user-friendly user experience, language barriers and their concerns of having to pay a fine and getting blamed for choosing the wrong ticket. There was a basic feeling of helplessness and not being able to communicate.
3. How do I plan to solve this problem?
After presenting the App to all of my interview partners, pen and paper became my best friends. I have made two rough sketches (see below) about the status quo and problems and ideas that came up within the interviews.


Most important for my interview partners was to reduce the complexity of ticketing systems and to get back the feeling of having everything under control. The price sensitivity was more secondary. There was the wish to talk to a human being and just to ask for the right ticket. As well the desire for a single ticket proposal for the entire route. Using the rapid prototyping approach, I have outlined one feature with three ways of guidance: via text, voice and video.

As shown in the Rough Prototype above, when opening the Citymapper App, there is a huge button that allows the user to continue with text input, voice guidance or starting a video call with a service person. After putting in the route, the quantity of people, the quantity of bikes etc., the customer chooses the kind of route: i.e. fastest route, route with the lowest price. Afterwards, only one ticket is shown, depending on the chosen route. The customer has the option to buy one ticket when making the trip all at once or to buy tickets separately when interrupting the journey and a time limitation is included.
Before buying the ticket via the app, the customer should see or hear (voice) the name of the ticket on the screen. The reason is to be able to buy the correct ticket also in supermarkets or small shops just by showing (or let them listen to) the ticket type and price to the staff. So the staff knows, what ticket is needed and can sell it right away. Especially in countries where no one speaks the mother tongue of the ticket buyer, a voice message about the needed ticket name or type in local language can be a big help. Voice and video options are also helpful for people that cannot see properly or illiterate persons that are more focused on colors and graphics.
4. And finally: A few key things that I have learned throughout this process.
I am more aware of how challenging it is to figure out the real needs of my interview partners. The truth lies within the unspoken words. It was challenging for me, to take a step back, let my interview partners speak and to put my point of view behind. Active listening is something I am really good at, but there is always a lot to learn and to improve. When sketching the screens in my little prototype, I have seen how many decisions a user has to make just by using one single feature of an app. That can be exhausting and I should minimize the decision steps and complexity in future. Finding a focus and not mixing up different approaches and tasks will be something I want to improve as well. Let’s see how it goes and you are invited to follow my path the next months.
Thanks for your time and attention up to here. You have ideas, how I can improve my work? Great. I would love to hear from you.