Column: User Assistance

A project management instructor told me that, if there were unlimited resources and no deadlines, there would be no need for project managers. This general principle applies to many aspects of human endeavor: If there is no tricky path for you to navigate between a rock and a hard place, anybody can do it. So, why do we need you?

Fortunately, UX professionals often find themselves having to negotiate conflicting goals, looking for that sweet spot that optimizes the end result. However, working in software development, I have found two dimensions of conflict that are particularly challenging from a UX perspective:

1. convention versus innovation
2. control versus freedom

I like to think of these as knobs, like the bass and treble knobs on my radio. You can’t move in one direction without going away from the other, and you generally want to find some point in between the two extremes. Read More

All UX professionals, not just user assistance developers, face the problem of integrating their work into the product development lifecycle. At lower levels of organizational usability maturity, too often, the contributions of User Experience tend to be reactive. Usability professionals test the usability of a given product, then designers mitigate any shortcomings they find, and user assistance developers merely document what is already there. This column takes a look at the full scope of the product development lifecycle and how UX professionals can add value.

Figure 1 shows a simple view of the product development lifecycle. You could certainly define more fine-grained phases, but the four phases I’ve shown capture most activities to which UX professionals can add value:

1. requirements definition
2. design and validation
3. development and testing
4. deployment and support

Read More

A theme I deal with a lot, both at work and in this column, is organizations’ asking user assistance (UA) developers to support more products with fewer resources. For UA developers who are experiencing a resource crunch, the obvious solution is writing less user assistance for a product than we would have produced in the past. (See my UXmatters column “Hockey Sticks and User Assistance: Writing in Times of Resource Constraints.”) But that still leaves the problem of how to write less and cover users’ information needs adequately.

Everett Rogers’s seminal model of the technology adoption process [1], charted in Figure 1, suggests an approach that might let us put the proverbial 10 pounds of content into a 5-pound bag of writer capacity. Rogers noted that the phases of technology adoption correspond to its adoption by distinctly different classes of people, who accept new technologies at different paces. Read More