Why do people listen to me?

And more importantly, why will they listen to you? I find myself mentoring writers who would like to get published or speak at conferences, and I notice that most have the same reticence: "I don't have anything important or new to say."

Yesterday I read my speaker's bio for the upcoming UA Europe 2009 conference and felt quite abashed. (The one in my preconference workshop description was even more 'abashing.') My initial reaction was "I've got to meet this guy." Like those who seek my advice on speaking and writing with authority and influence, my reaction was "I don't deserve those words." It reminded me of the first time I spoke at a WritersUA conference where I had one of the big rooms. I saw my title slide on a screen that was bigger than the flag backdrop in the movie Patton, and I wanted to tell the audience that what I had to say did not deserve a screen that big.

So I pondered all this on my drive to work this morning and asked myself how I had become a pundit. Actually, it's an important question because all technical communicators are in the business of speaking with authority and influence, and often we feel inadequate in the role. Like who am I to be writing about firewall rules in a help file meant for network security professionals?

The following curve came to me on I285 (it was rush hour and traffic was slow). The best part is that I got to see my love of bell curves and Sufism converge.

Click graph to enlarge

Pundits are not the leaders of the pack. In the adoption curve, I've always come into the party pretty late in the game [sound of mixed metaphors colliding], but that is where the pundit adds value. Up to that point, the innovators and early adopters have been tightly focused on details. In a way they are like the blind men in the Sufi tale, each feeling only a part of the elephant. Only someone joining in late can see the elephant as a whole. It is the role of the pundit to say "It's an elephant."

How do the innovators and early adopters react to this? "Duh, no lie, Einstein."

How do those coming behind the pundit react? "Wow, that is so cool, I get it."

The secret is to not compare yourself to the really smart people who have gone before you--that is way depressing, trust me. Instead, look at what you can offer to those coming behind. And incidentally, look at the area of that curve! What? 100 million people who can benefit from technology such and such, and a third are already doing it? That's 33 million folks in line ahead of you. Oh wait, that's 67 million behind you.

So recognize that as a technical communication professional, you're getting involved with products and technologies often at the sweet spot: Early enough to have a sizable audience that's not there yet, and late enough to have the vantage point to be able to see the elephant in the details.

Write about it, speak about it, let yourself get a little recognition for it. Just never quit blushing at the sales hype about you and wanting to "meet THAT guy."

How to improve the UI--really!

A colleague has made me realize that user assistance writers are codependents of bad UI design. Because we explain how the UI really works, we somehow leave our developers and companies feeling like they're "covered" when the users have a bad experience.

We're not covered; the users still had the bad experience. It's just that we can apply the "nanny nanny boo boo, you should have read the manual" defense.

A simple example is the Delete button. Because of bad design practices, it has two meanings in many software applications: "Hasta la vista, baby" as in gone, gone, gone, and "Removed from here and put somewhere else in case you change your mind" as in the Recycle Bin. Because of that ambiguity, we had a discussion at work about the need to explain in the context sensitive help exactly which Delete we meant on a particular dialog box.

But why is the UI using the same word for two very different actions in the first place?

So here is my new challenge. What if Help quit explaining how to interact with the UI and quit telling the users how the system would respond? What if that became the burden of the UI itself to make interactions clear and outcomes predictable? Better labeling, embedded text, useful tool tips, etc.

What would technical communicators do? What would Help do?

For starters, technical communicators could help write UI text. Then we could reserve Help for scenario type of topics, ala how to achieve some business outcome using the product or encourage users to attempt complex tasks by demonstrating their value.

But we have to break out of our codependency first. Part of me likes to document the obvious because it's easy; part of me likes to compensate for bad design because it gives me instant "I add value" gratification.

Sometimes being part of the solution just makes us part of the problem.

New column and lessons from the Dobro

I have a new column out in UXmatters: Architecting UA for Reuse: Case Examples in DITA.

Although I have owned a Dobro-like guitar for some years now, I just now got around to actually "studying" the correct techniques. Man! I had it all wrong. But the experience reminds me of a point my usability mentor, Loren Burke, used to make all the time. He observed that a common learning pattern was:

1. This is easy.
2. This is hard.
3. This is easy.

I see/hear a new song on Youtube or on one of the instructional links and think, "Oh I can play that." I then start to learn it and find that the picking patterns are awkward and the guitar sounds like a pig being tortured. I was three days into a half-minute rendition of "Will the Circle Be Unbroken" and sounding like someone putting thumbscrews to Porky. Then I woke up Sunday morning, picked up the Dobro, and voila! I could play it.

So it looked and sounded easy as a naive novice; it became hard as a struggling novice; then suddenly expertise emerged and it was easy!

So how does user assistance help move a user from the naive "this is easy" to the expert "this is easy"?

I don't have a good answer to that one yet, but I know this: The secret to learning to play the guitar well is to enjoy playing it badly. This seems counter-intuitive, but the point is that you can only achieve the second level of "this is easy" through practice, practice, practice. So you have to somehow enjoy that "this is hard" period enough to keep coming back and eventually work through it.

So how do we convert this principle into a working model for product skills where users do not want to invest time and energy in the "this is hard" phase?

My hope is to figure that out and get rich. In the meantime, I'll enjoy that slide up on the B string to G and the following back roll drone for a while before tackling some new way to make Porky screech.

A Birthday Poem

I am three score years upon this earth
This twenty first of May aught nine,
I pause to contemplate the worth
Of twenty-one thousand, nine hundred and fifteen days of mine.

In looking back at the seeds I've sown
It's clear that friends too few were gendered.
But the worth of those whose love I've known
Makes them all the better remembered.

So now to all who dealt me kind
So now to all who shared their ranks
Apologies if with absent mind
I have been slow in giving thanks.

Wow! What a Summit

I can't remember a more exhilarating STC Summit. Congrats to Alan Houser for pulling off a great event. The two keynotes were delightful and informative--making me excited about being a technical communicator. Unfortunately, my official duties didn't let me take in too many of the technical sessions, but I networked my little heart out.



Some IBMers at breakfast. By popular vote (at 7:30 a.m.) we decided it would be an IBMer happy hour next year. (l-r: Terri Whitt, Robert Anderson, Barrie Byron, Mike Hughes, Lori Fisher, Alyson-Kathleen Riley, Susan Becker, Mark Wallis)


Me with my fellow Fellows from IBM, Andrea Ames and Lori Fisher. It's good to be a Fellow :-)

Use Cases Are Working

Just in the nick of time, as my boss and I are putting finishing touches on our PowerPoint slides for our presentation for the STC Summit "Moving Documentation Upstream with Use Cases." The theory was that if we used use cases as our Information Development user analysis methodology, we could get involved earlier in the development process and even be able to influence design decisions.

We've had some intermediate successes but it has been hard to insert ourselves at the point in the process where we think the use cases can be the most effective. We recently tried with a project that probably comes as close to the perfect scenario: right team, right changes on the UI, good timing, etc. We had one design meeting last week where we collaborated among product developers, UI developers, information architects, information developers, and QA to understand why a user would view system statistics from the home page of one of our security appliances. The discussion last week was productive and helped form a better team vision of what the user would be doing and why (shifting the team from their normal approach of "What data do we have and how do we want to display it?").

This week the information architect ran a collaborative session where he did a sticky notes on the wall kind of card-sorting exercise that started matching "kinds of data we have" to "things the use wants to do with data" (essentially the use case titles we arrived at in last week's meeting). In a word, it was exciting!

The best part was at the end of the meeting where I asked the developers to accommodate room next to the graphs and tables for embedded user assistance to set the context for the user, based on the insights that had come out of the workshop. The developers agreed that at a minimum we could have fly-over text, pointing out that graph sizes would make real estate hard to come by.

I know this might sound trivial, but to be having discussions about what embedded assistance the designers and developers would accommodate this early in the project was HUGE! The fact that we got a concession of any type was MAJOR!

I hope those of you who are coming to the Summit will come hear our presentation and watch our demo:

Moving Documentation Upstream with Use Cases

Date: Monday, May 04, 2009

Time: 3:00 PM to 4:30 PM EST

Location: Hanover AB

Description

How to apply case methodology and structured writing to get information developers involved earlier in the design process and to produce testable information products earlier in the development cycle.

LEARNER OUTCOMES:

• Create UML use case diagrams and write use case descriptions
• Describe a systematic process for going quickly from use case diagrams to user documentation
• Describe the benefits of involving information developers early in the design process

Chase the rabbit down a hole...

And find a time vampire!



All I was supposed to do was fix some capitalization issues with our new DITA build. It was picking up a title attribute it had ignored in previous versions and I just had to edit the Navtitle attribute in about 100 references.

But there was a nitty little anomaly in how the css was rendering some paragraphs. Probably just a tweak needed here. Tweak, tweak, build...hmmm no that didn't get it. Time to move on and do what I came to do: fix capitalization. Oh wait, I wonder if this other little tweak will do it.
...
Two hours later, still renders wrong in some paragraphs and let's see, how many more topics do I need to edit? Oh, the 100 or so I haven't touched in the last two hours.

I should know better; we all should know better. As it was, I kinda got pulled into this quick sand pool by a buddy who had already been thrashing in it for a day. But we get sucked in by this never-ending thread of "just one more thing and it should work" morass.

Lesson learned. That rabbit looks so easy to catch up with when it jumps down that hole.

Be scared of the rabbit that goes down a hole; be very, very scared.

Miscellany

Everytime we pass a restaurant that has gone out of business and been converted into office space, my wife comments that they must have one really great employee break room. Wow! A break room with a walk-in freezer, pizza oven, and deep fat fryer.

Howard Speck added some really great rules to my earlier blog Why did it take me so long long to learn... I especially love "Never argue with an idiot, people watching can't tell the difference." I'm having that one printed on a card and carrying it with me!

The Atlanta STC Awards banquet is tomorrow! My wife is at a business meeting all day which means I will have to get dressed in my tux all by myself.

The STC Summit starts a week from Sunday--in Atlanta!! We have a local chapter cookbook we will be selling that is a MUST HAVE for anyone attending the conference. My favorite excerpt: "You know you're a Southern technical writer if you put in a comma where you want the reader to pause...and spit."

Actor Mug Shots

Click picture to enlarge it.

Why did it take me so long to learn...

• Never write an email response when I'm angry. Waiting 24 hours can mean the difference between a relationship-straining diatribe (and looking whiny) and a rational appraisal of a situation with reasonable recommendations.
• Don't use "Reply All" to show others how smart I am by taking on [whatever, whoever]. I now limit my distribution of "I think you did something wrong" e-mails to the individual. The serendipity is that half the time I'm wrong, and I'm saved the public embarrassment of their "Reply All" that makes that obvious to the world. I took a course in grad school that helped me analyze my interaction style. I titled the summary paper that described my newly found insight "You're Wrong and I Must Warn the Others." If that describes how you interact in groups, you might want to put it on your list of "things to work on." (BTW--I'm still working on it.)
• When having to choose between the best solution (as defined by, uh, me) and a consensus, go for the consensus. The theme of me being wrong half the time applies here as well--the compromise is not such a compromise since half the time (at least) my best solution would have been wrong.
• Don't squander the opportunity to lose an argument.
  

Doh!

It's April Fool's day and Google got me early. I took a link at the top of my email to New! Gmail Auto Pilot

Layoffs

The news this week was that IBM laid off 5000 workers in the US. Some take-aways for me:

• No matter how strong you are, you can't be stronger than your customers. IBM looked at the numbers and said we need to be leaner in the coming year. Anyone watching the news could have seen that coming.
• When you work for a good company, good people get laid off. Why? Because there aren't any bad people to lay off. Those of us who kept our jobs need to reflect on that with a bit of humility.
  
• In a bad economy, avoid specialist roles like "special adviser" or "ombudsman." If you're out there all alone on an org chart, well, it's as good as wearing a target. Avoid being an infrastructure person; try to be writing words someone is ultimately paying for (i.e., user-facing doc).

I got some insight from our director about how this sort of thing works. I'd seen it from the inside before, but his clarity gave me fresh insight.

It starts at high-level management as a dollar amount. "Our income and our burn rate are misaligned by this much, therefore we need to cut x dollars." Payroll is the deepest pocket, so that's where you have to go if x is a big number. Then middle managers do some calculations and x dollars is translated into y headcount. From then on, y becomes "the number." Lower level managers divvy up y among even lower level managers until some sub-component of y is communicated to a line manager who must convert that number into names, that is, actual people who have to figure out how to make mortgages and buy food.

It's a cold calculus and a heartbreaking one that gets more so as the process trickles lower and lower. It probably works because the ones at the top who have to start the ball rolling are insulated from the humanity where the ball lands.

So if you lose your job, take some solace in the coldness; it was never about you and it wasn't because of anything you did. If you keep your job, it doesn't mean you are better than those who didn't, just luckier, perhaps.

May we all be lucky.

Because I said so

A colleague sent me a link to a blog by someone leaving Google. The person joined Google seven years after it had been founded as its "first visual designer." He refers to himself as a "classically trained designer" and contrasts that to the other designers at Google, who had backgrounds in CS and HCI.

It reminded me why I have trouble working with visual designers. I deconstruct his blog to be saying, "It got frustrating not getting my way on the merits of my stated, expert opinion, but having to actually justify and convince non-classically trained people--often being asked to justify my decisions with USER DATA (how pedestrian!)."

I think technical communicators are grounded more in the social sciences and rely less on the kind of connoisseurship I find with visual designers. For example, I'm involved in fewer and fewer discussion where someone says "It just doesn't sound right to my ear." In most discussions I have with technical communicators, they have reasons and research to back up why this combination of words is more suitable than another combination.

Not that I don't work with visual designers who do the same. It's just that with visual designers I'm more likely to encounter the "because I have taste and you don't" rebuttal. (I have yet to get a good explanation for why Comic Sans is a bad font.)

Imagine going into engineering meetings and justifying my suggested changes to the UI labels by saying, "Because I am a classically trained technical communicator." Like THAT'S going to work.

My point is that I'm glad it doesn't work. I don't mind basing my decisions on principles and research that can be empirically validated. It's part of what makes me a professional.

Progressive User Adoption

I have a new column out in UXmatters.com on progressive user adoption. It is based on an article I wrote for the Cutter IT Journal. It shows how technical communicators can expand the value they add to their companies by increasing user adoption within their current user base.

I think it is a good example of how we can restate our value proposition in terms of our sponsors' business models, a theme I harp on a lot in this down economy.

Value

I'm working on a number of fronts around the issue of Value, as in the value of my profession to my company, the value of my department to my division, my value to my department, the value of STC to my profession, etc. A couple of aha! moments for me:

• Good organizations are not cutting stupid programs or laying off poor performers in the face of this economy! Good organizations have already cut their stupid programs and gotten rid of their poor performers. All that's left to cut are good programs and good people, so the rebuttal "We can't cut this program or this position because [however 'they're good' translates]" doesn't mean anything.
• We need to quit talking about mission and vision and talk only about deliverables and value here for awhile. What do I produce and how does it add value; what do we produce and how does it add value?
• We need to articulate how we assess the value [it] adds.
• We then make that assessment the litmus test for every initiative.
  

UAX

I was recently contacted at work to be a member of the "Next Generation User Assistance Experience Council." The person setting up the group was somewhat apologetic over its long title, but I loved it. I thought it told a compelling story. In setting up a folder to start collecting files and such, I named it "Next Gen UAX."

UAX, I like that! UAX carves out a special niche for us in the UX world. I also think it sets up some interesting discussions about what would constitute UAX as a discipline or practice that would be different from just talking about user assistance.

First, I think there are two dimensions along which to view UAX, each with its own set of implications and requirements.

• UAX encompasses how the content of the user assistance supports the user experience with the product the UA supports. Along this dimension we would discuss the usefulness of the UA.
• UAX also encompasses the user experience manipulating the UA delivery channels with things such as navigation, linking, interactions, affordances, pliancy, etc. Along this dimension we discuss the usability of the UA.

So the mantra of a UAX approach is to provide information that is useful in a way that is usable. Ingrained in this approach is a user-centric task analysis that identifies task- or goal-oriented information requirements and the design of a delivery mechanism that optimizes access to that information on an as-needed basis. It also requires an evaluation methodology that looks at how useful the information was to the user and how easily was the user able to access it.

I know this is not a big departure for most of us, but I do think that linking user, assistance, and experience into one semantic unit does shift the perspective in a significant way. It moves us further from being merely writers and more to being developers of information delivery applications. It moves us from looking at Help as a codified body of knowledge about the product as a whole and more as a collection of interventions targeted at specific moments of opportunities and points of pain. We will worry less about "Is this presentation consistent with one the user might have seen elsewhere in the Help" and more about "Does it meet the likely need of someone in this task on this screen?" We will worry less about "Is this complete" and more about "Is this sufficient?"

So, as of right now, I start relearning my craft under the new classification of User Assistance Experience (UAX) with the driving question of "What's next?"

Miscellany

A day in the life

Tom Johnson has an interesting post on Quick Reference cards that has double value. For one, it gives good advice on what to do and what to avoid. More importantly, though, it is a great snapshot of what a technical communicator's life is like. I highly recommend it to my academic friends to share with your students, especially those who have not yet started working in the profession. It's not a depressing snapshot, but it does provide a splash of reality in the face.

Shhhhh

In the never-ending cube versus office and office versus home discussions, I often hear the argument for the need for a quiet place in which to concentrate. For a lot of my career, the people who invented the stuff I documented have worked in the chaos of common work areas with couches and foosball tables. But to document their output seems to require quiet and to edit that documentation requires greater quiet.

I have no beef with any of that, but it reminds me of an observation I have made about sports, namely that we are wildly inconsistent with our expectations of crowd noise. For example, in baseball the pitcher throws the ball ninety miles an hour at the batter and puts all kinds of curves on it, but the crowd is hysterical "Batta, batta, batta, suhwiiiing batta." In tennis, the server throws the ball to himself and we are all "Quiet, quiet, quiet, everyone, he's SERVING."

In golf the ball isn't even moving and the player is trying to put it into a hole in the ground (not very likely to be dodging around) and again, "Quiet, quiet, quiet, everyone, he's PUTTING." But a quarterback has to hit a moving target while monster-size opponents try to give him a concussion and again, the crowd is screaming.

No point here, just a pithy, Friday morning observation. Life is good these days.

Conferences and such

OK, I just got my last set of slides off to Joe Welinske for the WritersUA conference, which is on March 29 to April 1. The presentation is "Architecting UA Topics for Reuse" and I'm pleased with how the it came out. After attending the Atlanta STC chapter meeting last week, I realize that there is still a lot of Fear, Uncertainty, and Doubt (FUD) around single sourcing. My presentation uses DITA examples, but I think the principles will be useful regardless of what tool someone uses.

One of the examples I use is a recipe for a cheese grits casserole that I made this weekend and used as a base for my crawfish etouffe. Oh my! It's worth coming to the conference just to get that recipe!

STC conference is in Atlanta in May. STC has extended the early bird rate to help with the economy. I'm doing a presentation on use cases with my boss. Hope I don't screw up.

I went to a 20 year anniversary celebration for the TCOM program at Southern Polytechnic State University. I am an alumnus of that program, a former faculty, former member of their advisory board, and still an occasional adjunct. There was a "here's what they looked like" slide show going in the background, and here are a couple from my academic days:

Doing part of my doctoral studies at the University of Manchester, England


Professor Mike in his office


And this one from the anniversary party itself:

It's Good to Be a Tech Writer

It's not me, it's you

I'm speaking at WritersUA conference in Seattle (March 29-April 1). One of my topics is "Managing UA Projects with Spreadsheets" in which I explain why I broke off my long-time relationship with MS Project to go with Excel as my tool of choice for managing user assistance projects. It includes a full tutorial that will put attendees in an exclusive club: folks who can do pivot tables in Excel. Hope to see some of you there!

It's not me, it's you

Scavenger Hunt

The more I look at the Atlanta Summit host city web site the more impressed I am with Brian Snead and Al Hood for a job well done. Among that, the cookbook, and the host chapter reception, I'm so proud of how we will be showing our Southern hospitality. Still some things to do, Atlanta STC members, you'll be getting an e-blast soon.

Just to make things interesting, I'll give away a free copy of our chapter Summit commemorative cookbook, Fixin to Eat: Some South for your Mouth from the Atlanta STC to the first commenter who finds where Phylise Banner and Andrea Ames are mentioned on our host city web site. (Council members who contribute to the web site are disqualified.)

Happy hunting!