Field workers, often employed at arms length from nbn through service agencies, are required to use nbn tools for jobs, tasking and invoicing. Historical implementation of digital tools for the field led to numerous sub-optimal 'solutions' being imposed on this workforce, causing field technicians to use software that is difficult, confusing, and adding significant clerical time to their day. Users had to become experts at using the tool rather than being employed for their primary expertise: fixing and connecting the citizens of Australia to our broadband network.
Our digital solution was part of a wider suit of simplification measures aimed to reduce the clerical burden on field workers. By not focusing on just the the software experience, we could increase our impact by springboarding off the results of task simplification audits.
Our tool, was used by the field to work out what job they needed to do, its lcoation and the standard tasks we expect them to complete (and get paid). It's a long user experience, but by focusing on one aspect, tasking, we could improve the highest value part of the process. Unable to re-architect the existing platform, we dove into customisation features of the platform, to drive real speed changes in how tasking was done. This reduced time to complete tasks by around 50%. Field were spending less time on administration and more time on actual work. This in part, contrubtued to saving nbn 100million a month.
The approach started wide and went narrow as the project progressed. With broad ethnographic research, we then moved into buidling prototypes to understand in detail, if our work was driving the outcome we wanted.
Ethnographic Research With Field Technicians
Going out the field, and understanding what it's really like to use our tools was a vital first step in understanding the problem space. It communicated, both for myself and the wider project team, the context in how the software was being used. Rather than looking at an isolated part of a tool, we learned that
- Field workers used many tools, the tasking tool was one of many they would use for any piece of work - from diagnostics to testing, from communications to mapping.
- Field workers work in challenging environments - harsh and bright environments (my research was conducted during the Australian summer) highlighted for instance, how hard it was for the field to see screens in bright and glaring sunlight.
- The fluid nature in how field technicians did they work - using intuition and problem solving to rectify issues.
By understanding this wider context of tool usage, we could make better decisions on functionality and presentation. For example colours and size of items could be optimised for high glare environments, simplifying interaction design reduced the cognitive load for the field technicians.
Service blueprints of the end to end experience, then coupled with detailed deep dives into key parts of the process drove our understanding of the process and where we could drive improvements.
Framing is such a key part of the teams understanding of the problem, and a vital step to move from research insights from your contextual enquiry into an artefact we could use to collaborate and decide what to do next.
Prototype to Build and Learn
Prototyping in Figma, and then researching with the field, ensured we were delivering improvements. Usability sessions, helped us test our concepts and our assumptions with field workers. It also uncovered some additional insights, such as [potential advantages in developing deeper integrations with testing tools, that could further improve the field experience
When this work is coupled with a small autonomous delivery team, we could deliver incremental improvements to the field with each sprint release.
Not all things work and some things don't work in the way you expect. Improving speed of task completion had a massive boost to improved field technician satisfaction and drove improved speed of task completion. However, some issues remained. Feeling burnt from previous tasking and invoicing failures, field workers worried about not being paid would often attach a multitude of pictures as 'proof of work'. This behaviour still added huge amounts of data and time to their tasking process, especially using mobile data in rural areas. - They simply didn't trust the process (yet) and were unwilling to give this up.
Many organisations use off the shelf tools to implements software quickly. However, without a solid research and discovery process which understands user needs, solutions often miss the mark. This is partly driven by the software itself - off the shelf tools are created to capture to a wide market. Their functions are often too broad and align to aligh with a specilaised workflow, which often lacks the nuance or customisability to truly help the unique needs of your workforce. You often can't just fit the people to the tool, and organisations need mechanisms to fit the tools to the people. Qualitative and quantitive research provides the insight, and design through prototyping and delivery, ensures we're delivering the right outcomes.