The ask
To reduce time and manual effort required to deliver a vital government service used by a huge number of people.
In this piece, I'm talking about how we tackled a small chunk of the overall, long-term engagement. This is a service that is part of a much larger service which we worked to automate.
The existing service that we automated was processed and handled manually, involving 3 full time employees working on average approx. 4/5 hours per day on this task, every day of the week. This depended on the number of users requesting the service (via an email inbox) and there were peaks in demand for this service where the people who had to manually handle the process were totally flat out. The task was repetitious and involved manually moving spreadsheets around, making minor edits and lots of back-and-forth via email with users. The workload was to be increased as new policy was going to require more and more requests to this service.
The team
(with a mix of client and consultants, allowed for up-skilling of client colleagues)
- 10x Dev
- 3x Infra
- 2x QA
- 2x Experience Designers
- 4x BA / Product
- 1x Project Manager
- 2x PO
The approach
We started by building a vertical slice that was desirable, usable and functional for a subset of the initial users.
The initial vertical slice was delivered to an initial group of pre-selected organisations. Those organisations had existing good relations with the client and were keen to take part in our user research and make sure their voice was heard in our user-centred design process. They provided regular feedback and user interviews to tell us what was working for them and what could be improved.
Also, any initial bugs could be fixed before this was rolled out more widely.
The coded prototype
To start, I facilitated collaborative workshops with the client to understand the as-is manual process in detail. Based on that, collaborative workshops were held to develop a coded prototype. I built this using the GOV.UK prototyping kit, using components from the GOV.UK Design System. A click-through demo (blurred for confidentiality) is shown below.
Using the GOV.UK Design System ensures accessibility best practices are followed. The design system has been designed with accessibility in mind and has been extensively user tested. By using those components and patterns as much as possible, we are putting ourselves in a good place for accessibility of the service.
I organised and facilitated usability testing of the coded prototype with future users of the service. Users were asked to click through the prototype as if it were a real service and they were using it to perform their task as usual. There were remote (screen share) sessions in which users were asked to:
- Click on the link (to the prototyped service) and run through the service as if they were trying to perform the task they currently do by emailing the manual process team
- Think out loud
- Tell us what was clear / unclear
With these usability tests, we:
1. Uncovered problems in the initial design
2. Discovered opportunities to improve the design
3. Learned about users, their behaviour and preferences
On the whole, users saw the research sessions as mutually beneficial. They could have their input and ensure we were designing the service as best as possible for them. Having this group of helpful research participants was critical. This project reiterated to me the importance of fostering good relationships with a group of users for research purposes.
Delivery
In terms of delivery, our team went through a couple of iterations to get to effective ways of working between BA / Dev / Design / PO.
One such iteration is that initially, the intended flow of the website was not immediately clear from the coded prototype. As the designer, I was frequently getting asked to join calls to clarify the flow and user journey. So, I created this user journey mural as a source of truth for all to understand and allowing devs to understand without having to join a call with design.
We employed an iterative design approach described in part by the diagram below. This diagram suggests learning only happens at the beginning which was not the case for our team. The learning was ongoing. Some examples of the activities that might take place are included in the diagram for each phase.
By ensuring we were prioritising regularly, we were able to deliver value from the outset and had a production service deployed to a subset of users within just a few months. The below picture shows an example of a MoSCoW prioritisation exercise we went through for user stories. The stories were picked up in order of priority.
The result
- A live service built with a user-centred design approach, ensuring we kept the users front and centre
- Strong collaboration between Dev, XD, BA and PO leading to the delivery of an effective service
- Freeing up time of full-time employees, allowing them to focus on more important work
- Decreased time to get a response from the service, from weeks to minutes
