By Padma Gillen, Scroll LLP Evidence-based content, designed around user needs, is transforming government content in the UK. By talking through the last major government project he led, Padma will explain how you can set up a content team, workflow, and governance structure that allows you to produce large amounts of high-quality content at pace (and let's you ditch all the bad stuff, even if other parts of the organisation think it's great). What you'll learn: --Different content team structures, and the pros and cons of each --Agile content production workflow with quality and pace designed in --The rituals you need to introduce to keep your content team learning and growing --The main challenges faced by content teams in large organisations, and how to overcome them --Governance structures that let you get things done, even if the organisation is challenged by user-centred content decisions

1. Transforming
Government Content
Padma Gillen, Scroll LLP

2. @ScrollUK
Hello!

3. @ScrollUK
Overview
1. A story
2. Organising content teams
3. Agile
1. Kanban and scrum
2. The sprint
4. Workflow

4. @ScrollUK@ScrollUK
A story about…1
The Smarter Guidance project

5. @ScrollUK
Smarter Guidance was about
increasing the quality
and reducing the quantity
of Defra guidance.

6. @ScrollUK
We started with 120,000 pages.
We’ve reduced that by 80%. So far.

7. @ScrollUK
We achieved this by designing content
around user needs.

8. @ScrollUK
As a…
I want to…
So I can…
User stories
UK passport holder
renew my passport
leave the country

9. @ScrollUK
We required acceptance criteria and
source content
before starting work on an item.

10. @ScrollUK
Workflow
For a quality product, every stage is important:
• Check we have what we need
• Draft
• 2i
• Fact check
• Fact check amends
• 2i
• Final approval
• Published

11. @ScrollUK
What does quality mean?
It’s quality content if it meets your needs as a user.
That means:
• you can find it
• you can understand it
• it’s factually accurate
• it’s complete
• it’s consistent with the rest of the site
• you can act on it

12. @ScrollUK
For a while, neither quality nor pace was
good enough.

13. @ScrollUK
So, we iterated.

14. @ScrollUK
We tweaked the 2i process, started crits
and set up fire teams.

15. @ScrollUK
We had a 2i meeting every week at first to
ensure consistency and as a forum for
questions.

16. @ScrollUK
We had a content design masterclass
every week to raise the standard of
everyone in the team.

17. @ScrollUK
My goal was that everyone on the team
would eventually be 2i.
Ideally, 2i should be peer review.

18. @ScrollUK
We had to figure out how to approach
highly technical content in plain English.

19. @ScrollUK
We found that 2i for specialist content is
pretty much the same as 2i for
mainstream.

20. @ScrollUK
Things we’re looking for in 2i
• Is it in proposition?
• Does it work with what’s already on the site (or
planned)?
• Does the structure make sense from a user
perspective?
• Does the analytics and other data back up the user
need, use of language and approach?
• Is it in plain English?
• Is it in style?
• Is the tone of voice right?
• Did the content designer take account of all fact
check comments - or give clear reasons why not?

21. @ScrollUK
2i is a training opportunity -
give clear, constructive
feedback that the content
designer can learn from.

22. @ScrollUK
If you pull all that together for
your team, you’ll have the skills
and process required to
produce quality content.
Consistently.

23. @ScrollUK
The quantity of work, resistance from
SMEs, and the firm deadline meant we
sometimes had to compromise on quality.
No one loved that.

24. @ScrollUK
We published MVP and started a content
debt spreadsheet so we can
go back and iterate.

25. @ScrollUK
We hit the target. Then we
organised things to make it
sustainable.

26. @ScrollUK@ScrollUK
Organising content teams2

27. @ScrollUK
Organise for maximum quality.
Design speed into the
process.

28. @ScrollUK
Options
1. Central team
2. Distributed team
3. Hub and spoke
4. Matrix

29. @ScrollUK
Central team
Pros
1. Easy to manage
2. Team communicates easily
3. Spot issues quickly
4. Strong team identity
5. Learns quickly
Cons
1. Doesn’t scale well
2. Can be seen as authoritarian
3. Can be remote from the user

30. @ScrollUK
Distributed team
Pros
1. Flexible
2. Closer to users
Cons
1. Communication
2. Creating a culture
3. Sharing learning across team
4. Spotting issues before they
become big problems

31. @ScrollUK
Hub and spoke
Pros
1. It scales
2. You can still:
- create a culture
- share learning
- spot issues
(as long as you have the right
structure and governance in
place)
Cons
1. Success depends on how
you organise it

32. @ScrollUK
Matrix
Pros
1. Designed for large scale
2. Allows communities of
practice
3. Breaks down silos and can
build content design
awareness across the
organisation
Cons
1. You can end up being
responsible for things you
have no control over
2. Can lead to confusion and
resentment

33. @ScrollUK
We went with hub and spoke.

34. @ScrollUK
For many situations though,
matrix has real potential.

35. @ScrollUK
For hub and spoke to work,
you need a clear hierarchy.

36. @ScrollUK

37. @ScrollUK
Organise larger teams into
several ‘fire teams’.

38. @ScrollUK@ScrollUK
Workflow3

39. @ScrollUK
From request to icebox
Content designers ask:
• is there a user need?
• how do you know it's a user need? (any data?)
• is it in proposition?
• is it already met on GOV.UK?
• is it already met elsewhere?
• are there clear acceptance criteria?
• is there clear source material to work from? (or an SME who can
explain?)
OK, we'll do something…

40. @ScrollUK
From backlog to done
Ideally this:
• Backlog
• Draft
• 2i
• Fact check
• Fact check amends
• 2i
• Published

41. @ScrollUK
From backlog to done
But could be more like this:
• Backlog
• Draft
• 2i
• Amends
• 2i
• Fact check
• Fact check amends
• Breathe!
• 2i
• Amends
• 2i
• 2nd factcheck
• 2nd factcheck amends
• 2i
• Amends
• 2i
• Published!

42. @ScrollUK@ScrollUK
Agile4

43. @ScrollUK
Source: GDS Service Design Manual

44. @ScrollUK
How to do it
1. Get a rough idea. (Discovery)
2. Build a minimal version and try it out. (Alpha)
3. Mess around with it lots based on user feedback and
behaviour. (Still alpha)
4. Get it roughly right based on what you’ve learned. (Beta)
5. Still listen to feedback and tweak as necessary (Still beta)
6. When you’re happy it’s all working well, consider it
‘finished’. (Live)
7. (But keep iterating.)

45. @ScrollUK
Source: http://agilemanifesto.org/

46. @ScrollUK
Agile works well for digital
because things change lots

47. @ScrollUK

48. @ScrollUK@ScrollUK
Kanban and Scrum3.1
Different ways to run agile projects

49. @ScrollUK
Kanban

50. @ScrollUK

51. @ScrollUK

52. @ScrollUK
Scrum

53. @ScrollUK
Scrum divides work into sprints.

54. @ScrollUK
The team agrees to deliver
a certain amount of work
each sprint.

55. @ScrollUK
Scrum rituals
Sprint planning
Daily stand-up
Show and tell
Retrospective

56. @ScrollUK
Content team
Each scrum team needs:
• product owner
• scrum master
• developers
This translates as:
• content lead
• content delivery manager
• content designers

57. @ScrollUK@ScrollUK
The sprint3.2

58. @ScrollUK
Sprint planning
1. Look at the top tickets (tasks) in the icebox (should be
highest priority).
2. Size the items (S, M, L, XL or 1,2,3,5,8).
3. See what’s not been completed from last sprint.
4. Look at the velocity of the team (how much you can
realistically get through).
5. Put enough stuff from the icebox into the backlog for a
sprint.
6. Assign them to content designers, or let content designers
pick items when ready.

59. @ScrollUK
Daily stand-up

60. @ScrollUK
Or ‘Slack-up’

61. @ScrollUK
Show and tell

62. @ScrollUK
(And do regular crits too.)

63. @ScrollUK
Retrospective

64. @ScrollUK
Big retrospective

65. @ScrollUK
Burndown chart

66. @ScrollUK
Thank you!

67. Scroll provides training in digital content skills
through the Digital Content Academy.
Find out more at:
www.digitalcontent.academy
www.scroll.co.uk
SCROLL
© Copyright 2016 Scroll LLP