Signposts

I recently attended the Glastonbury Festival and, despite the mud and mayhem around me, found myself pondering an issue that we have in our documentation set.

Throughout the week I was at the festival I spent a lot of time consulting a map of the festival site, trying to figure out both where I was and where I should go next. It wasn’t always easy and I got it wrong several times causing us to have to stop at the nearest beer tent, you know, just to make sure we weren’t completely lost.

The signposts around the festival site weren’t always clear, nor particularly abundant) and whilst we coped, it is definitely something they could improve. Being lost is never fun, and at some point over that week I realised this was similar to an issue we have with our documentation.

It was very much one of those thoughts that had probably been percolating at the back of my brain (a dark and dusty place, if truth be told) for a few days. Somewhere in those dark recesses, prompted by frequently being lost at the festival, my brain dragged up a quote from a blogpost I’ve mentioned in this months ISTC newsletter (you don’t have to be a member to receive the newsletter, anyone can sign up and anyone can view the archives).

The quote that had, seemingly, lodged in my head was “every page is page one”; the blog post it’s taken from is well worth a read (it’s linked in the newsletter).

Like many of you, we have a LOT of content, particularly when it’s broken down into topics. Whilst we take care to plan out what content we will be adding to make sure the structure makes sense, we realise it’s not always easily findable. One of the main reasons is that, by and large, most people will find their way into the content via the search results.

Taking the maxim that “every page is page one” makes sense for our situation, but how do we best signpost where the user has landed?

Have you tackled this issue? Do you have a solution? I’d love to hear your suggestions on this.

Comments

  1. I wouldn’t claim to have THE answer but we do make very effort to add a means of navigating to other information in all our documentation. This requires the writer to really get inside the minds of the users and attempt to predict what they are going to have to do next. Not always easy. Having input from SMEs helps though.

    For a fairly simple example, our docs could be on amending a word file. Obviously that covers opening Word, opening the file, making changes and saving the file. All of these elements maybe in different topics but understanding what the user may want to do next, not only helps you structure your topic but provides you with the required workflow to link to next step of a process.

  2. Couldn’t agree more Colum, to that end a lot of what we are currently looking at is focused around how we know people use our information (yes, we are asking our customers directly).

Comments are closed.