Working out the exact “shape” of the gov.uk beta has been a long, difficult process. Working out what needs it should meet, how best each need should be met and then defining how the whole proposition hangs together are hard problems.
But gaining a clear, shared understanding of this overall ‘shape’ is also fundamental to building a good digital product – “Every superfluous page we create is one more dead end for an angry, frustrated, confused user”
This blog post is about how we went about defining the shape of the citizen-facing beta of gov.uk, and the tools we developed along the way.
Before continuing I should add a caveat: this is just the first iteration of identifying user needs. It is essential that the shape of the product will continually iterate throughout its life, as will its underlying code, design, user interface and content.
Starting the long journey from ‘articles’ to ‘user needs’
We started with long lists of pages and search terms from Directgov. These we rephrased into statements describing something you might need from the government. Things like “I need to report a lost passport” or “I need to learn what Jury Service involves”. This gave us around 1,800 individual user needs, (or “tasks”).
- Decided which of these initial 1,800 user needs should be included in the beta
- Aggregated those needs which made more sense to be together
- Assigned a format to each user need (in gov.uk-speak a ‘format’ is a type of webpage or webapp e.g. a multipart ‘guide’, a simple answer page, a ‘find my nearest’ webapp. There are getting on for 10 at the moment)
- Assigned a priority to each user need
The team built a small webapp (source-code available on github) to manage this process and assigned each need a number, which allowed us to track its process. Here’s what it looks like:
The Needotron tracks the history of a need through the process and records the reasons for decisions. Things either end up being merged, binned or get a format assigned.
Scope: Should gov.uk try to meet this need?
We developed the following rules to help us decide which needs we should – and shouldn’t – be meeting.
- Do people want it? (based on traffic and search data)
- Can people reasonably expect government to be responsible for meeting this need?
- Can only government meet this need? (or is someone else doing it better already?)
- Is it explaining someone’s rights or obligations?
- Is it transactional or encouraging a shift to digital by default government services?
How should we group, prioritise and format these needs?
Grouping, prioritising and formatting these user needs ended up being an epic task, involving people from across GDS.
The first couple of approaches we tried were not completely successful. First we tried to organise the data using allourideas.org , then tried to apply analytics data directly. Sadly these approaches didn’t give us a clear enough answer, though it all helped build up a collective picture.
The method that finally worked was to first remove the needs that obviously fell outside of scope. This changed a huge problem into a big one. We then grouped the needs into broad subject areas (housing, police, pensions) to break the one big problem into many smaller ones. From there groups of 2 or 3 people discussed what should be merged, what should be binned and what format things should be.
All this was done as a paper exercise with the final result copied into the needotron.
We then assigned a priority to each need based on their knowledge of search analytics on Directgov. First working individually they each scored the needs as high, medium and low. The scores were then combined to create an overall score.
This prioritisation is being used to make sure we work on the most important things first, and invest the development time in building a handful of bespoke app for the needs that are both important and significantly differentiated – things like reporting a lost passport.
For clarity, this is not the same as saying that one need is more important to a particular user than another – everyone needs different things from government and we aim to meet them all and build in custom analytics into each page to make sure we do so.
We currently have just under 950 needs with formats and priorities assigned, with a similar number either discarded or, more commonly, merged together to form broader needs.
This treemap shows the breakdown by format:
Towards a product dashboard
We are planning to develop the Needotron into a fully fledged product dashboard, to help product managers understand how well each and every need is being met. It will give a view across the full technology and content stack (from the server that it is running on, to the version of the code deployed, to the edition of the content deployed). Crucially, it will also act as the aggregation point for all product analytics, highlighting explicit and implicit user feedback and giving access to A/B test results etc.
Its name started out as a bit of a joke, but the Needotron has quickly become the core of the whole project.