Hello everyone and thanks for joining us for today's webinar
"Content Design Techniques for
Your Intranet."
My name is Michelle, I'm the marketing specialist
here at Igloo.
I'm joined today by Wedge Black was a digital
workplace consultant at ClearBox Consulting.
I'll let him introduce himself in just a little bit,
but before I do, I did want to go over
a couple of housekeeping items.
I wanted to start by apologizing in advance.
Our webinar provider is
having some bandwidth issues with
everything that's going on in the world. And so
if there is any tech issues, we apologize in advanced.
We will be sending out a copy of the recording regardless,
So look out for that.
This presentation is being recorded,
and therefore we will make it available afterwards.
All participants have been placed on mute,
but don't let that stop you from answering
or asking any question. If
you'd like to ask a question, you can actually just submit
that through the chat feature that appears
on the left corner of your screen.
And with that let's dive in. Take it away, Wedge.
Thanks, Michele. It's great to be invited by Igloo to
talk about content. And thanks
to you for joining us today.
My name's Wedge — it really is —
and as a previous Intranet manager
for national and regional companies,
I've sat with communications teams
and now — as mentioned I'm a consultant —
I retain my interest, incomes,
and content.
ClearBox does a lot of digital workplace strategy and
we help organizations consider the best tools
and channels for their needs.
So we're going to look at content design
today. Here, the topics I'm going
to cover: content design itself,
needs, meeting those needs,
some big old skeletons,
and then actually writing. And
then some crits. And
I'm only going to introduce you to
these design techniques, and the topics
really revolve around user needs.
If your role includes internal communications,
knowledge management, or publishing, then
you'll likely already care about people's needs.
The content design approach compliments your
existing skills.
It adds an awareness of context, user
interface, and user experience.
We can only introduce a constant design approach
and I hope that you'll do your own research
and upscaling.
So I consider content design to be a discipline,
a set of techniques.
It's about evidence.
It's an evidence approach. It's an
evidence-based approach to discovering
and defining needs, on meeting
those needs through the presentation of content.
It's about content as the interface.
It's about upfront planning and
writing stuff to meet a need.
It may be about readability and
layout, but it's not just about
that. While layout is important,
content design is not merely about placing text
on a page.
So where does it come from? Well between
2010 and 2014
Sarah Richards and her team were working
within the government digital service, in
the U.K.,
and brought together techniques — no doubt
from user experience design and
practices — to create content design
technique.
Now, Government U.K. websites,
are very well known for clear, concise,
readable reference pages.
And Sarah literally wrote the book on content
design. So there it is, a unique
design itself, and you should definitely check
that out.
contentdesigned.london/book/
I get it. You hate the word content.
I know, I know.
But with the potential for rich digital
experiences within our workplaces,
it's a fine reminder that we could be talking
about animations, Videos,
graphics, and audio.
Word has been accepted across society.
Those youngsters planning the next Instagram story
talk about content creation.
The word is endemic and accepted.
But sure, if you mean 'text'
say 'text', no problem.
You're already an adapt communicator.
Content design brings additional techniques
for you to use and helps you be even
more user-centered, person-focused
than in your past engagement comms.
I'm going to introduce you to a set of techniques today,
and it may be that you can pick the most
useful on bring them to your communication
processes and teammates.
So today is a little bit about business change and
process change.
And making your approach to comms and publishing
bang, up-to-date.
Because you want to avoid this.
You know, have a look at this and see which
floor this elevator should take you to.
I mean,
someone wrote this. Someone laid it
out. Someone approved this.
And someone executed this.
And this is not user focused content.
If you wanna have a look at the original tweet,
pop to that large URL
https://d.pr/ZxiEgC
And again these slides will be made available afterwards.
So how do we go about discovering needs?
We've got to uncover them.
It all starts with understanding needs. Finding
out what's missing and what people
really need.
Your stakeholder might say,
"I want them to know",
and then you reply with, "But I think
people will need."
And then as a team you'll say, "Well,
obviously everyone's number one priority
will be..."
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.
So what research methods can you use?
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
need,
the subject matter experts, and
your business stakeholders, of course.
So how would you go about this? Well here's five ideas...
Desk research.
Have a look around for what already exists
internally
and what other organizations do. Consider
best practice resources. So
check out Igloo. Check out ClearBox.
Check out contentdesigned.london.
Have a look at what user research...
User experience research and usability
research has already been done.
I bet you did a content map analysis
when you lasted your big
Intranet migration program.
I bet you've got a list of
content that exists on possibly
you can then judge the gaps
that are in that content.
Of course, you should talk to subject matter experts,
but not just the policy setters.
You need to talk to the administrators,
and the process owners,
and the support workers, and the customer service
people — because they know what isn't working.
They know what's missing. And they know
what your customers crying out for.
Do your own user research.
This might be about shadowing someone
as they attempt to complete a task.
Do they have all the information we need to guide
them in task completion?
And here's an idea.
Make sure you attend town halls.
You know, those all-hand calls or
all-hand meetings that you have.
Have a look for how a crowd
responds to messages coming
off the stage, off on the leader.
And record the questions that
get asked.
And of course, you will leave specific
discussions with users
yourself to discover just what's happening and
what's missing.
Because all of this is about discovering what people
must know
in order to get on with their work
versus the nice-to-know stuff.
So, yes, when it comes to laying out your comms
we'll rely on the good old journalistic tool
off the inverted pyramid — which you can see
here. But I'm going to give you
some new tools today to help you define
the must know information.
Specifically, user stories
and job stories.
The first thing that you might do if
you got a big content project
looming,
is have a Discovery Day.
It's common enough in website work and
for big content projects.
It's about bringing together everyone who's
involved with a project but focusing
on content only.
It's for your writers, publishers, subject
matter experts, its for your stakeholders
and teammates.
But it's also for those senior reviewers
who might block content in the future
by adding too many new ideas.
A Discovery Day gets everyone aligned
around the principles and objectives and
processes.
But, you know, it's a big 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 approach
or a specific section of your Intranet.
As I said,
research isn't about exhaustive
quantitative studies.
This is about doing enough research
so you're certain you're going to create the right
content
for the right people.
You've done good research when you know the problem
and are ready to write those user stories
and job stories I mentioned.
So here on the slide on the left is a
few good ideas of what
results looked like. And, you know, we're
gonna share these slides after the Webinar.
Here's a slide I'll refer to
frequently in this webinar, are just to keep
us on track.
Now we've just mentioned Discovery Days,
and now we're going to look at user
stories.
Because user stories and job stories will help us
define the needs; because we want
to understand the problem before
we start building solutions.
So a user story. Here's the format.
As a colleague,
I need to
do something or know something so
I can achieve my goal.
So it's not about starting drafting.
That is not what we do when we want to start
creating user focused content.
We have to start with the user story.
Those of you who are into user experience design
may recognize this format.
It's a three part sentence
that expresses what someone needs from us,
you know, to achieve their goal.
User stories — plural — because
you'll need lots of them because you do not have one
audience, even internally within
your company. You have multiple audiences.
They help you keep
the readers background and goals
in mind, which helps you write useful
content in the appropriate language.
Let's have a look at a heavy example.
So as a systems administrator,
I need to know if and how
I can access our network when
outside of our offices
so that I can work from home
without impacting the service's I
provide.
So, job stories are very similar format.
A job story
is for a specific task for
specific audience, so you will
need several job stories.
So, the format again is time-
based. This time it's 'when' a specific
situation occurs
I need to know or do something
so that I can achieve my goal.
Let's have a look at a heavy example.
When a novel issue is logged
that our team has no experience of,
I need to find who to contact
for expert guidance
so that I can engage the right people
to solve the problem and close
the issue.
So the idea is,
as we do our research and define
the problem we wish to address with our content,
its user stories that guide us and
its job stories that specifically guide
our writing.
I think it's a good idea to
share your job stories and user stories
with a colleague or stakeholder to
ensure that they've written them so well
that your colleague os stakeholder
goes, "Yes, that's it. That's perfect. That's exactly
what we need to be writing."
And so, as you share your user stories
and job stories,
consider the acceptance criteria.
You don't want to be writing
10,000 words, so you want your
stakeholder who reviews it to understand

how to ensure your job story and user story
are good. And that's about sharing
your acceptance criteria.
So consider the format of acceptance
criteria
as you're getting feedback on your job stories.

And, I know this seems like a lot
of work, but it's just about planning
what you're going to write
instead of writing a first draft.
This discovery and defining reduces
review pain in the future by ensuring
writers and reviewers have a shared understanding.
Writers simply right to meet the need,
and reviewers don't derail the process
with 'one more thing' novel
ideas.
We need those new ideas at the beginning of the process,
not at the end of the process.
So we've just touched on user stories,
job stories, and accepting those
stories,
and we're now going to look at Wedge's skeleton.
So I know you want the meat. We all
are desperate to start writing, but actually we need to start
with solid foundations.
So this isn't a codified,
content designed technique, but rather
it's something I developed over the years with my stakeholders,
and I'm sure you do something similar
already.
Here's my process.
I lay out the bullet points in a Word document
or in Notes,
and I just cover everything that my research
and user stories and journey and
job story mentions. I get
it all out.
And then I just go through a process of reworking
that list
to ensure that it flows right.
So let's have a look at a car parking
story. Let's have a look at my first past
skeleton.
So, I've got my job story there to
remind me why I'm writing.
And this...
this dozen bullet points
covered everything I think
my news article reference article needs
to cover
to express that we've got car parking
changes.
Now, if you get 30 bullet points
something's gone wrong.
That isn't the page anyone's going to be able
to quickly reference.
But you decided five bullet points
or a dozen bullet points is appropriate.
So that's my first pass.
Let me show you my second pass, which
I think makes a little bit more sense as
you read it top to bottom.
You can see in green with the dots
where I've just moved things around because
once I got my brainstorm down
on paper, I then want to assess it
and move things around to get a good skeleton.
So it flows from the must-knows at the top
down to the nice-to-knows and contacts
and actions
at the bottom.
Your ordering might be different to mine, but
the point is we're following a process
and relying on our expertise.

Now, the third stage is to adding
the subheadings.
Subheadings are really important, even
for short articles.
They help the eye jump around
the page — and of course, people only ever
read what they need,
and so they help a person spot what they
really are interested in.
Here you can see I've made additional changes.
I've got my job story and user story here
to remind me why I'm doing this.
But once I put my subheading in, I just
had different feelings — a different
sense of what was important. So
as I put my subheadings in, I changed my
bullet points yet again.
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.
So share the job story and
your skeleton with your reviewer
and your stakeholders,
and explain that the bullet points are supposed
to meet
needs that have expressed in the job story.
And at this point,
you know, your stakeholders or your subject matter
experts input is invaluable.
This is when we should be amending the substance
and getting those bullet points right.
So we just touched on 'skeleton' and 'reviewing the skeleton',
and now we're going to get into actually writing.
But as I say, it is the last thing you want
to do, you know, never just sit down and start
your first draft.
Always go through a process
to
make sure that you're writing to the need.
I've just got a few slides here because
I'm not here to tell you how to write good comms.
We must write in a vocabulary of the
audience and in the tone suitable for the
topic. I'm sure you already know that,
but it's a principle off the content design
approach.
Your style stays the same,
but your language adapts to the audience,
and your tone adapts to the topic.
If we do all this,
our reviews won't surprise us with any
weird demands and ideas about
word play.
But of course, we should be open to suggestions around
terminology,
and we need to keep in mind
the audience stories, the user stories
and the job stories.
So I'm going to assume
that you've got a house style-
guide. So you already know the sort
of language that you need to use.
And we need to adapt our tone
to the topic.
Because the job stories and skeleton is so clear,
everyone knows what's coming. So there are no
surprises for your viewers. And that
means that when they get your first draft
article,
there's no surprises.
And so that means that the review cycle
is easier and more pleasant, and we
remain
on target to get useful
content written.
So that's where we've got to. We've
actually got our first draft now, after
going through a bit of a content design
process.
And the last thing is to do
a full review of all the content
we produced.
And content designers don't call them reviews.
I know we probably will continue
to use the word 'review' within
the communication teams, but content
designers use word 'crit'.
This is short for 'critique',
not criticism.
I think you reviewer, or the person performing a
review,
should be...
should have the user story, the job story and
the skeleton in front of them. And that way they
know what your draft
is supposed to be dealing with.
They know the substance off the article.
They might have some additional points to make,
but the point is we've got that strong
skeleton to build the flesh
of our content around.
I think that we can respect
the different people involved with our review
or with our crew...
crit.
We need to respect our subject matter experts
for their subject matter expertise.
They may not be involved
with the style and the layout of the content,
but we want to respect what they know about
terminology and how things work.
We want to respect content designers for their understanding
of the audiences because they've done
the research and they've designed user
story and the job story.
And we want to respect our writers
for their understanding of grammar and tone, because
it's our comms people who will be adhering
to the house style guide. So
we don't have to argue about the substance. We
don't have to argue about the tone
or the wordage, because we've
got all of this guidance and we followed the process.
The great thing about
crits is that you don't have
to take all of the advice
on board. Sometimes we have
to learn through comments and commentary,
but we don't always have to take action, because
we would only take action and change our
content
if we had missed something or something
was unclear in regard to
the user story.
Here's a top tip. Here's something I've learned:
I used to insist to reviewers
and content owners that text was the text,
and I would make them review drafts in Word.
This was especially useful in Office 365
or SharePoint
because everyone can access the same
documents and comment on the
same document, with no version control
mess caused by emailing attachments
around.
So that's why I loved it. I loved Word.
But, people used to say to me, "Oh,
now that it's published it just reads differently."
And they were sad,
and they were right.
I have now learned that context
really matters.
The article reads and feels different
in Word
to how
it feels and reads once it's published
in context.
I used to ignore this as just people's feelings, but
now I know that feelings really matter.
We don't absorb information as
a mere intellectual pursuit. We are
driven to learn what's relevant to us by
our emotional needs.
My best work now is done when I can
publish drafts in 'situ' for
a final review.
If your Intranet has a draft facility,
fantastic.
But if not, maybe it's okay
to do some final tweaking soon after
publishing.
Maybe that's okay.
So comparing crits to
reviews.
Here are the Crit
rules,
which, you know, we may not have had with our
informal reviews.
The idea is that we need to respect everyone
for their input and their
block of expertise as I mentioned,
the subject matter experts, the content designer
and the writers.
We need to focus on the content and only
the content. We're not gonna go back over
the process. And we're not going to discuss
the creator's preferences.
We're only ever going to be constructive,
and
we don't have to defend our
past decisions. So if someone had a
conflict about the comm,
if someone has a comment about the content,
we listen to that comment
in context to content,
not in context to my personal preferences
or the process. We don't have to defend
our decision, we only need to consider
the content that's in front of us
And interestingly, we don't have to take
on board all the
suggestions.
Because all of the critique
should be against the user story.
So, you know, someone might suggest, "Oh,
I think we need a paragraph here about
the pension pots."
And you can listen and note that comment, but you don't
have to add another paragraph to
your content unless the job story
demands it.
But I would suggest that you would be clever and
had a high pulling to the pensions...
the pension details on the Intranet because we
do like hyperlinks and we do like
related content.
But you don't have to cram more content
into your article for no reason unless
the job story requires it.
Crits can seem quite serious, but
they're great for building a team,
they're great for getting people involved and showing
that you care.
Maybe run a crit on a small
set of content first to show everyone how
things run.
Reviewers,
whether subject matter experts or stakeholders,
need to understand that they are reviewing the content
against the acceptance criteria. They
are not here to give you new ideas.
As I say, I like new ideas at the skeleton
fase, I don't like new ideas
when you're on draft two of your content.
The acceptance criteria around
meeting the needs expressed in the job stories
for the audience is described in the
user stories.
You may want to provide the job stories and user stories
along with the content
and a note about acceptance criteria.
Assuming you stick to the house style guide and
you have the tone right off the topic,
you may want to steer the reviewers
away from expressing their personal preferences
about vocabulary and punctuation
and grammar.
But be wide open to subject matter
experts about terminology and things
you miss.
So final thoughts... Just got a few
minutes I think before we go
into questions.
Don't be boring. You're a communicator.
You're a writer. You're a publisher. You already know
that you need to capture people's attention.
Content design is about
meeting a defined need.
And some content designers
might optimize content to simplify
the text so much that it loses flavor.
But content design itself does not dictate the
communications must be dull,
only clear.
It's that clarity that we're seeking.
Remember, everyone loves creating
content but few people love
maintaining it.
Whatever you create on the Intranet has a life-
cycle, and so I suggest you should plan for it.
An, I would say do your best to create
less content.
Always create
only for the need.
If you're serious about content operations,
rather than timely communications,
you'll consider life-cycle carefully. If
you've done your job story, you'll avoid
publishing unintelligible, urgent
announcements.
Now, this time...
At this time in the world, our urgent
announcements still need to be
clear, concise, and with
context.
A note about content debt.
Content debt is a time and resources
needed to deal in the future
with the content you created today.
You might believe your content is very valuable
today,
but it's likely that it has a half-life.
So it will either need deleting or improving
in the future.
Everything we create has a cost today,
but it also has a cost tomorrow.
Now content design
is very hot at the moment and content
designers are all over Web design.
Because that's where the money is.
With these content design techniques, you
can be the internal content hero.
I ask you to join me as an Intranet
content designer.
As I say, we communicated.
We have always striving to match the
message to the audience to
the channel.
Content design has four touchstones.
Content has to be in the audiences'
vocabulary,
in the best format for the audience,
it has to provide what the audience needs from
us, and it should be designed with data
or research results.
As I say, I can only introduce these techniques
to you today, and I'm hoping that you'll do your
own research.
Here are the books that have inspired and
taught me what I know about
content design.
And, there's the Content Design book at the bottom,
right by Sarah Riches, which I highly recommend.
And it's uniquely designed, too, of course.
All of this has to be in context with
your organizational strategies — strategies,
plural.
Digital workplace, I.T.
Internal Comms, Knowledge Management,
and your Intranet strategy.
Then you can build your content strategy,
which is another discipline.
Consider your content operations, which
is another discipline.
And then your content design and tactic.
Here are the terms that I've introduced today.
I hope you'll do your own research, and
you know, Michelle is going to make these slides
available to you after the webinar.
So thanks ever so much for
staying with me through all of that.
If you got any questions right now, Michelle
and I will be happy to take them.
Perfect. Thank you so much, Wedge. I
did just wanna... While people are asking
questions — again to ask questions you can ask
them in the left hand
side of your screen in that question and answer box —
While we do that, I did just want to give a
quick mention as to who Igloo is and
what we do.
At Igloo we look to simplify your journey
towards the digital transformation.
Our mission is to create digital workplace solutions
that inspire employees be more connected
and engaged in the workplace.
You can think about is the next generation Intranet,
but at the end of the day, we're a Digital Workplace
Solutions company. We connect people
to each other, to information, and to
the technologies they depend on.
We help our customers build and sustain digital destinations
that are beautiful, easy to manage, solution-
oriented — and our portfolio of digital
solutions integrates with the apps and systems
your business already relies on. And
centralizes that information in a single-source-
of-truth.
Our digital workplace platform helps organization
formed digital representation of their physical
space and culture, bringing people,
communication, collaboration, knowledge
and technologies into one central place
online.
But if not merely about a centralized
digital destination, it's that what
you do with it. And so to increase time to value,
our experts have taken some of the most
common challenges that customer face.
whether it's one of the challenges that Wedge touched on today —
such as knowledge management, employee engagement  —
or a different challenge, and we built
into fast-to-deploy and easy-to-configure solutions.
On that note,
with everything that is currently going on in the
world, we have actually created a set
of free solutions that you do not need
to be a customer of ours to take advantage of these.
And it's an 'incident planning zone.'
If you go to www.igloosoftware.com/continuityplanning
That's where you access those.
And I highly encourage you to check those
out. And with that, I think
we'll open the floor to questions. And it looks
like we have
a couple in there, Wedge.
Yes, indeed. I see
some about content operations.
Yes, it's just somebody asking, "Could you expand
on contact operations?"
Well, it's not my area of expertise,
but thank you for drawing our attention. It is a
discipline. It is something that I think
companies should
be getting good people involved with.
It's about how you operationalize your
content production and
creation and maintenance.
So content ops is about systems,
but it's about people, and it's about processes
so that there are fewer pain
points in creating
content at scale.
So this is less about
urgent news on more about
knowledge management and publishing content
for a single section of your intranet.
Um, I really do think he can talk to
some content
operations experts.
And if you tweet me, I can share
some of the experts I know.
Wonderful and looks like
there's one more question there... Are you able
to take that one this well, Wedge?
Let me see, uh,

"Is content design on the Intranet different
to content design on websites?"
So yeah, great question, because
as I say, Sarah Richard's developed
these principles and techniques
by doing website design, by doing content
for UK government — which is
all about expressing
dense, difficult information for
a very wide audience.
So I don't think there's a lot of difference,
but I think that there's a lag time
behind website design principles and
Intranet design principles.
As in, there is a lot of money
and benefit
in
improving your website for customers
and for citizens,
whereas maybe sometimes
we neglect our Intranet content.
It seems easier just keep
churning stuff out internally.
But of course, we should be doing
great content.
We should be using great content principles. And we should be
using our analytics and our research methods
to discover exactly what our
audiences need.
Our internal audiences, they may be
our colleagues, but we still can't assume
we know everything about their needs or their jobs.
So,
the differences might be scale,
budget, time.
So, your Intranet managers and your publishers
need to work out how to bring these principles
from website design — from content
designed for websites —
into your organization.
And I think because it is a set of principles
and techniques,
that there's lots of room for wiggling things
around and for making things work well
for you.
I've worked with government teams
in the UK
that have adopted content design
externally and internally,
and yet private companies,
in my experience, have not yet adopted
these content design principles fully.
And so I think there's a lot of opportunity to
improve our Intranets.
Wonderful.
And it looks like there's one more question here.
"How do you marry business needs to a user's
needs?" Oh,
yes. So,
you know, we start with the user needs
because we want our content to be
useful, usable and used.
Otherwise, what is the purpose of your Intranet?
However,
we do have to be,
you know, completely aware that the business
has a purpose.
So I did say, you know, have a look at all of the strategies —
plural — that run your business.
And some of those strategies may
well involve the purpose of your business. What
drives your business forward, and which...
and what sort of customers they serve.
So when I talk about stakeholders,
they may well be business stakeholders
rather than Intranet department
section stakeholders.
Marrying it
is a skill.
You might be more
user-focused than your stakeholders desire.
But I think if you got the business needs
in your mind
when you're doing the job stories,
that you can do well.
Wonderful. It looks like we'll actually cap
questions at that
point there. Wedge, did you just
want to give a quick shoutout on how people can get in touch
with you if you have further questions for you
specifically?
Well, thank you, Michelle. Yes, we're at
ClearBox and you can find us on Twitter at
ClearBox.
Or you can check out our website and our blog at
clearbox.co.uk where
I am definitely writing more about content
design last month and this month.
And you can find me on Twitter as Wedge.
Wonderful, and again a quick reminder
if you are interested, and
some of this has resonated with you and you want to find out
how Igloo can help you,
be sure to get in touch with us. Again, if you go
to that 'continuity planning'
section, that will help you If you are looking
to do some emergency comms, some incident
planning.
Because I know this is a very difficult time
for a lot of businesses. Otherwise, feel
free to book a demo with us on
igloosoftware.com and we will give you a free digital
workplace assessment,
kind of review those challenges and see how we can help
you with that.
Again, thank you so much for joining us.
Look out for a recording and we hope you
have a wonderful day.