Content design

Ray Newman on the pursuit of content perfection often sought by stakeholder types, especially in government:

The antithesis of content design is the old skool Civil Service idea that, if you just try hard enough, you can find “a form of words” that will make everybody happy, nobody sad, and nobody angry.

Or, at least, obfuscate the unpopular policy sufficiently that nobody will realise they should be mad about it.

And then towards the end of the post:

But sometimes, you need to hold the detail back; or disappoint some people to make it clearer for most people; or clearly and directly tell people something they won't want to hear.

It’s rarely easy to balance these, and the many other concerns in the mix. But that’s why the content needs to be designed – not just knocked out, banged together, or scribbled on the back of a napkin.

I think there is also something here about research, constraints and making informed decisions.

You need research to understand who your content is for and how it might affect them, either positively or negatively. But you also have the internal pressure of deadlines and budgets – these are frustrating, but very real content constraints. They too affect your decision making.

As Ray says, this is why many of us call ourselves designers these days and not copywriters. Our choices are based on the situation in front of us. We take all that we know about our users and design the best content we can at any given time.

In my experience, good content design is rarely about finding the ideal 'form of words'. It's about listening, compromise and pragmatism. Writing good content is a messy, movable feast, not a meal to be cooked to perfection.

Love this clear explanation from Martin Underhill of what headers, headings and titles are, and why they are very much not the same.

This resonates:

Three particular terms I often hear being used interchangeably are ‘header’, ‘heading’, and ‘title’; I even catch myself doing it sometimes! Let’s have a look how they can be confused.

And this seems pretty sensible:

What a designer calls something should not differ from what a developer calls it, and the easiest way to ensure this consistency is to use the terminology defined by the super smart people who wrote HTML and ARIA.

If you work in content that lives on the internet, I think you should know the differences and be able to explain them.

Basically:

• header – usually a banner area where a logo, strapline and navigation lives
• title – search-friendly metadata that describes the page and appears in the browser, not the page itself
• headings – the h1, h2, h3 content that helps structure a page and provides an outline of your content

If you're reading this and thinking, "Hmm, still not sure," then I highly recommend you go check out Underhill's post. It includes much more detailed definitions and useful examples to help you out.

This post by Geri Reid questions the traditional folder-based approach to documentation:

For years we’ve treated documentation like a filing cabinet. Put the thing in the right folder and give it a label. But much as it pains me, people rarely wander through my carefully crafted hierarchy, admiring the taxonomy. They search, skim, follow links. And the second finding information feels like work, they’ve checked out and just asked someone.

I have to say, this was exactly my experience on a recent guidance project. Users would often find the document they wanted and make a direct copy to keep locally. Of course, when guidance was updated, that local copy was soon out of date.

For these users, knowing where to quickly find guidance was important. To heck with the shared folder structure! And for those times where they couldn't find the right guidance document at all, they would simply ask a colleague for the answer.

Needless to say, I learnt a lot from this experience. It's important to organise documents in a clear, sensible way that people can easily navigate. But don't think for a second that users will or want to carefully wander through your folder structure to find what they want.

A short and handy intro to design documentation from Colin Baird:

Design documentation is an important part of the design process. It records the thinking behind the designs. It preserves knowledge for future team members. It gives you evidence when stakeholders challenge design decisions. A screen-by-screen explanation ensures that you don’t miss anything. A decision log gives a high-level overview of the who and why of design decisions.

I'm in the process of documenting some of my design work at the moment. For example, I recently updated some content based on feedback from the clinical assurance team. So I made a note of that in our shared decision log.

Having that decision documented will help anyone new to the project understand that there is a very good reason why things are the way they are. They can be reassured that the design work was based on sound clinical guidance.

Read Baird's post if you want to get started with this kind of thing yourself. There is even a useful four-column example you can swipe for your decision log. Lovely stuff.

I'm not sure how I hadn't read this before, but if you're looking for a handy guide to content journey mapping, this is for you.

When we start working on an end-to-end service, we define the users, then map out the journey. This process shows us what tasks users need to complete and highlights where the content doesn’t help them to do this.

What follows is pretty much a step-by-step to get you started. Of course, you'll need to take your organisation's specific circumstances and constraints into account. But hopefully it should be easy to get the right people together and start mapping those content journeys. Also, you can do all this at the start of a content project, not just when things already exist and are ready for an update.

This blog post on naming services is by Dani Allen, a lead content designer at TPXimpact:

Naming services is an important part of digital transformation. Service names need to be clear, concise and related to the task people are completing. But this can become harder when the situation becomes more complex.

The thrust of the post is about using dedicated workshops to get all the key people together:

An engaging naming workshop is a way of making sure that everyone has the same level of knowledge of what’s involved in this task, and the importance of it. Getting important stakeholders involved and as close as possible to this work will set you up for success.

I have one extra tip on naming your service. I learnt this the hard way last year. Before you start telling people your new service name, remember to carry out a quick check to make sure that any inevitable acronyms are not, well... a bit rude. Cripes.