A strong design project brief does more than describe what you want designed. It gives agencies enough context to understand the business problem, define the right scope, assess relevant experience, explain their process, and build a realistic proposal.
The best brief is not necessarily the longest one. It is specific about outcomes, audiences, constraints, decision-making, and delivery while leaving room for an agency to recommend the right design approach. Use the framework below to create a brief that produces more useful proposals and makes agency comparison easier.
What a design project brief should accomplish
Your brief should help a qualified agency answer five questions:
- What business or communication problem needs to be solved?
- Who is the design for, and what should those people do or understand?
- What deliverables are required, and what remains open to recommendation?
- What constraints affect strategy, production, budget, timing, or approvals?
- How will the team define a successful outcome?
If a brief answers only the first question—“we need a new website,” “we need a brand refresh,” or “we need marketing materials”—the proposals may be difficult to compare. Agencies may make different assumptions about strategy, scope, revisions, production, and handoff.
Start with the business context
Open with a concise description of the organization, its offer, and the situation prompting the project. Include information that changes the design decision, not every detail about the company.
Useful context can include:
- What the company sells and how it makes money
- Primary markets, customer segments, or buying audiences
- Current brand, product, or communication challenges
- Recent growth, launch, repositioning, merger, or market change
- Internal teams or external partners involved in the work
For example, “We need a more modern look” is subjective. “Our sales team is entering a new enterprise market, but current materials were built for small-business buyers and do not explain our implementation capabilities” gives an agency a more actionable starting point.
Define the problem before listing deliverables
A deliverable is an output. The problem is the reason the output is needed. Put the problem first so agencies can evaluate whether the requested deliverables are sufficient.
Describe what is not working today and how it affects the business. You might mention inconsistent communications, unclear positioning, poor usability, slow production, limited internal capacity, or a mismatch between the current brand and the intended market.
Then state the desired change. A useful format is:
Because current situation, we need to help audience do or understand desired change so that business outcome.
This structure keeps the project focused on outcomes without pretending that a particular design solution has already been proven.
Describe the audience and their decision context
“Our target audience is everyone” does not give an agency enough information to make sound design decisions. Identify the most important audiences and explain what they know, need, fear, or value.
For each primary audience, consider including:
- Their role, industry, location, or buying responsibility
- What triggers their interaction with the brand
- What they need to decide or accomplish
- Questions or objections that commonly slow the decision
- How they currently encounter the company or product
Also distinguish users from buyers, approvers, influencers, and internal stakeholders. A design may need to persuade an executive, support a technical evaluator, and remain usable for an operations team. Those differences can materially affect the recommended approach.
Separate fixed requirements from open questions
A brief should make clear what is already decided and what you expect the agency to help determine. This distinction prevents unnecessary assumptions and shows where strategic thinking is valuable.
Fixed requirements
- Required launch date or event date
- Existing brand elements that must remain
- Approved messaging, legal language, or accessibility requirements
- Required file formats, platforms, integrations, or production specifications
- Known deliverables and essential channels
Open questions
- Whether the project needs research or positioning work
- Which audiences should receive priority
- Whether the current visual system should be refined or replaced
- Which assets should be produced first
- How the work should be governed after launch
This is one of the most important scope distinctions in a brief. If everything is presented as fixed, agencies may be unable to challenge an inefficient approach. If nothing is fixed, proposals may become too broad to compare.
List deliverables, but define their boundaries
Provide a preliminary deliverables list while explaining what each item needs to do. Avoid treating a list of file types as a complete scope.
For each deliverable, note:
- Its purpose and intended audience
- Where or how it will be used
- Whether it is new, a revision, or an adaptation
- Approximate quantity, size, or number of templates
- Content, data, photography, illustration, or copy requirements
- Production and handoff expectations
For example, “presentation design” could mean a ten-slide investor deck, a flexible sales template, a library of master slides, or a complete messaging and narrative system. Those are different scopes even if they share the same label.
If you are unsure which deliverables are necessary, say so. Invite the agency to propose a prioritized scope and identify assumptions rather than forcing a premature inventory.
Explain the desired process and strategy depth
Agencies need to know whether you are seeking production support, design direction, research, strategy, or a combination. State the level of thinking expected before visual execution begins.
Possible inputs include:
- Stakeholder interviews or workshops
- Audience or competitive research
- Positioning and messaging review
- Information architecture or content planning
- Concept development and design exploration
- Testing, validation, or iteration
- Production, documentation, and team enablement
You do not need to prescribe every project phase. Instead, explain the decisions the process must support. An agency should be able to show how its proposed activities connect to the problem and outcomes.
For a broader overview of agency evaluation criteria, see how to choose a design agency. The brief is the input; the proposal should show how the agency will turn that input into a workable process.
Set criteria for portfolio relevance
Ask agencies to share work that demonstrates relevant problem-solving, not just visual similarity. A portfolio example can be useful because it shows experience with a comparable audience, business model, technical constraint, scale, or delivery environment.
In the brief, explain what “relevant” means for your project. You may want to evaluate:
- Experience in your industry or with similar buying audiences
- Work involving complex products or services
- Ability to extend a system across multiple channels
- Collaboration with internal marketing, product, or executive teams
- Experience preparing files, templates, guidelines, or other handoff materials
Do not require an identical past project. Strong agencies may bring useful experience from an adjacent context if they can explain the reasoning and constraints behind the work.
Specify ownership, approvals, and handoff
Many project problems occur after the design direction is approved. Your brief should explain who owns decisions, who supplies content, who provides feedback, and what the internal team needs to operate the system later.
Clarify:
- The primary day-to-day contact
- Final decision-maker and executive sponsor
- Stakeholders who must review the work
- Expected feedback method and review windows
- Who supplies copy, data, photography, or technical requirements
- Required source files, editable templates, documentation, or training
- Any licensing or third-party asset considerations
Be honest about approval complexity. A project with one accountable decision-maker is different from one requiring consensus across several departments. Agencies can plan communication and review cycles more accurately when those conditions are visible.
Include timing without disguising dependencies
Provide the desired start date, launch date, and any immovable milestones. Then identify dependencies that could affect the schedule, such as content readiness, legal review, platform access, product decisions, stakeholder availability, or procurement.
A credible timeline normally includes time for discovery, direction, review, revision, production, and handoff. If you need an accelerated schedule, say what is flexible: scope, review cycles, research depth, or launch sequencing.
A fixed date is useful information, but “launch by September 1” is not a complete schedule. Agencies also need to know when they can receive inputs, who can approve work, and whether the first release can be phased.
Share budget information and ask for a pricing model
Budget transparency can improve proposal quality because it helps agencies recommend a realistic level of strategy, production, and support. If you cannot share an exact budget, provide a range or describe the investment level you are considering.
Ask agencies to explain:
- What is included in the proposed scope
- Which assumptions affect the estimate
- How fees are structured
- What is billed separately, if anything
- How additional work or scope changes are handled
- Whether ongoing support is available and how it is priced
Do not compare totals without comparing scope. One proposal may include research, strategy, production, and documentation while another may cover only visual design. A clear pricing model makes those differences visible.
Define success and evaluation criteria
Design success should include more than whether stakeholders like the work. Identify the signals that matter to the business and the people using the design.
Depending on the project, success criteria might include:
- Clearer understanding of the offer or message
- Improved consistency across teams or channels
- Faster creation of recurring materials
- Better completion of a key user task
- Stronger readiness for a launch or sales process
- Adoption of templates, guidelines, or a new workflow
If you have baseline information, include it. If you do not, ask the agency to recommend how success should be evaluated. Avoid promising that design alone will produce a specific revenue result unless the measurement model supports that conclusion.
Ask for comparable proposals, not identical answers
To compare agencies fairly, ask each one to address the same core points:
- Understanding of the problem and opportunity
- Recommended scope and rationale
- Proposed phases, activities, and timeline
- Team structure and roles
- Relevant portfolio examples
- Client responsibilities and required inputs
- Deliverables, ownership, and handoff
- Pricing model, assumptions, and exclusions
- Risks, dependencies, and open questions
At the same time, do not force every agency into an identical solution. The quality of a proposal often appears in what the agency questions, prioritizes, or recommends changing.
Design project brief checklist
Before sending the brief, confirm that it includes:
- A concise company and project context
- The business problem and desired change
- Primary audiences and decision context
- Fixed requirements and open questions
- Preliminary deliverables and boundaries
- Expected strategy and process depth
- Relevant portfolio criteria
- Timeline, dependencies, and launch constraints
- Budget range or pricing expectations
- Stakeholders, approval path, and client responsibilities
- Ownership, source files, documentation, and handoff needs
- Definition of success
- Proposal response requirements and deadline
Common mistakes to avoid
Writing a solution instead of a problem
Prescribing a specific visual style or deliverable too early can prevent agencies from identifying a better approach. Describe the need and constraints, then explain which decisions remain open.
Hiding internal complexity
Leaving out reviewers, technical dependencies, or content owners may produce an attractive but impractical proposal. Include the people and systems that affect delivery.
Using vague quality language
Words such as “premium,” “modern,” and “memorable” need context. Explain what those qualities should communicate to the audience and how they support the business.
Ignoring the work after approval
A design system, template, or brand asset may need documentation, training, file organization, or implementation support. Include those requirements from the start.
Choosing on visual style alone
Visual appeal matters, but agency selection should also consider strategy, process, communication, relevant experience, ownership, and delivery reliability. For related trade-offs, read design agency vs. freelancer and design agency vs. in-house design.
Use the brief to improve the selection conversation
Once proposals arrive, return to the original brief and test each recommendation against the problem, audience, constraints, and success criteria. Ask agencies to explain assumptions rather than rewarding the longest document or the lowest initial estimate.
A strong design project brief creates alignment before the project begins. It helps an agency show its strategic thinking, reveals where scope needs refinement, and gives your team a practical basis for comparing proposals. When you are ready to discuss a broader design engagement, review Allinclusive’s design capabilities or use the contact page to start a conversation.
