Topic-based content development: How now, brown cow?

Well, I’d tell you to get a cup of coffee and have a seat, but we’re totally out of coffee here. This borders on Crisis. Had I known, I would have stopped at Starbucks on the way in. It’s bad all the way. I have a deal with one of our sales guys (because I helped him once on something) that when I need him to, he’ll run for coffee.

Today, I’m using that valuable chip. He’s a good man and will be a better man when he brings me coffee. I like men who bring me coffee.

So, if you have coffee, get some and have a seat. I’ll drink water, I guess.

You made a list and you checked it twice

When we left off last time, you made a list of all the stuff that your user can do in your product. Now, obviously, some of these topics are going to require more than Step 1, Step 2 and so on. Some of these topics will need overview sort of text. I call this narrative info, you can call it bananas, if you like. But this is the info your user needs to have before s/he can do the thing.

For example, before s/he can run a report, they need to know about what information appears on a report and why. So you may need a topic called “About reporting” that covers this info. It’s not a task, but it’s related to a task the user needs to do. It may also, by the way, need a picture that shows the concepts in the About topic. Consider that. It supports your visual learners.

Working in the coal mine

If you work in a Use Case- or Scenario-based development environment, topic-based content development is the only way to go. You can use the Use Cases or Scenarios to develop your topic list. It’s not a one to one correlation, though; one Use Case does not equal one topic. This helps you in planning and scheduling because you can tie what you’re doing directly to the development effort.

That’s huge. Seriously. It’s big.

Most companies have no idea how docs get done. It’s a dark and mysterious hole to them. Showing that Use Cases or Scenarios are things that you also do in Docs exposes what you do and when you can do it. You can show that these topics map to that Use Case and those topics map to this Use Case and so on.

You want it when?

You can also provide a rough time estimate for how long the topic will take to write. A completely out of the blue guess? I’d estimate, on average, 2.5 days to write a topic to ready-to-review draft.

Why? Because it takes on average 4 hours per page to get from air to final copy. A topic should be no more than about 2.5 pages, including graphics. Ready-to-review draft is about three quarters of the way there, in my experience. So rough estimate about 2.5 days – some topics will be easy, but the narrative topics may be much harder. But you know your material and how long this takes for you, right? You’ve been tracking your time and know for your situation, right?

This also helps you in scheduling. People get the idea that you can’t write about Use Case 345 until Use Case 345 is out of development and into testing, and that’s going to happen about… let’s look at the schedule… oh! Sept 25th. And you say it’s going to take you about 2.5 days to develop that topic, so we can expect to need to review it about Sept 28th or so.

When all things aren’t equal

Another big advantage with Topic-based content development is that you – or your boss or someone – can prioritize topics. In my experience, most tech writers have way too much information scoped for the time available. There’s never enough time to do all that could be done. Once you get your topics mapped to Use Cases and then on the master schedule, it becomes obvious to all if there’s too much work scoped.

When it’s obvious that the rest of the product will be ready in March and docs will be ready in August, this is now a scheduling issue. It’s not because the tech writer is stupid, it’s the schedule that’s the issue.

Now you or your team can start deciding what topics simply must be ready and what can wait or be delayed when time becomes an issue. “Perhaps we don’t develop the topics for new users or the expert users.” someone may say. That might cut the schedule back weeks or months. Perhaps there’s another writer that can be pulled in to help.

The point is, now people can see what you do and how long it takes. They have information to work with to start the negotiations to meet the release dates they are shooting for. Docs are no longer an unknowable black hole.

When variables won’t and constants aren’t: the review process

Another big advantage with Topic-based content development is the review process.

In a typical manual-based organization, you drop at least a chapter at a time on your reviewers. Is it a surprise that no one has time to review? You just dropped 45 pages on someone and want them to “just review that, please. Chapters 5 through 9 are coming tomorrow.”

But in Topic-based content development, you send a topic out for review. Most people don’t have the courage to tell you they can’t “possibly be expected to review 2.5 pages, that’s just too much.” So you may actually get your reviews done. Now, truthfully, you’re still sending 100 topics out for review but you’re doing it 2.5 pages at a time. It just looks like less work. You’re nibbling them to death like a duck.

Don’t mention the other 98 topics yet to come. Just smile and thank them for the effort for this topic.

All good things have to come to an end

While I typed this, my sales guy brought me coffee. I hugged him. Life is good. I think I’m going to go outside and sit in the sun, drink some coffee and warm up for a few minutes. My office is cold today. Expect more on this topic in a few days.

Where in the world is Sharon?

Speaking of cold – don’t forget to see me in Nashua, New Hampshire Tuesday of next week. I’m really excited to be in that part of the country. I’ve requested they warm it up by about 40 degrees. They said they’re right on that for me.

Nice people.


Leave a Reply

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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: