A project starts with a conversation. A useful brief makes that conversation concrete, even when the final solution is still taking shape.
Who is it for?
Describe the people who will use the result and the task they need to complete. A customer browsing on a phone has different needs from a team reviewing a dashboard every Monday.
What needs to improve?
Explain the current situation in plain language. Include examples of confusing screens, repeated manual steps or information that is difficult to find. Avoid sharing passwords, personal data or confidential business records in an initial inquiry.
What already exists?
List the content, brand assets, systems and data sources you have. Note who owns them and what permission is needed to use them.
How will you judge the result?
Choose a few observable acceptance criteria: a visitor can find a service, a report answers an agreed question, or a product label is readable at its intended size. These give reviews a clear purpose.
What are the constraints?
Share your timeline, budget range, dependencies and handover needs. Knowing these early helps define a realistic first version.
You do not need a perfect specification to get started. Tell me what you have in mind and we can work through the details together.