Content design

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.

I did not know a lot of the history outlined in this post by Caroline Jarrett until she kindly pointed me to it last year. Historical drama aside, I think the key distinction for me is the importance of testing content with users.

Plain language relies on testing with users. If the intended users can use the content to do what they need to do, it’s plain. If they can’t, it’s not plain. So you can only really know whether you have succeeded in writing in plain language when you have tested with the actual users.

And of course, this detail is fundamental to content design as a discipline. It's about following the principles of clear writing, but making decisions based on research and data. You need to understand what users need before you start writing. Then you need to test your content when you're done to make sure it meets those needs. It's only plain or clear if it does.