A step-by-step guide

How to design content that works

Content that helps your users, changes behaviour for the good, meets objectives, improves the world.

Tori Sanderson
Pragma Partners

--

Organisations are not used to thinking about whether their content works.

In many cases, organisations think that published content is content that works.

Usually, it is not.

What is content that works? Content that changes users’ behaviour, or that helps them Do A Thing, works. Content that doesn’t have any impact on user behaviour, probably has not worked.

For example, say a user is interested in applying for a grant. Content that gets them across the line — meaning into, through and finishing the grant application process — works. Content that tells them all about the application process but doesn’t guide them into and through it, doesn’t work.

My team creates content that works. We’ve designed content that helps people decide to install solar panels on their roofs, that helps veterans get civilian jobs, that lets people report terrorist activity.

Here is the process that we use, and that we teach our clients.

It’s a process designed to keep user research and insights at the very forefront of the design process.

Too often, user research happens, then content/UX design happens, and in the process of doing our work, the research insights don’t get carried forward into the design process.

We use this process to prevent that from occurring. Each of these tasks are included to make sure we keep referring back to the users and what they’ve told us.

There are heaps of ways to do this; this is just one. We find it works.

Face-to-face, one-on-one contextual enquiry will offer huge insights about your users’ needs.

Talk to your users

This is always our first step. And often, it scares people.

Talking to your actual customers is daunting. What will they say?

Whatever they say, once you start talking to them, you can’t hide from it. When you’re talking to real people with real needs, you can’t hide behind business processes, or system requirements, or internal politics. Not in the face of user experience.

Because your users don’t care about any of those things. They just care about the task they’re trying to achieve.

Which is exactly why we always start here. Talking to your users and understanding (deeply understanding) their experience of your service is the best antidote to corporate apathy.

Talking to your users will tell you three invaluable things:

1. What tasks they’re trying to do.

(Hint: “understand our business model” isn’t one of them. “Report a change of address” is closer.)

2. What content they need to do these tasks.

3. What content they don’t need.

(Hint: they need less content than you think.)

If you haven’t talked to your users first, any content you create is pure guesswork.

When trying to understand user needs, I recommend using contextual inquiry. I won’t go into detail about this methodology here, but the University of Minnesota has a pretty good online lecture about how to do contextual inquiry (don’t worry, there’s a transcript).

We use User Story Maps to document and prioritise user tasks from the research.

Prioritise their tasks

Once you’ve spoken to enough users that you start hearing the same insights repeated (it doesn’t necessarily have to be a representative sample), start prioritising their tasks.

We use two really useful processes to do this.

User Story Maps

First, we run User Story Mapping sessions — a technique developed by Jeff Patton.

User Story Maps are essentially a way to generate a user-driven backlog for building products. We use it as a way to document all the user stories and user needs that are identified in the research.

(We also use journey mapping, depending on the context. Both work! But I prefer user story maps for content work as they tend to get a bit more specific. NNG has a great description of the difference between journey maps and user story maps. Basically, journey maps are a discovery activity; user story maps are about design and implementation.)

There are tonnes of great resources on how to run user story mapping sessions. Here are some of the things we find essential to creating user story maps that actually inform content design.

  • Make sure everyone who did the research is in the room. They know and understand the users’ experiences deeply and will be able to communicate them.
  • Go wide, then go deep. Start by mapping all the user activities, then tasks, before going into detail on the stories within those tasks. Get the big picture — this will help you nail the details.

Do a User Story Map for each user group, or persona, for your digital service.

Once you have User Story Map for each user group, identify the priority levels of each user activity, based on how your users talked about their current experience and pain points.

For example, if your users are trying to report a change of finances, but can’t find where to do this, that would be a high priority user task. If they have expressed that they don’t really understand the reporting process, but that this hasn’t stopped them making a report, that would be a lower priority task.

The goal here is to end up with a clear idea of the content and features your users absolutely need, and which ones are ‘nice-to-haves.’

Content designers create content priority guides based on the user story maps.

Content Priority Guides

Once you’ve identified the highest priority user stories, the next step we recommend is creating content priority guides.

We find this step integral to creating content-first digital experiences, where the tasks that users are trying to do genuinely define the service’s design.

Content priority guides assist content designers and UX designers to prioritise the information and interactions that are presented to the user.

They help us remember user needs while we’re making the many small decisions that go into the design process.

When we’ve finished a content priority guide for a user story, we have all the content, in priority order, that the user needs. It has been through a content design process (as in, what is the best way to present this content to the user?) but not a UX design process.

This A List Apart article from Heleen van Neus and Lennart Overkamp talks about content priority guides and how to use them.

Content priority guides are functional, not pretty. They’re mobile-first.

And, importantly, content priority guides aren’t sat on for long before you get your UX/UI designer involved.

Which brings us to the next big phase of designing content that works:

Content designers and UX/UI designers work together in collaborative tools such as Figma.

Stop, collaborate and listen

Our content designers create content priority guides in collaborative design tools such as Figma.

We love Figma because we prioritise tools where we can work together on the same file. Because the next step, which we move onto as quickly as possible, is to bring our UX/UI designers on board.

Our content designers and UX designers start working together on how the user experiences and interacts with the content.

The process from content priority guide, to wireframe, to high-fidelity prototype.

This is a highly collaborative. Content designers work a step or two ahead of the UX/UI designers, having near-final content ready for UX and interaction design and then working on how it can be structured together.

In this process, content goes through changes — sometime minor and major — as it comes into contact with interaction design. For example, microcopy on buttons might change, or content might be restructured to make sense of a user’s journey through the interactive content.

For this reason, we recommend doing any required internal approvals with content after it has been fully designed and you have a low-fidelity prototype. Then stakeholders can experience the content in-situ, in the same context that users will experience it. This also helps them understand the structure and task-oriented nature of the content, rather than reading it in the vacuum of a Word doc.

Test your content

We use highlighter testing and face-to-face moderated usability tests to find out whether the content works.

When you’re trying to find out whether content works, you’re trying to find out whether it helps users do the task they came to do.

With this frame, you may not need to test the content itself; testing task completion through usability testing will reveal a great deal about whether the content is working.

However, there are times when testing the readability and relevance of content on its own can be helpful. We work with a lot of clients that struggle to meet best practice recommendations for content readability. Using testing techniques like highlighter testing can be a powerful way to show them how poorly written and designed content can impact users.

Using highlighter testing to test content readability.

We’ve written before about how we use highlighter testing.

And finally… keep going!

Following this process helps us ensure that the needs of real users, identified through research, is at the forefront during the whole design and testing process.

However, it’s not the end! Continuing the testing and iteration process throughout the entire life of the digital service will ensure your content stays relevant, useful, and in fact essential to user needs.

What next?

Here are a bunch of things that I recommend you read for more detail on each stage of the process mentioned here.

--

--

Tori Sanderson
Pragma Partners

I like building great things. General Manager, Product and Experience Design at pragma.com.au. www.torisanderson.com