This is sort of an off-topic post, obliquely related to things geospatial by virtue of the fact that our geospatial products come with help documentation. As LizardTech’s technical communicator, I attended WritersUA 2009 at the Westin Hotel here in Seattle a few weeks ago. The WritersUA Conference is the annual shindig for user assistance professionals (a.k.a. tech writers and our ilk).
Overall I was impressed, and in a lot of ways. There were over 300 attendees from all over the country, nearly 25 exhibitors and sponsors, and dozens of presenters over the course of three days. There was free wifi throughout the entire conference space, a huge Twitter monitor, and best of all, the opening speaker was Scott McCloud, who has written/drawn award-winning books (“Understanding Comics” et al.) and did the famed Google Chrome comic book documentation.
As is probably normal, the sessions were a mix of things that sounded information-packed and edifying and things that sounded irrelevant, although there were surprises. For instance, the closing session on illusion and mental models by a comedian/hack magician turned out to be one of the most inspiring sessions of the whole conference, as was Scott McCloud’s opener, even though you might have thought cartooning doesn’t have much to do with user help. And one session I was looking forward to turned out to be just bullet points that I might have come up with myself. The most useful session in terms of how to do things better was a session on improving knowledge bases for better troubleshooting.
I think I heard the word “cognitive” at least twice a day, which I thought was significant. It tells you how important the mind of the user is to UA professionals.
In my opinion there was a superfluity of sessions dealing directly with the Darwinian Information Typing Architecture (DITA), an XML language for documentation that the government is mandating wherever it can these days, and there was an inescapable prevalence of tool-specific sessions, lamentable only because most were not about the tools I’m using.
Notes on some of the most inspiring (in one case depressing) sessions:
Opening Session
On Monday morning Scott McCloud submitted to a Q&A session in which he described how the Google Chrome comic came about, what it was like doing it, and how the end result was received (wildly successful, borrowed from and parodied all over the Internet).
The big thing for me in Scott’s talk was the idea of isolation through sequence, which is what distinguishes comics from other drawn art. Few of us would want to turn our help into comics, but the idea of directing the user’s attention by using the same tools the cartoonist uses – removing everything from the user’s focus except what they need to know at that moment – is something that all of our user assistance projects would benefit from. He also talked about how the mind remembers static images more readily than moving ones, and about the notion of “two cognitive altitudes” (context and detail) and the importance of the balance between them.
As for the man as a speaker, I was amazed at the prehensile-ness of his mind. You could tell from the way he listened to questioners and then reframed their questions that his mind was completely wide open like those big dishes in the desert listening to noise in outer space, and when he listens you can see his brain reaching for whatever metaphor or symbol or phrase that will best capture the essence of the conversation. He’s really a technical communicator at heart. If you ever get a chance to hear him, take it.
User-Centered Design of Context-Sensitive Help
Matthew Ellison’s talk was a great intro to context sensitive help (CSH), in which tips or other help-ish material are built into the app, and are either visible to the user as they work or easily accessed by an icon or underlined phrase. CSH is becoming important as UA writers begin to acknowledge that no one reads help unless they are forced to at gunpoint (more on this, unfortunately, below). But more than an intro, it really gave solid best practices. One point that stuck with me was, “focus on answering likely questions rather than documenting the application.” Many times, we tech writers are tempted to write from our model rather than the users’, but again, more anon…
Best Practices for Embedded UA
Scott DeLoach talked about the most useful ways to embed assistance in the UI in exactly the amount and timing (and even phrasing) needed by the user. It seems to be a scientific fact that as long as you don’t call something “help” and it’s right in front of them, users will consult it. Lots of good info here, such as the fact that a novice will eagerly click “Quick tip” while an expert will want to see something like “Tell me more…”. One takeaway: sometimes thoroughness is less important than usefulness. Scott asked us to ask, “What are the things the user HAS to know in order to successfully complete the task?”
Lessons Learned from Research on “Help”
The percentage of users who consult online help and printed help, respectively, are “virtually no one” and “actually no one.” Those are the facts. Professor David Novick of University of Texas at El Paso seemed from the start to want to make us cry, and from the beginning he drilled home the dour and research-supported truth that we’re wasting our efforts. There was no good news to balance this glum panorama, either. It was a dizzying ride through a milky-way of dismal data points, at the end of which he said, “and when they DO use the help, research shows that it doesn’t make users more productive.” We all went out of there and shot ourselves.
Better Knowledge-Base Articles for Complex Troubleshooting
To my lights, the best session of the lot. I’m glad I have the slides, because I could barely keep up with this guy. David Farkas is a professor of technical communication at the University of Washington here in Seattle. He moved through his slides very quickly, rightly using them only as touchstones for the actual content of his presentation, and if you took notes you missed the next thing. David offered lots of good info I will be reviewing, like how to title KBs most effectively, how to structure them, and how to “reduce the cognitive load” on the user’s mind as they troubleshoot problems. He regards the KB’s purpose as a troubleshooting mechanism for “bugs, known issues, things that fall between the cracks” rather than a body of help topics per se.
Magic and Mental Models: Using Illusion to Simplify Designs
Jared Spool’s “magic” presentation on Wednesday was a fantastic end to the conference. It seemed at first to consist of amusing but unsuccessful attempts to read people’s minds, but that was all just a way of demonstrating Kano’s model and the role of delight, which, nutshelled, says that if you get the basic functionality right (things people need and expect), you can add another aspect Kano calls delight. This is a little extra something the user is not expecting. One example he used is that when you attach your iPod Nano to sync it up the image changes to an image of not only the model you have but also the same color. Jared said most users won’t even notice this, but those who do will experience delight.
Jared also explained the difference between the designer’s model and the user’s model this way: none of the Disney imagineers wants a vistor to the haunted house ride to come out at the end and say “Oh my gosh, the speakers around turn #3 were amazing…I have to have that in my house!” The user is supposed to have a model in his mind that says THIS IS A SCARY PLACE, THERE ARE GHOSTS AND HALLOWS IN THERE. (Jared didn’t say “hallows”, that’s my paraphrase.) The designer’s model is different; it’s about wires, mirrors, speakers and other functional components. The point is, we who make products don’t need to explain our model, we just have to make sure the user’s model works.
In the end Jared pulled off a bona fide magic trick and we were all delighted.
What I came away from the conference with was a motivation to reduce the “cognitive load” on our users, give them the assistance they need (and only what they need) when they need it, and finally to delight them.
Our customers deserve all that. After all, they have the world on their shoulders.
Posts
