Need to estimate hours for your content production? Step one: Don’t guess! Better questions help keep content production from derailing our design projects.
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 two to three times 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.
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.)
Helping your team scope the writing assignment is part of your job as a writer. Determine: What 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 nonwriters 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.
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.)
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:
Let’s take a look at each.
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.
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 longer to write than 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:
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.
If you’re the person asking how long the content will take, here are some ways to make things easier on your writers:
This post is part of a series extending ideas from Writing for Designers, my book about how to get the writing done on web and UX projects. I originally published a version of it on my LinkedIn profile.
Scott Kubie is the lead content strategist here at Brain Traffic and the author of Writing for Designers from A Book Apart. Scott has focused on the content side of digital experiences since 2009, and was the first UX content strategist at Wolfram Research. He grew up in rural Nebraska, and studied electronic media and journalism at Drake University.
Get valuable content strategy resources and insights delivered right to your inbox.