Last week GDS met with colleagues from Department for Transport (DfT) and two of its agencies to talk about their – and their users’ – needs of a consultation platform. As we often get requests from departments for advice on picking user platforms or running engagement exercises, we thought it’d be useful to share with you the process we went through in order to determine these needs of a consultation platform or tool. Actually, we use this process on our other projects too.
Bit of background
DfT and its agencies (such as VOSA and DVLA) hold over 50 consultations a year. The number of responses these consultations get vary widely. There isn’t really a ‘typical’ consultation. They’ve had success using Citizen Space as their engagement platform but it’s important to regularly review suitability of what you use, especially as new digital tools and methods emerge.
GDS puts the user first- and that’s what we do in our workshops. Obviously enough, we consider users to be anyone who uses the system, whether that’s people in departments administering a consultation, or a citizen responding. The list of users we came up with for the consultations run by DfT and its agencies are:
- General public/ citizens
- Lobby groups
- Policy teams
- Comms team
- National and local press
- Local Authorities
- Other Government Departments (OGDs)
We use these categories of users – written on cards and stuck to the wall – to stimulate discussion about the needs each type of user has. We articulate these needs or “user stories’ in the following format:
As a [type of user], I need to [do a thing] so that I can [get some benefit].
Here are some of the stories DfT and its agencies came up with:
- As a respondent to a consultation I need to be able to respond to consultations easily so that my input can be heard by the Government
- As a member of the comms team, I need to tell respondents precisely where a policy is in its life, so that we receive useful and useable responses
- As a citizen, I want access to easily understood additional background information so that I have context and can provide a more informed response
- As a respondent, I need to know how when the consultation closes so that I can comment in time
- As a local citizen, I need to see proposals on a map (e.g. changes to roads, new roads, etc) so that I can understand their effect on my local area more easily
- As a trade organisation, I want to see the detail of the policy/regulation so that I can fully understand it before responding
- As a member of the public, I want a way to easily respond ‘yes’, ‘no’ or ‘I don’t know’ rather than having to write an essay, so that I can be be heard without using too much time
- As a respondent, I don’t want to have to respond to every question, so that I can answer just the things I know/care about
- As a member of the policy team, I want to be able to easily categorise and analyse responses, so that I can understand who has responded quickly (even during the consultation itself)
- As a respondent, I want to be alerted when a response is published so that I know that someone has taken my comments into account
- As a citizen, I need a way of knowing what happened as a result of the consultation, so I can hold the Government to account
As you’ll see, many of the stories apply to more than one type of user, which is why we used ‘respondent’ as shorthand for ‘member of the public’ and ‘citizen’.
This method of capturing things that users need to do has some interesting side effects. It:
- enables us to focus on genuine user needs, by ensuring that every function proposed has a real benefit to a real user. This cuts down on superfluous “nice to have” functions that lead to difficult to manage or use systems
- allows us to capture what the product needs to do without being prescriptive about how it does it
- focuses the team and stakeholders on users, and makes transparent any tensions between competing needs
Having run a number of sessions with people who do consultations, we know that a lot of these stories are common to most (if not all) consultations. I hope the ones above might provide a useful starting and thinking point for you. Would it be helpful for us to come up with a list of the most typical user stories we encounter?
In this particular case, we stopped at the point of collecting user stories but in other cases, we might go a bit further, by offering help them identify tools which deliver the kinds of functionality they need, connecting them with suppliers, putting them in touch with colleagues who’ve done similar things so they can benefit from the experience of others. If you’d like to know more about these things leave a comment and I’ll write another post.