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 :-)