Lessons from Ray Gallon on cognitive UA design

Context is everything: Support your users in their integrated competency learning and embed user assistance in the user interface and conceptual context in task topics. That’s in a nutshell what I took away from Ray Gallon‘s  webinar “User Become Learners”, the first in a series of 3 webinars on “Cognitive Design for User Assistance“.

To catch up before the second webinar on Tuesday, 29 January, read on or watch the recording made available by Adobe who hosted and sponsored the webinar (requires an Adobe ID) or check out Ray’s slides.

Evolving learning needs

What we need to learn changes all the time – it even seems to change faster these days. So for us technical communicators, says Ray, it’s not sufficient to show users how to use or learn a product. Beyond that, we need to teach users how to learn to adapt a product to their evolving needs.

To back up his claim that learning needs are not static, Ray showed OECD statistics for the last 50 years: In average European working days, routine manual tasks are down. Routine cognitive tasks way down. Non-routine manual tasks are way, way down. By contrast, expert thinking is way up. And complex communication is way, way up!

To help users meet these challenges, technical communicators need to offer decision support and to convey knowledge. Users need to be able to decide which problem they need to solve and if and how they can go about it. This requires knowledge: They need to understand contexts, underlying concepts and applicable tools. All this means much more than just explaining a product’s user interface – which would be routine manual and cognitive tasks that are on the way out.

How minimalism can help

Ray recalled the core principles of decision support, according to the U.S. National Research Council. Half of them relate directly to the tech comm principles of minimalism (as summarized by JoAnn Hackos on her blog recently):

1. Begin with the users’ needs in decision support; focus on users’ actions in minimalism
2. Connect information between producers and users in decision support; understand the users’ world in minimalism
3. Design for learning in decision support; ensure that documentation is findable and contains troubleshooting information in minimalism

Just because minimalism emphasizes hands-on practice doesn’t mean it shuns conceptual information, says Ray. So to add value to the documentation, describe applicable tasks, not just the user interface.

That means we tech comm’ers don’t just merely describe the menus and icons. Instead, we must also get involved in the design of the product, especially the interface with its labels and error messages and pop-up hints.

This way, usage of our documentation can improve drastically: Rather than supporting rote memorization or, worse yet, require users to look up the documentation repeatedly, users can learn from the documentation and apply what they find to decide what they need to do and how.

To carve up or synthesize?

One of the most important consequences of Ray’s paradigm for us tech comm’ers is that it effectively abolishes a dear dogma of topic-based authoring, namely the separation of concepts and tasks. Ray explains that just because we need to understand these areas separately (when we make sense of products during analysis) doesn’t mean we need to keep them separate when we present them again to users (during synthesis). Imagine a pizza: You need to understand crust, tomato sauce and toppings separately – but you would never serve them separately to the user. (For more about this, see Mark Baker’s blog post.)

For documentation, this means to empower the user: Read/understand once, apply many. I think the parallel to single sourcing is obvious and deliberate: Write once, use/publish many. Give users all the information they need – and only that, no more, nada mas! (And offer it in a way it’s findable immediately.)

Specifically, put conceptual information where it is most useful, into tasks. Integrating conceptual information into tasks avoids that concepts remain abstract and removed. In addition, progressive disclosure can help with the efficient embedding of user assistance into the user interface.

My lessons learned

I think Ray’s approach makes a lot of sense. It can improve many a help system that follows the letter, but not yet the spirit of topic-based authoring.

But two factors in my daily work dampen the effect of Ray’s ideas for me:

• We use a DITA-based information model which allows and in fact encourages contextual information as part of task topics. We want to ensure that users understand when they need to perform a task and why. I believe the <context> and also the <prereq> element in DITA serve this purpose well, without fully replacing concept topics.
• Ray’s assertion that “good user assistance is only needed once” is a bit too idealistic for many software products I have documented. Many are very complex, some are poorly designed to boot to allow the user to safely deduce a general principle about the product. So Ray’s paradigm does require not merely the technical communicator’s participation in the design phase, but actually good design. As Ray said during the Q&A session, “This is easy to explain, but hard to do.”