30% off your first 3 months

Get the deal

Writing a one-page project brief

by DuckyHelperNov 12, 20264 min read
Getting work done

TL;DR:

  • A brief is one page that answers: what problem, what goal, what is in and out of scope, when, and who.

  • Writing the brief forces the disagreements out early, when they are cheap to fix.

  • Share it before work starts, ask for objections, and update it when something real changes.

Two weeks into a project, the designer is polishing a page nobody asked for, the writer is waiting for a decision, and the person who requested the work is surprised by the direction. Nobody did anything wrong. They just never wrote down the same picture of the job.

A one-page brief is the cheapest fix. It takes an hour to write and a few minutes to read, and it turns hidden assumptions into sentences that people can agree or disagree with. The page limit is the feature: it makes you choose.

When a brief is worth writing

Reach for a brief when several people are involved, when the job runs past a few days, or when others depend on the result. A ten-minute task needs only a message. Anything larger repays the time the brief saves.

Talk to the people who care first

A brief written alone is a guess. Before you draft, ask the person who wants the work two questions: what is going wrong now, and how will you know it is fixed? Ask the people who will do the work what they would need to start. Take notes and use their words.

The five parts

  • Problem: what is wrong or missing today, in two or three sentences. No solutions yet.

  • Goal: what will be true when the project succeeds, ideally something you can check.

  • Scope: what is included, and just as important, what is not.

  • Timeline: the start, the main milestones and the end date, with calendar dates.

  • Owners: who is responsible for the result, who does the work, and who must approve.

Keep each part short. If the problem takes a page, the project is probably two projects.

A goal you can check

"Improve the website" is a direction. "Visitors can find the opening hours and order a loaf from their phone" is a goal, because someone can try it and say yes or no. Where a number helps, write the number plus how you will measure it. Do not invent a target you have no way to measure.

Worked example: a brief for a website refresh

A small bakery wants to refresh its website. This is an invented example, to show how the five parts fit on one page.

Part

What the brief says

Problem

The site looks dated, opening hours are hard to find, and ordering needs a phone call. Customers often ask by message for information that should be on the site.

Goal

A visitor on a phone can find the hours, see this week's menu and place an order request in under three screens of scrolling or tapping. We check this by asking five customers to try.

In scope

New home, menu and contact pages; updated photos; an order request form.

Out of scope

Online payments, a shop for non-bread products, translating the site.

Timeline

Kick-off Mon 2 Nov, text and photos ready Fri 20 Nov, build done Fri 4 Dec, launch Mon 14 Dec.

Owners

Owner: Sam (approves). Writing: Priya. Photos: Marcus. Build: Dana.

Check the dates. Counting from 2 November 2026 (a Monday) to 20 November is 18 days, which is two and a half weeks. From 20 November to 4 December is 14 days, two weeks. From 4 December to 14 December is 10 days. So the whole project runs 42 days, which is six weeks, from 2 November to 14 December. If a milestone does not land on a working day, the brief is wrong, so check each date on a calendar.

Notice what the out-of-scope line does. When someone later asks for online payments, the brief gives a calm answer: that is a separate project, here is why. It stops the scope from growing a little each week.

Share it, then change it on purpose

Send the brief to everyone named in it and ask: "What here is wrong, or missing?" Give a deadline for replies. Fix what you hear, then treat the brief as the reference.

The brief is not frozen. If the timeline moves or the scope changes, edit the page, add the date of the change and tell the group. The point is that nobody works from a version that quietly stopped being true.

Mistakes to avoid

  • Describing the solution before the problem. "Build an app" is not a problem.

  • No out-of-scope list. Everything left unsaid will be assumed to be in.

  • Two names against one task, or none.

  • Dates written as "end of month" or "Q1" with no day.

  • Writing the brief and never sharing it.

Doing it faster

Keep a blank one-page template with the five headings and a line of guidance under each. For the next brief, copy the template and fill it in during a short call. If you want help spotting vague spots, DuckyHelper can read the page on your screen with you and point at sentences that a stranger could read two ways.

Frequently asked questions

Can a brief be longer than one page?

It can, but a longer document is read less and argued with less. Keep the page, and link to supporting detail for anyone who needs it.

Who should write the brief?

Whoever is closest to the work, after talking with the person who asked for it. The person who asked should read and approve it.

Get started

DuckyHelper can
do more

It sees your screen and works in any app you use. Try it for 10 minutes, no card.

Get it for Mac, Windows or Linux

Share

Questions and jobs

Do anything

Ask it a question or hand it a job, in any app.

Doing jobs for you is in early access on Mac. Asking works on Mac, Windows and Linux.