Monday, April 16, 2007

Design for the Primary User Assistance Experience--
How do you architect a Help experience? Well, the common wisdom is to design it around the user tasks. But what does that that really mean and how do you implement such a design strategy?

Let's start by asking how a user gets to a Help topic. There are four ways:
  • Through a context-sensitive link on the user interface itself
  • Through the Help table of contents
  • Through a link from another Help topic
  • Through a search/index results list

Alan Cooper, author of The Inmates Are Running the Asylum, points out that design works best when it targets a specific user. I think a similar idea for Help design is appropriate: Decide which of the four access points is your critical user experience and then optimize your design for that experience.

I think the most important user assistance experience is what happens when the user clicks the context-sensitive link. The user is on task and the Help needs to be focused and useful so that the user can get back on task as soon as possible.

The product I am working on now has page-level context-sensitive Help for every page in the application. We are designing and developing "task support clusters" around every one of those entry points. These are the critical conceptual, task, and reference topics designed specifically to support someone who has clicked on Help from a page-level Help link or button. The first topic the user gets is typically one we call a "keystone concept," a blend of what does this page do, show me an example, give me some tips--whatever seems most appropriate for someone being on that page and asking for help. Part of that keystone concept includes links to task information as well as higher level and deeper level conceptual topics. After designing and while writing the task support cluster, accommodate the other ways those topics could be accessed. Here are some implications:

  • Don't put navigation and obvious UI interaction information on the keystone concept topic.
  • Don't burden the users with a link farm right away that overwhelms them with new choices to make. Add value at every click; this first click should give valuable insight that the user can apply.
  • Make sure that the user can link to navigational information from conceptual topics in case those topics are accessed through the TOC or other non-UI links.
  • Put the appropriate task, reference, and additional conceptual links on the bottom of the keystone concept topic. When choosing how advanced or how elementary the available topics should be, assume the user was smart enough to be in the application at a fairly deep level to begin with.

The last bullet point is a key to staying parsimonious with your links. If your Help provides basic domain educational topics (for example, Firewalls 101) , collect them in their own "book" and put it in the TOC. That way, you can link to the book from a task support cluster and not provide a lot of distracting links and unnecessary navigation within the Help file for someone who is on task.

Finally, let the TOC emerge from an analysis of the content this task support approach creates.

Friday, April 06, 2007

Iterative Design and Big Boxes--
A couple of decades ago, at the early part of my technical communication career, I developed and delivered installation and maintenance training for industrial equipment (specifically, hot melt glue machinery that went on packaging lines) . Part of my job included setting up equipment for lab exercises, which required plumbing hydraulic and pneumatic lines and solenoids and such. My technical background is in electronics, so this hydraulic and pneumatic plumbing aspect was a challenge for me. Basically I had a small box of fittings and connections, and if I needed to get part A plumbed to part B, I found a fitting that went on part A and kept going into my box finding and connecting fittings until I had a jerry-rigged arrangement that ended with a fitting that matched part B. It worked.

I then had an opportunity to visit a Procter and Gamble plant in Lima, Ohio, where they were completely refitting a production line. I was thrilled; I was going to get to see how a by-gawd union pipe-fitter for a major packaging plant did it. I showed up; the union pipe fitter showed up; she had a BIG box of fittings that she kept digging into until she had an arrangement that fit on part A on one end and part B on the other. My reaction was, "Well I'll be damned!"

I moved on, away from hydraulics and pneumatics and into the more rational word of software applications. I was committed to the belief that thorough planning and design could create efficiently producible documentation that was user-friendly. Twenty years later I am a user assistance architect with a PhD working for IBM. What does that mean? I now have a BIG box of tools and patterns that I fish around in, but basically I still get from A to B by looking for what fits and doing a lot of trial and error.

But at last I think I get it: That's the way design happens!

I now give myself shorter planning windows and plan on doing frequent iterations to get it right. I fiddle less with planning tools and more with wireframing and rapid prototyping tools. My mantra is learn fast, fail early. Get something that you can play with, interact with, and show others as soon as possible.

This is not a natural behavior for technical communicators; we have this notion that things we develop should be accurate and complete (and even look good). Well, eventually, they should be, but not at first. To do collaborative, iterative design, we must create cultures where we show first drafts and half-baked ideas to others and not worry that we will be judged by their flaws and inadequacies. We must be willing to let others share their early drafts with us and not judge them for their lack of quality that can come only with polishing. There is little time for polishing at the early stage of design, and besides, you'd be polishing a lot of stuff that eventually gets thrown away.

Don't stop analyzing and planning, just recognize that the real creative breakthroughs come from building and kicking what you've built. The earlier you can do that and the more iterations you can take it through, the better the final design will be.