Every seasoned web professional has had a project derailed by content. Overly-ambitious launch dates get pushed back and back again because someone underestimated how much work it would take to get the content done. (And that work takes 2-3x longer than it should because we didn’t start with content in the first place!)
The seemingly-innocent question of “How long will it take to write this?” is full of traps and rabbit holes. Doing the writing often means forcing teams and organizations to make difficult decisions they’ve previously been able to put forward. What is our refund policy, anyway? Exactly how many credits are we offering with the platinum plan? And so on.
But your project manager is no spring chicken. They know to ask how long the content will take at the beginning of the process. Smart! So they turn to you and ask: “How long is it going to take to write this?” Hoo boy. It’s time to proceed very, very carefully.
Clarify the purpose of the question.
Your first job is to fully understand what you’re being asked. Are they asking in order to budget hours as part of a contract? To budget how much of your time they’re asking for relative to other requests they might have? To figure out how the writing work lines up with other milestones? Estimating how long it will take to get the writing done is a process, and that process needs to be more robust than “ask the writer to guess”. (DO. NOT. GUESS.)
Clarify the scope of the question.
Helping your team scope the writing assignment is part of your job as a writer. Determine: What all are you being asked to write? All of the writing on all of the pages? Some of the writing on some of the pages? Is what we see in the wireframe everything that needs to be written, or is it only scratching the surface of every possible state and screen and message that’s needed?
A challenge you’ll run into is that non-writers often don’t understand that there’s more to writing than writing. Will this work require discovery interviews? User research? Stakeholder presentations? Iterative working sessions with designers? Content testing? QA, legal, and compliance reviews? Newspaper reporters might be able to get away with knowing their topic, deadline, and an ideal word count, but UX writers and content designers need to know a lot more to make estimates about their work. If you’re being pressed to make an estimate that relies on assumptions, be sure to document those assumptions and voice your concerns and questions.
Plan your workflow.
One way to reduce traps and time-sucks is to plan your writing workflow. Writing down an overview of how you will prepare, compose (draft), edit and refine, and finally finish your writing assignment gives you insight on what it will take to get the writing done as well as how long it might take to do it. (My book, Writing for Designers, gets into this planning approach in detail.)
Choose your approach.
With a well-planned workflow and well-scoped assignment, you are finally ready to answer the original question: How long is the content going to take? At this point, you have two basic approaches to choose from:
- Multiply real work to create an estimate in hours.
- Reframe the question in terms of deadlines and effort.
Let’s take a look at each.
Approach 1: Create an estimate, in hours, based on real work.
If you have a lot of one kind of thing to write — product descriptions or how-to articles, for instance — then your best option is to finish a small set of those items, track your time, and multiply for the remainder.
Break off a small chunk, like 5 out of the 50 articles you need to write, and plan those out as a separate project. Do the work on them from start to finish (or as close as you can get to finished) and take note of obstacles and friction along the way.
Sometimes teams don’t like to do this because it isn’t tidy. “Why can’t we just do it all at once?” Well, we could, but our estimates will be much less accurate, sometimes by orders of magnitude, and it could disrupt the entire project. Sometimes we go slow at first to go fast later.
Approach 2: Reframe the question around deadlines.
Deadlines are more instructive than estimates, especially if your writing explores a new topic, space, or interaction. Because of the complexities of the design process, an interactive app flow with a mere 300 words might take you five times as long to write as an article with 3,000. Some assignments could require only an hour of the hands-on-keyboard work people think of when they think of writing, but dozens of hours of discovery, prep, organizing, stakeholder wrangling, and so on.
Additionally, the availability of stakeholders, subject-matter experts, editors, reviewers, and anyone else who needs to touch the writing can have a big impact on what’s possible within a given timeframe, and is hard to account for with a purely hours-based estimate.
For these reasons and more, I tend to prefer deadlines over estimates (and project-rate to hourly, if you can manage it). If you’re asked “how long it will take” to do the writing, try reframing the conversation around a deadline instead. You’ll want to know:
- How done does the content need to be? (Rough draft or word perfect?)
- How does the writing deadline relate to the rest of the project? (It doesn’t always occur to folks that we can have writing deadlines that are distinct from other project milestones.)
- Who needs to be involved, and what is their availability?
If questions like these are frustrating to your colleagues, I sympathize. Sometimes you just have to let them have a win and say “ten hours, boss!” with a big smile on your face and do your best. But these kinds of questions should be welcome in a healthy process, and asking them frequently will create an expectation that this is stuff we want to figure out before we create unnecessary content emergencies.
Help a writer out.
If you’re the person asking how long the content will take, here are some ways to make things easier on your writers:
- Invite writers into the process as early as possible. If you expect someone will be doing the writing on your project, get them involved EARLY and include them in the overall planning process.
- Identify your own review and QA process steps. If you’re a project manager or product owner, you probably have a better idea of the kinds of reviews, QA, and compliance steps the content will have to go through. Have information on that ready when you recruit your writer to help inform their estimate.
- Be confident in your deadlines. Wishy-washy answers are not helpful. “Oh, well, gee, it’d be really nice to have the draft by Friday.” Nope. Be particular. “We have to have a complete rough draft of content by 10 a.m. Friday so the designer will have time to integrate it into their prototype ahead of the design review at 3 p.m.”
Editorial Note: I originally wrote this post for LinkedIn, then updated it for the Brain Traffic blog, and have now archived that updated version here. Just so you know.