Checkable Done-Conditions: Turning a Task Idea Into a Brief Someone Can Act On
Most task briefs fail at the same point. The employer knows what they want, but the words on the page describe a feeling rather than a finished piece of work. A reader sees phrases like "make it look professional" or "quick turnaround on a few changes" and has to guess what that means in hours, deliverables and risk. Two qualified people can read the same sentence and produce wildly different quotes, which wastes both sides' time. This article focuses on one specific habit: writing done-conditions that a stranger can check. It is written for independent workers reading briefs, small employers writing them, and agent operators who need a human-owned task to be scoped clearly before anyone commits.
Why adjectives cannot carry a brief
Adjectives such as clean, modern, fast or accurate feel informative when you write them, because you have a picture in your head. The reader does not have your picture. They have only the words. A practical test is to ask whether two competent people could check the finished work against the sentence and reach the same verdict. If the answer is no, the sentence is a preference, not a condition.
Done-conditions replace adjectives with observable outcomes. Instead of "the layout should feel modern," write "the layout uses the attached colour palette, all headings are in the attached typeface, and the document fits on two A4 pages." The second version can be checked by opening a file. The first version can only be argued about.
This does not mean every brief needs to be rigid. Creative work often needs room. The aim is to separate what is fixed, which should be checkable, from what is open to judgement, which should be named as such.
Four parts every brief should separate
A workable brief usually has four distinct parts: the goal, the inputs, the deliverables and the done-conditions. The goal explains why the work matters in one or two sentences. Inputs list everything the worker will receive, such as existing files, data exports, login details for a test environment or reference examples, along with anything they must supply themselves. Deliverables name the exact artefacts to be handed over, including format, file names and where they are sent. Done-conditions state how the reader will know the work is finished.
Keeping these parts separate helps both sides. When a worker asks a question, you can see whether it concerns the goal, an input that is missing, or a done-condition that is ambiguous. Mixing them into one paragraph makes every question look like the same question.
Out-of-scope items deserve their own line too. A short list such as "not included: translation, hosting, copywriting beyond the supplied headlines" prevents the common situation where a worker finishes everything described and the employer expected something adjacent that was never mentioned.
A practical checklist before you publish
Before publishing a brief, read it as a stranger who has never spoken to you. Work through these questions in order and rewrite any line that fails.
First, can you point to one sentence that states what "finished" means? If not, add it. Second, is every input either attached, linked within the platform, or explicitly stated as the worker's responsibility? Third, does each deliverable have a format and a destination? Fourth, is there at least one done-condition a reviewer could check without asking you? Fifth, is there a list of things excluded? Sixth, are any figures, dates or quantities written as numbers rather than words like "soon" or "a few"? Seventh, does the brief say what happens if a condition cannot be met, such as a request for a short written note explaining the gap?
If you can answer yes to all seven, the brief is likely clear enough to be priced honestly. If not, the unanswered question is the place to start editing.
Reading someone else's brief carefully
Workers benefit from the same discipline when they read a brief. Before applying, try to restate the task in your own words and list the deliverables and done-conditions. If you cannot do this in a few lines, ask a specific question instead of a general one. "Do you want a PDF or source files?" is far more useful than "Can you tell me more?"
Pay attention to the difference between compensation that is described and compensation that is confirmed. A brief may state an indicative figure for the work as proposed. That is a starting reference for discussion. It is not evidence that the task is funded, that work will be assigned, or that payment will follow any particular outcome. Ask directly what has been budgeted and what conditions apply, and record the answer in writing.
Be cautious about briefs that omit any description of inputs or acceptance. Missing information is not always malicious, but it reliably produces disputes later. A short clarifying exchange before starting is cheaper than an argument after delivery.
Keeping briefs current after they go live
A brief is a working document. When a requirement changes, update the done-conditions rather than leaving the original text in place with a comment underneath. Note the date of the change and what it affects, such as scope, deliverables or timing. Anyone who applied under the earlier version should be able to see what shifted.
For agent operators and anyone coordinating several human workers, keep a single record of which person owns each deliverable and which version of the brief they accepted. That record matters most when work is handed between people who will never meet. Clear ownership is a process choice you make; it is not something a platform can settle for you, so decide it explicitly and write it down.