I am Praveen Karadiguddi, a delivery manager in Home Office Digital. After previously spending a fabulous year at GDS, my move to the Home Office has provided a fresh perspective. In a sense I am now on the other side of the fence trying to deliver services following GDS standards and approach.
My first project in Home Office Digital was to help on the Biometric Residence Permit (BRP) service. Foreign Nationals must have a biometric residence permit (BRP) if they want to apply to come to the UK, apply to extend their visa or settle in the UK. Our service allows users report a problem with your their BRP, report a lost or stolen BRP and query when a BRP hasn't arrived.
As part of the delivery of service,
- We now have a working Beta service that has been publicly released. What’s more, our users are satisfied with the service.
- We have created a module to assist in the development of form based applications called HOF. This closely follows the guidelines set out by GDS in GOV.UK elements and rapidly reduces the development time for form based projects.
- We have employed the kubernetes API, enabling us to quickly spin up new environments, saving us both time and money.
Team’s focus on user needs
We’ll be posting in more depth about HOF and use of Kubernates in later posts. Here I’d like talk about how the team’s relentless focus on user needs improved the service we delivered.
Working in agile teams, it can often be a challenge to explain to stakeholders, who may be more familiar with working in traditional environments, that beginning with upfront designs, architectures and release plans simply doesn’t work. After all, because how can you know what to build for your users if you haven’t spoken to them to understand their needs?
User research is often with opposition,. However, building a service that meets the needs of its users will save time and money because you’ll be more likely to deliver a service that people can actually use.
Ongoing, regular testing
We ran more than 70 interviews with users. Interviews began at the discovery phase and are ongoing, despite the project being released. The research included thorough usability testing of the most challenging needs that asylum seekers have, and also carefully considered the needs of assisted digital users to ensure the needs of those with limited digital skills, confidence or access were also met.
All team members regularly attended usability testing sessions. It's important to have the whole team involved in the research, as it helps them relate the work they do back at their desks to the real user need that they have witnessed first hand.
This results in user stories more accurately reflecting the user needs. It also helps service managers fully appreciate exactly how users interact with what is being developed and why the various aspects of the design are so important.
A research-centered roadmap
To reflect our ongoing learning, we had a constantly evolving roadmap influenced by and regularly changed based on our interactions with users and potential users of the service. Where we established a need, user stories would be written and rough prototypes would be refined and refined again, leading to designs we could then implement for real.
The stories progressed through the typical software development workflow: Backlog, Next, Dev, Review/Test/Live etc, as shown in the diagram below. The content, being an integral component of the service, was also regularly tested with users and the GDS content team to make sure it was clear and easy for users to understand.
So to summarise,
It’s so important that everyone in team is involved in the entire process for it to work most effectively. Likewise, the whole team must embrace user experiences and understand how they underpin everything that we do.
Our team, in the words Home Office Digital’s head of user research, Katy Arnold, is a “truly cross-functional and exemplary team”, i.e. we had a service manager, user researcher, designer, developers and content designer working together on every single aspect of the project. It goes to show that when user centred design and agile working go hand-in-hand, we are able to create great services.
Agile is a thing your team is, rather than simply a set of processes to follow. It’s all very well saying you are working using agile methods, but in order to be successful, your team has to be truly agile itself.
Do you have a different approach or thoughts on what we’re doing? We would love to get your thoughts, inputs and experience in the Comments section below or via twitter.