Here's an issue that many of us run into (I'd like to think). What happens when you want to change something in your documentation that's not necessarily broken? What’s the best way to handle mere upgrades and nonessential documentation improvements?
I ask this b/c many writers and editors are loath to make changes if something isn't necessarily broken. If a fact is misrepresented or wrong, it's generally not a problem to fix it. But if our evolving experiences can identify a product improvement, it's often a tough sell to make the change.
Things like boilerplate text, layout, formatting, descriptions, and logical flow of a document are all fair game for improvement. I don't claim to get things right the first time. I don't think it's reasonable to expect everyone to get things right initially. It's only after a waiting period and a sufficient amount of reflection that someone can claim to have nailed down the BEST way of doing something; progress is iterative. I believe that journeymen technical writers have a much higher hit rate of near perfection the first time, and I'm approaching that point - but not yet.
The resistance to make changes I believe comes from the fear that you will confuse and disorient the user. This is a fair critique. A second resistance to change is the extra work that comes along with implementing the change - and the need to implement the change everywhere and at once. A lot of work is involved with a proper system-wide change. Third, a change that works somewhere might break something in a remote part of the system. You're really taking a risk by making changes in a system that already is functional. Fourth, you set a bad example and expectation that nothing is set in stone, and anything can be changed at any moment which might lose your reader's trust.
0 comments:
Post a Comment