Content design for services: what’s it like?
What do content designers on services do all day? Find out how working on a service is different from other content design work, and what skills and qualities it requires.
By Angela Moore
Angela is a content designer and strategist. She’s been a consultant for Scroll for over a decade, and has worked on government content since the earliest days of GOV.UK.
Content design for services: what’s it like?
I’m a content designer, and a few years ago I switched from writing guidance for government to working on services. (Now I do a bit of both.)
My first few weeks on a service were a blur of post-its, agile ‘ceremonies’, Jira tickets and developer-speak. As I settled in, I started to understand the differences between these two roles, and the different skills you need to bring to them.
Working with different people
Working on GOV.UK, I spent most of my time with policy teams and lawyers. There were some other stakeholders, too – external communications, and ministers if they were involved in signing off the work.
Now, I work on multi-disciplinary teams. These teams usually include a business analyst, a delivery manager, developers, QA testers, a product owner, a user researcher and an interaction designer.
As a content designer, you’ll work most closely with the user researcher and the interaction designer. But you should expect to work very closely with every single role on your team. So try to learn what everyone does, and how your work impacts on each other.
More about roles in a service team (opens new tab).
The meetings (all the meetings)
(In Agile, these are called ‘ceremonies’, but we’re content designers here, so - no.)
Days on a service team are quite structured and there are lots of meetings. Every day starts with a short meeting called a ‘stand-up’, where you quickly talk through the work you’re currently doing.
Work tends to run in 2-weekly sprints, and usually in those 2 weeks there’s a ‘retro’ (where the team thinks through what worked well and what didn’t in the last sprint), and a ‘sprint review’ (where the team shows what work was done in the last sprint). There’s also planning for the next sprint.
Then - because communication between the different roles on a team is so critical - there tends to be a lot of time spent with each other during the day.
I learned to block out focus time when I needed to get work done.
If you value doing work in a more unstructured way, where you can largely pick and choose when to be present, service work is not for you.
Read about Agile meetings (opens new tab).
Get to grips with Jira and know your board
All the government service teams I’ve worked on use Jira to record their work. The way that work is managed varies. (It’s honestly best left to the agile gurus to worry about exactly what flavour of agile or Kanban or scrum is happening.)
However it works, each service team has a Jira ‘board’ that shows in-progress and up-coming work. It’s really important that you understand, use and get involved in this board. It’s how you can see what work is being done, show what work you’re doing, know when to intervene (“Did a content designer look at that?”) and understand what’s going on for your team.
Ideally, you only do the work that’s on the board.
Teamwork, teamwork, teamwork
In service design, the focus is on the team. Nothing you do is in isolation. Your work will depend on the technical design of the service, the user interface styles, the backlog of work to be done, the priority of each piece of work and more.
The model is collaboration and consensus. You need to be a team player, to work well with people, to listen, to lead when appropriate. You need to be willing to make decisions. This is not trivial ‘teamwork = dreamwork’ stuff. Getting good work done is actually contingent on your teamworking skills.
This is not for everyone – and if you prefer to work in isolation, it might not be for you. But when it works well, and you feel like you’re building something together as a team, it’s incredibly rewarding.
Fewer words, more design
I’ve written government guidance on complicated subjects, like how the EU common agricultural policy farm subsidies work in England. That takes a lot of words.
On a service, the basic premise is to write as few words as possible to enable a user to complete a task. Sometimes, that’s 5 words on a screen. Those words really count, though, and I agonise over them.
I sometimes miss writing lots of words.
What makes up for this is that I do more design work. I don’t mean putting UI elements on a page. I mean designing solutions based on user needs. It’s about really understanding the problem, in the context of the service as a whole, and finding the best way to solve it. It’s lovely work – strategic and analytic and creative.
Being user-centred is easier in services
Having worked on both GOV.UK and services, I can tell you that it’s easier to be a content designer on a service. The ecosystem in service design is better set up to be user-centred. It’s absolutely not perfect, but it’s a lot better.
I have some thoughts on why this might be – for example, services have to meet the GDS service standard – but that’s a different blog post.
Basically, services do more user research, testing and iteration. They (should) have more data to work from. This means you can make more evidence-based design decisions, which makes our job as a content designer much easier. (And it’s brilliant. And the way things should be.)
It’s more technical
The most technical thing I did writing guidance for GOV.UK was load a manual into Whitehall publisher.
Services have a lot more ‘tech-y’ stuff going on. Common tools are Figma, for early design work; the GDS prototyping kit, for testing designs with users; and of course, Jira.
Most services do not have a content management system. Working on one big, sprawling live service, we had to learn to download and search the properties files (bits of code) to check what language we used in different parts of the service.
Try to learn what the developers are talking about - what’s a BAT test and why is this stressing everyone out? Devs will explain constraints and peculiarities in the code that will impact your work. The best QAs are like brilliant secret 2i reviewers – calling out inconsistencies and errors in the work before it goes live.
Here’s a secret
You do need to engage with all this tech-y stuff. But you do not need to be a total pro.
A confession: I can’t use the GDS prototyping kit. I loathe Github - all that appalling ‘commit to master’-style language. I think on my current project I’m going to have to learn, but I’m avoiding it as far as I can.
That’s just not the kind of content designer I am. I am much more about humans, and service design, and the law, and language, and accessibility.
And this is fine. I’m still effective and good at my job.
Be bold
Content design is hard everywhere. You’ll still get told to “just add words”. You’ll still catch the devs or the product manager thinking it’s OK if they “just quickly write something”.
Also, because services are so complicated, most people will look at a service and see only the words. So we can be the focus of lots of questions and analysis.
So, as always, you need to know your stuff, stand your ground and be able to explain what you have done in order to meet a user need.
And be bold! Content design is a fundamental design skill without which no service would work - and you own that skill.
What HSE said about our work
Read about the work Scroll did with HSE in our HSE case study.