User needs and campaign sites: some principles

This morning at UK GovCamp 2016 we had a great session on government campaign sites, and how well user needs and user stories work for them as a mechanism to capture the things they need to do.

We’ve done quite a lot of campaigns, and often, we struggle to express the user needs that they meet. By and large, we are all convinced that there are some, but we struggle to express them. We end up with things like:

“As a user, so that I can (have my behaviour changed by government), I want a government website to (tell me things (or let me look something up (or help me find some service)))”

This is not very satisfying: mostly because it’s plainly wrong. No one needs “behaviour change”. It’s a non-sequitur. So, we were wondering: do we need a different mechanism to capture stories in this situation? If so, how do we keep our work grounded in reality? That’s what user needs do, and that’s pretty important. Or, do we just need to think about the normal story format in a different way. For example:

“As the NHS, so that I can reduce the cost of preventable illness, I want other people to stop smoking”

But this doesn’t feel great either: separating the person with the need from the person doing the thing breaks the assumption that people do things because they need them.

This generated a lively discussion. Ultimately, I think we all agreed on a few things:

This feels like a good rationale. It may make it a bit painful to understand what the needs are or to express them clearly, but that’s good pain. It’s the hard work we need to do to make things simple.

And on that note, we decided to have a stab at coming up with some principles for what a good campaign is. We came up with a few.

Measurable KPIs

We need campaigns to have measureable outcomes. These should not be things like “reach”, which are too easy to manipulate. They should measure crunchy outcomes and impacts, as objectively and honestly as possible.

AKA principle #3: Design with Data.

Think about channels

People rarely come to websites just because you’ve built them. And if they have an underlying need that they can’t articulate, they’re even less likely to than usual. It’s essential to go to them: to make your campaign visible where they already are.

AKA principle #7: Understand context.

Identify underlying user needs

Campaigns must still address needs: but those needs may be “underlying”, or unarticulated. To be effective, we must understand them. This requires us to articulate them based on research and evidence, not supposition and assumption. Otherwise we’re just making things up.

AKA principle #1: Start with needs.

Time limited iterations

Campaigns that just go on forever won’t work very well. We need to regularly assess their effectiveness, think about whether the user needs and broader context may have changed, and make sensible changes.

AKA principle #5: Iterate. Then iterate again.

Transparency

Campaigns that don’t work or aren’t necessary should be changed or done away with. As with almost all government work, it needs to be done in the open.

AKA principle #10: Make things open. It makes them better.

Have an action for users to take

Finally, and perhaps most importantly, there needs to be something for people to do. “Raising awareness” is not useful. We need people to actually do – or stop doing – something.

AKA principle #8: Build digital services, not websites (sort of)

The GDS design principles are good

For me, this was most interesting as a session because I approached it wondering if the GDS design principles might just not work for things that are essentially marketing. And I left it thinking firmly that that’s not true. They work just fine. The rest of them apply too – do less, consistent not uniform, this is for everyone – all just as good and important things for campaigns as for everything else. That last one especially, as people who are digitally excluded are often lost in this conversation.

We might need to interpret these principles a bit differently, but that’s ok. That’s what agile really is: thinking about how to apply good principles in ways that work for your project – not slavishly following a methodology or a set of rules.

I’m looking forward to the next campaign we do, and putting some of this morning’s session into practice!

(PS: here are the @lily_dart’s notes from the session)