Why don’t users read the documentation? In many cases, they need to stop what they are doing, go into the documentation, and find the information they are looking for. Then, they need to return to the user interface, remember what they were doing, and start again where they stopped.
Embedded user assistance relieves this pain point by delivering the information users need when and where they need it. Users no longer need to search for the information they need, and they often don’t even realize they are reading help. For example, a wizard in a product provides a lot of embedded assistance that guides the users through the task.
Embedded user assistance is only part of a complete documentation plan. It does not replace the need for other types of content. For example, embedded user assistance is not a good delivery mechanism for comprehensive concepts and detailed discussions of a topic with strategy and best practice guidelines. However, with a strong design, embedded user assistance can support the immediate needs of the user and provide a valuable, contextual link that steers the user into the other parts of the documentation as needed.
The actual format of each part of your documentation depends on the specific requirements of your audience. Some audiences require printed material while others are very comfortable with a completely online set of content. These requirements need to be collected from all audiences, including those who you sell the product to. If the documentation doesn’t help sell the product, it isn’t delivering all the value it can.
When you develop embedded user assistance, you use many of the same tools you use to develop and deliver other types of documentation. However, you may use some of these tools in new ways. You may also use some tools much more than usual. For example, you will use graphic tools for much more than screen shots as you mock up potential designs and visually communicate your design ideas.
The biggest difference in your processes will be in the way you work with your development team. Embedded user assistance requires a close working relationship between the development and documentation teams. You also must be much more than just a writer. Since the content is integrated with the product, you are much more involved in prototyping, designing, and tracking the content development and integration. Strong project management skills are a must.
With all these changes, are you still a technical communicator? Where is the line between information developer, designer, architect, and user interface designer? In many cases, these blurred lines are taking the technical communication profession in new directions. We are no longer technical writers. Interesting questions surround what we will be doing in the future.
Paul, very interesting post. I particularly like the question you concluded with. I’m a believer that technical writers are under-utilized as user experience advocates. Technical writers are great user proxies and if we tested documentation from the perspective of experience more regularly I have to believe that it would be a net positive for those products that took the exercise seriously. I’ve written a couple of posts about this on our company’s blog, you might find them interesting:
http://blog.lugiron.com/2009/04/documentation-as-a-tool-for-user-centered-design/
http://blog.lugiron.com/2009/04/from-technical-writer-to-user-engagement-specialist/
Take care,
Louis
Paul, please define “embedded user assistance” as you understand it. I recently saw online a paper where this term was illustrated by including hyperlinks to prompts about the meanings of fields in a form (see often at Amazon.com and elsewhere). I would say this is a very nonrobust meaning of the term. I’m more interested in sw product development in which the user’s workflow context is maintained by the product, so that the interface can prompt the user with very context-sensitive assistance in the context of “how far along” the user is relative to the product’s stated goals. I also feel that today’s sw apps are too feature-rich and don’t capture enough about the user’s goals at the outset of use. Those goals can be used by the product as a guide against which assistance can be offered to the user when a troublesome step is reached. In other words, why would a robust sw app need to provide a “task topic” (in DITA-speak) instead of reminding the user where their works falls within the product’s stated workflow and transformation of the user’s working dataset?
When you develop embedded user assistance, you use many of the same tools …
Does this mean that I can develop embedded help for my application using RoboHelp and then work with the appropriate engineer to add the hooks to my help? Or, is there some sort of specialized tool that I need to acquire to implement embedded help?
Paul, you raise some interesting ideas. I define embedded UA as any assistance delivered directly through the UI (not in a separate window or separate deliverable). Embedded UA comes in many forms, from text on the window (such as in a wizard), to text displayed when you mouseover a field or menu option, to extensive sections of text displayed in an embedded HTML control in the window. You can use expand/collapse areas in the UI, DIVs that display like tool tips, or many other delivery formats and methods. When I’ve presented conference sessions about embedded UA, I’ve included various types of embedded UA to show the wide variety (and lack of standardization). If you would like to see some of these samples, please feel free to contact me directly and I can share my desktop to show you various samples (see http://www.useraid.com/contact.htm).
Troy, you can use RoboHelp, Doc-to-Help, ePublisher, and many other tools to develop embedded UA content. Then, you work with the developers to create the content display mechanism you need to use. In fact, Doc-to-Help provides an HTML control that developers can embed directly in the UI. If you would like more information about various techniques and technologies, please feel free to contact me directly.
I will be in touch. In the meantime, I would say that IMO it matters less whether the assistance appears *embedded* than whether the assistance is *intelligent*. By intelligent I mean that (1) the app is aware of the user’s “progress” toward some set of explicit, app-relevant goals, and those goals must have been captured by the app at the outset of the user’s work with the app; (2) the app’s awareness of the user’s progress through the app’s workflow determines the set of assistive topics that are presented. These topics would form a tree whose root(s) is the topic “most relevant” to the user’s present “location” within the workflow space.
How is this different from context sensitive help?
Aneesa, embedded user assistance is different from context-sensitive help in that it is integrated directly into the user interface. It also isn’t labeled as help (so more users will actually read it). For example, wizards are actually traditional documentation (steps) integrated into the UI as a guided process. The most important aspect is that information/assistance is delivered when and where the user needs it without making the user stop what he/she is doing and going into a separate help system to find the information he/she needs. Does that help?
I think there is one more aspect why embedded help can be a good thing: My wife often complains that I’d rather search for an hour to find my way before I am willing to ask somebody for directions. The problem is: I just don’t want to admit that I need help. It is the same with many users. They do not want to admit that they need help, so they don’t call it. However, if by some lucky coincidence there is some clue on the screen this does not hurt their ego and gets them back on the right track.
Paul – I was just reading your blog post about embedded user assistance. We are thinking of moving towards embedding user assistance into one of our new apps, and I would really like to know how we can leverage our existing tools (RoboHelp, FrameMaker) to create this content. Any information you can give me would be much appreciated. You can email me directly if you find it is more appropriate.
This topic continues to be popular as more applications move toward integrated user assistance. Integrating community-generated content into applications is also an interesting related area.
Nicky Bleiel (www.nickybleiel.com) and Scott DeLoach (www.clickstart.net) also often present conference sessions about embedded and integrated user assistance. If you would like to explore other options and methods, feel free to email me and I can share other samples with you.