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.
5 comments:
I very much agree that user assistance should be involved in UI design. If something is hard to document, it's hard to use, too. Therefore, the UI is the place to fix it, not the documentation.
Minimalism in documentation should include not only minimizing the docs to only what the user needs, but minimizing what the user needs from docs.
I think we tend to get stuck in occupational silos, so that the "writers" think they can't be involved in what "designers" or "developers" do. Whatever my job title, I tend to think of myself as a "user experience specialist with verbal communication expertise". That helps me to remember that my job is not about writing docs; it's about helping users do stuff.
"But we have to break out of our codependency first."
Right -- I'll just reach over, switch off the codependency, and then get to work.
(Seriously, though, have you any examples of breaking out?)
Good question, Milan! One of the advantages of a blog is to be able to spew out half-baked ideas--in fact, I think that is the value of a blog. So "no" I don't have a good example of how to break out. I think the first step of breaking the codependency,however, is to figure out what's in it for the codependent. In my case, it's allowing myself to feel good about what I do when what I do is not the right solution. I need to stop feeling like I did a good job because my Help is complete and accurate.I think a second thing we all need to realize is that our fellow codependents are not going to carry us around on their shoulders in celebration. We aren't going to be popular in the short run.
That last part is important. The product managers I work for still tend to use word count as a measure of "quality" or "productivity" or both. If I'm consciously and strategically reducing word count, and I forget for a few days to keep reeducating these guys about it, the drop in my volume can translate into a reduction in my perceived value, which in turn can make it harder to get in the door when the UI design is going on. I have to just keep hammering at it.
Good article Mike. I follow your posts regularly and I read this one when I was documenting a poorly written and user unfriendly application. Luckily, the clients appreciated my inputs and modified the UI. It was less work for me, but the clients were happier and gave my company another order!
Cheers,
Kartik.
Post a Comment