How to Write a Clear Task: Before-and-After Examples

A task can take hours to complete and still return from review because the request was unclear. Writing a task means providing enough information for the contributor to understand the outcome and for the reviewer to verify it.

Clear tasks reduce reliance on memory and private conversations. Someone joining later can understand the context without starting again.

Make the title describe an outcome

Connect your task template to the team task routine and clear decision records, so clarification stays with the work.A useful title names an action and a specific output. “Website” is a topic. “Improve the website” is a direction. “Fix the contact form link on the service page” defines work that can be done and reviewed.

• Before: Follow up with the client. After: Obtain client approval for the service page copy.

• Before: Design the campaign. After: Prepare first drafts of three campaign assets using the approved brief.

• Before: Form issue. After: Fix the missing confirmation message after contact form submission.

Keep context, links, and detailed requirements in the description so the title remains easy to scan.

Answer the questions needed for execution

Explain why the task matters and how it supports delivery. Include scope, exclusions, required files and links, and decisions needed before work starts. Include relevant information rather than the whole conversation history.

For a form issue, include the page link, reproduction steps, expected result, and actual behavior. “The form does not work” leaves too many possibilities.

Define completion before starting

Acceptance criteria make an output reviewable. Specify that required links work, the form reaches the agreed destination, the mobile version is checked, and the responsible person approves the result.

Avoid unverifiable requirements such as “make the design excellent.” Connect review to the approved brief, requirements, and examples. Name the decision maker for creative choices.

A before-and-after description

Before: “We need to update the service page quickly. Check the client messages.”

After: “Replace the old copy with the approved text in the attached link and update the contact number in two places. A redesign is outside scope. The developer implements the changes; the project owner reviews the text and links on mobile and desktop. Work starts after copy approval is confirmed. Agree on a deadline based on current capacity.”

The revised version separates required work from deferred work and explains review and approval. Resolve unanswered essential questions before moving the task into execution.

A copyable task template

• Title: a clear action and specific output.

• Goal: why the delivery is needed.

• Requirements: scope and necessary steps.

• Inputs: approved links, files, and decisions.

• Ownership: who leads execution and who reviews or approves.

• Deadline: the actual commitment and dependencies affecting it.

• Acceptance criteria: what must be true before closure.

Split tasks that hide multiple deliverables

Separate independent outcomes or work with different owners and dates. “Write, design, and build the page” hides three stages and their dependencies. Separate tasks make remaining work and waiting clearer.

Do not split work just to increase task counts. Each part should be actionable or reviewable and clearly connected to the larger delivery.

Frequently asked questions

Does every task need a long description?

No. Include only what prevents misunderstanding. A familiar small task may need a title, reference, and acceptance criterion.

What if requirements change?

Update the description and record the change, reason, and approver in task comments. Discuss the impact on scope and deadlines.

Who should write a task?

The requester or project owner may start it. Review it with the contributor before making a commitment. Shared understanding matters more than who wrote the first draft.

Use team collaboration to keep clarification and decisions beside the work.