In January 2022 the user-centred design team started a new project to look at improving the way we manage grant activity across BEIS, from designing a grant to monitoring and reporting on grants we have awarded.
For some context, BEIS plans to deliver about £22 billion in grants over the next 3 years. We are one of the top 5 government departments by amount of grant funding given out. We decided to do a pre-discovery because we knew this was a huge topic and a really important project for BEIS.
Some of the team had never done a pre-discovery so we looked for guidance on this project phase, but there was nothing in the Service Manual.
That is why, at the end of our pre-discovery, we saw an opportunity to share our experience. We ran a workshop to share what we learnt during Services Week 2022. Within a few hours of opening ticket sales, all 50 places were filled! So we knew this was a topic lots of people are interested in.
Here’s what we learned.
So what is pre-discovery?
Pre-discovery is time to understand why your project is needed and find out what you already know about the topic. You are asking yourselves whether there is a problem that needs to be solved.
Pre-discovery is also a chance to gather user research that has already been done on similar projects. However, you shouldn’t do comprehensive user research or attempt to find solutions because it is unlikely that you will have enough evidence to fully understand your findings.
In the discovery phase you will then move on to fully understanding the problem. You are probably not experts on the topic at the start of any project, so pre-discovery forms the basis for a successful discovery.
How we approached pre-discovery
We needed to know why we had been asked to solve the problem.
The grants team in BEIS gave us their initial problem statement for a digital grants service. We asked lots of questions to challenge this:
- does this service need to be built?
- what would be its purpose?
- what similar services are there and how do they work?
We also needed to work out whether we should be looking at solving a problem for the businesses applying for BEIS grants, internal BEIS colleagues, or both.
How we worked together in pre-discovery
We spent about 11 weeks in pre-discovery and had a team with lots of different experience, including:
- service designers
- business analysts
- user researchers
- content designers
- developers
- policy experts
To kick off, we held a workshop to talk about team culture. That was a good way for us to get to know each other - favourite food is always a topic that everyone can talk about!
This exercise also made us aware of personal preferences around working and what kind of team we have in terms of neurodiversity. Ours was leaning more towards the introverted side.
How we found out what we thought about the problem
Right at the start of the project we noted our assumptions. This was a really useful exercise. We wrote down our assumptions about users, timescales, cost, technology, any risks or cultural barriers.
We mapped them on a Risk-Impact diagram – what would be the biggest risk if we didn’t address it? And where do we think we could make a big difference? This made it easier to understand what our priorities should be.
We also mapped the stakeholders for our project to see who runs grants in BEIS and who we wanted to talk to during discovery.
How we worked out what we don’t know
The most time-consuming task we did was desk research. This took up the bulk of pre-discovery.
We read through and summarised all the documents we had about BEIS’ past digital grant projects, and how past and current grants are run by policy teams.
These materials were a mixture of service assessments, reports, application forms, guidance and meeting notes. This took a really long time! The whole team pitched in.
We clustered key insights together on Mural to pull out themes in our findings:
- what do we know about grants in BEIS?
- what do we know about our internal and external users?
- what are the main problems?
- how might we address them?
That allowed us to see the gaps in our knowledge. In other words, what do we need to know more about?
We also spoke to other departments who are working on managing grants, to learn about the tools they are using and the services they have built or are building.
With that knowledge, we had a clearer picture of what is possible, and what technology is currently available.
How we did (a bit of) user research
Even though pre-discovery is not the place for substantial user research, we needed to talk to some senior stakeholders to understand gaps that we found during desk research. We talked to grants policy team members about their processes, the tools they use and any pain points that they experience.
We knew that senior stakeholders are very busy and that we’d need to talk to them again in discovery. So we decided to start by sending off a survey to get some high-level information about areas that desk research hadn't told us much about.
This wasn’t about finding out all the details – it was about working out what we know and what we need to research in discovery.
What next?
As user-centred design specialists, we would like to solve the whole problem and design an end-to-end journey. But in real life there are restrictions: there are budgets, timelines and business needs to keep in mind.
In discovery we plan to choose one area to dig into in more detail, while still having a broad overview of the whole problem.
When we move into discovery we will spend most of our time talking to people: our users and stakeholders have a wealth of information that will help us understand the problem. They are the reason why we are trying to make improvements in the first place.
Not all projects need a pre-discovery. We hope this was useful if yours does!
Leave a comment