Case Study: Transport for London

Written by Rodrigo Lopes

Technical Architect at Transport for London

Overview

It is estimated that at least 75% of the inhabitants of London regularly use the TfL website to plan how to get from one place to another, pay fines, buy tickets, check the status of the service and much more. We have about eight million visitors per month and each year the TfL website receives an average of 250 million visits.

TfL website visits

I've been working at TfL for five years and about one year ago I was chosen to lead the development team of our new web site (we have other teams taking care of the API/data, design, content, UX...) On the 25th of June we released the beta version of our website (beta.tfl.gov.uk) and I'm going to talk a little bit about the process used to create the new TfL website below.

New TfL website

Challenges

The current TfL website was created back in 2007 and since then, apart from the content, very little has changed. Transport for London gives utmost importance to users' needs, whether they are in tube stations, using printed maps and guides or online. With the increasing number of visitors, Internet capable devices and Internet speeds, as well as the emergeance of new technologies used to build websites we realised it was time for an upgrade.

TfL website

Among our biggest challenges were:

  • - Designing a site that would work on all classes of device available to access the Internet
  • - Improving the user experience by remembering journeys, locations and users' preferences
  • - Taking full advantage of the fact that many devices are location aware
  • - Creating quick and easy navigation, especially for users on mobile devices
  • - Increasing of performance
  • - Bringing over 150 different websites and services under the same brand/guidelines

After much discussion with the public through forums and questionnaires, it was determined that our users needed a simple, fast and affordable website (and who does'nt?). We also needed a more integrated experience across all of TfL's brands in order to provide users with the information they need without forcing them to resort to different tools, apps and websites.

Solution

To turn users' needs into reality we created a brand new design. It was not only a visual redesign - we changed everything from the programming language used to build it, through the way folders were organised on the server, the integration with CMS all the way to the deployment process.

At each step much attention was given to the needs, aspirations, and limitations of end users of our site. We used a process called user-centered design, or UCD. To help us with this TfL contracted companies specialising in UX, development and testing. We have brought in more than a hundred professionals to work with us at our office in central London.

At each stage the design has been tested with real people to make sure that our ideas were working.

Early in the project our UX team showed users simple designs (sometimes even on paper) to enable the quick exploration of different ideas. After that came wireframes (still simple, with no colour or pictures) and only at a later stage, users were able to test layouts closer to the final versions used on the site today.

Some tests were done in rooms devoted to usability, where participants were observed while using the devices. Often developers and designers also watched the tests to see exactly how their creations were received by the users. It was extremely useful for our development team, as well as being a new experience for many of them.

Guerrilla testing

Other tests were carried out in the streets and at tube stations, where users were trying to solve real problems. This type of test is a quick and cheap way of collecting insights from people in real situations. It can be used at any stage of the project and answered some specific questions coming from the developers and designers as well as giving us general feedback.

A team of researchers spent the day in a tube station in central London, where they tested some site features such as our live departure board, "near me" (used to display other stations, cycle hire, bus stops, places of interest and other useful information, all based on the user's location) and the journey planner, among others. The design of some features has been completely modified based on the results of this research.

Running guerrilla research for the new TfL website

User testing and design iterations

As I said before, we tested each iteration of our design heavily and we believe that the homepage is clean and well-structured with core services easily accessible as a result of this. Other segments have been moved to the bottom of the page but still have easy access.

User testing

Accessibility

As TfL is part of the British government, we care a lot about the accessibility of the site, not only because it is required by law but also we want to bring the best experience to users of the site. The site has been tested with users with various disabilities and feedback from these tests also shaped our results so far.

Results

We're still in beta but we can already see some wonderful results.

Responsive design
  • - The new site is faster than the current one, even with more assets and high-definition images.
  • - No matter what device you are using, the user has access to all parts of the site.
  • - Geo-location allows you to plan your journey from your precise location, and also shows information regarding possible problems on the chosen route.
  • - The number of steps required to plan a route has been decreased so that users have a faster experience when they are on the go.
  • - The site shows the arrival time of your mode of transport (bus, train, tube, river) based on the user's location.
Mobile
  • - The new design delivers a great user experience, be it on mobile, tablet, desktop, SmartTV or virtually any other device
  • - Journey Planner is simpler, faster and easier to use
  • - Maps were integrated with Journey Planner
  • - Faster service updates
  • - New content and navigation

TfL current vs. TfL beta

Current homepage vs Beta homepage

Current v Beta homepage

Current Journey Planner vs Beta Journey Planner

Current v Beta homepage

Current Journey results vs Beta Journey results

Current v Beta homepage

Although the site heavier in weight, it is faster in performance. The expectation is an even greater improvement in performance since the site is still in Beta and does not use all of our infrastructure. Large images are not loaded when the site is used in devices with smaller screens, which makes the site really fast when you need it to be fast.

Performance

Learning

While working at TfL for over five years, starting a project of this size from scratch without reusing any of the previous site (not even the infrastructure) is a huge challenge. And there is nothing better for our type of work than overcoming challenges.

The web team (designers and developers) learned a lot working closely with the UX team, seeing how every user experience is equally important and how UX was important in the decisions made in the design and development of the project. We did our best to balance modernity, accessibility and interactivity with ease of use.

Next Steps

We are still only beginning, there is much more to do. Our next step in the very short term is to enable user login to provide a personalized experience for the visitor (at the moment information like journeys, recent searches, favorite tube stations and bus routes are saved without login, but only on the device currently being used). We have plenty of new exciting features coming up very soon.

If you managed to get here to the end, thanks for reading. If you are not satisfied yet and want more information (in which case you are probably a lot like me), please contact us.