I was first made aware of this problem via social media. A wheelchair user (Katie Pennick) tweeted about their experience of being left unable to get off of a train due to ramp assistance failing to turn up. Other twitter users then shared their similar experiences below. For this project, I wanted to find out how widespread this issue is, what the causes are, then hopefully come up with a viable solution.
I chose Transport for London (TfL) as the theoretical client because they are the authority who manage and oversee most of London's public transport network.
Design a product that makes travelling on public transport in London easier for people with mobility issues.
I started my research with blogs and articles written by target users to learn about their personal experiences. I then read surveys and reports to find solid data on the wider issue. I also looked at the latest transport improvement plans to see how necessary and futureproof a proposed digital solution was. These sources all helped to paint a general picture of how accessibility within the public transport system works and what the problems are. I found that:
From my research, it was clear that the issues with accessible transport in London don’t just occur during journeys, but actually begin during the journey planning stage. Outside of facility upgrades, there were problems surrounding information, assistance and possibly more that a digital solution could address. My further research needed to look at the whole experience.
Now that I had a general idea of the problem and established my target user group, I wanted to find out more about the current products being used by them to plan accessible journeys, and how useful they are. I entered the same journey into three different journey planners, analysed their UIs and compared the information provided on accessibility.
Both Google Maps and Citymapper suggested journeys based on general “wheelchair accessibility” which doesn’t take into account different levels of mobility. They did however include live navigation and transport updates, with Citymapper also including step-free exit information. TfL journey planner had the most accessible personalisation options which meant it could cater to more levels of mobility, but it had no app and no live navigation.
Overall, the existing options weren’t great. They had some useful features to inspire my design but loads of room for improvement.
Next, I wanted to better understand the users’ experience of journey planning and travelling on public transport. With this information I could map out user journeys, identify pain points and think of solutions.
I wanted to find out first hand from users about their journey planning behaviours and what they thought would improve their experiences. I used google forms to survey members of the target user group.
The most valuable insights were:
While I’m aware 6 respondents isn't wholly representative of the target user group, it was still valuable hearing that they would see value in such an app.
To better understand the journey experience, I watched videos and listened to podcast episodes of target users detailing their journeys on London’s public transport.
The scenarios from these accounts gave insight into how users interact with the system and uncovered more pain points for consideration:
I planned an accessible journey, attempting to emulate the actions of target users.
I made use of websites, apps, and accessible maps.
I found that there was a lot more accessibility information available online than what was included in journey planners. Needing so many different sources highlighted a longer than necessary user journey, and the importance of a solution that includes all of the most up-to-date information in one place.
With much of London’s public transport system requiring stepped access, people with mobility issues are already at a disadvantage. This is made worse when the systems in place to make travel easier for them fall short. These failings play a part in denying them access to aspects of life such as work, socialising and leisure activities.
Going forward, my aim was to target the three main points of frustration that repeatedly showed up: finding accessibility information, journey planning and booking assistance.
Now that I had figured out the main functionality of the app, I started creating a rough app architecture.
I then started wireframing screens for different user journeys based on the apps’ functions. While I was prototyping I found more efficient user journeys, and the app’s architecture and UI continued to develop.
TfL Accessible Journey planner is a travel app that makes navigating public transport in London easier for people with mobility issues.
The app initially opens to onboarding screens which give users a quick overview of the app’s functions.
This is followed by self-select onboarding which begins the personalisation process.
The most up-to-date accessibility information is now all in one place. Users no longer need to reference multiple sources when planning accessible journeys, or worry about being suggested journeys that aren’t actually possible for them.
More personalisation options means users are now given suggested journeys that are more tailored to their specific needs.
Users can save future journeys and their most used stations to be notified of transport and facility disruptions that are relevant to them. In the case of disruption, replanning options are offered, ensuring users avoid as many potential delays as possible.
This app allows users to book assistance more quickly and conveniently, whether they’re planning days in advance, or are searching their journey just before heading out. Assistance request statuses are clearly displayed to keep users assured that they won’t be left stranded.
Mobility aid icons allow users to select their journeys based on which of their wheelchairs or scooters they’ll be able to use.
The final prototype was tested on 4 non-disabled users due to a lack of response from my outreach to the target user group. The tasks and the questions I asked allowed me to assess the app based on:
The testers were able to navigate the app fairly well and gave mostly positive feedback with only minor UI and syntax improvements suggested.
Overall I’m happy with the project outcome. I greatly improved my UX/UI design skills which was my biggest personal goal. As this was my first UX/UI project, I learned a lot about the whole process, especially when it comes to what’s realistic within certain time frames.
I also learned the importance of wireframing and testing during earlier stages. With earlier testing, changes could have been made, and more rounds of testing could have been completed for further improvement.
There are a few ways I would further develop this app, these include but aren’t limited to: