You write the brief at the end of a long day: “Client wants a team page like the one on their competitor’s site. Assets in the Drive folder. Needs to go live this week.” Your developer opens it the next morning, their time, while you are asleep. Which competitor? Which Drive folder? Does “like the one” mean the layout, the hover effect, or the photo style? They can guess, or they can ask and wait. Either way, a day has gone.
A remote developer can only act on what is written down. When you share an office, a vague brief gets repaired in a two-minute chat by the coffee machine. When the person doing the work is in another country and starts their day as yours ends, every gap in the brief turns into a delay or a wrong guess. The fix is not longer briefs. It is briefs that make the decisions in advance.
A brief is a list of decisions, not a description
The most useful way to think about a brief is this: every question the developer would otherwise have to ask is a decision you have not made yet. “Build a team page” leaves dozens of decisions open. Grid or list? Bios visible or in a pop-up? What happens when somebody leaves the company? Who adds new staff later, the client or you?
Some of those decisions really can be left to the developer, and saying so is itself helpful: “Use your judgement on spacing; match the existing About page.” The trouble comes from the decisions you assumed were obvious. They are obvious to you because you were on the call with the client. The developer was not.
A good test before you hit send: if this person could not contact you at all until the work was finished, would they build the right thing? If the answer is “probably not,” the brief needs another pass.
Nine things a workable brief contains
1. The outcome, in one sentence
Start with why the work exists, not what to click. “The client wants visitors to see real people before they book a consultation” tells the developer what matters when they hit a choice you did not foresee. A developer who knows the purpose makes better small calls than one who only knows the task.
2. Exactly where
Give the full URL of the site and the page, and say whether the work happens on staging or live. If there is a staging copy, give that address too. Name the theme or page builder in use if you know it, because “edit the header” means very different things on a block theme, an Elementor site and a custom-coded theme.
3. What is in scope, and what is not
List what to do, then list what to leave alone. The second list is the one that prevents surprises. “Do not change the main menu; the client is reworking it separately” saves an awkward conversation later. If you want to know about other problems the developer spots, say “note anything else you notice, but do not fix it without asking.” That single line keeps scope tidy, and it connects directly to how you keep WordPress projects from quietly growing.
4. Constraints
Plugins that must not be added or removed. A page builder the client’s in-house person edits, so the work must stay editable in it. Brand colours and fonts. Hosting limits you know about. Any plugin that is licensed on your agency’s account rather than the client’s. Constraints are cheap to write and expensive to discover.
5. Access, sent separately
Say what access the developer will have and how it will reach them, but do not paste passwords into the brief itself. Briefs get forwarded, copied into tickets and saved in shared folders. Create a named user with only the role the job needs and share credentials through a password manager or another private route. Our post on sharing client logins safely covers roles and revoking access afterwards.
6. Assets, all in one place
Images, copy, logos and fonts in a single folder with a clear name, and the brief should say which file goes where. “Team photos are in /team-page/photos; use the cropped versions, not the originals” beats “assets in Drive.” If copy is still coming from the client, say so and say what to use as a placeholder.
7. A reference, with the part you mean
Reference sites help, but only if you point at the specific element. “On example-competitor.com/team, copy the card layout and the hover that reveals the bio. Ignore their colours and photo style.” A screenshot with the relevant area circled is better still.
8. How you will judge it
Two to four short statements that describe finished work. “Cards show four per row on desktop, two on tablet, one on phone.” “Each card links to the person’s LinkedIn profile, opening in a new tab.” These become the checklist you and the developer both work from, and they make the review step faster. We go into reviewing against them in checking outsourced work before it reaches the client.
9. Timing and who approves
Say when you need it and why, so the developer can tell you early if it is not realistic. Say who signs off: you, or a colleague, or the client after you. And say whether the developer should deploy to live or hand back for you to do it.
A template you can copy
Paste this into your ticket system or email and fill it in. Leave a line blank only if you genuinely do not mind what happens there.
- Client / site: name and live URL
- Work on: staging URL, or live with backup first
- Why this matters: one sentence
- Do: numbered list
- Do not: numbered list
- Constraints: plugins, builder, brand rules, licences
- Assets: folder link and which file goes where
- Reference: URL plus the exact element you mean
- Done when: two to four testable statements
- Access: what role, sent by which route
- Needed by: date, and the reason
- Approves: who, and who deploys
- Questions I already expect: answer them here
That last line is worth a moment. Before sending, read your own brief as the developer and write down the first two questions you would ask. Then answer them in the brief. It takes a few minutes and often saves a full round of messages across the time difference.
Phrases that mean something to you and nothing to them
Agency shorthand is the biggest source of confusion in remote briefs. Watch for these:
- The client’s names for things. “The blue banner,” “Sarah’s page,” “the old offer.” Use the URL or the block’s actual title.
- “Like last time.” Last time is in your memory, not theirs, unless it is linked.
- “Make it pop,” “cleaner,” “more modern.” Translate taste into instructions: more white space between sections, larger headings, remove the drop shadows.
- “Quick fix.” Describe the result you want and let the developer tell you how quick it is.
- “Standard.” Your standard contact form, your standard footer. Link an example site where that standard is already built.
Bugs need a different kind of brief
Everything above is about new work: something to build or change. When the job is “something is broken,” the developer needs a different set of facts: where it happens, what the error says, who sees it and since when. We wrote that up separately as a checklist and template in how to report a website problem to a developer, which works just as well when the person reporting is your client and you are passing it on.
After you send it
Invite questions, and ask for them in one batch. A line such as “If anything is unclear, send all your questions together and I will answer them first thing” stops a slow trickle of single questions across the time zones.
Ask for an estimate before work starts on anything bigger than a small change. An estimate is also a test of the brief. If the developer’s estimate is far from what you expected, one of you has misunderstood the scope, and it is much cheaper to find out now.
Expect the developer to restate the job. A good remote developer will often reply with “So, to confirm: four cards per row, bios in a hover, no menu changes, deploy to staging only.” That reply is not bureaucracy. It is the cheapest quality check you will get.
Keep the brief as the record. If the scope changes mid-job, update the brief or add a dated note at the bottom. When the work is reviewed, everyone checks against the same document rather than a memory of a chat.
Trial your brief on small jobs first. If you are new to working with a remote developer, a small, well-briefed piece of work tells you a great deal about how they read instructions. We cover setting that up in running a paid test task before committing.
Good briefs get faster to write
The first few take effort. After that, most of the template carries over: the same constraints for the same client, the same “do not” list, the same approval route. Many agencies keep a short notes file per client site so the fixed parts of every brief are ready to paste. Briefing well is part of the larger habit of outsourcing WordPress work without losing control of it.
If you are short of hands and want a developer who will read a brief like this closely and send questions before guessing, that is the kind of work our overflow development help for busy agencies exists to take on.
Next in this series: Agency Ticket Triage: Urgent, Routine or Change Request
