Blog Otro--
I decided I need to learn Spanish (again-I've decided this about three times now). This time I think I'm going to make it. Why? Thanks to technology I am able to enjoy total immersion within a culture from the comfort of my couch and desk. I watch the news on Univision as I have my morning coffee, and I listen to CNN en Espanol as I drive to work. And most importantly, I've started a blog on Univision.com. http://mipagina.univision.com/mikehughes.
Be sure to visit my alter-ego (as if my one ego wasn't enough!) Between all of these tools plus my translation applet on my Google home page, I'm set to be bilingual in no time.
So the next time you see me, just say Hola! I'll know what you mean.
Tuesday, July 31, 2007
Tuesday, July 24, 2007
A Newsy Blog--
Al Hood announced at last week's STC meeting that I am the "Atlanta Conference 2009 Planning Committee Chair." I remember shooting my mouth off that we needed such a committee. Holly Harkness and Al swear I volunteered. (Personally, I think everybody else took one step back.) On a serious note, I think the 2009 STC conference being in Atlanta is a great event to spur us to re-invigorate our Atlanta chapter, and I'm eager to get some folks together and help make that happen. So avoid making eye-contact with me in the next few months, otherwise you will be chairing a sub-committee. (The COOLEST one will be to organize and man our promotional booth at next year's conference in Philadelphia.)
I have a new column out on UXMatters discussing the benefit of collaborative walkthroughs with user assistance. Give it a read when you get a chance.
I'm on a team right now that will be taking our new user assistance design out to the usability lab at Southern Polytechnic State University next month. They have a great lab out there, and I encourage technical communicators to get more involved in the usability of documentation. One of the most important problems we still need to understand better is the conflict between our desire to produce complete documentation and the user's reluctance to get off task for too long. We are hoping where I work to start a long-term research relationship with SPSU to help us understand the roles user assistance can play in the context of solving problems within software applications.
One more sales pitch: My new book A Research Primer for Technical Communication that I coauthored with George Hayhoe is due out today! OK, it's no Harry Potter, but I do think it demystifies research and sets a practical agenda for defining best practices within our profession. Give it a read (and support my granddaughter's college fund).
Al Hood announced at last week's STC meeting that I am the "Atlanta Conference 2009 Planning Committee Chair." I remember shooting my mouth off that we needed such a committee. Holly Harkness and Al swear I volunteered. (Personally, I think everybody else took one step back.) On a serious note, I think the 2009 STC conference being in Atlanta is a great event to spur us to re-invigorate our Atlanta chapter, and I'm eager to get some folks together and help make that happen. So avoid making eye-contact with me in the next few months, otherwise you will be chairing a sub-committee. (The COOLEST one will be to organize and man our promotional booth at next year's conference in Philadelphia.)
I have a new column out on UXMatters discussing the benefit of collaborative walkthroughs with user assistance. Give it a read when you get a chance.
I'm on a team right now that will be taking our new user assistance design out to the usability lab at Southern Polytechnic State University next month. They have a great lab out there, and I encourage technical communicators to get more involved in the usability of documentation. One of the most important problems we still need to understand better is the conflict between our desire to produce complete documentation and the user's reluctance to get off task for too long. We are hoping where I work to start a long-term research relationship with SPSU to help us understand the roles user assistance can play in the context of solving problems within software applications.
One more sales pitch: My new book A Research Primer for Technical Communication that I coauthored with George Hayhoe is due out today! OK, it's no Harry Potter, but I do think it demystifies research and sets a practical agenda for defining best practices within our profession. Give it a read (and support my granddaughter's college fund).
Monday, July 16, 2007
Encyclopedias do not user assistance make--
One of my colleagues attended an internal training session last week so she could observe how our documentation is used by people doing realistic tasks. Her observations were not surprising, but bear repeating:
One of my colleagues attended an internal training session last week so she could observe how our documentation is used by people doing realistic tasks. Her observations were not surprising, but bear repeating:
- Users had a lot of knowledge already.
- Users tried to solve problems using no help. They started [doing the primary task] without consulting any documentation.
- Users rarely looked at the guides or quick start cards. Documentation was the last resort.
- When using documentation, users gravitated toward the diagrams.
- Users got frustrated when they saw how many documents the [product] has on [our customer support] website.
- Users did not use the Help button on the user interface.
- User assistance has to be useful in small chunks (users don't want to spend time in documentation).
- User assistance has to be specific (users are there as a last resort and will abandon general discussions).
- Information developers should influence text on the UI (since users rarely summon the hidden Help files).
- Information developers need to emphasize informative graphics as much as they can.
- The user interface needs to provide a more compelling access to Help.
In short, Help designs and content development should be less concerned about being complete and in depth and be more concerned about being relevant as soon as possible. Time and time again I see that users go into the documentation as a last resort and when in the documentation, get back into the application as soon as they can. Help needs to look and act more like a performance support system and less like an encyclopedia.
Do the following quick audit:
- Pick any spot on your UI and imagine a likely question the user would have. Click on Help and have an associate start counting out loud--very loudly. How long did it take to get to the answer? How many clicks? Did each click add value?
- Does the Help add value beyond what is already on the UI? In other words, if all you have to say about the customer name field is that's where you put the customer's name, why bother? Seriously, we don't have to fully document our products. Nothing hides useful information better than surrounding text devoid of meaningful content.
- How much of the user's time does your documentation waste by talking about itself? I know your English teacher said to start a chapter by describing its purpose. But I have never seen a user go into a manual to answer the question, "What is chapter two about?" And please, if you take up any space explaining your typographic conventions, users do not care!
- Do you provide meaningful examples or practical guidelines?
- Do you use informative graphics?
Help needs to be quick and relevant. If a topic needs to have the users spend more than thirty seconds, it probably doesn't belong in Help. Because they won't.
John Carroll in the Nurnberg Funnel made the point that training had to accommodate how users really learned. Help has to accommodate authentic user behavior--precisely those behaviors that my colleague observed. Given a choice between re-engineering the user assistance and re-engineering the user, you will be more successful in the long run doing the former.
Tuesday, July 10, 2007
Product Names--
I was helping my wife this weekend brush our dog's teeth. Yes, that's the level of quiet desperation my weekends have gotten to. She brushed and I held. As it was, the dog was pretty calm throughout--probably helped by the fact that it was chicken-flavored toothpaste--so I thought I would read the instructions on the toothpaste bottle, if nothing else as a professional courtesy to the technical writer who had authored them. (A dying profession indeed, Jared Spool, may doggie breath afflict thee all thy days!)
Actually, they were pretty useful, even including a tip to let the dog taste the toothpaste first before going in with a glob on the included brush/finger-mitten. The only problem was that the marketing department had apparently insisted that the writer use the full product name when referring to the toothpaste--and it was a looooonnng name. Seriously, it wrapped half-way around the bottle. Something like PetProper Canine Oral Hygiene Conditioning Paste. I had to read that three times in one paragraph, each time having to rotate the bottle to take it all in.
I'm having a similar problem at work, we have to reference our product in our Help topics, because they are shared with a larger Help file, and the reader needs to know what product each topic refers to. I understand, but why do product names have to be so big? I won't even tell you about the full name, but the SHORT name is going to force users still on 800 x 600 to scroll horizontally!
Solution
Here's the answer. We've all seen the cavemen guys on the Geico commercials, right? These guys are pretty articulate, but they're still cavemen. So they would be masters of monosyllabic speech. Marketing should hire the cavemen guys to name our products. That way, we would have names like "Ug" and "Mook." Easy to type; easy to read.
Or we could tell marketing that Help readers have already bought the product and ask them to give us easier substitutes.
Personally, I'm holding out for the Geico cavemen.
I was helping my wife this weekend brush our dog's teeth. Yes, that's the level of quiet desperation my weekends have gotten to. She brushed and I held. As it was, the dog was pretty calm throughout--probably helped by the fact that it was chicken-flavored toothpaste--so I thought I would read the instructions on the toothpaste bottle, if nothing else as a professional courtesy to the technical writer who had authored them. (A dying profession indeed, Jared Spool, may doggie breath afflict thee all thy days!)
Actually, they were pretty useful, even including a tip to let the dog taste the toothpaste first before going in with a glob on the included brush/finger-mitten. The only problem was that the marketing department had apparently insisted that the writer use the full product name when referring to the toothpaste--and it was a looooonnng name. Seriously, it wrapped half-way around the bottle. Something like PetProper Canine Oral Hygiene Conditioning Paste. I had to read that three times in one paragraph, each time having to rotate the bottle to take it all in.
I'm having a similar problem at work, we have to reference our product in our Help topics, because they are shared with a larger Help file, and the reader needs to know what product each topic refers to. I understand, but why do product names have to be so big? I won't even tell you about the full name, but the SHORT name is going to force users still on 800 x 600 to scroll horizontally!
Solution
Here's the answer. We've all seen the cavemen guys on the Geico commercials, right? These guys are pretty articulate, but they're still cavemen. So they would be masters of monosyllabic speech. Marketing should hire the cavemen guys to name our products. That way, we would have names like "Ug" and "Mook." Easy to type; easy to read.
Or we could tell marketing that Help readers have already bought the product and ask them to give us easier substitutes.
Personally, I'm holding out for the Geico cavemen.
Monday, July 02, 2007
Timberline Hitches and C++
Just went camping for three days with an old high school buddy, who happens to be an experienced scout master and an all-around great camper. He insisted on teaching me how to tie a timberline hitch. He said it was an essential knot and came in handy if you were going to drag a log with a mule. I reminded him I didn't have a mule.
I tried to sign up for a course on Java programming once, but all of the ones I found required the C++ course as a prerequisite. The rationale was that the principles for programming in C++ applied to Java as well. I wondered why they couldn't teach those same principles in the context of Java and not make me take a five-day course in a language I was not interested in.
I'm sure that the timberline hitch was an invaluable knot for pioneers and farmers clearing off land, just as I'm sure that C++ is a really spiffy programming language. I just don't think that I need to know either of them. So why are some insisting that I do?
It comes down to this: "Dammit, I worked hard learning this, and now you're going to sit and listen while I teach it to you."
I think I do the same thing sometimes to my documentation readers. It took me a long time to master some nuance of the software I'm explaining, and dammit, they're just going to have to sit and listen.
Then I wonder where they went. Well, this is for you and the mule you rode into town on--what do you mean you don't have a mule?
Just went camping for three days with an old high school buddy, who happens to be an experienced scout master and an all-around great camper. He insisted on teaching me how to tie a timberline hitch. He said it was an essential knot and came in handy if you were going to drag a log with a mule. I reminded him I didn't have a mule.
I tried to sign up for a course on Java programming once, but all of the ones I found required the C++ course as a prerequisite. The rationale was that the principles for programming in C++ applied to Java as well. I wondered why they couldn't teach those same principles in the context of Java and not make me take a five-day course in a language I was not interested in.
I'm sure that the timberline hitch was an invaluable knot for pioneers and farmers clearing off land, just as I'm sure that C++ is a really spiffy programming language. I just don't think that I need to know either of them. So why are some insisting that I do?
It comes down to this: "Dammit, I worked hard learning this, and now you're going to sit and listen while I teach it to you."
I think I do the same thing sometimes to my documentation readers. It took me a long time to master some nuance of the software I'm explaining, and dammit, they're just going to have to sit and listen.
Then I wonder where they went. Well, this is for you and the mule you rode into town on--what do you mean you don't have a mule?
Monday, June 25, 2007
Maturity or Bureaucracy?--
In his latest Alert Box, Jacob Nielsen talks about the pros and cons of developers doing their own usability testing. For a while, now, Nielsen has had a maturity model that basically states the more mature an organization is about usability, the more independent the usability function is within that organization. Therefore, developers doing their own testing is an indication of low maturity.
I disagree. One of the most mature organizations I ever worked at from a usability perspective was CheckFree Corporation. For one, the concept of ease-of-use was embedded in their corporate mission statement and they had their own usability lab. The lab was run, however, by designers in the UX department. These folks were part of the Development organization and their main deliverable was not test reports; rather it was the wireframes from which the development team coded the product. A salesman for an external lab once asked me how I sold my usability value within the company. I told him I didn't, the only reason I did usability testing was that I wanted the data to see if my designs would work before the marketplace provided that feedback. My company valued my wireframes; I valued the data that informed those wireframes.
Still, there persists this popular belief that usability has really made it when it is an independent department in a company. To me that's like measuring the maturity of an engineering company by whether or not it has an independent department for doing the math. It doesn't make sense for engineers not to do their own math, nor does it necessarily make sense for designers not to do their own usability testing. To say it is not in their basic skill set merely sets up the question, "Why the hell not?"
About 25 years ago I was managing a training department when my company was making the transition from having a department secretary who typed our video scripts to having the instructional designers use word processors. There was almost a mutiny. Today, we see word processors as cognitive tools, things writers use to help compose and organize their thinking--not merely as output devices.
Usability testing should be the same. It shouldn't be something we send over to the usability pool to have done by "those people." It should be a routine task in the course of doing design.
In his latest Alert Box, Jacob Nielsen talks about the pros and cons of developers doing their own usability testing. For a while, now, Nielsen has had a maturity model that basically states the more mature an organization is about usability, the more independent the usability function is within that organization. Therefore, developers doing their own testing is an indication of low maturity.
I disagree. One of the most mature organizations I ever worked at from a usability perspective was CheckFree Corporation. For one, the concept of ease-of-use was embedded in their corporate mission statement and they had their own usability lab. The lab was run, however, by designers in the UX department. These folks were part of the Development organization and their main deliverable was not test reports; rather it was the wireframes from which the development team coded the product. A salesman for an external lab once asked me how I sold my usability value within the company. I told him I didn't, the only reason I did usability testing was that I wanted the data to see if my designs would work before the marketplace provided that feedback. My company valued my wireframes; I valued the data that informed those wireframes.
Still, there persists this popular belief that usability has really made it when it is an independent department in a company. To me that's like measuring the maturity of an engineering company by whether or not it has an independent department for doing the math. It doesn't make sense for engineers not to do their own math, nor does it necessarily make sense for designers not to do their own usability testing. To say it is not in their basic skill set merely sets up the question, "Why the hell not?"
About 25 years ago I was managing a training department when my company was making the transition from having a department secretary who typed our video scripts to having the instructional designers use word processors. There was almost a mutiny. Today, we see word processors as cognitive tools, things writers use to help compose and organize their thinking--not merely as output devices.
Usability testing should be the same. It shouldn't be something we send over to the usability pool to have done by "those people." It should be a routine task in the course of doing design.
Friday, June 22, 2007
Call Me Tina--
Apologies to Holly Harkness for the pun on her blog title. I was chatting it up over wine with my mentor and friend Carol Barnum last night at an alumni social and happened to mention that after my varied career in a number of aspects of user-centered design (usability, training, performance support, UX design) I was happy to be back in the core field of technical writing and user assistance in particular. Carol seemed surprised at that, and given all of the buzz over the last couple of years about how we are so much more than technical writers and how we are moving on to sexier roles, I guess I am somewhat of an anomaly. I was making it in the big city and chose to move back to the farm. We talked a little bit about why.
Putting on the Sneakers
At the heart of it, I suppose, is that I like to write and I am trained to write. Information design and writing are my core skills. So I am glad to be back in my sweet spot. As a UX designer, I was always behind the professional power curve of the likes of, say, a Luke Wroblewski, or in usability trying to keep up with such luminaries as Jared and Jacob--not to mention Carol. Technical writing might not be the biggest pond, but it is one in which I know how to fish pretty well, and there is comfort and reward in that.
The less obvious but maybe more compelling reason is somewhat counter-intuitive: In spite of all of the obituaries on technical writing, it has the greatest job security of all of the fields related to user-centered design. In spite of its being often maligned, Help and other product documentation are must-haves, check-off points in the the product bill of material. Companies don't want to spend a lot on it, but no product manager is going to say, "Let's not offer Help with this application." Companies whose products lack usability can still believe they have it. Not true of documentation. If you don't have it, you don't have it.
The down-side, of course is that companies don't want it to cost a lot, so documentation departments get downsized a lot or doc gets off-shored. For one, I think the off-shoring of customer-facing documentation is a short-lived experiment that shows many signs of failing or at least stabilizing due to supply-demand equilibrium.
Well, what about cutbacks and layoffs? It reminds of the story about the two guys running from the bear. One stops to put on his running shoes (sneakers if you are from the South and older than 50), and his friend says, "Those won't make you faster than the bear." The guy counters, "I don't have to be faster than the bear, I just have to be faster than you."
The point is (yes, please, Mike, what is the point?) although good writers get laid off, they don't get driven out of the business. Keep actively pursuing excellence through education and professional development and you will stay ahead of those who don't. Those are the ones the bear gets.
Apologies to Holly Harkness for the pun on her blog title. I was chatting it up over wine with my mentor and friend Carol Barnum last night at an alumni social and happened to mention that after my varied career in a number of aspects of user-centered design (usability, training, performance support, UX design) I was happy to be back in the core field of technical writing and user assistance in particular. Carol seemed surprised at that, and given all of the buzz over the last couple of years about how we are so much more than technical writers and how we are moving on to sexier roles, I guess I am somewhat of an anomaly. I was making it in the big city and chose to move back to the farm. We talked a little bit about why.
Putting on the Sneakers
At the heart of it, I suppose, is that I like to write and I am trained to write. Information design and writing are my core skills. So I am glad to be back in my sweet spot. As a UX designer, I was always behind the professional power curve of the likes of, say, a Luke Wroblewski, or in usability trying to keep up with such luminaries as Jared and Jacob--not to mention Carol. Technical writing might not be the biggest pond, but it is one in which I know how to fish pretty well, and there is comfort and reward in that.
The less obvious but maybe more compelling reason is somewhat counter-intuitive: In spite of all of the obituaries on technical writing, it has the greatest job security of all of the fields related to user-centered design. In spite of its being often maligned, Help and other product documentation are must-haves, check-off points in the the product bill of material. Companies don't want to spend a lot on it, but no product manager is going to say, "Let's not offer Help with this application." Companies whose products lack usability can still believe they have it. Not true of documentation. If you don't have it, you don't have it.
The down-side, of course is that companies don't want it to cost a lot, so documentation departments get downsized a lot or doc gets off-shored. For one, I think the off-shoring of customer-facing documentation is a short-lived experiment that shows many signs of failing or at least stabilizing due to supply-demand equilibrium.
Well, what about cutbacks and layoffs? It reminds of the story about the two guys running from the bear. One stops to put on his running shoes (sneakers if you are from the South and older than 50), and his friend says, "Those won't make you faster than the bear." The guy counters, "I don't have to be faster than the bear, I just have to be faster than you."
The point is (yes, please, Mike, what is the point?) although good writers get laid off, they don't get driven out of the business. Keep actively pursuing excellence through education and professional development and you will stay ahead of those who don't. Those are the ones the bear gets.
Tuesday, June 19, 2007
Dressing Like a Grownup--
Al Hood posted pictures from the STC conference recently on his president's blog. There was a picture of me "on Mike's one day to dress like an adult." I actually had on a tie and sportscoat because I was a keynote panelist for the opening ceremony.
Well, I'm dressed kind of like a grownup again today, no tie, but an Izod golf shirt, khaki slacks, sports coat, and leather loafers. I'm going to the STC meeting tonight.
Normally I wear shorts, t-shirt, and sandals to work. What's interesting about that is that I work for IBM. When we (ISS) got acquired by IBM, we asked if our dress code would be affected. Their reply was interesting:
Thomas Watson, IBM's founder, established the white shirt, blue tie, blue slacks look because he felt that "IBM people should look like our customers," and in those days, IT folks and accountants looked like that. Well today, our customers wear shorts, t-shirts, and sandals; so I'm right in step with founder Watson's philosophy.
It makes me wonder, though, as a technical communicator, how else have my readers changed over the years, and what archaic misconceptions might I be dragging around with me? Is the user in my user-centered approach to designing documentation still around, or did he retire years ago? Is he now wearing sandals and t-shirts while I'm writing for wing-tips and ties?
If users shift from being task-oriented, for example, to being concept oriented, how would we know? In fact, I suspect they have. A lot of our conventional technical communication wisdom predates intuitive user interface design, dashboards, and such. We still document GUIs as if most of the world still wonders how radio buttons work.
At my last job, which dealt with online banking, one of our sponsors commented that the Internet and email were becoming the technology of "our customers' parents; the new customers want to bank by Blackberry and cell phone."
The whole persona of the user who is intimidated by technology and befuddled by arcane interactivity--in short the user of my user-centered world--is probably going away (gone away?). To paraphrase Pogo, "We have met the user and he is us," is the downfall of all designers. We design and write for ourselves in the belief that our users are like us. Or we write to someone as they were twenty years ago when we first started studying them.
What if they grew up?
Al Hood posted pictures from the STC conference recently on his president's blog. There was a picture of me "on Mike's one day to dress like an adult." I actually had on a tie and sportscoat because I was a keynote panelist for the opening ceremony.
Well, I'm dressed kind of like a grownup again today, no tie, but an Izod golf shirt, khaki slacks, sports coat, and leather loafers. I'm going to the STC meeting tonight.
Normally I wear shorts, t-shirt, and sandals to work. What's interesting about that is that I work for IBM. When we (ISS) got acquired by IBM, we asked if our dress code would be affected. Their reply was interesting:
Thomas Watson, IBM's founder, established the white shirt, blue tie, blue slacks look because he felt that "IBM people should look like our customers," and in those days, IT folks and accountants looked like that. Well today, our customers wear shorts, t-shirts, and sandals; so I'm right in step with founder Watson's philosophy.
It makes me wonder, though, as a technical communicator, how else have my readers changed over the years, and what archaic misconceptions might I be dragging around with me? Is the user in my user-centered approach to designing documentation still around, or did he retire years ago? Is he now wearing sandals and t-shirts while I'm writing for wing-tips and ties?
If users shift from being task-oriented, for example, to being concept oriented, how would we know? In fact, I suspect they have. A lot of our conventional technical communication wisdom predates intuitive user interface design, dashboards, and such. We still document GUIs as if most of the world still wonders how radio buttons work.
At my last job, which dealt with online banking, one of our sponsors commented that the Internet and email were becoming the technology of "our customers' parents; the new customers want to bank by Blackberry and cell phone."
The whole persona of the user who is intimidated by technology and befuddled by arcane interactivity--in short the user of my user-centered world--is probably going away (gone away?). To paraphrase Pogo, "We have met the user and he is us," is the downfall of all designers. We design and write for ourselves in the belief that our users are like us. Or we write to someone as they were twenty years ago when we first started studying them.
What if they grew up?
Thursday, June 14, 2007
Dagnabbit!--
I'm just too old for some of the new design trends, and I'm starting to mutter at my PC sounding like my Aunt Hattie (bless her heart). I'm back on my soap box about how affordances are going out of vogue with interaction designers in favor of pliancy. One more time in English:
Affordance is the quality an object to look actionable by the nature of its appearance. A graphic of a button with the word Submit on it has a lot of affordance. The convention of underlining a link and putting it in color is so ubiquitous that it has become an affordance.
Pliancy is when an actionable object changes appearance when you mouse over it.
I was on Boxes and Arrows (a premier site on design), and I wanted to read the article "Comics: Not just for laughs!" in the snapshot above. I kept clicking on the author's name, and I kept getting a bio of the author. Finally I moved my mouse incidentally over the name of the article and voila! it turned red and was underlined.
Why does the most important action a user would want to take (open the article) not have an affordance while the links to the author's bio and comments on the article have them?
This is like so Web 2.0 where the user is expected to explore the page in order to discover its functionality as if it were a PlayStation game. I'm feeling ancient.
I know, don't talk, Mike, with your mouth full of Metamucil.
Monday, June 11, 2007
Holly's Back--
For those who missed Holly Harkness's transition from her President's blog, her new blog is: http://dontcallmetina.wordpress.com.
For those who missed Holly Harkness's transition from her President's blog, her new blog is: http://dontcallmetina.wordpress.com.
Just got back from a week at the beach playing with the grandbaby and mastering boat drinks made in a blender--IOW, feeling pretty calm and mellow.
There are a couple of reviews of this year's STC conference on UXMatters .
I wrote this one: http://www.uxmatters.com/MT/archives/000197.php It's pretty positive, but I do imply a certain industry guru is standing in elephant poop based on a comment he made in his blog.
This one takes the conference to task, but did have nice things to say about my presentation: http://www.uxmatters.com/MT/archives/000196.php
All in all, minor quiblings aside, all views seem to point to exciting possibilities for our profession and how it is converging with other user-centered disciplines. We are writers, hear us roar, kind of stuff.
There are a couple of reviews of this year's STC conference on UXMatters .
I wrote this one: http://www.uxmatters.com/MT/archives/000197.php It's pretty positive, but I do imply a certain industry guru is standing in elephant poop based on a comment he made in his blog.
This one takes the conference to task, but did have nice things to say about my presentation: http://www.uxmatters.com/MT/archives/000196.php
All in all, minor quiblings aside, all views seem to point to exciting possibilities for our profession and how it is converging with other user-centered disciplines. We are writers, hear us roar, kind of stuff.
Tuesday, May 22, 2007
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.
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.
Monday, May 21, 2007
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:
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:
- What is the intent of the screen?
- What are its primary objects (what should the user look at)?
- What are the traits or attributes of the objects?
- How do you weight the objects?
- 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:
- What's a good starting value (or what influences the starting value)?
- When would you make it higher?
- When would you make it lower?
- What happens if it gets too high?
- What happens if it gets too low?
- 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.
Friday, May 18, 2007
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:
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 :-)
Tuesday, May 15, 2007
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.
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.
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:
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.
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.
Friday, March 30, 2007
Tuesday, March 20, 2007
Chinking--
I've created a new term, chinking, to mean:
I've created a new term, chinking, to mean:
- Breaking a topic into atomic chunks and then making the user get to them through individual links. Also,
- Chunking these mini-links into a page of virtually nothing but links (typically introduced with an anemic stem sentence)
Essentially, it's Information Mapping as practiced on the planet Bizzarro.
Structured writing approaches, such as Information Mapping and DITA, assert that a topic should be self contained. That means that it has to have enough depth and breadth to satisfy a reasonable need for information. Some user assistance writers take modularity to too granular a level and thus undermine the ability for a topic to stand on its own.
Chunking good.
Chinking bad.
Wednesday, March 14, 2007
Is It Help or Is It a Pop Quiz?--
I love the Southern expression, "Bless their hearts." It's kind-hearted, but with a tinge of self-righteous superiority. As in, "They're doing the best they can, bless their hearts." It's also sympathetic with no commitment to be helpful. As in, "Can't log into the critical network drive that has all your work stored on it? Bless your heart." I think error messages should end with it. "System 404 error, website can't be found, bless your heart."
I went into a Help file recently trying to get help about an application. I used the context-sensitive link expecting to learn more about the page I was on. I got a page with an anemic stem sentence with seven links. I wasn't quite sure which one would help me so I guessed and clicked one. It expanded into five more links. They were trying their best to help me, bless their hearts.
But my response was not one of gratitude. What I wanted to say was, "Hey, who's supposed to be asking the questions, me or you?" Since the Help screens that were being 'anything but' were part of a Help system I am working on, I get to roll up my sleeves and do something about it.
So we are now working on a new architecture, one that emphasizes giving useful information on the first click and then offering a simple, two-path fork: One that gets the user directly to the task information (procedure) and one that takes the user to a guidelines topic. Each of those topics can have more links on them (for example, extended background topics linked from the guidelines topic), but by then the users are smarter and can understand their choices better.
On simple screens, we can make either the guidelines topic or the task topic part of the initial information screen. (In those cases, if the UI is self-explanatory, consider making the guidelines topic the first topic and link to the task topic from it.) On complex, multitask screens, such as multitab screens, the Help link could open a topic that has a Tab/Description table. For each tab description, provide the double link, i.e., task or guideline.
Principles
I love the Southern expression, "Bless their hearts." It's kind-hearted, but with a tinge of self-righteous superiority. As in, "They're doing the best they can, bless their hearts." It's also sympathetic with no commitment to be helpful. As in, "Can't log into the critical network drive that has all your work stored on it? Bless your heart." I think error messages should end with it. "System 404 error, website can't be found, bless your heart."
I went into a Help file recently trying to get help about an application. I used the context-sensitive link expecting to learn more about the page I was on. I got a page with an anemic stem sentence with seven links. I wasn't quite sure which one would help me so I guessed and clicked one. It expanded into five more links. They were trying their best to help me, bless their hearts.
But my response was not one of gratitude. What I wanted to say was, "Hey, who's supposed to be asking the questions, me or you?" Since the Help screens that were being 'anything but' were part of a Help system I am working on, I get to roll up my sleeves and do something about it.
So we are now working on a new architecture, one that emphasizes giving useful information on the first click and then offering a simple, two-path fork: One that gets the user directly to the task information (procedure) and one that takes the user to a guidelines topic. Each of those topics can have more links on them (for example, extended background topics linked from the guidelines topic), but by then the users are smarter and can understand their choices better.
On simple screens, we can make either the guidelines topic or the task topic part of the initial information screen. (In those cases, if the UI is self-explanatory, consider making the guidelines topic the first topic and link to the task topic from it.) On complex, multitask screens, such as multitab screens, the Help link could open a topic that has a Tab/Description table. For each tab description, provide the double link, i.e., task or guideline.
Principles
- Don't make the users click through a link farm before they get to anything useful. Give them insight into the application at their entry point into the Help system.
- Don't overload the user with decisions at their entry point into the Help system. Expand their choices as they travel the drill-down path.
Subscribe to:
Posts (Atom)