You draft what you think people need to know but, once the stakeholder has added every possible detail, your communiqué covers a dozen topics and addresses nobody within your intended audience. The review cycle, which should be about honing the message, becomes a vicious circle until you no longer recognise the purpose of your draft. If only there was a standard approach to agreeing what must be covered in a news article or a reference page.
While you should certainly discuss such matters with your knowledge manager, take a look at these content design techniques and see which you can bring to your organisation’s approach to crafting content. As a comms pro, or intranet publisher, these tools will complement your existing skills.
Content design is using design techniques to plan and create content
Content design is an evidence-based approach to creating content to give the audience what they need in a way they expect and can use. It’s about discovering and defining needs and meeting those needs through the presentation of content.
As I said in my introduction to content design, it’s a movement, a grouping of practices, and becoming a discipline, thanks to Sarah Richards (and team) who developed the approach while working at the Government Digital Service.
It’s often about having an open, fluid discussion in a big room with all the right people.
But such a workshop is a fairly heavy commitment; I know you won’t do it for every reference page or news story, but it could be a great start if you’re revamping your knowledge management site or a specific section of your intranet.
A discovery day is common enough in website work and big projects; it brings everyone together, like a project kick off day, but for content. It’s for your writers, publishers, subject-matter experts, stakeholders and teammates – but also those senior reviewers who might block your content in the future by adding too many new ideas!
A discovery day gets everyone aligned around the principles, objectives, and processes.
Suggested flow of tool use
Here’s a visual of the tools / techniques in the kind of order they might be most useful. As it says, you can review the work in a ‘crit’ whenever it seems sensible to. You can get a bigger version in my slides at the end of this article.
When briefed about a news-worthy matter, or when revamping a particular section of the intranet, you and the stakeholders / subject-matter experts will likely have assumptions about what must be mentioned and how. Content design directs us to start with data, with information, with research results.
Your stakeholder might start with “I want them to know…” and then you reply with “But I think people will need…” – and these are all assumptions and that’s fine, you’re an expert in your role, but all assumptions need testing and some need smashing.
It’s less about drafting a page, and more about planning the content. It all starts with understanding needs – finding out what’s missing and what people need to achieve their goals.
So, how do you find out what’s missing, what’s misunderstood, and what’s truly needed? It’s not about surveying 20% of your colleagues for every reference page. This is about doing the minimum research to be able to start with evidence rather than only assumptions.
It’s about conversations with:
- those with the need / people affected
- the subject-matter experts
Think about what already exists internally (survey results, feedback, failure-to-find reports, analytics), and the best practice resources out there [see last section].
See what UX (user experience) research has been done already. Perhaps you’ve got personas, perhaps you’ve got a list of ‘top tasks’ for the intranet, or a content gap analysis done after a migration project.
Talk with the subject-matter experts – not just policy setters and directors, but the administrators, the process owners, and the support workers / customer service people, who really know what works and what doesn’t. For example, HR will likely receive the exact same queries from dozens of people at key points in the year. There’s probably an unloved hard-to-read FAQ (frequently asked questions) document that gets sent around.
Attend townhalls / all-hands calls and see what questions come up, and the reaction to answers.
Run a discovery day to bring people together and focus on the content part of the intranet.
Do not start drafting! We’re still in planning mode. Upfront planning will reduce the pain of reviews and improve the relevancy and usefulness of the end product.
First, write the user story. Those of you into user experience may recognise the format.
A user story is a three-part sentence that expresses what someone needs in order to achieve their goal.
As a [colleague in a role / dept]
I need to [know or do something]
so I can [achieve a goal].
User stories, and you will need several because you do not have ‘one audience’, help you keep the readers’ backgrounds and goals in mind, helping you write useful content in the appropriate language.
Second, write the job story. A job story is for a specific task for a specific audience, so just as you may need several user stories, you may need several job stories.
When [specific situation]
I need to [know or do something]
so I can [achieve a goal].
You will need to come back to your job story frequently as you plan and draft your content.
The job story needs to be so specific and well-written that your stakeholders go ”oh yeah, that’s right, that’s exactly what we need to deal with”.
I shouldn’t say this, but considering the busy internal communicators and intranet publishers I know, I would not blame you if you focused on brilliant job stories, over user stories. I say this because content design means to be inclusive and person-focused because it is applied to external websites so much. Internal communicators benefit from being able to get to know their internal audiences intimately.
So this isn’t a codified content design technique but rather something I’ve developed over the years with my stakeholders. I’m sure you do something similar.
Rely on your research results and your job stories and keep your user stories in mind.
- Lay out bullet points to cover everything
- Rework the list to order it from ‘must know’ to ‘nice to know’ / context
- Consider breaking the list up with sub-headings to chunk the list
- Sure, draft a title but don’t set your heart on it.
If you get 30 bullet points, something’s gone wrong; that isn’t a page anyone’s going to quickly reference. But you decide if five bullets or a dozen is appropriate.
When you put the sub-headings in, see if that makes you re-order your points. See what naturally fits.
Sub-headings are really important even on a short article. They help the eye jump around the page, and of course people only read what they need. So they want to go straight to the best bits for them.
Circulate the job story and skeleton around your project teammates, subject-matter experts, and stakeholders. Explain that the bullet-points demonstrate what the article will express. Explain that the bullet points should meet the needs expressed in the job story. Ask for input and approval to proceed.
I think it’s great to have a job story to define the problem and a skeleton to demonstrate the substance of your proposed article. It sets expectations and they’re easy to review and improve, because they only deal with the substance, not the style.
Working with subject-matter experts and stakeholders
Separate the substance from the style. I suggest reviewers should focus on the substance.
- Respect subject-matter experts for their subject-matter expertise.
- Respect content designers for their understanding of the audiences.
- Respect writers for their understanding of grammars, voice, and tone.
Your reviewer has approved the skeleton bullet points. They know the substance. They may now have additional points to make and maybe that’s OK. But the style isn’t their remit.
You absolutely do want help with vocabulary, but you do not want help with the tone or with punctuation, assuming you are a trusted and experienced writer. Unless you’re ghost writing or creating something that actually represents a person or department, you’re in control of style and tone. Obviously, you must be humble enough to listen to others’ input, but your concern is communicating to the defined audiences (user stories) in a way that they will appreciate. Your comms experience is needed. You’ll follow your communications house style guide. This is about readability, comprehension, and impact.
Any review can be emotional. Paragraphs we’ve worked over multiple times can be criticised again, or simply cut. Content designers don’t do reviews! They do crits!
It’s content critique, not criticism.
Crits have rules:
- Respect that everyone did their best work considering the time and resources allotted.
- Focus on the content, and only the content in front of you; not the process, not the creator.
- Offer constructive suggestions.
- Decisions don’t have to be defended.
- Suggestions don’t have to be taken on board.
Doesn’t that look empowering?
Crits are about seeing if the content satisfies the job stories – if the content reaches the agreed acceptance criteria. Sure, suggestions can be taken on board, but they don’t have to be!
If someone says “I think we need a paragraph about the pension pot here” you can listen and note, but you don’t have to add it unless it fits the job story. You might be clever and add a hyperlink to pensions, but you don’t have to cram more content into your article for no reason.
Crits may seem serious, but they’re great for building a team, getting people involved, and showing you care. Maybe run a ‘crit’ on a small set of content first, to show everyone how things go.
Slides from my IntraTeam 2020 presentation
I presented the following slides at the IntraTeam European Digital Employee Experience conference on the 4th of March. I’ve previously presented a similar webinar, and you can listen and watch that video.