Returning to Findability
About two years ago, I started a series on findability because it was a topic that interested me. My goal was to write a book on the subject, moving post by post. Although I never have time to write a book, I could fathom sitting down to write a post each evening. I figured that any insightful, in-depth book would require me to write at least 100 posts on the topic. But somehow when I reached 50 posts, I came to a wall and couldn't see beyond it. I threw up my hands and decided the problem of findability in tech comm had no answer.
However, this topic of findability keeps poking up its head wherever I go. It's a topic that a great many people are interested in as well, since it sits at the heart of tech comm. When you think about it, the entire discipline of tech comm is about helping people find the answer they're looking for.
I want to return to the series and finish off the 100 posts. To recap, here are a few findability tips that came out of the previous posts. They are in no particular order:
- Add related topics at the end of each topic (such as with a relationship table).
- Include cross-references within topics.
- Provide alternative navigation methods outside of a traditional topic-based hierarchy.
- Address real questions users have.
- Search engine optimize your help topics.
- Include a "known limitations" topic that lets readers know what they can't do.
- Do card sorting to group topics how your users would group them.
- Provide faceted classification for users, so they can see content based on various organizations.
- Organize for learning by providing a level-based structure.
- Put the most popular questions on the homepage of the help.
- Include help icons in the interface at the pain points of the application.
- Create help that people can consume in multiple modes (video, text, illustration, audio).
- Enable users to find answers through social search (such as asking on Twitter).
- Include an Ask a Question button on each help topic.
- Follow a reverse engineering process for your help, regularly reviewing user feedback and continually adding to the help.
- Write help from a user-centered perspective rather than a product-centered perspective.
- Write help that addresses end-to-end scenarios rather than just single how-to topics.
- Include metadata with each topic so you manipulate the content through various facets.
- Chunk your content small enough so you can reorganize it in a plethora of ways.
- Provide an index.
Right now my posts are an ongoing brainstorm. They are a compilation of thoughts that don't necessarily cohere into any systematic approach toward creating findable help material.
I hope that the above miscellany of points might eventually be categorized into larger sections, such as the following:
- User-centered writing
- Search engine optimization
- Faceted navigation based on metadata
- Interface text
- Multiple formats and outputs
Rather than creating a list, such as "50 ways to make your help more findable," I'd like to write a book that outlines a detailed approach, step-by-step, taking the reader from beginning to end to achieve findability.
I'd Rather Be Writing Newsletter
Get new posts delivered straight to your inbox.
About Tom Johnson
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in , API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.