Wireframing--
I don't think that wireframing user assistance is probably a common skill among UA writers, since the user interactions are largely defined by the authoring tools. I certainly never routinely did wireframes until I became a UX designer and was designing the user interface for the application. As UA becomes more integrated into the user interface, however, and as user interactions within the UA become more complex or application-like, e.g., Wizards, wireframing should become a routine activity for UA Architects and Information Designers.

The purpose of the wireframe is to show the layout of the elements within the User Assistance Interface, describe their content or presentation rules, define how the user can act on them, and how the system should respond to those allowable user actions. The wireframe is, in essence, the blueprint that communicates the following:

• Tells the UI developer how to present the UA--in all of its possible states
• Tells the technical writer what kinds of content needs to be provided
• Tells the QA tester how the UA interface behaves

What the wireframe does NOT show is the actual content delivered. It might not even define the source(s) of the information--that might be better described with an information flow diagram.

Tool Talk
Wireframes can be built with a number of tools: Visio, special wireframing software such as Axure (see www.Axure.com for a free 30-day download of a very useful wireframing tool), or even PowerPoint. Using the action buttons and hyperlink tool in PowerPoint allows you make a fairly robust demo/prototype of how the user interactions would work.

For the project I am doing now, I first used PowerPoint to experiment with user actions and system responses, using sample content to do reality-checking on the user experience. I then did production-level wireframes in Visio, using placeholders and lorem ipsum text to illustrate content. I used the Software/Windows and Dialogs stencil to show the UI and the UA components. For each view or state I used two pages, one to show the UI wireframe and a second one to document the elements and interactions. On that second page I used an object table that has the following columns:

• The callout number I use on the wireframe for that element
• The name of the element
• The user action
• The system response
• Comments

I have created a row with those elements that I have stored as a widget in my custom stencil. I drag that widget onto the wireframe, document the element, and then cut and paste the row to the object table I am building on the following page. I have found this to work better than what I used to do, that is, try to document the wireframe with notes on the same page as the wireframe. That just got way busy and limited the information you could put in the note. The down side is that you have to have two pages in front of you to understand the page's look and interactions.

A tool like Axure has a more friendly approach, allowing you to see an element's notes while still viewing the wireframe, but it has the same downside as above if you want to see the notes of several elements at once. It has an additional limitation of not letting you edit your notes if you are viewing multiple elements (in its Word document output). This is a pain if you are editing your notes for things like consistency, e.g., did I hyphenate single-click in the other notes or not? Hey! We're tech writers; we worry about stuff like that :-)