Content design for services: what’s it like?
I’m a content designer, and I recently switched from writing government guidance to working on services.
My first few weeks were a blur of post-its, Kanban walls, 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 do them.
If you’re considering switching to working on services, this might be useful.
Working with different people
In my previous job, I spent most of my time working 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 a multi-disciplinary team. The team includes business analysts, Java developers, front-end developers, QA testers, a product owner, a user researcher and an interaction designer.
You might think I’d work most closely with the user researcher and the interface designer. That’s only true some of the time – I’ve worked equally closely with everyone else on the team.
So I’ve had to very quickly learn what everyone does, and how our work impacts on each other.
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 organisation’s priorities 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. 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 really 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.
Now, the basic premise I work from is to write fewer words. 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 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 service design
The ecosystem in service design is more set up to be user-centred. I’ve never had to explain why user needs are important or what a content designer does. (In my last job, I had explanations of both of these saved in Google docs because I had to email them so often.)
I have some thoughts on why this might be – for example, services have to meet the GDS service standard – but that’s probably a different blog post.
So, we do more user research, testing and iteration. It makes your 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.
In my new job, we don’t even have a CMS. I’ve had to learn to download and search properties files to check what language we use in the service. We use Jira as the ticketing system for our work, so I’ve learned to use that. I know how to upload the latest code to a preview environment, how toggles work and what a BAT test is.
I think you need to engage with all this stuff.
In particular, you need to learn to use the GDS prototyping kit, Sketch and Github, so you can collaborate on design work and keep it up-to-date. I loathe Github – all that terrible ‘commit to master’-style language – but I am soldiering on.
You also need to engage with the developers and QAs. Developers can explain constraints and peculiarities in the code that might impact your work. QAs are like brilliant secret proofreaders – calling out inconsistencies and errors in the work before it goes live.
Harder but better crits
Design crits are always an exercise in ego-suppression and listening, but that goes double for content designers on a service. That’s because most people will look at a service and see only the words. We tend to be the focus of lots of questions and analysis.
So, as ever, you need to know your stuff, and be able to explain what you have done in order to meet a user need. And of course there is no better way to improve your work than a crit, so crit early and often!
Top tips if you’re thinking about making the move
- Learn to prototype – with Sketch, the GDS prototyping kit or whatever tools suit you best.
- Engage with the tech stuff – be open to learning useful tech skills.
- QA testers are your friends – they know all the tricks for making the service work.
- Make sure you understand the wall – UX wall, Kanban wall, whatever your team uses – you need to know exactly how it works.
- Be bold – writing is a fundamental design skill without which no service would work – and you own that skill!