Good, not perfect

Like you, I’ve sat through all of those motivational talks. Quality is Job 1. If it’s worth doing, it’s worth doing right. Nothing less than your best.

And I get it. I strive for quality. I try to do my best all the time.

But a funny thing is happening: the definition of quality is changing. Some people are very uncomfortable with that, but that makes it no less true. I wrote about this change a while ago, in a piece called Redefining Perfection.

What’s causing the change?

holygrailPartly it’s the influence of agile, which started in software development and will inevitably spread to other disciplines. In agile, quality is defined by what meets the customer’s expectations — by user stories. That means quality isn’t defined (if it ever really was) by what we think we know about good writing and good design. Put another way: if your user guide keeps customers from having to call Tech Support, it doesn’t matter if it’s printed in 6-point type on the back of a brown paper bag. It’s a good user guide.

Then there’s the reality that everything we publish can be revised and republished in an instant. When I started in technical communication, I ceremoniously handed a stack of proof sheets to the printer and waited for the book to come back. Once the books rolled off the printing press, everything — from the most brilliantly written setup procedure to the most embarrassing typo — was immutable. Not any more. So why wait until it’s perfect? Why not get content into the customers’ hands quickly? If later I find a typo, or if the part number for a thingumabob changes, I can make the update with a simple click.

No more pressure to meet lofty standards of editorial quality, design, and what have you. No more pressure to get everything right the first time. Not perfect, but still good.

What do you think? Am I onto something? Or am I all wet? (If I’m all wet, don’t worry. I can fix it in the next revision.)

Originally published on the SDI blog, 24 June 2013.

12 thoughts on “Good, not perfect

  1. Mark Baker

    Larry, I think you are absolutely on to something. The Web is moving us from a civilization based on publications to a civilization based on conversations. The perfections of conversation are different from the perfections of publication. Key virtues in conversation are immediacy and sincerity. An ad hoc response that is immediate and sincere is more perfect in a conversation than a polished and pristine response that comes a month later.

    The average time it takes to get an answer to a software development question on Stack Overflow is 11 minutes. That is the new performance standard for technical communication.

    1. Larry Kunz Post author

      Thanks, Mark. Of course we’d all like to attain both “immediate and sincere” and “polished and pristine.” But if only one of those is possible, then it’s pretty clear to me that “immediate and sincere” is going to win.

    1. Larry Kunz Post author

      Thanks, Dave, for the link to your article. You’ve helped me see parallels between software and technical communication.

      Software that’s buggy or (worse) that causes my computer to crash is like instructions that are inaccurate or incomplete. We can’t accept those. But we can all think of examples of software that gets the job done, even though its UI might be “clunky” or “unintuitive.” And we’ve all seen instructions that contain just the right information even though they look sloppy. Are they perfect? No. But they’re good.

  2. Val Swisher

    Larry – You are absolutely correct. This is a trend that we’ve been seeing for a long time. Good enough is…good enough. As I mention in my most recent blog post, (, one of the challenges we face is the lack of quantifiable measurements for “quality content”. Mark references “11 minutes to find an answer” as a performance standard in the software development work for a Stack Overflow question. Perhaps the time it takes to find an answer is something we can use as a quantifiable measurement for content finadability (though I think we would all agree that 11 minutes would not be effective!). However, overall, much of what we discuss when it comes to quality content is subjective.

    How do we measure “effectiveness”? How do we measure “meets user needs”? Because we have no objective standards – and perhaps there is no way to measure some of these things – it is impossible to actually quantify quality.

    That said, if there are errors in content, we are able to go back and fix the errors on the fly now. That is a relief to many writers, but I have to wonder if it makes it acceptable for us to create “sloppy” content. And how, exactly, do we measure sloppiness? Good discussion.

    1. Mark Baker

      Just to be clear, 11 minutes is the average time to get a new reply, not the time to find an existing answer. 11 minutes would not be a particularity good time to find an answer to a reference type question, though it would actually be a pretty good time for finding an answer to a more complex question, especially one that involves weighing several options.

      The Web introduces a new form of communication: the recorded conversation. Forums and Q&A sites like StackOverflow are all essentially recorded conversations, with greater or lesser degrees of curation applied. A huge amount of the total bulk of technical communication on the Web today are in the form of these recorded conversations. Tech writers talk from time to time about mining the forums for topics to add to the docs, and I am sure many are doing just that. All the same, I still find more answers to my technical questions, from complex programming topics to simple questions about my phone, in recorded conversations.

    2. Larry Kunz Post author

      Great questions, Val. I’d venture to say that if we can measure effectiveness, then we won’t have to worry about measuring sloppiness — or anything else. Of course, the way to measure effectiveness — of answering the question “does it work?” — is mighty elusive.

  3. Neal Kaplan

    And to prove this point, I started writing a comment this morning when this comment section was empty. I got distracted, and came back a couple of hours later to find five comments already written.

    But that’s what our readers are expecting: Frequent updates and quick responses. I’ve been working with agile teams for a while, so I’m used to being in doc triage mode (get it good enough and toss it out the door, because the next project is coming up fast).

    I’m using a support tool (Zendesk) for my knowledge center. I can click a button and turn support tickets into topics (usually with a bit of editing along the way). This question->solution->documentation path is very powerful, and, as Larry points out, it fulfills the requirement of documentation to reduce support tickets.

    1. Larry Kunz Post author

      And then, Neal, do you come back later and refine the topics to spruce up the wording, etc.? Or have you found that you can just leave them in the knowledge center, as-is, and your customers are satisfied?

      1. Neal Kaplan

        Sure! I’ve had users comment on topics (asking for more information, or examples), and I’ve gathered more information, myself, and added that to the topic. In this type of fast and collaborative documentation, nothing is set in stone. The downside is that you might read a topic on Monday and not come back on Thursday when I’ve added a great new example. That presents more work for the reader (who expects a reader to check back on the documentation just to see if it’s been updated?), but it also means that incomplete or incorrect information isn’t sitting around until the documentation set is updated for the next major release.

  4. juliovaz

    Excellent stuff. The reality is that technical communicators must now be in the mode of providing quick and accurate answers. Most users will forgive grammatical and non-critical spelling errors on the first response with the knowledge that it will be corrected later. We should spend less time on wordsmithing for the first quick response and go back to that after the “crisis” is over. Over time you can work on “perfection” but you have to initially meet the need.


Tell me what you think

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s