Column: User Assistance

If this column’s title sounds familiar to you, the bad news is you’re getting old, but the good news is your memory hasn’t gone yet. It was the title of a presentation I gave at the STC conference in Anaheim ten years ago. However, many of the points I made in that talk are still relevant to user assistance today, so I would like to update some of them and offer some new thoughts as well.

When product teams ask technical writers to document software products, writers usually start their projects by analyzing the tasks users will perform when working with them. A task analysis generates a list of procedures—plus the supporting information users need to follow them—and eventually results in a document in which sequentially numbered instructions are the dominant type of information—neatly organized under user-centered task headings and preceded by enabling knowledge. It sounds ideal, classical even. The problem? Users don’t read procedures. Read More

I hate the unnecessary inclusion of versus in titles and headings, because it often implies an adversarial relationship where one does not—or at least should not—exist. But, while product managers are often the greatest allies UX professionals can have, in spite of the many positive aspects of our relationships with them, there is some inherent tension between us. They usually want as many features in a product as possible, while UX professionals and developers typically do not want to be held accountable for fulfilling unrealistic expectations of what we can accomplish in a single product release. Read More

In my previous job as a UX designer, I learned the value of collaborative design walkthroughs. During walkthroughs, the UX designer would step through a user scenario—using the wireframes or mid-fidelity prototypes—with a cross-disciplinary team comprising product management, other UX designers, business analysts, developers, product testers, and technical communicators. The motivation for doing these walkthroughs was to reduce the amount of churn around product requirements that was occurring during coding and testing. No matter how well-written a requirement or use case was, it wasn’t until stakeholders could interact with a design within a tangible context that the full implications of a requirement or its lack of sufficient specificity became evident. Read More