Project Description
We hear a lot of things about the various public transport networks, but fault reporting is not really something that makes the headlines. Every day, bulbs flicker, fittings wear down, and cracks appear under the immense traffic of London’s commuters. And it’s up to station staff to ensure these things are reported and fixed in a timely manner.
This network was in a unique position, where they had a number of devices (mostly iPads) that were suddenly available to bring them into the technological age. One of the very first services to be made available on these devices was this maintenance app; a staff-only, native app that would allow users to quickly and easily report faults, increasing the number being reported promptly and ensuring timely action to remedy them.
Not afraid of a challenge, the network wanted to launch this app while simultaneously embracing Agile methodology, bringing in external expertise to both create the service, and to train their internal employees in how to work in an Agile way.
On my first day I was handed a 28 page requirements document, detailing every function the app ought to have, each mapped to a ‘stakeholder request’. These were based on business requirements from an organisation who has always worked in a Waterfall way, but they were keen to change the way they worked. I read this document but took it with a pinch of salt, feeling fairly certain that some of the requirements might be contradicted by end users when questioned.
In the document were some clearly defined business objectives:
Reduce the delays in fault reporting
Reduce the amount of faxing – replace this entirely, or at least use it less
Provide more accurate fault location information
Support and enable clearer fault communications
Introduce an additional fault reporting channel which can be used in operational situations, such as a bomb scare
I quickly went out into the field to find out more about what users needed from the app. The existing process went something like this:
- A member of staff spots a fault, e.g. a blown out light bulb
- They tell their supervisor
- Their supervisor makes a note
- A couple of hours later, when back in the office, they write out an email to the control centre
- The control centre then calls them back with more questions because they have various fields to fill in
- The fault gets assigned to a contractor who comes and fixes it in the next few days
- Afterwards, the supervisor receives an email or fax to say that it’s been done, asking them to check it was done satisfactorily
This didn’t always go smoothly. Sometimes faults were submitted on bits of paper via fax. Sometimes, when the contractor arrived, they were unable to find the fault. Sometimes, it was such a hassle to submit the report that smaller faults weren’t being noted at all.
Through my time spent in the contact centre and with staff, I was able to get a feel of how the app should work, and created a task model to demonstrate every possible use a user could get from the app (from what we knew so far). The user experience goals were really quite ‘normal’ for app design; speed, ease, recognition over recall, and error prevention where possible. A suggestion in the brief had been that the app could use photos; a fantastic solution to ‘how to describe where the fault is’. A user could take photos from different angles and show exactly where the problem lay. In addition to this, I added annotation functionality; a circle tool, a free-draw tool, and an undo. This way, users could be even more specific.
The state model for a reported fault
We weren’t able to change the legacy systems that recorded this data in the contact centre, so I worked with them to understand the fields they needed to fill in, and what these terms really meant to Joe Bloggs in the station. I was aiming for an app that, while aimed at station staff, could be used by any employee with any level of experience to report a fault – anywhere. This is where I find that being an outsider absolutely has its advantages. If I don’t understand it, it’s not simple enough.
The functional requirements had already been defined, with a limited scope for the pilot. So once I had an idea of how the app could work, I put together some wireframes and ran ‘quick and dirty’ testing using InVision, changing things on the fly. I iterated on these designs, testing with users of different levels both in the quiet of the office and the bustle of the work environment. It’s not often that you get something really close, really fast, but the wireframes got an approval rating of 96%, and the live app scored 94% (an expected drop; you couldn’t type into the wireframed prototype, making the real thing a little slower).
However, the first version of the app was certainly not the final thing – we were starting with an MVP and building upon it. While the first version could report faults, it could not receive updates and could only work for some of the network, due to a mix of legacy systems. As such, I was simultaneously working on an “end state vision” that made the most of everything iPads have to offer, e.g.
Location tracking, so users did not need to specify where they were;
Multiple user logins, so devices could be shared across users on different shifts;
A fault dashboard with live feedback, so users could see the current status of their faults and immediately approve or reject a fault that had been worked on, adding photos if needed;
A management dashboard, so station supervisors could monitor faults for multiple stations, or look at the workload of specific users;
Plus generally integrating the user flow to work seamlessly across two different systems, each requiring similar – but slightly different – information about the faults being reported.
Wireframe examples
The end state vision for a user dashboard on iPhone, ‘day one launch’ dashboard on landscape iPad, and options to specify fault access times on a portrait iPad
A selection of the detailed wireframe design (including flows and interaction design across multiple states) created for the TfL Fault Reporting app
Some of the finished UI design work
As this project is internal it has not been widely publicised, but the following are quotes from users and stakeholders:
“Really nicely designed, a really clean interface”
“Looks like it’s an Apple iOS app”
“It’s so much better than what we do now”
“You couldn’t make it any easier than that, really”
I am pleased to report that my “end state vision” wireframes continue to be refined with ongoing user research and Agile development, and the app is steadily being rolled out across the network. I’ve spotted a few people using it while on my morning commute, too!