Project brief: what it is and how to complete one before starting work

A brief gathers information before you promise a result

A brief is a short set of questions and answers about the work ahead. It helps you understand the client's problem, constraints and criteria for a useful result.

A client asks for “a modern page for a course”. The designer imagines a striking presentation, the marketer expects webinar registrations, and the course owner wants payments for an existing product. While the team debates colours, it has no shared answer about what visitors should do. This illustrative example shows why it helps to start with questions.

A brief can be a document, a form or the outcome of a conversation. Choose a format that helps the client give meaningful answers. A long questionnaire does not guarantee quality: when a question is unclear, people often reply with a convenient generalisation.

An example brief for a course landing page

The unknowns are explicit here. That is better than inventing a date to fill a field. Before making a public promise, the team must confirm it or choose an honest way to describe enrolment. The condition that there is “one approver” also needs a real agreement within the client's team.

Include available examples and explain what works in each one: the structure, tone or way of presenting the programme. A link accompanied only by “make it like theirs” leaves the person doing the work to guess someone else's preferences.

How to clarify answers without an interrogation

Replace abstract judgements with specific situations. Instead of asking “what makes you unique?”, ask why someone chooses this course, what they have already tried and what worries them. Instead of “what style do you want?”, compare two examples and ask which elements are suitable.

Do not treat the client's answers as established market facts. “Everyone needs a course like this” is an assumption until there is supporting evidence. The page can describe confirmed programme content; disputed promises need a separate check.

How a brief differs from a specification

A brief describes the starting situation and expectations. A specification turns the agreed solution into requirements you can check: which sections are needed, which form states must be handled and what counts as finished. Research, discussion of alternatives and clarification of scope may come between the two.

For a small task, both sets of information can fit in one document. It still helps to recognise the transition: “we want enquiries” does not define the form fields, consent requirements or what happens after submission. Estimating the entire implementation from that phrase leaves most conditions hidden.

1. Mark the information that is confirmed.
2. Keep open questions in a separate list.
3. Clarify the solution and the boundaries of the work.
4. Agree on a verifiable result before making final commitments.

Working through answers: turning “we want something modern” into a clear task

Suppose the course client says: “We need a modern website to get more enquiries.” That gives the conversation a direction, but it is not enough for an estimate. Ask three follow-up questions: who visits the page, what currently stops them from making an enquiry, and what happens after submission. In this illustrative example, visitors do not understand how much practice they will get, worry they will struggle and want to check the schedule before buying.

The page now has a more specific purpose: help someone new to the field assess the course format and request a conversation. Supporting information includes a sample assignment, a clear syllabus, the instructor's experience and participation conditions. An attractive opening screen cannot replace that information. If the materials are not ready, record an owner and a delivery date for each one in the brief, instead of inventing graduate outcomes.

Discuss budget together with scope: “What range can we consider, and what must it cover: copy, design, development, photography or ongoing support?” A single answer such as “up to RUB 100,000”, without a scope of work, creates false clarity. The amount here is a hypothetical constraint, not a market price for the service. You cannot promise the full wish list before estimating it.

Ask what specifically works in a reference: one may have a clear syllabus, another large photographs and a third a simple form. Record separately what must not be copied. References then become a discussion of choices rather than a demand to “make it like theirs”.

Resolving contradictions before estimating the project

The client may want three things at once: launch next week, have five people approve the copy and show a programme that is not yet confirmed. Do not hide this behind a “brief completed” status. Flag the contradiction and offer a choice: limit the first release to confirmed information, change the deadline or change the approval process. The client makes the decision with an understanding of the consequences.

Separate answers into “confirmed”, “assumed” and “to find out”. For example, the course owner has confirmed the beginner audience, the conversion expectation is still a hypothesis, and the start date is unknown. A brief must not turn an assumption into a requirement. For each unknown, name the person who can answer and the point after which a missing answer changes the plan.

Before ending the conversation, restate the task in your own words: “We are building a page to introduce the course and collect requests for a conversation; payments and the student account area are outside the scope; one representative approves the copy.” Ask the client to confirm that wording. Then prepare an estimate or the next document: a specification. The brief explains why the work is needed and under what conditions; the specification explains how the agreed result will be checked.

You can send the template below before the meeting, but you do not have to make the client fill in every item alone. For a complex commission, it is often more useful to work through the questions together and send back a concise agreed version after the conversation.

Open the template: copy it or save it as a PDF

Record the next step after the brief

Start with one task: “Confirm the start date and the page approval process.” In its description, state the expected output: confirmed answers from the course representative, with unresolved conditions clearly marked. You do not need to transfer the whole article into the app; keep what you will need when doing the work.

DesktopMobile

View screenshot ↗

Close ×

A task card in the real Sinqly interface: the title and description help preserve the intended result. The screenshot shows an illustrative client proposal in Russian.

Schedule the questions before estimating and starting production. If an answer depends on the client, allow time for correspondence and do not treat waiting as guaranteed readiness.

1. Create a task with a specific action in its title.
2. Add the completion conditions and necessary context to the description.
3. Choose a day and check whether the work fits alongside your other commitments.

DesktopMobile

View screenshot ↗

Close ×

The Sinqly task overview shows actions and dates in an example project. The screenshot uses Russian demo data; you can build your own plan from the same kind of concrete steps.

Signing up for Sinqly is free. You can also work through the article's example in an ordinary document; the app helps you return to the actions you chose.

How to check the completed brief

Show the brief to someone who was not in the conversation. Can they explain the audience, the intended visitor action, the constraints and the next open question? If not, add the missing explanation. If they can, do not expand the questionnaire just to make it feel comprehensive.

Keep one current version. Any new agreement about the scope must be recorded there, rather than left in a stray message. When something changes substantially, revisit scope, timing and how the result will be checked.

A brief is useful when it reduces guesswork. Its purpose is to support the next decision, not replace every conversation with the client.