Article

All Aboard

How might we solve the problem of broken elevators in public transport?

The Concept Team from the Innovation department developed the All Aboard project. This project aims to improve accessibility of public transportation in Amsterdam, by sharing information about broken elevators. It addresses existing challenges on how to plan a reliable route but also getting help if something goes wrong. A lot of different solutions were presented that go beyond this app so we can improve the travelling experience to all passengers, including the ones with reduced mobility.

Goal 

The goal of this project is to help public transportation organisations in Amsterdam providing accessible and inclusive journeys for everyone, with a focus on providing information about the status of elevators.

 

Duration 

01-01-2023 to 31-12-2023

 

Process

We followed a double diamond process, starting with researching the problem, ideating possible solutions, and scoping the solution. We then moved on to designing and developing the final solution. Key insights from each stage of the process are outlined below.

 

1. Research Workshop

Workshop

In this research workshop we used the 4C's framework as methodology, in a 2h30 session with 7 participants. The aim of this workshop was to dive into the problem and ideate about possible solutions.  

Key insights:
  • The majority of route planning apps lack information about the status of elevators;
  • Assistants do not always feel responsible to help;
  • There is a lack of centralised ownership and coordinations among different service providers;
  • GVB app has information about the elevator status but it is not always accurate and has poor findability;
  • Crowdsourcing, sensor-based monitoring, and improved accessibility features in route-planning apps could improve the services.

Read the full report here.

 

2. Field Study

Field Study
In this field study, all team members immersed themselves in the user's context by dividing into four groups, each using a different route planners and heading to different destinations. The tasks we performed included: planning the route with the selected app, following the planned route and evaluating its accuracy, finding a broken elevator, and asking for assistance.

Key insights:
  • Current route planner apps do not warn about broken elevators in the route you are planning;
  • There were inconsistent assistance across different stations. For example the groups that went to central station were immediately offered a taxi as alternative, while in Venserpolder the assistant did not feel responsible to help;
  • It is difficult to identify the elevators. Some have an ID but it is not always visible and it is difficult to remember;
  • The walking time is underestimated for elevator users and/or different types of wheelchairs;
  • Missing alternative routes in route-planning apps.

Read the full report here

 

3. Scoping the project

We picked four opportunity questions to further ideate and scope our project into something our team could develop:

    1. How might we collect information about wether an elevator is broken?
      • Sensors are the most popular solution, and ProRail and GVB have ongoing projects to achieve this. However, these projects may take some time to be completed. Meanwhile, we considered a crowdsourcing alternative to help travelers exchange information.
    2. How might we inform people wether the elevators on their way are working?
      • We considered sending messages or notifications to travelers about the status of their frequently used elevators. In the future, we recommend adding these features to existing apps and displaying this information on public transport and platform displays.
    3. How might we assist people for questions, advice and finding solutions?
      • For now, we decided to provide the assistance numbers of service providers. In the future, we envision a call service that feels responsible for the success of the entire journey and a 'help app' where travelers can send help requests and nearby people are notified.
    4. How might we give alternatives whenever there is a broken elevator on the way that prevent a successful journey?
      • We chose to offer alternative elevators, but in the future, we recommend providing alternative routes or the option of getting a taxi.

 

4. Prototype

Prototype

We designed and built a prototype to test our solution and we called it "All Aboard". The key functionalities are:

  • Quick way to report: we allow users to share wether an elevator is broken between themselves;
  • Notifications: we allow users to favourite their most used elevators and get notified whenever there is a status change (broken or working);
  • Assistance numbers: we share in the app the service provider and phone number related to each elevator;
  • Overview information of the elevators: each elevator has its own page with pictures, station name, exit name and lines.

The Design prototype was made in Figma and has open access.

The developed Mobile app is currently in beta version, awaiting further collaboration to conduct a pilot. To access the code please contact ConceptTeam@amsterdam.nl

 

5. Data

We compiled a complete dataset with all the elevators in Amsterdam (public transport). This dataset includes pictures, coordinates, stations, lines, and dependencies.

Dependencies were a challenge that we haven't envisioned in the beginning of the project. While visiting the stations we found out that not all elevators go from street level to platform. For some stations there is an intricate diagram, that can provide alternatives, even if one (or more) elevator is broken.

Elevator diagram from Weesperplein metro station

Elevator diagram from Weesperplein metro station

 

This dataset can be accessed here.

 

6. Usability Test

Usability tests

In this usability test we interview 6 participants and 3 tested 3 different scenarios.

Key insights:
  • Notifications proved to be handy, because elevators can be favourited once and users do not need to actively use the app;
  • Half of the participants prefer a standalone app because of the clutter of functionalities in current route planners;
  • QR codes have low recognisability. The majority of the participants did not know how to use it;
  • The assistance numbers were overlooked;
  • People recognise better the name of the stations than individual elevators, we should cluster them.
  • Participants emphasised the importance of receiving reliable notifications (accuracy)

Read the full report here.

 

7. Advice for next steps

We tested our solution and observed the enthusiasm and positive impact these new functionalities could bring to travelers. As a Concept Team, our role is to create proofs of concept and evaluate their potential, but we do not handle scaling up. Currently, we are seeking further collaboration with Vervoerregio Amsterdam, ProRail, and GVB.

This is our advice for the next steps:

  • Use our dataset as starting point. Data from all elevators connected to public transport is available;
  • Improve internal process for more timely updates. Service level agreement to 99,8% uptime with service suppliers;
  • Publish the data in public standards. For example in Dova format so it can be used by route planners and third parties;
  • Run a pilot with the 'All aboard' prototype. Improve processes and test with pilot group;
  • Automate the data. Use data from sensors in order to improve the quality;
  • After all being tested and changes made the existing route planners can implement elevator data and new functionalities.

Future prototype

Some of the functionalities we recommend adding to existing route planners

 

 

 

Additional info

Image credits

Icon image: All Aboard

Media

Documents