The increasing number of passengers using mobile devices like smartphones or tablets in last few years have motivated transport companies to develop mobile websites and apps for their customers. However, the transition from desktop to mobile versions is challenging and many websites are still not optimised for user experience on such devices. In this paper we present a usability study carried out with the timetables of Nottingham City Transport website. A number of design changes have improved the overall user experience as confirmed by the results.

1. Improving transport timetables
usability for mobile devices:
a case study
Manuel Martin Salvador, Marcin Budka, Tom Quay, Anthony Carver-Smith
11th International Conference on the Practice and Theory of Automated Timetabling
24/08/2016 - Udine, Italy

2. Mobile vs Desktop traffic
Mobile
Tablet
Desktop
August 2016

3. TransXChange: UK nationwide
standard for exchanging bus
schedules and related data.
● bus schedules including stops,
routes, departures times,
departure frequencies, etc.
● the days on which the services run
● bus operators information
● information about accessibility of
stops and services for wheelchair
and other users
● 316 pages PDF!
Transport data in the UK

4. NCT bus information system
TransXChange
file (XML)
Importing script
Journeys
Database
Timetable
generator
Journey
planner
Departure
boards
Real-time
information
Fares UI
UI
UI

5. NCT bus information system
TransXChange
file (XML)
Importing script
Journeys
Database
Timetable
generator
Journey
planner
Departure
boards
Real-time
information
Fares UI
UI
UI

6. Challenges
Timetable generation
- Support TransXChange
- Grouping lines with similar routes
- Day shifting (buses running after 00:00)
- On the move → Dynamic timetables
based on location and time
Timetable UX
- Small screen size (too large timetables)
→ Compress rows and columns
- Variable resolution (vertical vs horizontal
orientation) → Responsive
- User interaction → UI controls

7. Usability study
● Set some tasks for the user to solve
● Ask the user to think out loud
● Let the user freely interact with the app
● Take notes!
● Optional: eye tracking

8. Continuous usability testing
Hypothesis Design Develop Test Decide

9. Continuous usability testing
Hypothesis Design Develop Test Decide
Formulate the initial hypothesis. For example:
“90% of users can find the time to catch the next 1A bus at County Hall stop in less than 20 seconds”

10. Continuous usability testing
Hypothesis Design Develop Test Decide
Design one or more solutions that help to test the hypothesis. For example:
1. Plain timetable
2. Plain timetable + search box
3. Compacted timetable

11. Continuous usability testing
Hypothesis Design Develop Test Decide
Implement the solutions in a testing environment.

12. Continuous usability testing
Hypothesis Design Develop Test Decide
Perform the usability test by selecting a number of users and splitting them in different groups
(one group per solution). We should collect as much qualitative and quantitative feedback as
possible that can help make a final decision.

13. Continuous usability testing
Hypothesis Design Develop Test Decide
Analyse the results, present a report to the stakeholders, and decide the next steps.

14. Continuous usability testing
Hypothesis Design Develop Test Decide
Ideally, the final decision would be to release the best solution to the production environment.
However, the decision could be to reformulate the hypothesis, test different solutions, or
increase the number of users, among others.

15. Key performance indicators
American Customer Satisfaction Index (ACSI) indicators:
● Overall satisfaction. How did you feel overall with finding the information in the
timetable? From 1 (very dissatisfied) to 10 (very satisfied).
● Level of difficulty. How difficult was it to find the information that you needed? From
1 (extremely difficult) to 10 (extremely easy).
● Expectancy. Do you think that this timetable is the most appropriate tool for finding
the bus information? From 1 (falls short of your expectations) to 10 (exceeds your
expectations).

16. Additional feedback
Quantitative. For example:
● Number of taps
● Time per screen
● Total time
Qualitative. For example:
● User direct feedback
(spontaneous or using a
questionnaire)
● User indirect feedback
(when thinking out loud)

17. Timetable UX changes
Time navigation buttons
Tap on table to
expand/collapse stops
column
Header
3 rows direction/date
Button to show all stops
Row and column
highlighting
Only main stops are
initially displayed
Compact times by
frequency

18. Results
3 Tasks: easy, medium, difficult.
Total participants: 12
Splitted in 2 groups:
● Group A: original timetables
● Group B: new timetables
3 Key performance indicators:
● Satisfaction
● Difficulty
● Expectancy

19. Lessons learnt
Initial assumptions are often wrong
→ Test more, test often
Finding people to do testing (for
free) is difficult
→ Incentives could help
There is no “average” user
→ Find people from different
backgrounds

20. Future work
Take advantage of other
information sources:
● User journeys (e.g. automatic
highlighting based on user common
routes)
● Realtime information (e.g. show
where are the current buses)
● Disruptions (e.g. adjust times based
on planned disruption information)
Accessibility testing with visually
impaired users

21. Thanks
Slides: http://www.slideshare.net/draxus
Email: manuel.martin@wearebase.com
Twitter: @draxus