Hello! We are the Get Citizen Income Information Service team.
Our team’s aim was to review how DWP accesses citizen income information and if required, create a new method of doing so. We want to give fast, reliable access to citizens’ income information to enable DWP services to drive operational efficiencies, reduce fraud and error and inform future departmental policy.
We recently completed our Discovery phase and want to share a little about our product and our learning.
During Discovery we did a few things that, with hindsight we would have done differently. For anyone about to embark on a Discovery of their own, here are our top tips:
1. Get the right team at the right time
Due to a number of reasons we started our Discovery without our Senior Delivery Manager or User Researcher. Because of this, we didn’t truly hit our stride until halfway through week three when they joined and the team was complete. In retrospect we’d advise all teams to only start Discovery with all roles filled and present from the start.
2. Stay focused
Discovery is a rollercoaster of Post-Its and user research, but the fact is you’re either in Discovery or you’re not. The team should be wholly dedicated to producing something worthwhile – any other projects or responsibilities that could be a distraction will have to wait.
3. Get everyone involved
Perhaps one of the best things to come out of our Discovery is that everyone on the team has a story or anecdote from speaking to users directly. By getting involved in the research, we all have first-hand accounts of the problems our users face every day. This helps to put a face to the problem as well as growing a shared understanding.
4. Trust the research
User research was crucial to our Discovery, letting our users guide us through their workflow made us question our assumptions to understand their needs. The simplest questions asked provided keen insight. In its simplest form we wanted to determine:
- What are you trying to get done?
- How do you currently do this?
- What could be better about how you do this?
As we compiled our analysis the solution slowly started to build itself.
5. Speak the same language
Our team consists of people with experienced civil servants and newbies all with different backgrounds and experiences. A challenge we experienced early on was getting everyone on the same page and understanding what each other meant. Words are subjective and can be interpreted in different ways, get your team on the same page so you can all understand each other.
6. Nail down the problem and make it clear
Speak in plain terms within your team and with stakeholders to determine what the actual problem is. It’s incredibly important that the whole team understands the problem, the stakeholders and the potential solution. Threading together a group of individuals with different approaches can be difficult, however if the entire team understands the core of the problem at its most base level it can unite to solve it together.
7. Make use of your networks
When undertaking user research you’ll often come across blockers be it process or sometimes not knowing who you actually need to speak to. Asking your team’s networks is invaluable, especially if you could potentially provide value to them. People naturally want to help each other; the thing you may be looking to build could help them, let them know your team is looking to add value!
8. Too many cooks (will become disinterested in the broth and just walk away)
Our initial team was very different come the end of Discovery, shrinking considerably despite adding permanent additions during the process. The team initially had representation from all across the department, and whilst they may have initially been stakeholders and dedicated to the project, unless they had clearly defined work to get on with this slowly tapered off, often through no fault of their own. The smaller team had a better dynamic, stronger focus and unified drive to solving the problem at hand.
9. Location, location, location
We loved our little glass-walled Discovery room. It was an invaluable workspace for an agile environment with space to write on walls, throw sticky notes everywhere and chart user journeys.
The Discovery room became a team member in its own right as an environment we could share ideas. Maximising the wall space for collaborative work proved a fruitful endeavour for the team, it was a joy watching our progress as we filled the space with user research.
10. Show, don’t tell
Our most effective Show and Tells during Discovery involved us taking our stakeholders through the research and planning on the walls, actively engaging them with the resources as well as being available to speak to anyone and everyone following the presentations. Due to the varied locations of our stakeholders we also ran virtual sessions but we felt as a team that the in-person sessions were far more effective and engaging.
Our Discovery has successfully progressed to the Alpha stage so we’ll blog again at a later date to share our experiences of the next phase of delivery.
We’ve thoroughly enjoyed Discovery and the time put in to working on this project has challenged our assumptions. Most importantly, the user research has ensured that the product we create for our stakeholders is something that they actually want, will use, and will solve their data problems.
2 comments
Comment by Naomi Bell posted on
A great balanced view and well presented insight into agile ways of working during a discovery phase. I will be re-using for future Discovery phases, thanks ??
Comment by Cathy Dutton posted on
Great article, this discovery sounds very similar to a project I’m currently working on in DEFRA, are there any discovery findings/outputs that you are able to share?