Alan Rider is a digital capability lead at the Department for Transport.
It can be tough to find the data you need to do a task. It’s not that it doesn’t exist or that someone is hiding it. It’s that it’s sometimes hard to find, and finding it takes a long time.
We suspected that was a problem for people working in the Department for Transport (DfT).
However, at that stage, it was an assumption. We carried out a discovery to check whether we were correct, and if we were, what we needed to do to fix it.
Proving our case
We spoke to over 60 people across the department who confirmed this. It wasn’t just data sets they wanted to find, but they also wanted an expert to talk to.
In some cases they needed to talk to someone from the outset. They wanted to know what was available and how it should be used and interpreted.
When you’re not sure what you need or where to find it, you waste a lot of time and energy in pursuit of it. A simple way of seeing available data and tracking down an expert would free up time to focus on delivery.
Meet our personas
We created four personas. They represented users in policy, statistics, transport modelling and operational research. We set out their needs, mapped their user journeys and worked out where their pain points were.
Priya works in policy. To inform her work, she draws on the expertise of others in the department.
Simon works as a transport modeller. He constantly updates and improves his models, drawing on the best available data. His work is technically complex. He typically works on the same kinds of problems for a long time.
Charlene is a statistician. She takes raw data and processes it to produce statistical reports. She’s an expert on her data, and fields lots of incoming requests from the department and from the public.
Halil is an operational researcher. He provides analysis on a range of topics to decision makers and internal teams. He draws on a broad base of analytical disciplines.
Every picture tells a story(board)
Once we determined the user need, we worked with an external partner to help us as we moved into alpha.
We spoke to an extra 60 users in more depth. This enabled us to develop a set of storyboards to explore their potential user journeys. This allowed us to understand how a data index could work in practice.
We developed paper prototypes and operational proofs of concept using the GDS frontend toolkit. These helped us test functionality and determine if the service was technically viable.
We developed an operating model to ensure the index was sustainable. We produced a delivery blueprint so that systems were in place to support it.
We built a pop-up agile workspace in a meeting area to promote the work and our agile approach. We used mock-ups, storyboards and a user research wall. We created a comfortable space to conduct interviews that put people at their ease.
What did we find out?
We learned a number of things during the process.
Expertise was as important to users as access to the data assets
Sometimes it is necessary to restrict direct access to a data set and point users to a person to talk to about it first – usually the data owner. This protects both parties.
It’s important to understand what a user needs to decide if a data set is useful
People access the data set to see what’s in it, but what they’re really interested in is how suitable the form of information is to the current task. This could be a database, spreadsheet, document or visualisation. They also want to know what level of assurance it’s been through before they use it.
Once a user journey is understood, it’s important to get a working prototype, using real data, in front of users. The team integrated the GDS frontend prototype with cloud-based ‘search as a service’ technology.
This provided an operational proof of concept involving 600 real DfT data sets to support user research. It also demonstrated the value of the service and its technical feasibility.
It was important to develop an operating model in parallel
This helped us to build buy-in across the business. It also ensured that the information in the index is well maintained. Rather than invent new processes, we linked into existing processes and responsibilities.
It was hugely beneficial to have a dedicated agile space to work in
It helped us visualise the research findings, meet with users and run show-and-tells, which enhanced our work. Lots of visitors saw what a fully agile project looked like. This was still a bit of a novelty in the central department.
Having completed a successful alpha, we are now in the process of securing internal sponsorship and funding for the beta stage of the index. The benefits of demonstrating how an agile project like this can work are already paying dividends. We are now using the same approach as a model for other agile projects.
Other departments are asking us about our approach to developing the index and internal teams are learning from the process and looking to apply agile techniques to their projects.
If you want to know more, leave us a comment below. You can also follow the DfT on Twitter.