Content design: the very first step
We hope by being clear about the answers we need upfront, it will help us and the people we work with
Our content designers got together for a team away day. Our mission? To draft a discussion guide to get the information we need but don’t always get when we start a task or project. Sometimes it’s information people don’t know we need. We hope by being clear about the answers we need upfront, it will help us and the people we work with.
We don’t often get the chance to get together in person. So we like to make the most of it when we do and usually treat ourselves to tacos. It’s become our content team tradition.
What’s a discussion guide, and why have you written one?
We’ve come up with a set of questions we can ask when we first start a project or content task. We won’t be asking every question in every scenario. And we know that someone might not have all the answers straight away. It’s more of a robust checklist to guide us. The aim is to avoid the awkward misunderstandings, frustration and design ping pong that can happen when content designers don’t have what we need.
A lot of us are probably guilty of embarking on a project without thinking about the time and effort it will take to achieve the end goal. The scope creeps, the deadlines shift, and unexpected obstacles keep popping up.
This might feel particularly familiar if you’ve ever been brought into a project and tasked with creating the content for the final output. Whether that’s a report, a blog post, or a service. What appears as a simple enough task: to write the words, actually involves a lot more work under the surface.
To write clearly and concisely, you’ve not only got to understand what you’re saying and its context, you also have to know what you’re not saying. What are the many different ways in which this could be interpreted, and how can we prevent that?
Once again for the back: content designers do more than the words
You may already be aware that not everyone knows what content design is. Maybe you’re not sure yourself. In our experience and from what we’ve seen in the never-ending conversations about it in the content community, not all colleagues and stakeholders know that content designers do a lot more than the words.
When our colleagues ‘get’ content design, work feels so much easier. No one’s having to ask for meeting invites. There’s less back and forth when designing. The service is likely simpler to use because content designers are all about making things make sense to the user. Whether that’s through the simple language we use or by putting content in the right place at the right time.
Though sometimes it becomes clear that people aren’t sure what we need to do our jobs. And while it’s ultimately our responsibility to ask, this can be tricky in an active project when you’re deep in a design problem and the next sprint ceremony is about to start.
How a content design discussion guide will help us (and the people we work with)
We pulled together a set of questions to help us get the information we need to start a project confidently. We’re asking people to tell us:
- About the project/piece of work and how we fit into it
- If this project/piece of work is billable
- About the deadline and any dependencies that might impact it
- About the purpose of this work
- What a successful outcome of this project would look like
- If the goal is to have a finished product, or something that can be iterated
- About the background of the work/project – what’s been done before?
- About any background reading – where are documents, what should we read?
- About any existing style guides or design systems
- Who we go to if we have questions
- Who we go to if there are blockers
Questions like “what is the deadline?” might seem obvious. But it’s important because people can forget to include the quiet, non-writing work content designers have to do in their timeframes. It makes sense if you’re used to only seeing the finished product, and if content designers like us aren’t broadcasting that kind of work. Things like researching, gathering and analysing existing material, and getting answers to questions take time.
We also wrote a list of follow up questions we might ask to understand the scope of the work, such as “What do you need us to do?”. Is it proofreading, editing, writing new content, or iterating existing content? We included helpful prompts for ourselves to consider. Are there any dependencies, and does the deadline seem sensible?
Giving us everything we need to know upfront allows us to plan our work and let you know if there’s a problem. We’ll know whether it’s really a case of “just” adding some words to a page. Spoiler: it’s probably not.
We have questions about questions
On the subject of dependencies, we also need the answer to ‘who do we go to if we have questions?’. We know. So meta, right?
Content designers need to understand the problem so the words we eventually write are grounded in the user’s needs, not something we think sounds cute. As we work through existing material or make progress with the design, we are guaranteed to have questions. The longer those questions go unanswered, the more of a blocker or risk it can become.
The person we need could be the person responsible for delivering the project, a product manager, a subject matter expert, a service designer, or a business analyst. Telling us who we should go to if we have questions, or helping us find the right person if you’re not sure, helps save us all a lot of time and heartache.
We’ve tried this approach and we’re going to ruthlessly iterate it
We used our discussion guide recently when we spoke with a client about a potential opportunity to improve their website content. The kinds of things we asked about included:
- their current content governance arrangements
- what is not already known about users
- the limitations of their CMS
The discussion guide helped to keep us focused on establishing the potential project’s scope and the resources that would be available to us.
That said, although it worked well on this occasion, we won’t rigidly stick to this approach or interrogate our colleagues instead of having a nice, human conversation about the work. We’ll be ruthlessly iterating our approach based on our, and our users’, experiences with it.
For example, we’ll think about what questions we really need and if we can cut the list down in the future. When is the right time to ask which questions? Where’s the best place to keep the information we’re given as a result of using the checklist?
Once we’ve had more opportunities to put this approach into practice we’ll be asking our colleagues for feedback so we can improve it. We’ll also give an update on how it’s going and what changes we’ve made.
In the meantime we’re keen to hear what other people have done. Do you face similar challenges? What’s your approach been?