New Column--
Please see my column in the current UXMatters. It is called The Anatomy of a Help File and discusses how user-centered Help can be developed iteratively.

Patterns for Interviewing SMEs--
At this year's STC conference, I attended a presentation by Larry Todd Wilson on Knowledge Harvesting. Larry is a knowledge management consultant who specializes in capturing knowledge from experts. Larry talked about patterns of interviews he would use, based on the situation he was in. One pattern that seemed appropriate for investigating software application screens that serve as status or dashboards was this one:

1. What is the intent of the screen?
2. What are its primary objects (what should the user look at)?
3. What are the traits or attributes of the objects?
4. How do you weight the objects?
5. How do you integrate this screen into your decision making?

Another pattern I have found useful for investigating screens that require the user to enter a numerical parameter is the following:

1. What's a good starting value (or what influences the starting value)?
2. When would you make it higher?
3. When would you make it lower?
4. What happens if it gets too high?
5. What happens if it gets too low?
6. What indicators (e.g., reports) would you look at to evaluate if your choice was too high or too low?

I think as an industry, we would be well-served if we could categorize a set number of patterns like this to help us interview SMEs. If you have any useful patterns, please send them to me and I will share them.

Breathe in, breathe out--
In my last blog I spoke about the importance of collaborative walk-throughs, and I wanted to reflect a little on what behaviors seem to make them more effective.

In a sense there are two complimentary activities that should occur in a collaborative walk-through in the early phases of a project:

• On the one hand, you want to uncover and illuminate a diversity of approaches and opinions.
• On the other hand, you want to get convergence around a set of standards and best practices for going forward.

Opposing goals? Not at all, it's more like the breathing in and breathing out that sustains life. Both are necessary. And to ride the metaphor a little longer, just as individual stress can be managed by seeking a rhythmic balance to one's breathing, collaborative stress can be managed by trying to seek a good balance between diversity-seeking and convergence-reaching.

Diversity-seeking needs to be openly valued and encouraged. Differences need to be viewed as the natural outcomes of multiple perspectives and not as competing ideas. Phrases such as "I disagree" or "You're wrong" need to be replaced with "I did it a different way," or "I see the probelm a little differently."

Convergence-reaching is the necessary coming together around an agreed upon standard or way to do something. A good exercise during a walk-though is to conduct a claims analysis on each different approach, that is, articulate the positives and negatives of an approach. And ALL approaches have positives and negatives. Concise must be balanced against incomplete, accurate against pedantic, good for novices versus inefficient for experts, etc. Bear with the following anecdote for an illustration.

The Shark
When I was ten years old, my brother and I were swimming in the surf at Gulf Shores. There are certain events in your life that cause what I call "moments of crystal clarity." A shark's dorsal fin breaking the water (when you are a swimmer) is one of those moments. Well, that happened to us and we were doing a nightmarish run through waist-high water trying to get back to shore. With safety just yards away, we were suddenly confronted by a viscious dog on the beach. To make matters worse, the dog had only three legs, thus adding credence to the bad feeling we already had about the shark. Shark behind us, dog in front of us...and then it happened, an insight of crystal clarity: We had to find the depth of water that was too shallow for the shark and too deep for the dog. We did and we walked home safely. This summarizes for me what is the essence of design, finding the right path between the shark and the dog, and claims analysis is a good way to get there.

More reflection later, the day job calls and I can see the fins and hear the snarling already :-)

Team Writing--
My current project has four writers dividing up the contents for a Help file in our belief that nine women could have a baby in one month if properly managed. Our motivation is to try to get an initial Help file delivered to QA at the same time the product first goes in for testing. Just to make it more challenging, this is the pilot project for our transition to DITA and our first release out-of-the-gate since becoming part of IBM. To heck with the proverbial adage of eating an elephant one bite at a time. For some reason I thought eating an entire herd would be the way to go. We bundled new release content, new (for us) IBM styles, new authoring tools, new publishing and deployment architecture, and a new information development methodology. Just reading that sentence back to myself has been liberating; it explains the general sense of anxiety I have been feeling and the sleepless nights of late. (It also explains my lack of blogging activity of late--I've actually been working the day job!)

Whether we survive the journey (let alone be successful) aside, I'm amazed we have gotten this far and are still alive. An important element for having gotten where we are is that we have recognized and accommodated the organic aspect of a team and the value of information in context. By that I mean that a team must learn as a team and that learning must occur wrapped around tangible examples and solutions.

We started by commandeering a small conference room and declaring it to be our project's "war room." We worked in weekly iterations, setting the goals for the next week's iteration at the end of the current week. Most importantly, we set up standing war room meetings four days a week for one hour each. In these meeting we shared tool and methodology lessons learned, white-boarded architectural issues, and discussed progress toward project goals.

When we started getting to the point where we were developing content individually, we scheduled formal walk-throughs in a larger conference room. We set up a projector and each day a different writer did a show and tell of what he or she had done. We looked at the product being documented, the Help the writer had developed, and the underlying XML structures the writer had used to identify the semantic content. We added an editor to the team at this point as well.

What I have learned most of all is that even though the daily war room meetings were absolutely necessary and were very productive, we would not have converged nearly as well without the walk-throughs. I must admit that they were stressful at times, having that many peers question almost your every decision, but that is where we became aware of the many different ways a writer could look at something and see it differently. The thrashing around in the walk-throughs is where it all got sorted out. And the range of the discussions was unbelievable, at times tackling high-level architectural issues, at others dealing with the necessary style minutia that does not become apparent until four different writers tackle what is essentially the same document. The importance of an editor at this point cannot be underestimated, acting at times as researcher and historian ("This is how we've done it in the past, this is what the IBM style guide says") and as referee at times.

Had we all hunkered down and stayed in our cubes cranking out content, our project would be a literary platypus of mismatched styles and informational structures. This was an important lesson for us because our traditional approach had been more of a writer-document specialization approach. Certainly easier to manage and maintain consistency, but one that lends itself to a waterfall convergence of documentation at the end of a project, and not as useful in an iterative, early blending of product and documentation we have been trying to get to.

In the next several blogs, I will try to capture some team dynamic guidelines I have learned through all of this.

Stay posted.