4 things we hate to hear (but hear all the time)

  1. “We’ve been working on this project for about nine months and are now in user testing. We go live in two weeks and the users have requested a user manual. How soon can you get started?”
  2. “I’ve written all the instructions. I just need you to pretty it up.”
  3. “We need the user guide in three weeks, but we will probably be changing the GUI right up to go-live. Will that be a problem for you capturing screenshots?”
  4. “Can’t you boil it* down to a one-page cheat sheet?”
    *”It” is a 100-page+ manual.
Advertisements

6 Responses to 4 things we hate to hear (but hear all the time)

  1. Fred Sampson says:

    OK, we know that these are the canonical “things we hate to hear,” but is anyone actually hearing such foolishness these days? And if you are, I have to ask, where were you when the project started? Where was your manager? How is it that you and your manager don’t know about the project, don’t know about the need, hadn’t already scoped it, planned it, been involved from the very beginning? Seriously, are you truly so unaware of what’s going on in your company? And if so, why are you still there?

  2. hharkness says:

    You’re making the assumption that managers of technical communicators understand what we do and go to bat for us. I’ve been lucky in that regard, but I know many who aren’t. Many companies have a reorganization every year or so, which means that even if you’ve got a supportive manager this year, next year you may have one who is clueless.

    A friend of mine has a very supportive manager, but the manager travels a lot on other projects and isn’t always able to get involved.

    Even if you are very well regarded, you still have new people coming into the company who have prejudices against tech writers and feel our services are unnecessary. In a loose organizational structure, it isn’t always easy to enforce the use of tech comm services for every project. Especially if the tech comm group is understaffed.

    Keep in mind that large companies can have a over a hundred projects going on at any one time. It’s not that easy to stay on top of each of them. Chaos still reigns in many organizations.

  3. Michael says:

    With point 1 it sounds like you’re describing my employer’s web site development strategy. Something is happening behind the scenes, but nobody at the front end has a clue what’s going on.

  4. Mike Hughes says:

    Like Fred, I’m not very sympathetic on this one.

    Point 1. “the users have requested a manual.” I’ve never heard THAT but probably wouldn’t hate it if I did 🙂

    Point 2. Bummer, how can you work with such jerks? I much prefer SMEs who make no attempt to capture their knowledge before coming to me.

    Point 3. Why have screen shots at all? If the user assistance is to support the GUI, move it into the GUI and let the screen itself be the “screen shot.” All software undergoes revision up to ship date. Our communication strategy must accommodate that reality.

    Point 4. I think every 100 page manual could benefit from a one-page cheat sheet. Do one and make it the cover!

  5. Gordon says:

    Easy rebuttals.

    1. I can start immediately, but will mean I can no longer work on X, and I’ll have an estimate of how long it’ll take to complete the work with you by end of play tomorrow. Now, who ARE the users that have requested this?

    2. Thanks. (You then re-structure the document and go back to the originator to fill in the blanks, clarify the ambiguous and so on. Gently point out that next time you’d love to help from the start and that that means they won’t need to write the doc in the first place).

    3. Not at all (plan for them and do them last).

    4. I’m with Mike on this one! (although it does depend..).

    Of course it’s never that easy. I’ve worked at places where we didn’t know which projects would “go product” and we didn’t have the staff to doc them all. We planned the ones that everyone (else) thought would end up in the product but we did occasionally have to field this kind of request. Our solution was to agree up front that any late doc requests would mean a lag in the appearance of the documentation.

    But in saying all that, the systemic treatment of tech comms as the ‘end of the line’ or ‘oops we need docs’ seems (SEEMS!) to be slowing disappearing. The more we can all do to help the better.

  6. Tom Johnson says:

    “Can’t you boil it* down to a one-page cheat sheet?”
    *”It” is a 100-page+ manual.

    I hear this one all the time. We finally decided to create this one-page deliverable, so I scoured magazines looking for the perfect layout that would accommodate a one-page job aid design. I finally found something I liked and started creating the one page (double-sided) deliverables for projects. SMEs and users loved the deliverable. Surprisingly, I found I could fit about 10-15 pages of content into these one-pagers. Personally, I think they are now an indispensable part of any user instruction package. It’s impossible to single source the content with them, and they are like writing poems more than a novel.

    No one has ever complained that the documentation was too short. But many have griped about it being too long.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: