Ways of working
Content design is not copy writing. It may not even be about writing a lot of words. It's a way of working that starts with the problem you need to resolve for users.
Work with others to understand the problem you need to address on behalf of the user. Other people in your team may already be doing that.
A content person comes in many guises and you may not be a part of the multidisciplinary product team. While you're gathering evidence about the user, try to build relationships across that product team.
As a priority make sure you champion the user's needs and plain English from a content perspective. Any team should be receptive as they will be working to improve the current experience the user has.
If it's not clear how you will work together, approach the product manager. Ask questions to know what the team members do and what they need to find out. You will find you have much in common.
A content designer should contribute from the start of a project through its life cycle. This includes the project phases of planning, discovery, designing, iterating and improving.
Sprint cadence or workflow
In your team there may already be a sprint cadence that includes content design. Become familiar with agile practices such as the Kanban wall, daily stand ups and sprint planning. Understand the user journey and their needs. Get involved in usability testing sessions and iteration.
Otherwise, the content workflow may be separate from the product team. At the very least, make sure the team has real content to use, when they're building a prototype. Also ensure your team uses real content when it does usability testing. Attend playbacks from this testing, to know how your content needs to change.
As well as designing the user experience with product team members, a content designer works to know the facts with subject matter experts.
Your aim from the outset is to simplify everything for the user. Your main task will be to set up a clear path for them to achieve their goal.
Start with a user story. You should create one for each piece of content, from user research. If you're part of a multidisciplinary product team, everyone is likely to be using them as you design and build.
A user story will help you to pinpoint the user need from the outset. It puts the user front-of-mind and gives you a focus when designing and writing the content.
Next, create a structure for your page, based on the user story. Write up meaningful H2 headers to serve as signposts to help the user do what they need to do.
Round this out with acceptance criteria, so you can confirm whether you've achieved what you set out to do. Acceptance criteria is an invaluable goal when designing content.
Use your criteria when asking stakeholders to approve content. They are also a useful check when doing usability testing with your users.
Working with subject matter experts
Share your way of working with your subject matter experts – in person if possible. Pre-empt each piece of content with:
- a user story
- high-level page structure
- acceptance criteria.
They're a great way of introducing your approach to a subject matter expert, which may be completely foreign to them. It will show them how you're focusing on the user, and what you're trying to solve. Ask them for feedback. Find out if there's anything missing and if you're on the right track.
This way you're not asking them to read a lot of text from the outset. You're introducing them to the topic - their topic, and how you're both collaborating on behalf of the user.
When the time comes for them to fact check content, they're already familiar with the aim of each piece of content.
Use pair writing to create content side-by-side with a subject matter expert, for example a technical writer, lawyer or policy author.
See Digital Transformation Agency's method for Pair writing.