A surprising number of project briefs are written backwards. They begin with a page count, a platform name or a list of features, then add a short paragraph about the business at the end.

That can feel efficient. It gives an agency something concrete to quote. It can also lock everyone into an answer before the real question has been understood.

A useful brief does not need to be long. It needs to give the people doing the work enough context to ask better questions.

Begin with the situation

Write down what is happening now and why the project has become important.

For a website, that might be:

  • the business has changed and the current site still describes an older version;
  • important enquiries are arriving through personal contacts but not through the website;
  • pages are difficult to update and teams have stopped trying;
  • the brand is preparing for a funding round, new market or platform review;
  • search traffic exists, but visitors do not understand the offer;
  • the site is slow, broken on mobile or full of missing links.

For a product, it might be:

  • a team is managing a critical workflow through spreadsheets and email;
  • customers need secure access to information that staff currently send manually;
  • an existing platform is expensive to change;
  • a new service needs to be tested before the company invests in a full build;
  • users can complete the task, but support requests show that the experience is confusing.

The situation gives the studio a reason to care about more than the requested output. “We need a new website” is an output. “Our sales team has to explain the business from the beginning after every website enquiry” is a problem worth designing around.

Name the people involved

“Users” is too broad to be useful.

A membership platform may involve an applicant, an approved member, an administrator, a finance team and a content editor. A marketplace may include a buyer, seller, operations team, support team and delivery partner. They may all use the same product for different reasons.

List the groups you know about and describe what each one is trying to finish. You do not need perfect personas. A few accurate sentences are more useful than fictional names and stock photographs.

For example:

New members need to understand eligibility, submit their application and pay. The internal team needs to verify the information before granting access. Existing members need resources and a clear renewal process.

That paragraph is already beginning to describe the product.

Explain what exists today

Show the current website, software, forms, spreadsheets, documents and workarounds. Include the uncomfortable parts.

A studio needs to know:

  • which systems contain important data;
  • who updates them;
  • what users already recognise;
  • which integrations cannot be changed;
  • where manual work is carrying the process;
  • what has been tried before;
  • which parts of the current experience still work well.

Screenshots, screen recordings and a real spreadsheet can be more useful than twenty pages of polished requirements.

Share the constraints early

Every project has constraints. Hiding them only delays the moment they affect the design.

Useful constraints include:

  • a fixed event or regulatory date;
  • a limited internal team;
  • a required platform or existing licence;
  • a legacy system that must stay in place;
  • languages or accessibility needs;
  • internal approval cycles;
  • security or data-residency requirements;
  • dependencies on a vendor, API or payment provider;
  • a budget range.

Budget does not need to be a negotiation trick. It helps the team recommend a proportionate route. A studio will approach a ₹2 lakh website differently from a ₹20 lakh platform, even if both begin with the word “portal.”

Describe success without inventing precision

You may not know the final metric, especially before analytics are in place. You can still describe what should be different.

Examples:

  • a prospective client should understand the offer without a sales call;
  • members should be able to renew without staff sending manual reminders;
  • an administrator should be able to publish a property without a developer;
  • the product should support the first 100 vendors without a separate process for each one;
  • the mobile checkout should reduce avoidable errors;
  • the site should provide a credible public identity for business verification.

These are useful outcomes because they can shape priorities. “Increase engagement” is too vague unless the team agrees what engagement means.

Separate requirements from ideas

A requirement is something the product must support. An idea is one possible way to support it.

Requirement:

Members need to know when their fixed deposit is approaching maturity and be able to request renewal.

Idea:

Add a red notification badge to the dashboard.

The idea may be good. It should still remain open to testing. When briefs mix every idea into the requirements list, design becomes an exercise in arranging decisions that have already been made.

A simple way to help is to label the document:

  • Must support
  • Important question
  • Current idea
  • Later possibility

That small distinction creates room for better work.

Include the content reality

Web projects often appear ready until the team asks who will write and approve the content.

State what exists:

  • approved company description;
  • service information;
  • product data;
  • case-study evidence;
  • team biographies;
  • legal and policy copy;
  • photography and logos;
  • testimonials with permission;
  • translated content;
  • search research.

Also state what does not exist. The plan can include content work, but only if the gap is visible.

Give the studio access to the right people

A project loses weeks when the people in workshops cannot answer the questions and the people with the answers never join.

Identify:

  • the project owner;
  • the final decision-maker;
  • subject-matter experts;
  • the person who understands the current system;
  • the people who will operate the new product;
  • legal, security or compliance reviewers;
  • whoever controls the domain, hosting and critical credentials.

Nobody needs to attend every meeting. The studio needs a reliable route to the right person when a decision affects their area.

Ask for a proposed route, not only a price

A useful response to a brief should explain:

  • what the team believes the problem is;
  • what remains uncertain;
  • the proposed phases;
  • who will work on it;
  • what the client must provide;
  • which assumptions affect cost or timing;
  • what will be delivered;
  • how the work will be tested;
  • what happens after launch.

A low number attached to a vague scope is not clarity. It is postponed disagreement.

A simple brief structure

You can use this structure for a website, application or product-discovery engagement:

  1. About the organisation
  2. Why this project, and why now
  3. Who will use it
  4. What exists today
  5. What is difficult today
  6. What should be different
  7. Known requirements
  8. Open questions
  9. Systems and integrations
  10. Content and assets available
  11. Constraints
  12. Indicative budget and timing
  13. Stakeholders and decision process
  14. What you want from the studio

A page or two can be enough. Attach the evidence that makes it real.

The brief is the beginning of the conversation

A good studio should challenge parts of the document. That is not a sign it ignored the brief. It is often the first evidence that the team is treating the project as a product decision rather than a production order.

The goal is not to arrive with every answer. The goal is to make the important questions visible while there is still time to change the answer.