A Better Brief for Better Work

A good brief is not a constraint on imagination. It is the frame that lets the important questions come into focus.

A brief is useful when it gives a team enough shared understanding to make decisions independently. It should describe the problem, show why it matters, and establish the boundaries of the work. The document earns its place by helping people move forward with fewer avoidable misunderstandings.

Describe a concrete situation

Begin with a person trying to do something in a specific context. What are they attempting? What information do they have? Where does the current experience become difficult? A concrete situation creates a more useful starting point than a request to make a page feel more modern.

For example, a team might need to help a workspace owner understand which invitations still require attention. That situation suggests information, decisions, and outcomes the design can address. It also provides a practical scenario against which to compare different solutions as the work develops.

Separate outcomes from proposed solutions

The desired outcome and the first suggested implementation are different parts of a brief. Helping someone find unfinished work is an outcome. Adding another dashboard card is one possible approach. Keeping those statements separate leaves room to explore whether the proposed approach actually solves the problem.

Describe success in terms that can be observed. Someone should be able to identify the relevant item, understand its state, and continue the task. That description gives reviewers something more concrete to discuss than whether a particular layout feels right on its own.

State the constraints that matter

Useful constraints explain the boundaries of a decision. The team may need to preserve an existing content model, support a particular device range, or work within a shared component library. Write those limits down early so that exploration happens within the space that is actually available.

Distinguish a firm requirement from a preference that can be reconsidered. If a constraint has a reason, include that reason. It helps someone recognize when a different approach still respects the intent, and when an apparently small change would create a larger problem elsewhere.

Give evidence a clear place

Bring together the examples that explain the problem: a confusing workflow, a repeated question, or a visible inconsistency. Describe what each example demonstrates. A collection of screenshots becomes more useful when the reader understands which part of the experience deserves their attention.

References should also have a stated purpose. One may illustrate a navigation pattern, another a useful content hierarchy. Explain which qualities matter and which are incidental. This helps the team learn from a reference without importing decisions that do not fit the current product.

Keep the brief useful during the work

A brief should remain a working reference as the project develops. Record answers to important questions, clarify assumptions that proved incomplete, and update the scope when the team makes a deliberate change. Keep the current direction easy to find rather than burying it in a long conversation.

Before the work is considered finished, return to the original situation and walk through it using the proposed result. Check whether the person can make the intended decision with the information available. A better brief makes that review possible because it established a clear purpose from the beginning.