A practical guide / By f13s
Start with a question.
Write a better brief.
A useful project brief explains the problem, the audience, the desired outcome and the constraints. For media, AI agents or software, start with what someone needs to achieve. Then define the smallest piece of work that would make a meaningful difference.
What problem should the brief explain?
Describe what happens today and what you want to change. Name the person who experiences the problem, the situation they are in and the outcome that would help them. A deliverable such as “an app” or “a video” can be part of the brief, but it does not explain the need on its own.
For example, a hypothetical product launch might begin with: “People reach our website but do not understand how the product fits into their working day.” That gives the creative and software work a shared question to answer. It is more useful than choosing a format before understanding the gap.
Bring evidence when you have it: customer questions, examples of a repeated task, existing content or observations from people using the current experience. Mark assumptions clearly so they can be checked.
Which f13s department is the right starting point?
Choose the department closest to the main problem. A project can involve more than one discipline, but it helps to identify the first outcome and the work that supports it.
Media ↗
Start here when you need to clarify a message or create marketing content. Include the audience, channels, footage or brand assets, and the response you want to encourage.
Useful first outcome: one agreed creative direction and a defined set of content formats.
Agent ↗
Start here when a repeated workflow needs automation or assistance. Include sample inputs, the tools involved, the decisions being made and the points that need human approval.
Useful first outcome: one bounded workflow with clear success and handoff conditions.
Software ↗
Start here when people need a website, app or digital workflow. Include the user journey, target platforms, existing systems and the data needed to complete the task.
Useful first outcome: one complete user journey with agreed acceptance criteria.
What needs to be decided before work begins?
State the required deliverables, timeline, budget range if known and the person responsible for feedback. Separate fixed requirements from preferences. Explain which existing assets can be reused and identify any access, licensing or platform dependencies.
For an agent, boundaries also include what information it can read, what it can change and when it must stop for review. For software, describe user roles and the data they can access. For media, identify approval requirements and where the finished assets will be used.
How will you know the first version is useful?
Write acceptance criteria that someone can check. For example: a visitor can understand the offer and find the relevant service; a support workflow routes an unsupported request to a person with its context; or an app user can complete the essential task on the required device.
Keep optional ideas in a separate list. This protects the purpose of the first version without losing ideas that may become useful later.
Your starting point
A brief you can use.
Copy these prompts into a document. Short, specific answers are more useful than polished language. If something is unknown, say so.
- Problem: What happens today, and what needs to change?
- Audience: Who is this for, and what are they trying to do?
- Outcome: What should be possible after the project?
- Scope: Which deliverables or steps belong in the first version?
- Inputs: What assets, information and systems already exist?
- Boundaries: What permissions, approvals or constraints apply?
- Success: What observable result would show the work is useful?
- Practicalities: Who reviews the work, and what timeline or budget constraints matter?