“We’re going to split you into groups and get you to do the work.”
Words that strike fear into the hearts of conference-goers everywhere, but the delegates at the GDS Content Design Conference were equal to the task.
We ran 2 sessions on ‘Content Best Practice’. Rather than preach the ‘GDS way’, we wanted to share ideas about what works, what doesn’t and how we can make things better.
Each session was split into 4 groups, and we used Post-It notes (of course) to generate answers to 2 questions:
- what does ‘good’ look like?
- what problems do you experience in producing content?
We then chose one problem per group and thought about solutions.
It was a valuable exercise in its own right: it’s great to discuss these things with colleagues across government. But here I want to take the next step by presenting some of the results and suggesting a couple of ways to continue the conversation.
The results are in
After the session we gathered 231 post-it notes, transcribed them and turned them into word clouds. This is what we found:
What does ‘good’ look like?
First we asked our groups to think about how they know a piece of content is good.
We really wanted to know what measures people actually use, rather than what they think they should use. I think we got a mix of both.
Variations on making it easy for the user, meeting user needs and using clear, plain English were the most popular answers. We could think of these as our goals. Other answers touched on how we might discover whether we’ve met them, eg positive customer feedback, a reduced number of phone calls and low on-page searches.
Some answers reflected the reality of working in a government department or agency, ie meeting business or ministerial needs, or gaining senior leadership approval. Nothing wrong with this, of course, provided it’s not at the expense of meeting user needs.
What problems do you experience in producing content?
We know what we want to see in good content, so what’s stopping us from producing it?
Many of the answers could be grouped under a heading of ‘culture’. In general terms, some people in departments and agencies don’t ‘get’ the GOV.UK style and approach.
More specifically, people mentioned press office or ministerial interference in the content creation process, or a culture of short deadlines that has an impact on quality. Policy colleagues not recognising the benefits of plain English was another theme.
A few people mentioned content formats as an issue, suggesting that either we don’t do a great job in explaining how existing formats should be used or we don’t have enough of them. (It could be both.)
Pick one problem and describe the solution
Education and evidence were strong themes here. People suggested workshops and guidance to help non-content colleagues to understand the GOV.UK approach.
There was a feeling that GDS needs to lead on this, as content teams in departments and agencies could only do so much.
Using analytics and case studies to demonstrate best practice were also mentioned.
Next steps
It was an enjoyable and interesting session, but where do we take it next?
I’d like to suggest a couple of themes we could pick up and develop on Basecamp.
User needs
We know that user need is - or should be - at the heart of what we do. This was shown by the answers to the first question.
But do we have widely-known, consistent and reliable methods for measuring whether any particular piece of 'department and policy' content meets a user need?
Could we create a toolkit or checklist for this? What would be in it?
Working with non-content colleagues
Getting non-content colleagues to understand why we focus on user needs and why we write in plain English is clearly very important.
Perhaps we could approach this in 2 ways:
- share examples of ‘breakthroughs’ we’ve had in our own departments and agencies - what did you do that helped non-content colleagues understand (and perhaps even support) the GOV.UK approach?
- suggest ways that GDS could help - if we were to organise workshops, who should come and what should we be telling them?
Look out for the Basecamp threads (coming soon) or leave your thoughts in the comments below.
4 comments
Comment by Rachel Caldwell posted on
Really like the idea of a user needs toolkit / checklist. Gathering user needs in a clear, consistent and productive way can only help push the use of them forward.
Comment by Joanne Schofield posted on
Maybe consider 'pair content writing' with non-content colleagues...
http://www.uxbooth.com/articles/write-better-content-by-working-in-pairs/
...encouraging them to think more about the content creation process, focus on the user-need (through practical examples), question meaning and what's essential, share their service expertise and increase understanding of the role and purpose of content on the site. Establishing a practical understanding of content would reduce resistance from services in the future.
Comment by Karen Turner posted on
Really enjoy reading the blog ... it's inspiring to see the value being put on customer wants and needs, but sorry to note that jargon seems to be creeping in ... for non-techies like me words like iterate, roadmap, basecamp, firebreak, toolkit are confusing. And that's just on this page!
To make it easier for all readers, how about using:
improve rather than iterate
plan rather than roadmap
??? to replace basecamp (no idea what that means in a digital context)
firebreak (ditto)
toolkit is also a bit of a cliche (maybe just stick with checklist?)
Comment by John Turnbull posted on
Hi Karen,
Thanks for your comment. You make a valid point - though, in my defence, some of the words you cite appear on the page but not in my post 😉
'improve rather than iterate' - I can agree with this; we iterate to bring about improvements, so 'improve' is what we usually mean.
'plan rather than roadmap' - there's a difference here: a roadmap shows where we want to get to, but not how we'll get there (like a plan does).
Basecamp - I should have included a link. This is an online project management tool that content people across government use to collaborate.
Firebreak - not a term widely used outside GDS, but this is a period spent by one or more teams working on whatever they decide is of most value, rather than everyday 'business as usual'.
Toolkit - yes, agree that 'checklist' is a usually better option.