photo credit: katiemarinascott
Do you ever feel that you’re doing as much Product Management as you do writing?
I’m building an online portfolio, so I’ve gone through a lot of my old documents to get some samples, and I’ve notice something interesting.
The docs I deliver, which are supposed to contain things like Interface text or Help text, also contain tons of suggestions to change features, flows, buttons, and screens. And not change a little. Several times, I’ve suggested that we remove (or add) whole screens, or even sets of screens from an interface.
And to cut to the chase, almost every time it was technically feasible to make the change I suggested, the team agreed to do so. In other words, I was catching issues that needed work.
My point is not that I’m really good. My point is that most tech writers would have found the same problems. Writers seem to catch issues with flow, design, or feature sets that would otherwise go unnoticed by the team.
Why is this?
The question could mean at least two things:
- Why do tech writers catch problems that other people miss?
- Why do tech writers catch problems that have nothing to do with writing?
I have some theories about the first question, but I’ll stick to the second one for now.
Why do tech writers catch problems that have nothing to do with writing?
Actually, it’s kind of a trick question, because everything we write about has to do with writing!
If I’m writing about how to move from screen to screen in an Installation Wizard, then moving through those screens is my business. The flow in question DOES have to do with writing.
Ok, Smartypants: Why do tech writers catch problems with flow, UI, and features?
I’ll tell you this much: It’s not because we’re smarter than the rest of the team. I’ve worked with really brilliant Information Architects, Designers, Developers, and Product Managers, but I still find “gotchas” in the UI. Something else is going on.
I think we get tipped off about problems when our jobs are harder than they should be.
Because really, we’re pros, and we know how to guide someone through a flow. We know how to explain what a given button does and when a person might want to click it.
So when I find myself really struggling to explain what’s going on, I start to wonder what the problem is. And after wrestling a while with the words, I scrutinize the thing I’m writing about.
“Hmmm,” I say, “if this button wasn’t here, or if it did something slightly different, the page would be easier for me to write about.”
“Hmmm,” I say again, “if this screen took people THERE instead of HERE, then I could reduce my word count by half.”
Hmmm.
And you know what? I’ve found a golden rule of tech comm:
A change that makes a thing easier to document is a change that makes it easier to USE.
When, purely to make my job easier, I imagine the UI without that pesky button, I find that a person using the software has one less obstacle. If that tricky screen went to a different place, my audience would accomplish its goal in three steps rather than five.
And that’s when I send my note to Product Management.
Has anyone else found difficult writing to equal problems in the UI? Do you find that you frequently suggest changes outside the realm of the words?
5 Responses to “Why Tech Communicators Find Problems That Others Miss”