Improving the services of the EMT of .

Photo by Carlos Zurita on Unsplash

I’m going to tell you about the project of the last two weeks we were doing in the Bootcamp UX/UI in Neoland.

First Week (Discover and Define)

They gave us a brief in which, our client was the EMT of Madrid, the objective of our project was: the experience of users who go by bus through the city, after conducting a study have realized that each year there are fewer customers who use this means of and users are more dissatisfied. And our target audience were: the elderly, users with reduced mobility, the blind, the hearing impaired, or impeded.

The method to make this project was a double diamond design . We divided it in two weeks, one to look for as much information as possible and the other to develop the future product.

To find out which ideas are best, the creative process is iterative. This means that ideas are developed, tested and refined several times, so weak ideas will fall into the process.

Our first step was to raise the research questions, My team consisting of Manuel Lamata Elena Marcost and Dalton Rodríguez Abreu started to raise a series of doubts that we needed to resolve during the research to be able to propose a proposal that will solve real problems of users. We divided these series of doubts into User, competition and company.

Desk Research, Netnography and Benchmarking

At the end of the research questions, we began to investigate as much as possible to give a solution to the questions we had. We did it through these 3 techniques to look for the information in short what we got was:

  • Greater proportion of women
  • High representation of seniors between 65 and 80 years old
  • High concentration of residents in Corona A of Madrid
  • Higher proportion of retirees and a lower proportion of students and workers
  • Greater representation of trips by reason of leisure
  • Majority use of the Transport Season Ticket/TTP
  • There is dissatisfaction with the frequencies, which do not coincide with what is marked on the awnings.
  • People travelling with baby carriages are dissatisfied with the accessibility and occupation of the platforms.
  • There are numerous complaints about the poor accessibility of buses.
  • People complain that buses pass by if they don’t raise their hands.

Safari (Where amazing happens)

Safari is a UX technique in which you go “to the place of facts” to understand and see how users behave. In our case, as they live the experience of moving by bus. When we went home we all decided to go back by bus to see firsthand the behaviour of our users, the next day we had these conclusions:

  • They complain that braking does not allow them to move around the bus.
  • Older people get up one stop early to get out more comfortably
  • Older people need the bus to tip over to get on and off.
  • Satisfaction with the new information panels
  • Insecurity for not knowing if there are free seats
  • They complain about the impunity
  • No possibility of transhipment

After putting all this in common we decided to go the four of us to the nearest stop and see if we could get some more “finding”. This part of the safari where we did it in common I’m going to call it as the NBA slogan: Where amazing happens.

I put you in context, rainy day and the stop overflowing with people, we positioned ourselves as we could to protect ourselves from the rain and in less than 5 minutes all this arose.

A lady gave to activate to the button to have the sonorous information (we tried to look for it and we did not find it) we realized that it did not work well, that it was sounded quite bad especially by the traffic and the people talking. We confirmed that the great majority uses the manure and queues are formed when entering the bus. And a lady lost the bus for not raising her hand, the lady was at the back of the stop and there were enough people in front of her so she did not have space and when she saw her bus pass by it was already too late, you can imagine the anger of the lady who “let off steam” with us ranting about the EMT and its service. Saying for example that before “she always stopped without raising her hand and did not understand why not now”. That talk with the lady gave us many clues as to what we could improve.


At the end of all this, we began to make a survey to have more information. The result was this:

People with disabilities:

  • They prefer to travel by bus.
  • Most have trouble getting on or off the bus.
  • They encounter obstacles until they reach the bus stop.
  • Most have not been able to get on the bus at some time.


Manuel had the opportunity to do two interviews with elderly people (Mari Carmen and Merchi) of Emt type user and from there we got enough findings and we made the customer journey, empathy map and the person.

From all this we get the pain points that our interviewees gave us that were these:

  • Most of them don’t have clear information about how many trips are left on the card.
  • Need to know waiting times more accurately
  • The moment to pay inside the bus generates a great stress
  • If the bus is too crowded, they don’t get on.
  • Have problems with bus accessibility (boarding and alighting)

Second week (Develop and deliver)

Facing the challenge

We start the second week with the challenge: To improve the accessibility of users from the moment they arrive at the stop until they sit on the bus. This implies:

  • Knowing waiting times
  • Request bus stop
  • To know if there will be room in the interior
  • Know the balance of the transport card


Once we knew the challenge, through the HMW we posed questions to solve the challenge. We divide it in arriving at the stop, in the stop and during the trip.

Deciding HMW Questions


After HMW we did the MoSCoW process which is a simple way to rank user stories in order of priority. MoSCoW means: Must, Should, Could, Wont


Ideas to solve

Once we were clear about the problems we were going to solve, we brainstormed possible solutions and chose those that were more interesting or more viable. At the end we were talking about which would be the best solution and we decided to make an smart stop.

Smart stop

The operation of the stop is as follows. Through Beacons placed at the stop and on the bus. It would send information about whether it has to stop or if there is someone in a wheelchair so that the driver is more careful when parking.

At the stop there will be a touch panel that shows the stop information (bus number, route, bus occupancy, being able to ask the bus to stop, knowing/recharging your card balance) Next to the touch panel there will be a side panel with Braille information.

To make the payment, we would use the DSRC system, which is the same system used by highways with electronic tolls. It would be a wireless charge in which people each time they ride the bus would pass through an arc located in the door of the bus in which the collection of the trip would be made. This would only be valid for people who have the transport pass. With this we try to avoid the stress moment that Merchi and Mari Carmen told us that happens to them every time they have to get on a bus and we would also speed up the entrance queues.

In terms of occupancy we will use the Amazon go system. The system that uses cameras to track people’s movements and identify their interactions with products. In our case it will serve with a heat map to know the occupation of the bus.

Flowchart and Wireframes

Personally it was the first time that I did the flowchart and it seemed essential for the realization of the project.

As we had few screens, we decided that each one of us should do our own and share the ideas we had from the flow, this took us no more than 10 minutes and in general the four of us had it quite similar. When we called Leti, our teacher, everything changed

First she asked us a series of questions to understand and empathize with our project. We went step by step understanding, clarifying and discovering our solution (more than we thought at the beginning). What took us 5 minutes with Leti asking questions (and also made us think it’s even more important) took us at least 1h.

My mistake and I think that the rest of my colleagues was to think that with the four screens was clear and simple enough to express our project in a diagram but the reality is that even if you have few screens you can have a great flow. The diagram makes you think, put logic into your project and helps you make wireframes much faster and better.

Flowcharts and Wireframes

Functionalities discarded

A big part of the challenge, we spent iterating. Solutions that we thought could be implemented but that in the end we didn’t know/could do.

  • Reservation of seats and spaces, since the few possibilities of control could generate greater frustrations.
  • We cannot control the destination of passengers (even the user may not know their final destination stop).
  • System failures may occur
  • The stop and the descent can coincide in the same stop and it is difficult to synchronize both actions.
  • Payment by card of amounts greater than 20€, as it would be necessary to consider a process that would allow the secret code to be entered securely and is difficult to reconcile with the rest of the functionalities.

For the future

The aim of this project was to improve public transport in Madrid, focusing on those people who have some kind of disability or who have a more specific need. And focusing on accessibility because in that aspect there is currently much to improve.

These were the functionalities that we would like to add and that due to lack of time we could not.

  • Expand the functionalities of intelligent stops through a personalized app
  • Include payment and subscription recharge via mobile device
  • Add functionality that offers alternative routing options
  • To design new intelligent stops that solve the physical and architectural problems presented by the current canopies.
  • Seat reservation

Source link


Please enter your comment!
Please enter your name here