Ironhack Prework, Challenge 1: Design Thinking
UrbanGo is a public transit and mapping startup based in Silicon Valley. Their goal is to solve the problems of urban mobility by providing the quickest and cheapest public and private transport routes to their users.
UrbanGo has already developed a mobile application that lets users select a starting point and a destination and provides different multimodal routes with the estimated time and cost.
My task for this first project of my prework is to create a feature for this app that solves the pain of having to purchase different public transport tickets through different channels.
Premise:
- Users already have all their information on the app, they will neither need to login nor enter any data when making a purchase/checking-out;
- Security issues and other limitations have been overlooked. The focus, for now, is on finding a quick and user-friendly solution.
Before we get into the details of the project it is worth mentioning that, since the app UrbanGo wasn’t available in my country, I used Citymapper as a reference because they share similar features.
1. Empathize
The first step of the Design Thinking Approach defined by IDEO is to get familiarity with the product and, most importantly, empathize with the target user. We were asked to start with a personal introspection that aims at finding the answers to four pivotal questions:
“What problem are you solving?”
With this project I aim to solve the issues that some users experience when using the app: even though it offers a good mapping service, having to switch to a different app or channel in order to purchase tickets may result quite jarring to those who feel the need for a single app capable of checking for routes and purchasing tickets at the same time.
“Who is your audience?”
My target audience consists of tourists and travellers — ranging from 18 to 50+ years old — who like to know their way around when it comes to transfers.
“Who is your client’s competition?”
My major client’s competitors are Google Maps, Moovit and Trainline.
“What’s the tone/feeling?”
The app is aesthetically appealing and easy to use. It provides the user with many different filters and options to make sure that they get exactly what they need, plus it notifies the user about the current state of transfers (delays, cancellations, etc.), resulting in a fulfilling experience during the search.
Now it’s time for the interviews! We were asked to reach out to 5 different users that have used public transport, especially abroad, to garner some interesting insight from their experiences.
Click here to see the Google Sheets file containing those Q&As.
2. Define
Now we move onto the next phase where we have to write down our findings and define a problem statement, focusing on the user’s viewpoint. The task is to detect the main problem that we want to solve.
On page 2 of the previous document, named “Findings”, is where you’ll find the insight that I got after reviewing my users’ answers.
These interviews brought up several issues that users experience while using public transports, and they mainly have to do with how convenient, functional and straightforward the system is. After some reasoning, I set efficiency as my priority, because many negative experiences that the users shared during the interviews could be improved by a more responsive and efficient system.
Problem Statement
An actionable problem statement combines user, need and insight. The following is the one that I came up with:
“Travellers need a way to purchase tickets easily and quickly through a simple interaction within the system, because the need to get them through a different channel would make the process confusing, slow and annoying.”
3. Ideate
During the ideation phase designers use brainstorming techniques to generate a lot of ideas to solve a problem. The goal is to come up with as many solutions as possible and then picking only two or three of them based on our findings. A good practice is to draw a simple mind map to get a better understanding of the product we’re designing.
- Digital tickets: of course the first thing that popped into my head is the implementation of an in-app purchase system that allows users to get a digital version of their tickets so that they won’t have to deal with queues and vending machines another day in their lives! [see Elisa qn. 10; Anna, qn.6–10; Riccardo qn.10].
- Card: another option that was frequently mentioned by users is an hourly/daily/weekly card that simplifies the process of purchasing multiple tickets [see Emanuele, Ylenia, Elisa, Anna, Riccardo, qn.8]. You can easily purchase one in-app and then collect it at the booth and enjoy hopping on and off transports as much as you wish!
- Digital Card: I quickly realized that, since a digital alternative to physical tickets had been greatly appreciated by users during their past experiences, the same must be true for cards as well! Being able to use transports freely for as long as you want through a single QR code or barcode on your smartphone sounds pretty sweet, huh?
- Prepaid System: some users might prefer a system that deducts the ticket’s cost directly from their credit on the app, just like using a credit or an ATM card or a PayPal account that one can easily top up according to their needs [see Elisa, Ylenia and Riccardo, qn.9].
After coming up with some ideas to solve the main problem— and having a good time while doing so! — I felt like going a little further: adding features to the newly developed purchase method would give the app that extra oomph to take on competitors, so why not have a little fun with it and think about what users might like to see in the app in the future? To do so, I turned once again to the insight from my interviews to come up with valid solutions:
- Turnout Statistics: some users complained about past experiences pertaining to chaotic and overcrowded stations [see Emanuele and Anna, qn.4]. A nice workaround to help them avoid busy hours would be to provide turnout data so that they may choose the most convenient option, which is more unlikely to yield unpleasant surprises.
- Reviews/Ratings: implementing ratings and reviews for each transfer would be a good way for users to share their experience and read about other people’s stories. This way the app might prevent them from experiencing confusion and frustration due to lack of user feedback [see Emanuele, qn.6; Ylenia, qn.4; Elisa, qn.7].
- Ticket Library: another cool addition would be some sort of library to store tickets for those who like to plan ahead and purchase tickets beforehand [see Ylenia and Riccardo, qn.9], providing users with an easy and quick method to retrieve them when needed.
- Chat: who said that mobility apps can’t have a social feature? How many times did users have to seek help from residents? — Many, I tell ya! [see Ylenia, qn.3; Elisa, qn. 3; Riccardo, qn.4]. By adding a chat to the system, users would be one text away from reliable information delivered by residents or travellers with first-hand experience.
4. Prototype
For the fourth and last stage of the project, we had to pick one of our top solutions and develop it in a few hand-sketched screens: the goal is not to create a beautiful drawing, but to be able to shape our ideas into a paper prototype.
Since the main objective of the project is to come up with a way for users to purchase tickets using the app, I chose to focus on the first four concepts — the others are nice additions best taken into account only after the purchase system is implemented, so I decided to set them aside for the time being. Then I thought about combining digital tickets and a prepaid system, because I’d rather prioritize the purchase of single, digital tickets over multi-day cards for the launch of the new system — I feel like tickets are a necessary first step which multi-day cards would most likely follow up pretty quickly— and because I really liked the idea of a credit-based system.
Note: after I started prototyping, it just made sense to me to also have a ticket library — which will be referred to as the “My Tickets” section in app — to collect purchased tickets, so I ended up adding this feature as well.
The user clicks on the search bar in the home page (#1) — note that we also have two new icons on this page, which will be presented later on — then selects a starting point (#2), such as their current location, and a destination (#3): in the example that I made, the user would tap on the search bar, thus causing the keyboard to pop up, and then input their destination.
Once the user has selected both a starting point and a destination, the app will load all available transfer options (#4). The user selects one and is then prompted to the route screen (#5). By clicking on the newly added “Tickets” button, a new screen will appear with the total number of tickets — and their respective cost — that will be needed for that itinerary. They select one or more to purchase and then click on “Next”(#6).
Now that tickets have been selected, the user will need to choose a payment method (#7)— in this case, “Pay with Credit” — and then click on “Next”; then a detailed review of their fare would be displayed for payment confirmation (#7) and once they click on “Confirm” they can either review the purchased tickets, go back to the home page or to the route screen.
As mentioned previously, there are two new icons for both credit and “my tickets” sections in the home page. It just made sense to me to have those displayed right in the home screen, and I will briefly explain what the look and feel of these features are going to be like.
By tapping on the “My Tickets” icon, two lists with both purchased and validated tickets will appear (#1)— if there are any. By tapping on the eye icon, the user can visualize the QR code or barcode for the chosen ticket (#2): once they scan it to get on transports, they will be automatically prompted back to the previous screen, and the used ticket will now appear in the “Validated” list.
By tapping on the credit icon instead, users will land on a screen showing them the current credit (#1). By tapping on “Recharge!” they can either opt for a single recharge (#2) or for an auto-recharge option for which they will choose the frequency (#3). In both cases, they will be able to select their desired amount and their preferred payment method.
After their desired options and clicking on “recharge”, users will get to a payment confirmation form (#4). Once they click on “confirm”, they will receive a “thank you” message stating that the credit has been added to their account and they can either go back to the home page or to their credit section by clicking on the respective buttons (#5).
Final Words
This project was my first experience with the Design Thinking approach, and I must say that I had a lot of fun with it!
I enjoyed every single step of the process, but I can honestly say that envisioning and sketching out the mind map, as well as the paper prototype, really had me glued to my chair for hours; I could really feel my wheels turning while trying to come up with creative solutions to my users’ issues.
Being a perfectionist, the hardest thing that I had to learn was to focus on content more than the look and feel of the prototype, but I’m sure that I’ll get more and more used to this approach during the bootcamp.
Thank you for your time, and feel free to leave a comment with your thoughts!
Feedback is highly appreciated! 😃
