WSWhat Scene?

Learn · Process & management

What should you leave out of a project brief?

Leave out the solution. Page layouts, feature lists with no reason attached, technology choices that are not real constraints, and visual adjectives like clean or premium all decide things the studio is meant to propose. Keep the problem, the audience, the content you have, and the limits you cannot move.

The test for any line is whether it says what is wrong or how to fix it. The UK government's service manual makes the same point about user needs: describe the problem, such as needing a reminder, rather than a solution, such as an email, because the second may rule out a better answer.

Two things belong in a brief even though they feel awkward: what is explicitly out of scope, and who has the final say. A competitor link is fine if you add a line on what you admire and what you do not want copied.

A brief is a first draft that a studio is expected to question, so mark what you are unsure of instead of presenting it as fixed.

Updated October 2026

Related

Want this built, not just explained?