Content design

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.

And now for something a little different with a touch of fruity language.

One of the lovely colleagues on my previous project shared this blog post by Cap Watkins with me last year and I have thought about it a lot since. Essentially, if you are having a difficult design or content conversation, how much does the issue mean to you on a scale of 1–10?

There have been a few times recently when I could tell someone felt far more strongly about a decision than I did. So, I acquiesced, with the hope that the next time I'm a ten-out-of-ten on a topic with that person involved, they'll recognize that and hear me out. If you can let go of the things that don't matter so much to you directly, you can build currency with others and earn their trust when you do wind up pushing back.

I have found this an incredibly useful mental trick. When you are in the fog of deadlines and challenging work, it is easy to feel like every decision matters and all arguments are worth fighting for. But that's not how true collaboration works.

To work effectively as a team when things get tough and tense, there has to be a bit of give and take. You can't go full steam ahead into every single conversation. It's unlikely that your way will be the right way every time.

So yeah – these are good questions to ask. Is this decision – this argument – really that important to me? Do I feel so strongly about it? Or can I let this one go and save my persistence for a problem that's more of an 8, 9 or 10 out of 10?