Automating Taxi Stockholm’s airport bookings
Background and goals
Airport transfers is a big source of taxi bookings. Such a big source that, at Taxi Stockholm’s traffic control center, they have a dedicated workstation with an operator working only with airport bookings. Iteam was tasked with making the work of these operators more effective and less demanding.
The operators had a large cognitive load remembering different rules for processing bookings and spent a lot of unnecessary time cutting and pasting information between different systems. This meant that they lost valuable time they could have spent directing taxi traffic and making sure they always had just the right amount of taxis available at the different airports. It also meant that training new operators for this position was difficult.
I worked as a user researcher together with a team of developers and a digital designer. My role consisted of defining, planning, and conducting the user research activities and overall insight generation process.
Process and solution
Understanding context of use
Studying educational documents and other documentation
To gain a basic understanding about the work, business rules and systems me and my team studied educational documents for the operators and technical documentation.
Observations and interviews
We observed and interviewed operators in their work. The research revealed a much more complex workflow than the documentation did. The operators had a huge cognitive load, having to remember things such as rules about how to process different bookings and shortcuts to overcome system bugs and quirks. We also got valuable insights about workplace setup that would affect the design of our solution, such as many operators navigating only with the keyboard and placing windows on their display in certain ways.
Producing and evaluating solutions
Evaluating automation possibilities through prototyping and user testing
In our initial research we identified an opportunity for automation of activities, since much of the work was repetitive and defined by rules that could be defined and given as system instructions. This mainly in the manual transfer of bookings between systems. We explored the technical constraints of this and what percentage of automation would be valuable to the users.
We created a prototype that simulated the automatic transfer of certain bookings that we tested with the operators. The tests gave us clearer requirements for which bookings should be handled manually and which could be automatically processed. They also showed that the operators needed a transparent automation process to feel in control, where they could clearly see when bookings were automatically processed.
To further explore this need for system transparency, the team did a co-creation workshop together with the operators. We worked in three smaller groups where we discussed, sketched and tested paper prototypes on each other. The end result was a simple interface that would visualize booking processing status and allow the operator to handle any errors.
User testing and iterating
Me and the digital designer created a prototype of the status interface that we tested with 5 operators. This produced limited results because the booking data in the prototype didn’t feel real enough and the technical setup was very different from the actual setup of the work station. Therefore, we decided to start development of a working prototype that could fetch real booking data. We conducted another round of tests on this prototype, on a setup closely resembling their own. Since then, we’ve iteratively expanded, improved and tested the solution.