Public Transportation in Lisbon is hard.

But maybe it can be easier….

Our first Ironhack Design project was designed to give us a crash course in the design thinking process. We were taught how to take an issue, get a scope of what we would need to learn to improve the issue, define who could teach us more about the issue, and how to design both written surveys as well as in-depth interviews to understand how people are affected by this problem.

The problem

Our team decided to discover what sorts of transportation issues people are facing in modern-day Europe. (and there are plenty) We wanted to design the challenge around improving public transportation options in particular- including any sort of self-powered transport like biking or walking. To do this, we decided to approach this problem by using the design thinking process. Let’s get right into it!

Surveys, Interviews, Affinity Maps, and How Might We?

To approach our topic in an informed way we needed to gather on information on who these people are, and how they live. We created a survey that gathered information about what sorts of public transport people use, what their experience is with public transport. We made sure to ask both and their pain points and their ideas for improvement. When designing survey’s it's important to not ask questions that might lead someone into thinking that we wanted a certain kind of answer. The process of eliminating bias meant thinking about question design in a critical way. We had to be through if we wanted to learn what frustrates people about public transportation in their cities, and what they would do to improve their experience.

Interestingly enough, our survey received many more answers than anticipated, with users chiming in from across the globe, we were pretty impressed to receive such a global response!

We then hit the streets and changed our survey questions in order to design them for in-person interviews. We visited one of the main public transportation centers in Lisbon to talk to real people about their experiences and get deeper insights that would essentially be case studies.

We returned shook. The issues that we thought would be most prominent in the conversation about public transportation, weren't. This was one of our first unequivocally important lessons in design: “you are not your user”. We created a visual board to give us a better way to visualize our survey results and quantify them and group them. Here’s how that looked.

We learned that most people’s frustrations are primarily centered around late or canceled vehicles, and lack of public transport routes beyond max capacity hours.

“You, are not your user”

We realized that the main design issues around public transportation are often very much infrastructural issues that are impaired by variables of a massive scale. The problem is very much an interdisciplinary one, and we wondered at how we could find a way to approach the users problem that could be improved through tech.

And I do mean, find the users problems, there is a reason we aren’t talking about finding solutions quite yet. The reason is that design thinking isn’t about finding the solution right away. We would call that an informed guess. Overzealous entrepreneurs, businesses, and creative visionaries the world over have lept into finding a solution for problems that ultimately….no one cared about. The danger in this is that people and groups invest time, money, and resources into an idea that doesn’t help people, and that time and money- well it could have gone towards something impactful if we had only done our homework.

So it’s really about finding the right problems to solve. Bill Nye knows what I mean.

After we gathered research using user interviews, we took all of our information and created a question that encapsulated our problem, and specifically outlined what parts of it we want to solve. We call this the “how might we” statement”. In the end, ours was- “how might we help people better access their transportation options to help them get to where they’re going in the quickest way?”.

Persona’s, User Journeys, and Empathy Maps

From there, something cool happens- we begin to figure out who three different types of people who might have the issues we highlight might be. These people then get carved out into an almost-real person, who acts as the archetype to represent thousands who have a similar experience. After looking at who we surveyed and analyzing the makeup of Lisbon, we came up with three people. I’ll share a couple them below.

We ended up telling the story of Maria, because we thought she was the best representative of the average Lisboners experience, and also because we believed that we could help her more than we could help our runner-up Joao.

Next step is to create an Empathy map. Essentially this is a constructive graph that helps us flesh out what Maria might experience on a daily basis. We answer the questions of what she might, feel, hear, see, and say, in order to get a better understanding of her experience and the influencing factors in her life.

We’re getting close to the finish line! After you create an empathy map, we can begin tell the story of the User Journey. This document will outline all of the different steps that our user goes through to have an experience. In this case, we outlined Maria’s commute and talked about every step she needs to take to complete the task of her commute as well as (and this is the important part) the emotional journey she of this experience. We highlight her highs and low’s in order to understand exactly what parts of her user experience are causing her the most pain.

Why focus on pain? Because that is what we’re here to do for our users, reduce their pain. Wherever there is a pain point, there is an opportunity for betterment and development.

We discovered Maria’s greatest pain points occur when she needs to skip her metro or take a different route because her bus or metro is delayed or because there isn’t enough room due to overcrowding. It’s really stressful for her to risk being late for work and have little control over the information available to her in order to make better choices.

Hypothesizing and Brainstorming

After we figure out what Maria’s daily experience was like, we had to ask ourselves some tough questions in order to develop a hypothesis on how we could help. Some essential questions you can ask yourself or your team to arrive at the same insights might be questions like:

1. What product/service will you be designing for?

2. And what goals was this product designed to achieve?

3. Based on your research which of your user needs is not being met?

4. For each unmet user goal, list the negative effects it has on the product.

5. What metrics will you use to measure success?

It’s essential to know what the purpose of your product is, and what could happen when it goes wrong, as well as knowing how to determine if it’s going right.

We came up with a hypothesis, which was essentially-

“We believe that creating a resource to inform Lisboners of their daily transportations options along with giving them updates will give users better navigation/scheduling tools than what exists in the market today.”

After we’ve defined the direction in which we want to approach our problem, we finally can begin to explore solutions! We entered an intensive brainstorming session where we thought of every possible thing we could that could improve our users commuting experience as outlined above. Basically, we wrote on a LOT of post-it notes. This part tends to be a lot of fun, it's both collaborative and bars-off. Everything goes. At times hearing the wildest ideas will spur another innovative idea that no one would have thought of otherwise. It’s important to write everything you think of down! Brainstorming gets people shaken up out of their regular ways of thinking, which is massively important in creative problem-solving.

Here are some of the tenants of brainstorming

1.Defer judgment

2. Generate lots of ideas

3. Encourage unusual ideas

4. Combine ideas

It may seem that the process is both organized and chaotic. This is in part because every step of the way, we’re practicing something called divergence and convergence. I think this picture explains it quite well.

whenever you want to learn more about a problem, you need to go wide and gather as much info as possible. Then we narrow in what we learn to define the next steps. Once we define the next steps, we can go wide again to arrive at a solution, which will be our final conversion and narrowing. One way to think of this is as a cycle of ideation and analysis. Ideation is what allows you to have creative ideas, and then to make sure that they get refined and become razor-sharp, you have to analyze and refine those ideas.

Concept Testing

After we brainstormed we came up with concept maps of our favorite two solutions. Basically, we created a low-fi mockup to give us, and users that we would later survey a basic idea of how two possible solutions for our problem would look like as apps.

Personally, I liked the second concept better, and I thought that the first idea could somehow be integrated into the second. However, it doesn’t matter what I want because

I am not my user

I’m not saying this for my health, it’s really, really true! And as much as I struggled to want to cling to my ideas, our decisions must be backed by research. We went back to the metro where we conducted our original interviews and asked people what they thought of the concepts, and if they had a preference. The responses were overwhelmingly positive and we discovered that most users did actually prefer the second concept. Which was great! It was then our job to build it out using something called a Service map.

A service map is a diagram that lets us see all the different parts that must come from different places and come together along with the experience of the customer's journey when using our product or service. A picture is worth a thousand words.

We made sure to outline what the users physical experience of using our app was, how they would interact with our app and the real world, the support that the user might come into contact with was the support on our back end, as well as the partnership we’d have to make to be sure that we could be successful in our purpose.

When done successfully, a user map tells the story of product design.

In the end, we picked the name Locoguia because we wanted to allude to being both a local-guide as well as a locomotive guide (Guia being the word for a guide in Portuguese). Our app would give Maria the options to set her schedule including the dates, times and locations to which she needs to be on a regular basis. From there, the app would give her prompts that let her know when she had to leave the house by according to the public transit traffic and scheduling data for the day. The app would then guide her both on and off across multiple forms of public transit. Additionally, it would notify her of full trains or schedule delays ahead of time and provide alternative routes for her to take with the delays in mind. In in the end share data with to both encourage and gamify her time saved by using the app. Over time app usage would lead to discounts with local businesses we’d create partnerships with.

We thought our solution would help Maria because it allows her to have all the knowledge she needs to make the best decisions in the morning at her fingertips, as well as reduce the stressful parts of her morning by providing detailed directions that go beyond google maps, and smart routines that could guide her with prompts to get her places on time, just by getting an idea of her schedule!

Although normally, we’d then get into the building process for our working model, all of that is for next week. At the end of this process, I was tired, but it was an incredibly satisfying result. Good design is work, but it is powerful work. Thanks for walking with me through the design process! Xau!