A better creative brief begins with better questions
You do not need every answer before starting a project. A clear goal, an honest starting point, and a few useful boundaries can move the conversation forward.
A project often begins as an observation: the website no longer reflects the business, a workflow takes too much effort, or the brand needs a clearer direction. That observation is useful, even before it becomes a detailed brief. The next step is to ask questions that turn the concern into something a team can work with.
What do you want to make possible?
Describe the goal in terms of what should change for the business or the people it serves. A request for a new page is more useful when it also explains what the visitor should understand or be able to do. A request for automation becomes clearer when it describes the work your team wants to improve.
Keep the outcome separate from the first solution you imagined. A redesign, an integration, or a new product might be the right response, but the goal helps everyone evaluate the options. When there are several goals, agree on their order so that tradeoffs can be discussed openly.
Who is this for?
Identify the people involved and the context in which they will use the experience. A first-time customer and an internal team member have different questions. Someone using a phone between appointments may need a different path from someone carefully comparing services at a desk.
Bring what you know about these people, and mark the gaps honestly. Existing customer questions, support requests, or team observations can provide useful context. Keep observations separate from assumptions so that research has a clear job to do.
What already exists?
Collect the current website, brand materials, content, forms, and systems that relate to the work. Describe what is useful and what causes friction. This helps a project team understand what to preserve, what to improve, and what needs further investigation.
Include the less visible parts of the process. Who approves content? Who owns the data? Where do inquiries go? Which systems have access requirements? These details can affect delivery as much as the visible design, and they are easier to account for when raised early.
What are the boundaries?
Share any timing constraints, budget range, dependencies, and approval responsibilities you already know. If a date depends on another team or a system migration, say so. If the scope needs to be phased, identify what must be useful at the first release and what can follow later.
A brief can leave questions open. Its purpose is to give the conversation a clear starting point. Rocket Launch’s Resources page includes a plain-text project brief worksheet built around the goal, the people, the starting point, and the boundaries. Use it to gather your notes, then bring the parts that need discussion. Strategy, design, and delivery can develop from there.
