As readers and content both go increasingly online, findability becomes an ever greater concern. The organization of content therefore becomes more and more important. Content can’t be effective if it is not found.
There are three components to content organization: classification, relationships, and stickiness. Traditionally, we have focused most of our effort on classification as a means of organization, but this needs to change.
Stickiness
Stickiness is simply the propensity of an idea to stick. Chip and Dan Heath wrote an excellent book about stickiness called Made to Stick. Still, it may not be obvious that stickiness is a form of organization. So let me suggest a definition of organization that will make the role of stickiness easier to see:
Content organization is a response to the activity of the information seeker, designed to make that activity more successful.
In other words, we organize content (or anything else) so that the reader’s attempts to find it will be successful. By this definition, anything we do that makes it more likely that any reader information-seeking behavior will succeed is content organization.
Stickiness is a form of organization. By miguelb (Flickr: Sticky bug-eating plant) [CC-BY-2.0 (http://creativecommons.org/licenses/by/2.0)], via Wikimedia Commons
If we take this approach — if we start by looking at how readers seek information — we will notice that a lot of our reader’s information seeking behavior is based on stickiness.
Stickiness is simple. Stick your hand in a jar and the stickiest item in the jar is the one that will most likely come back in your hand. Any way you look for content on the Web, there are usually thousands if not millions of pages that relate to what your are looking for. The ones you will actually see are the ones that are the stickiest.
Google essentially works by measuring and recording the stickiness of content. Content gets sticky when people like it and refer to it and read it. Content gets sticky when it is chosen from search results, when it gets liked and tweeted and plused, when it gets referenced or voted up on social networks and Q and A sites. Readers make content sticky, not writers. Writers can only make content that is likely to get sticky, and put it where it can begin to pick up stickiness.
Stickiness, then, is a form of organization that you court, rather than create. But stickiness is also, in many ways, the most sophisticated form of organization, because it incorporates so many factors, and because it filters out individual judgement in favor of the judgement of the crowd.
SEO may be able to make your content a little bit stickier, though if you are too slick about it, it won’t stick. (See what I did there?) But what really makes content sticky is being good, and being useful. Sticky is hard to fake.
Relationships
Relationships are all the navigable connections between one piece of content and another. Classification provides one kind of relationship. Even stickiness can provide a kind of relationship, because one piece of sticky content will tend to stick to other pieces of similarly sticky content. But there are relationships between pieces of content that are not a product of either classification or stickiness.
Content, in itself, describes the relationship between things in the world. Content on one subject mentions content on countless other subjects. Every one of those relationships between subjects is a potential relationship between pieces of content. Readers can discover these content relationships for themselves using search, or the author can provide them by creating hypertext links.
It may seem hard to think of hypertext links as a form of organization. For one thing, they tend to be irregular, capable of pointing off almost anywhere from almost anywhere in the content. The web of relationships they create often has no obvious order about it. Indeed, a visualization of a web of links often looks completely chaotic.
A top-down visualization of hypertext links looks chaotic, but links can accurately follow the complex and irregular relationships that content actually describes.
But again this is to confuse organization with classification. Classification creates orderly rows and columns. But the world does not organize itself in rows and columns. Indeed, the parts of the world that do organize themselves in rows and columns can be described very well by spreadsheets and databases. Content’s domain is precisely those relationships that are not regular: the bumpy, the lumpy, the unexpected, the counterintuitive, and the downright odd. To confine content to orderly classifications is to rob it of the ability to rule its own domain.
The purpose of organization is to help readers find information, and for the irregular relationships that content describes, and that readers may wish to follow, links fulfill that purpose.
Relationships shine as a means of organization on the Web. Footnotes and cross references provide relationships on paper, but they are so expensive to navigate that their value is minimized. On the Web, on the other hand, relationships are cheap to establish and cheap to navigate. Relationships therefore play a far greater role on the Web than they did in the paper world.
Classification
That leaves classification. It’s what we know best, and often what works best for us to manage the content we create. No wonder we tend to rely on it at the expense of stickiness and relationships. But genuinely useful classification can be hard to achieve.
The problem with classification is that its usefulness depends on how well the user understands the classification schema. One of the things our new definition of organization tells us is that if we are going to classify content, we had better observe how the reader classifies things and base our classification on theirs. Asking them to learn our classification scheme is not going to work unless their motivation is unusually strong.
One of the problems with trying to classify things the way the reader classifies them is that readers don’t usually classify things at all; they usually just name them. Classification is something you do when you have to manage all the members of a set. If you only deal with a few items from that set, you generally just give them names and ignore the rest.
Another problem with classification is that it gets more and more difficult, both to do and to navigate, as the number and diversity of items increases. The more different things you have to classify, the more arbitrary the classes become. As quantities increase, classes become too large and have to be subdivided, creating classification schemas that are more and more deeply nested and often more and more arbitrary.
In the paper world, classification was by far the most important form of organization, despite its drawbacks, because stickiness was so hard to measure and relationships were so hard to navigate. In many fields, it was accepted that you had to be educated in the field in order to successfully find information in that field, and a large part of your education in the field consisted of learning its classification schemes.
But on the Web, stickiness and relationships are far more powerful and far easier to use than classification. People are navigating much larger volumes of content, so the problems of classification are magnified. And people no longer accept that they have to study the classification schema of a field before they are allowed to look stuff up in that field.
The result is that classification drops to third place for most Web content, behind relationships and stickiness. The problem this poses for writers is that they are more familiar with classification, and their tools are built more for classification, than they are for stickiness and relationships. This needs to change.
This is a great summary of things that have been bothering me for years.
“The problem this poses for writers is that they are more familiar with classification, and their tools are built more for classification, than they are for stickiness and relationships. This needs to change.”
Writers trying to force content into a tidy classification scheme end up creating unusable documentation. I’ve seen this firsthand when readers complained that I didn’t document something important, and it was two or three steps away from their current location on the TOC. But of course I built that TOC, I knew it inside and out, and most readers never looked at the darned thing. My customers searched for some keyword or phrase, the search gave them a likely option, and when they didn’t find what they wanted they tried again (usually a minority), gave up (far too many), or complained (not nearly enough). In any case, they blamed me (or my company) for not giving they what they expected.
The problem was that the relationships were incomplete, stickiness was all wrong, and I was relying on classification to make it work. The result: Upset customers and a massive overhaul of the documentation.
Thanks for the comment, Neal.
Indeed, it seems to be a complaint as old as the hills in tech comm: the user was close, but they never found the content. So many of the times that users complain about missing information, it isn’t actually missing. They just couldn’t find it because the docs were not designed to support the information finding strategies that the user were actually using.
It’s almost amusing: we’ve been expecting the users to learn how to use the documentation so they can learn how to use the product!
Neal, interesting little comment there. I remember that a few technology books have an small section as ‘How to use this book’. Although the book has a TOC, a preface and an introduction, this ‘How to use this book’ section prepares users for what to expect, where, and for what kind of information.
Is it time to embrace the same for product knowledge base? When I plan a new KB, I plan it as if I would plan a new product, a KB itself is a product and I often have a section as ‘How to use this KB’.
I understand that users refer to a KB when stuck, when they are short of time, and this ‘How to use this KB’ may not make sense to them; however it helps them when they are not able to find what exactly they are looking for (assuming that it may happen with any user, anytime). Two, this section certainly helps those users who are trying to know the product in general, such as new features, upcoming release, whey they are evaluating a product (they have more time to refer to support), and when they are comparing multiple products to make a buying decision.
Two,
Thanks for the comment, Vinish.
I hate to say it, but, by and large, if the reader has to read how to use a knowledge base, they won’t use it.
It is something of an axiom of content strategy that if the reader has to learn how to navigate your site, you have already failed. And I think this is particularly true for technical communication. After all, people come to knowledge bases, and to tech comm in general, because they are struggling with a problem they cannot solve. Their brain is full of the problem. They have no mental reserve to devote to learning the navigation. They are frustrated by their problem. They are not in a mood to learn something new.
The last thing tech comm should do is further tax the reader’s mental or emotional resources by requiring them to learn to use the docs. Instead, it should work the way the reader already expects it to work. And if we take full advantage of all three means of organizing content, then the ordinary Web conventions of search, link, scroll, and back provide all the navigational tools we need to organize any content set.
The cardinal rules of information design should be familiarity, simplicity, and consistency.
Pingback: Tech Writer This Week for August 14, 2014 | TechWhirl
Thanks Mark. To be honest, I saw it coming from you. 🙂
There are systems where the architecture is complex, the workflow is too inter-woven and so planning the IA for their KB can be tricky. For example see the SalesForce help at: https://help.salesforce.com/apex/HTHome and I am lost. It does not make much sense to me, neither for structure nor for layout (layout, refer to your post on staging your content few weeks back).
For such cases, I am happy to defy the conventional wisdom “The cardinal rules of information design should be familiarity, simplicity, and consistency”, if a quick note on ‘How to use the KB’ can make things easier for users. The only objective of this section is to give quick less-than-a-minute directions to users.
We may conclude that such a ‘How to use this KB’ section helps us cover up the actually poor architecture of KB. Not necessarily. As I said, the product is bootstrapped funded and cannot really afford six-ten months’ budget for its KB and redesigning and restructure for a complex KB (such as of SF) may have its own challenges and limitations. Till the time it happens, why not to help users use ‘whatever the KB they have’ more effectively. Conventional wisdom and best practices are understandable but like a cop, an occasional barge into no-entry is fine with me to catch hold of a nasty element! 🙂
PS: I posted a reply 2 days back too, guess it landed in your SPAM.
Well, certainly, if you are stuck with the KB and your users are having trouble using it, it can’t hurt to provide information on how to use it. I doubt it will get read much, and I doubt it will help much (though it may, for some audiences) but if it is all you can do, you should certainly do it.
The fact of most of our lives is that we have to make do with what we have most of the time. The opportunities to make major changes only come along every so often.
A big part of the problem, though, is that the systems we have, and, often, the systems that we adopt when we throw out the systems we have now, are ones that rely on complex classification schemes to address problems that could be addressed much more simply by stickiness and relationships.
When it comes to tools, tech comm is drowning in complexity, and it holds us back from keeping up with our user’s real information seeking behavior. We need a simpler approach. But simple here does not just mean less, it means different. That is what the SPFE project is trying to introduce.
But until that door opens for us, yes, we have to make do with what we have.