A project brief helps people agree what they are trying to achieve. It does not need to solve every detail before a conversation begins. It should explain the problem, the people affected and the constraints that matter.
Describe the situation before the solution
Explain how the work happens today and where it becomes difficult. Include examples: customers cannot compare products, staff copy information between tools or a website is hard to update. This gives a partner room to recommend a suitable approach.
Name the people who need it to work
List the main users and the people responsible for decisions. Include the team that will maintain the result after launch. Ask what each group needs and who will approve content, design and changes to the plan.
Explain the practical boundaries
Share any important dates, budget range, existing tools and security or accessibility requirements. If something is uncertain, say so. A clear unknown is easier to discuss than an assumption that appears late in the project.
Agree how progress will be reviewed
Describe what you want to see at key stages, how feedback will be gathered and how decisions will be recorded. Ask how changes to the work will be assessed and priced. This gives both teams a clearer way to handle new information.
Keep the first version simple
A short document with the current problem, audience, desired outcome and practical constraints is enough to start a useful conversation. Add detail as you learn. The brief should support decisions, rather than become a document nobody returns to.
