Task Brief Examples: Turn a Vague Request Into a Testable Deliverable
A request such as “improve our website” or “do some research” leaves both sides guessing about the result. A task brief turns the request into a bounded piece of work that can be estimated and checked. You do not need a long specification for every small job; you need enough information for a capable person to understand what done means and which questions remain open.
· By Nothing.gripe
Replace vague outcomes with concrete outputs
Vague: “Clean up the spreadsheet.” Clearer: “Standardize the date format in the supplied workbook, remove exact duplicate rows using the agreed record key, add a tab listing ambiguous records, and return the edited file plus a change note.” The second description tells the worker what to produce without pretending every data issue is already understood.
- Name the file, artifact or result that will be delivered.
- Describe what should happen to ambiguous or exceptional cases.
Define constraints and dependencies
A brief should state which inputs are supplied, deadline, tools or methods allowed, access requirements and what is out of scope. For a research task, include time period, geography, source standards and expected format. If a required input is missing, identify the owner and due date instead of silently assuming it will arrive.
- List the materials the requester will provide.
- Identify privacy, licensing or tool-use constraints.
Make proof and review criteria observable
For a website check, acceptance may include a list of tested pages, steps, expected versus actual result and severity. For a writing task, it may include length, audience, required sources and one review round. Avoid criteria that rely only on “I will know it when I see it” unless a subjective review process is agreed.
- Specify proof files or links needed for verification.
- Name the reviewer and when feedback is expected.
Add payment and change rules
State budget, currency, payment milestone, revision allowance and how new requests are handled. If the work cannot be estimated because the problem is unknown, create a discovery task first. A brief protects the requester too: it makes it easier to compare estimates and spot a mismatch before the work is funded.
- Define what is included and excluded.
- Agree how scope changes affect price and delivery date.
Copy-ready brief for a small task
Fill these fields before you publish or fund a task. Specific examples help a doer estimate effort and make it easier to agree on whether the result is complete.
- Outcome: [the problem this task should solve]
- Deliverable and format: [file, link, report or other concrete output]
- Inputs supplied: [files and context the doer is authorized to use]
- Acceptance checks: [observable conditions that must be true for the work to pass]
- Proof: [what evidence to include with the submission]
- Deadline and budget: [date, amount and currency]
- Out of scope: [what is explicitly not included]
- Access and privacy: [least-privilege access, safe transfer method and data that must not be copied]
Before funding, make sure the budget fits the scope and the review criteria are achievable. Do not request passwords, wallet recovery phrases or unnecessary personal information as proof.
Put the advice into practice
Write the brief around an observable output, clear boundaries and fair acceptance rules. When a problem is too uncertain to estimate, fund or scope discovery first. That improves the chance that both sides understand the task before time and money are committed.
Turn the brief into a funded task
Before publishing, state the deliverable, file format, deadline, acceptance checks, proof required and budget. Keep the first task small enough for a doer to estimate honestly, and make the completion standard testable rather than subjective.
Common questions
How detailed should a task brief be?
Detailed enough to estimate the work and agree how completion will be checked. A tiny routine task may need a few bullets; an uncertain or higher-risk project needs more context, dependencies and review rules.
What if I do not know the solution yet?
Describe the problem, constraints and evidence needed, then define a discovery deliverable. Do not pretend to know an implementation plan before the worker has investigated the issue.