How Do You Write a Task Description People Actually Understand?

The cost is invisible but constant. Every ambiguous task generates a clarifying question, a day of delay, or — worse — work done to the wrong assumption and discovered at review.

This guide covers why descriptions fail, the five parts of a clear one, worked before-and-after examples, and how to write for someone reading it months later.

Quick answer: A task description works when someone who was not in the conversation can pick it up and start without asking a question. That requires five things: a title stating the action, the context behind the request, what done looks like, any constraints, and links to whatever is needed. Most task descriptions fail because they were written as a reminder for the author rather than as instructions for a reader.

Why Most Task Descriptions Fail

Weak task descriptions share three faults: they are written from the author's memory, they omit why the work matters, and they never say what finished means.

Each is easy to fix once you notice it.

Written for the author, not the reader

"Fix the export thing" makes complete sense to the person who just had the conversation. It makes none to a colleague three weeks later.

The author is not writing instructions; they are writing a memory aid. The habit persists because it always feels sufficient at the moment of writing — the context is fully present in your head, so its absence from the page is invisible.

Missing the reason

A task that says what to do but not why forces the assignee to either guess at intent or implement it literally.

Literal implementation is the more expensive failure. Someone builds exactly what was asked and it does not solve the problem, because the request was one person's idea of a solution rather than a statement of the need. Including the reason lets a capable person propose something better.

No definition of finished

Without stated acceptance criteria, "done" is negotiated after the fact. The assignee thinks it is complete; the requester does not.

This produces the most frustrating category of rework — work that was done well against an unstated expectation.

What a Good Task Description Contains

Element Purpose Weak version Strong version

A title that states the action

"Add password reset link to login page"

Context Explains why (omitted) "Support gets ~15 reset requests a week" Acceptance criteria Defines done (omitted) "Link visible, email sends, expires in 1 hour" Constraints Bounds the work (omitted) "Use existing email template; no new library" Non-goals Prevents scope drift (omitted) "Not changing the login flow itself" Links Removes hunting (omitted) Design file, related ticket, error log Owner and date Establishes accountability Unassigned Named person, due date

The Five Parts of a Clear Task

Every task needs a title that states an action, the context behind it, what done looks like, the constraints that apply, and links to everything required.

A title that states the action Start with a verb and name the object. "Add password reset link to login page" tells you what will change. "Login page" is a topic.

The test is whether the title alone tells someone what will be different when the task is complete.

Topic titles cause people to open tasks just to find out what they are, which is a small tax paid dozens of times a day across a team.

The context behind the request

Two or three sentences on why this exists. What problem prompted it, who is affected, what happens if it is not done.

This is the part most often skipped and the part that most improves outcomes, because it lets the person doing the work exercise judgement. A developer who understands the problem may solve it more cheaply than the solution originally requested.

What done looks like

List the conditions that must be true. Keep them observable — someone should be able to check each one without interpretation.

Three or four criteria is usually right. Fewer leaves ambiguity; many more suggests the task should be split.

Constraints and non-goals

State what must not change, what approach is ruled out, and what is explicitly outside scope.

Non-goals are underused and disproportionately valuable. "Not redesigning the login flow" prevents a well-intentioned person from expanding a two-hour task into a two-day one, and it prevents the awkward conversation afterwards.

Links to everything needed

The design file, the related ticket, the error log, the document, the customer conversation.

Every link you do not include is a search the assignee performs, or a question they ask. Tools that let you attach and cross-link — in Taskzin, linking a Doc directly to the task — remove that hunting entirely, but the discipline matters more than the mechanism.

Before and After: Rewriting Weak Tasks

The same request rewritten with context, criteria and constraints turns a task that generates questions into one that can be started immediately.

A vague request

*Before:* "Improve the dashboard" *After:* "Add last-30-days filter to the sales dashboard. Sales leads currently export to a spreadsheet to see recent performance, which takes about ten minutes a day each. Done when:

a date filter appears above the chart, defaults to last 30 days, and the existing chart updates without a page reload. Not changing which metrics are shown. Design: [link]."

The rewrite takes ninety seconds and eliminates at least one round of clarification.

A bug report

*Before:* "Export is broken" *After:* "CSV export returns empty file for reports over 5,000 rows. Reproduced on production, Chrome 128, account [id], report [id] — smaller reports export normally. Three customers reported this week. Done when: exports over 5,000 rows complete successfully, or the user sees a clear message if a hard limit applies. Error log: [link]."

Reproduction steps and scope are what turn a bug report into something actionable rather than an investigation task.

A creative brief

*Before:* "Need a banner for the campaign" *After:* "Design hero banner for the spring campaign landing page. Audience is existing customers on the free plan; message is that the trial now includes reporting. Done when:

1600x600 and mobile variants delivered, headline under eight words, brand palette, CTA reads 'Start free trial'. Not covering email or social variants — separate task. Brand guidelines: [link]."

Naming the audience and the message is what prevents the third revision round.

Writing for the Person Who Picks It Up in Three Months

Avoid pronouns and shorthand, name people and systems in full, and record the decision rather than only the instruction.

Avoid pronouns and shorthand

"He said to change it after we talked about the thing" is unreadable to anyone else and to you in six weeks.

Write as if the reader has no memory of the conversation, because eventually that reader is you.

Name people and systems explicitly

"Ask the vendor" becomes "Ask [company], contact [name] — see thread linked below". "The old system" becomes the actual system name.

Shorthand is the most common reason old tasks become uninterpretable. It costs nothing to expand and saves a research exercise later.

Record the decision, not just the instruction

If a task exists because of a decision, note the decision and its reasoning briefly.

Months later, someone will ask why the work was done this way. The answer sitting on the task itself prevents the same discussion being repeated from scratch — and occasionally reveals that the reasoning no longer applies, which is equally valuable.

Common Task Writing Mistakes

The three recurring faults are topic titles, bundling several outcomes into one task, and assuming context the reader does not have.

Titles that are topics, not actions

"Reporting", "Onboarding", "Mobile" are subject areas. They tell you nothing about what will change, and boards full of them cannot be scanned.

Bundling several tasks into one

"Fix the export, update the labels and add the filter" is three tasks. It cannot be estimated, cannot be partially completed, and blocks itself if one part is delayed.

One outcome per task. If the description needs the word "and" between deliverables, split it.

Assuming context that exists only in your head

The single most common failure, and the hardest to notice, because the missing context feels present while you are writing.

The practical check: reread the task pretending you were on leave when it was discussed.

Anything that would prompt a question needs to be on the page.

A useful team habit is to treat every clarifying question as a defect in the description rather than a normal part of the process. When someone asks what a task means, the answer goes into the task itself, not just into the reply. Over a few months this quietly raises the standard across the whole backlog without anyone running a training session.