Hello! I’m Jason, a User Researcher for the Get Citizen Income Information team, part of DWP Digital.
I’m part of the team building a back-end system that will help DWP effectively use citizen income data supplied from HM Revenue & Customs.
The key to user research is understanding that you’re building the right system to meet the user needs which in turn leads to design-driven development. You define the user needs and then iteratively build a product, testing alongside development to ensure user acceptance.
However, during this project I was presented with a problem I had not yet encountered before as a user researcher. Because we were building a back-end system, there wasn’t a testable user interface.
So faced with this problem, how did our team carry out user research and do user acceptance testing? In short, how did we make sure we were actually meeting the user needs defined in discovery?
1. We grouped our user needs into five core themes
As we were not building a user interface for a majority of our stakeholder groups we needed to review how we grouped our users. Using traditional personas is a powerful technique and helps give a name, face and story to users. However as our user base includes many segments of DWP colleagues, traditional personas identifying roles and permissions didn’t seem to fit the bill for us.
Instead, we grouped our user needs into five core themes of functionality. By establishing our user needs in this way we could look to deliver a service which would meet the practical needs of users first as opposed to building for mythical non-typical users.
This was extremely effective as it helped us make sure that what we built matched the user’s true need. Our role as a product team is to build an intuitive service which matches the intent of the user. By documenting their true intent and holding that as a core acceptance criteria we ensured that we're building something our users truly need.
2. We were transparent with our findings and processes
Our team wanted to remain as objective and honest throughout the process as possible. Our space was free and open for any DWP team to visit where we’d happily walk all parties through what we had learned so far and what the research was leading us toward. We opened each show and tell with a review of the user research undertaken within the sprint with the anonymised results and insight shared openly for discussion.
By being transparent with our findings and processes, we had to defend our approach from all of those who took interest in our project. Whilst some may see this as potentially irritating we saw this as an opportunity to demonstrate our findings, showing our working out and hold our findings up to direct scrutiny. As the department as a whole was our primary stakeholder we needed to ensure they had access to our insight as well as the assurance they were welcome to speak to us at any time.
3. We gathered feedback from teams
Whilst we didn’t have a shiny user interface to test, that’s not to say we couldn’t test things we were developing. Not only did we float our proposed architecture with potential stakeholders but we also directly tested our developed documentation. Gathering feedback from teams who would actually use our documentation was incredibly important to us, whilst the end result of our service would likely benefit many teams within DWP, our true stakeholders and development partners in this process are the DWP Digital teams.
Reviewing our documentation with them proved incredibly productive showing us how important good documentation is and all the audiences that it could impact. Just because we didn’t have lovingly designed screens to test, didn’t mean we couldn’t test.
4. We developed a deep understanding of our users’ needs
Building on our conversations and the interviews we conducted during Discovery, we established what was important to our users beyond their initial operational needs. We reviewed how they interacted with their workspace, determining what was truly important to them. Alongside the operational needs we outlined what was important to them about what they did. Building this into definitions of done, we aimed to find out what was important to our users beyond their typical daily work.
By deferring to our stakeholders and combining data from interviews clear trends emerged. It was obvious to us that our stakeholders knew what they wanted to do and the limitations they had which inhibited their work. By ensuring that anything built during our alpha phase met the themes identified this meant that the product we were developing would improve existing processes and empower our users.
5. We ‘showed the thing’ in a different way
As we didn’t have a colourful user interface to continually test we needed to ensure the team and other stakeholders were engaged with what we were doing. Yes, our work is incredibly important but discussing data in abstract terms can be cold. To increase engagement and track our progress we injected characters, pop culture and personality into the project.
We created energetic, eye-catching displays using quotes from stakeholders and we showed our research in a way which not only caught the attention and imagination of the team but helped us be more approachable to other stakeholders at all levels.
6. We carried out research as a team
All members of the team are involved as much as possible in our research efforts. Our team, including developers, delivery managers, architects, testers, business analysts and product owner are actively encouraged to join in on interviews and workshops.
Engaging the entire team in speaking to our stakeholders continues to be powerful, leading to illuminating and unexpected conversations.
The above approaches have ensured that our team remains engaged with the research although we don’t have a core user interface to iterate upon. As we progress from alpha to beta our team is committed to implementing user research into our work, by putting the DWP services at the core of our product development we are aiming to deliver a service which is truly user driven.