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 Timetabling24/08/2016 - Udine, Italy

Mobile vs Desktop traffic

Mobile

TabletDesktop

August 2016

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

NCT bus information system

TransXChange file (XML) Importing script Journeys

DatabaseTimetable generator

Journey planner

Departure boards

Real-time information

Fares UI

UI

UI

NCT bus information system

TransXChange file (XML) Importing script Journeys

DatabaseTimetable generator

Journey planner

Departure boards

Real-time information

Fares UI

UI

UI

ChallengesTimetable 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

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

Continuous usability testing

Hypothesis Design Develop Test Decide

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”

Continuous usability testing

Hypothesis Design Develop Test Decide

Design one or more solutions that help to test the hypothesis. For example:1. Plain timetable2. Plain timetable + search box3. Compacted timetable

Continuous usability testing

Hypothesis Design Develop Test Decide

Implement the solutions in a testing environment.

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.

Continuous usability testing

Hypothesis Design Develop Test Decide

Analyse the results, present a report to the stakeholders, and decide the next steps.

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.

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).

Additional feedbackQuantitative. 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)

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

Results3 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

Lessons learntInitial 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

Future workTake 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

ThanksSlides: http://www.slideshare.net/draxus

Email: manuel.martin@wearebase.com

Twitter: @draxus