Nandini gupta usefulpopularhelp_tekom

Editor's Notes

1. When creating and serving content, it helps to remember that users typically look for Help in two scenarios: when they want to learn and when they want to solve a problem. The mood and expectation of the users in one scenario is vastly different from the mood and expectation in the other. When users want to learn, they are patient and playful. When they want to solve a problem, they are time-constrained and ready-to-snap. The format of Help that works in the Laidback Learn scenario does not always work in the Quick Help scenario. For example, videos might not work as well as FAQs in the Quick Help scenario. The perception of Help as good or bad depends a lot on users in the Quick Help scenario. The trick is to track user feedback with rigor and optimize Help for these users who are looking for specific answers in Help.
2. It’s important to ensure that users find the format and presentation refreshing. Someone once tweeted “Learners are always two clicks away from Angry Birds. And that's why you'd better make teaching & learning engaging.”Today’s users interact with a diverse range of applications. Because of the variety of devices that they use and the different purposes for which they use software, the software experience of most users today is rich. In this scenario, the over-templatized clinical Help needs to make way for something that has the power to delight. We need to relook at traditional learning theories, gather data on how users are consuming the content, and break the form intelligently. While our traditional Help formats serve as a robust backend, we need to devise and deliver new front-ends to serve Help. Visuals and multimedia play an important role here. Equally important is structuring and writing style, which as user feedback suggests, needs to be efficient and engaging at the same time.I have some examples of visual docs and new front-ends.Here’s the first one:This document is one of our most-read docs. Over the years and over many updates, it had become an information dump. In an effort to cover all scenarios, reported by users over the years, readability and findability was sacrificed. A complete revamp was done and you can see how instructional design strategies, such as branching and chunking, were applied to transform a long linear doc into a visual doc.
3. Another example. This is from the Adobe Illustrator documentation:Graphics and intelligent structuring are used here. The layout is visual and easy to scan. Detailed information has been layered to allow for different user levels and needs.
4. A third example: The FAQ format is chosen here to help users easily find answers to the many questions they were repeatedly asking on various forums. The answers usually get buried in a typical user guide. The page supports different ways to navigate and allows users to engage.
5. A last one.Content on display is curated by the tech writer, sourced inhouse and from the community. You can see both learning and troubleshooting content. Plus, the page has dynamic content from social media channels.
6. Today’s Help must be social and collaborative. Instead of trying to document all that the software does or document every piece of content ourselves, we need to work with a content strategy that takes into account usage patterns and user feedback and includes content contributions from internal and external communities. Allowing users to evaluate the content (through social features, such as rating and commenting) facilitates a seamless churning that’s required to keep the most relevant content findable. Today’s technical writer needs to engage with the user community and play a larger role of a curator and a community editor. Whether it is on the forums or on social media, interacting with the community helps us identify the top issues in the software that we are documenting and gather real-world examples.
7. An example of content created by users and Quality Engineers on niche topics, such as integration of RoboHelp with third-party version control systems. A complete collaborative effort based on a content strategy to leverage the knowledge of power users on user-requested topics.
8. Diverse user preferences are a reality. As someone said “Some users want to know the concepts behind a product before they use the product. Other users want to use the software without any preamble. You cannot please everyone, but if you know your audience, you can produce documentation that is useful and acceptable to most people.” The good news is that today we have access to a vast amount of usage data and feedback to know our audience. Page views, search data, context paths, ratings, and comments – all of these data points can help us understand what our users want.
9. Making Help popular and useful requires a sea change in the way we create Help. The document development cycle can no longer end abruptly with a software release. Instead, it needs to continue well beyond a release and the phase that follows a release is an exciting phase for technical writers. In this phase, we need to engage with internal and external user communities and track usage data and feedback to enhance the core we delivered with input from different internal stakeholders. Our approach should be that of a web designer trying to make a qualitative improvement in the user experience.
10. In an article inMashable,Mike Puterbaugh made a very strong case for valuing documentation. He explained why product documentation is a great marketing asset. The article has some great advice for people who are trying to make Help useful.I also found a small blog post on a presentation called Helpful Help. The post resonated with me.
11. Some quotes I keep in from of me.