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.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.