Begin with the current situation
Describe the product, flow, or system as it exists today. Explain what users or team members experience right now and where the pain is showing up.
State the change you need
Be direct about what should be different when the work is done. That could mean a launched feature, a redesigned flow, a more stable product area, or a faster internal process.
Name the constraints
Useful briefs include time pressure, launch dates, business dependencies, internal approval realities, technical limitations, and any known scope boundaries.
Include enough context to reduce guesswork
Share what tools, systems, stakeholders, or user groups affect the work. The goal is not to overspecify every detail. The goal is to remove avoidable ambiguity.
Keep it decision-ready
A strong brief helps everyone answer the same questions: What matters most? What is urgent? What is flexible? What does success look like? If the brief does that, it is strong enough to move forward.