A better project starts with a better question.

A useful project brief describes a change in work, not only a list of features. Before selecting a platform or framework, explain what people are trying to do and what currently gets in their way. This keeps the discussion open to solutions with different levels of effort.

Start with the audience and task. Who uses the service? What prompts them to begin? What information do they need, and what should happen when the task is complete? Include people who support the process as well as the primary user. A portal, for example, may solve a real access problem, but a clearer page or a better handoff could address it more simply.

Describe the current process in a few steps. Note where work waits, gets repeated, or depends on one person. Include examples of confusing or exceptional cases. Avoid sharing sensitive personal or business data in an initial enquiry; representative, anonymized examples are usually enough to explain the pattern.

Define what a successful first release would allow someone to do. Separate essential outcomes from preferences and later ideas. Identify constraints such as existing systems, accessibility, language, data handling, internal approvals, and who will maintain the result. If a date or budget matters, state the range and explain why.

A brief does not need to predict the final design. Its purpose is to create a shared problem statement and a useful first conversation. After that, the team can compare approaches, surface unknowns, and agree a scope that is understandable to everyone involved.