Briefing template for designers: 32 prompts and a readiness score
Copy a 32-prompt briefing template for designers, use an 8-field quick version, and score project readiness with a practical 20-point check.
Kristian Hoffmann
SaaS founder and operator
A useful briefing template for designers is a decision document: it states the problem, audience, objective, scope, deliverables, inputs, constraints, review route, and definition of done before visual work starts. It asks the client for context and decisions without asking them to design the answer.
The master template below contains 32 prompts for substantial projects. An eight-field version covers smaller assignments, while a 20-point readiness score shows which unanswered questions need attention.
A brief is ready when the designer can make the next decision without inventing client intent.
Copy-ready briefing template for designers
Create one answer beneath each prompt. Give every answer one of three statuses: Confirmed, TBC — owner and resolution date, or Not applicable. If a client lacks the vocabulary to answer a creative question, present two or three concrete options instead of accepting a vague adjective.
1. Project snapshot
1. What is the project name and the request in one sentence? 2. What type of project is this, and where will the result be used? 3. Who is the daily contact, and who owns the final decision? 4. What is the requested release date or window, and how flexible is it?
2. Background and problem
5. Why is the project happening now? 6. What exists today, and what should be retained, changed, or removed? 7. What specific user or business problem should the work address?
3. Audience and context
8. Who is the primary audience, and who is explicitly secondary or excluded? 9. In what situation will that audience encounter the design? 10. What should the audience understand, decide, or do next? 11. Which questions, objections, language needs, or accessibility requirements affect the work?
4. Objective and evidence
12. What is the single priority objective? 13. What observable evidence would indicate that the design is doing its intended job? 14. Which outcomes are useful but outside this project's objective?
5. Scope and deliverables
15. Which pages, screens, assets, or components are included, with counts where possible? 16. Which sizes, formats, breakpoints, variants, and interaction states are required? 17. Where will each deliverable be used, and what must the handoff package contain? 18. What is explicitly outside the assignment?
6. Content and assets
19. Which approved files, copy documents, data sources, and URLs already exist? 20. Which inputs are missing, who owns each one, and when is it due? 21. Who verifies and approves final copy, claims, product data, and other supplied content?
7. Brand and creative direction
22. Which brand guidelines, design-system components, or existing identity elements apply? 23. Which references are relevant, what specific element is useful, and why? 24. Which visual or tonal approaches should be avoided, and for what reason?
8. Functional and technical constraints
25. Which platform, CMS, production environment, or vendor specification governs delivery? 26. Which functionality, integrations, responsive states, and error states need designs? 27. Which technical, content, localization, or accessibility constraints are fixed?
9. Review and approval
28. Who collects and consolidates stakeholder feedback? 29. Which review checkpoints, planned revision rounds, and response windows apply? 30. Who gives final approval, and where will that decision be recorded?
10. Delivery controls
31. Which milestones and dependencies affect the sequence, and who owns each dependency? 32. Which budget, effort, purchasing, or production boundary should influence design choices?
That is 32 prompts across ten sections. The count is not an industry benchmark; it is a deliberately auditable framework. Every prompt either defines a decision, identifies an input, or names responsibility.
The brief should sit beside the proposal, scope document, project plan, and feedback record rather than absorb all of them. In particular, an answer to prompt 32 gives the designer a working boundary. Commercial terms still belong in the document used to agree them.
Use the eight-field brief only when four conditions hold
A simple briefing template for designers is suitable when all four of these conditions are true:
- There is one named decision owner.
- The assignment contains no more than three deliverable types.
- The work has one main channel or usage context.
- No unresolved integration or functional dependency can change the design.
If a project meets those conditions, use this eight-field brief:
1. What are we making, and why now? 2. Who is it for, and what should that person do next? 3. What is the priority objective, and what observable evidence matters? 4. What exactly will be delivered, including counts, formats, and variants? 5. Which assets are supplied, and which are missing? 6. What creative direction applies, and what should be avoided? 7. What date, dependency, and working boundary shape the assignment? 8. Who consolidates feedback, and who approves the result?
Move to the 32-prompt version if any condition fails. A small logo refinement with one approver may fit eight fields. A rebrand, webshop, or multi-stakeholder website usually needs conditional questions and a fuller record.
Keep the brief separate from four neighboring documents
Canva describes a design brief as a short document containing the details a design team needs. The RGD client/design brief resource emphasizes objectives, goals, rationale, milestones, and audience. A Milanote design brief summary also names scope, objectives, audience, budget, and timeline. Those elements belong in the brief, but not every project record does.
| Artifact | Question it answers | Typical owner | Update pattern |
|---|---|---|---|
| Intake questionnaire | What did the client initially tell us? | Client | Submitted once, then clarified |
| Design brief | Which context, objective, and boundaries guide design? | Designer and decision owner | Versioned when a decision changes |
| Scope document | Which work and commercial conditions were agreed? | Service provider and client | Changed through the agreed commercial process |
| Project plan | Who does what, in which sequence, by which date? | Project owner | Updated throughout delivery |
| Feedback log | Which comments became decisions? | Feedback owner | Updated at each review |
This separation exposes contradictions. If the brief names five page templates but the scope names four, the discrepancy is visible. If a stakeholder sends a new direction by email, it remains a suggestion until the decision owner updates or supersedes the brief.
Write the brief in seven decision passes
Completing the template from top to bottom can produce shallow answers because later decisions expose earlier gaps. Seven focused passes create a cleaner review sequence.
Pass 1: Reduce the background to current state, trigger, and gap
A company history is not a project rationale. Record three things instead:
- Current state: what the audience sees or uses now.
- Trigger: why work has been requested at this point.
- Gap: what the current material fails to explain or support.
For example: *The existing product page presents three service tiers with the same visual priority. A new tier is being introduced. Prospects need a clearer way to identify which tier matches their situation.* This gives the designer a problem to organize without prescribing a layout.
Pass 2: Choose one priority objective
Separate the intended effect from the proposed design treatment. *Add an animated comparison* is a solution. *Help a qualified visitor distinguish three offers* is an objective.
Add an observable check that the project team controls. For a landing page, that might be whether a review participant can identify the intended audience, summarize the offer, and locate the next action. Do not invent a percentage uplift or revenue target merely to make the brief sound measurable.
Secondary objectives can remain, but rank them. If brand expression, lead capture, and product education are all labeled first priority, the brief has deferred the central trade-off to the designer.
Pass 3: Describe an audience situation, not a demographic label
*Small-business owner, age 30–50* says little about the design decision. Use a compact situation statement:
The primary audience arrives after comparing two providers, needs to confirm implementation effort, and hesitates because the service boundaries appear unclear.
Then identify the implications: vocabulary the person recognizes, information required before action, likely objections, device or environment constraints, and material that should not be assumed. If the project serves distinct audiences with incompatible needs, name a primary route or define separate journeys.
Pass 4: Express scope as countable nouns
*Redesign the website* is an ambition, not a deliverable list. Write each output as a noun with a count and required states:
- One responsive landing-page design with desktop and mobile compositions.
- One pricing component with default, selected, loading, and error states.
- Three campaign graphics in dimensions supplied by the publishing channel.
- One annotated handoff file plus an asset manifest.
Follow the included list with exclusions. Copywriting, custom illustration, implementation, photography, localization, or additional breakpoints should be identified as included, excluded, or unresolved rather than left implicit.
Pass 5: Turn assets into a manifest
Do not treat *client will supply content* as a completed answer. Give each input five fields: asset name, required format, owner, status, and due date. A logo can be present but unusable for the intended output; a product screenshot can be current but unapproved.
Useful statuses are Ready, Needs review, Missing, and Replaced. Link to the current file rather than describing its location as *in the email thread*. If an upload limit or accepted format matters, verify it in the actual collection and production systems instead of copying an assumed limit into the brief.
Pass 6: Translate taste into observable direction
Words such as *modern*, *premium*, and *clean* conceal disagreements. Ask what each word means in this project. A client might use *editorial* to mean large type, restrained color, generous image crops, or merely a reference they like.
Annotate every reference with three notes:
1. The element to examine, such as hierarchy, pacing, typography, or image treatment. 2. The reason it supports the objective or audience. 3. The element that should not be copied.
This keeps references from becoming requests to imitate an entire competitor page. Negative direction deserves the same precision: replace *not corporate* with the exact cues the client associates with that description.
Pass 7: Close responsibility, timing, and review
A date without dependencies is only a preference. Work backward from the requested release and name content delivery, stakeholder review, production, and approval as separate events. Assign an owner to each one.
Define feedback mechanics before the first presentation: one collector, one location, named checkpoints, and a final approver. Contributors may comment, but the brief should state who resolves conflicting comments. If a delayed input changes the feasible sequence, update the plan rather than silently compressing later work.
Budget or effort belongs in this pass when it changes the design route. A fixed illustration allowance, a limited development allocation, or a vendor production ceiling can rule out otherwise attractive concepts. Record the boundary and who can authorize a change.
Score brief readiness out of 20
The following Brief Readiness Score is an operational decision framework, not an industry benchmark. Score ten checks from 0 to 2, producing a maximum of 20 points.
| Check | 0 points | 1 point | 2 points |
|---|---|---|---|
| Problem | Missing | Broad symptom | Specific current-state gap |
| Audience | Everyone or absent | Segment named | Segment plus usage situation |
| Objective | Treatment only | General intention | Priority objective plus observable check |
| Scope | Open-ended | Partial list | Counted inclusions and exclusions |
| Deliverable specifications | Names only | Some formats or states | Count, use, format, variants, and handoff |
| Content and assets | Assumed | Inventory without owners | Status, owner, and due date recorded |
| Creative direction | Adjectives only | References supplied | References annotated with reasons and limits |
| Constraints | Missing | Some constraints named | Fixed constraints and verifier identified |
| Feedback ownership | Multiple uncoordinated voices | Collector implied | Named collector and feedback location |
| Approval and timing | Date only | Approver or checkpoints named | Approver, checkpoints, dependencies, and record |
Calculate readiness = sum of the ten scores. Use these house rules:
- 16–20: design can be scheduled if every hard gate also passes.
- 11–15: continue discovery and resolve the lowest-scoring items before production.
- 0–10: the record is still intake material rather than a usable design brief.
The four hard gates are scope, deliverable specifications, feedback ownership, and approval and timing. Each must score 2 before the brief receives a ready status. This prevents a total of 16 from hiding an undefined deliverable or missing approver.
The arithmetic is deliberately transparent: ten checks multiplied by two points equals 20, and a score of 16 permits four lost points outside the hard gates. Teams can change the threshold after observing their own projects, but the scoring labels should remain stable long enough to compare briefs consistently.
Worked example: from 13 points to 18
Consider a fictional company, Northline Metrics, commissioning one product landing page. The initial briefing identifies an operations-manager audience, explains that the current page mixes three products, and includes a counted page scope. It also provides annotated visual references.
The initial score is:
| Check | Initial score |
|---|---|
| Problem | 2 |
| Audience | 2 |
| Objective | 1 |
| Scope | 2 |
| Deliverable specifications | 1 |
| Content and assets | 0 |
| Creative direction | 2 |
| Constraints | 1 |
| Feedback ownership | 1 |
| Approval and timing | 1 |
| Total | 13/20 |
The score identifies four actionable gaps rather than prompting another broad kickoff meeting:
1. The product lead becomes owner of the missing interface screenshot and receives a due date, moving assets from 0 to 2. 2. The designer records desktop and mobile compositions, required form states, and the handoff package, moving deliverable specifications from 1 to 2. 3. The marketing lead becomes the single feedback collector, moving feedback ownership from 1 to 2. 4. The founder is named as final approver at wireframe and visual-design checkpoints, with decisions recorded in the project portal, moving approval and timing from 1 to 2.
Those four decisions add five points because the asset gap was completely missing. The revised score is 18/20, and all four hard gates score 2. The objective and technical constraints remain partial, so their assumptions stay visible rather than being mistaken for confirmed facts.
Choose Word, PDF, or a portal by how answers will change
A briefing template for designers in Word and a briefing template for designers in PDF can contain identical questions, but they support different moments in the workflow.
| Format | Use it for | Main trade-off |
|---|---|---|
| Word or editable document | Drafting, commenting, and one-off projects | Files and comments can split into competing versions |
| A dated snapshot for reading or archiving | Updating answers requires returning to an editable source | |
| Collaborative canvas or design file | Workshops and visual reference annotation | Structured text, approvals, and file collection may need another system |
| Form or client portal | Repeatable intake, conditional questions, uploads, and status tracking | Setup takes more thought than sending a blank document |
For a Word version, paste the 32 prompts into a document, apply heading styles, and keep one named source file. Export a PDF only after the relevant answers are confirmed, then include the version and date in its filename. Treat that PDF as a snapshot, not as a second editable master.
The template in this article is free to copy into your own workflow; it is not an attached download. That distinction matters because a supposed free design brief template is not useful if its labels differ across the Word file, PDF, and intake form. Build each output from the same master question set.
For repeated client work, evaluate how a system handles question templates, upload validation, account requirements, approvals, and structured export. Project briefing software for designers: a practical selection guide provides a separate software scorecard, while How to choose client portal software for your agency focuses on testing the complete intake route.
Add project-specific modules without rebuilding the core
The ten-section master is the common layer. Duplicate it, then append only the module that can change decisions for the current project. A growing collection can become a Web design project template library: build faster briefs, provided each variant retains the same core statuses and approval fields.
Graphic briefing template for designers
Add questions about:
- Exact placements, dimensions, orientation, and production context.
- Required copy variants and the date at which text becomes approved for layout.
- Color, file, resolution, bleed, or finishing specifications supplied by the relevant channel or production vendor.
- Source-file requirements and responsibility for checking supplied asset permissions.
A social graphic, trade-show panel, and printed brochure should not share guessed technical specifications. Ask the channel owner or production vendor to confirm current requirements.
Brand or rebrand module
Add the brand architecture, audiences affected by the change, existing elements to retain, required identity applications, and migration order. Separate identity decisions from the production of every possible branded asset.
References need particular care here. Record whether the client is reacting to typography, tone, distinctiveness, category cues, or application quality. A folder of admired logos without annotations transfers the interpretation problem to the designer.
Landing-page or website module
Add the proposed page inventory, content owner per page, navigation model, responsive requirements, reusable components, functional states, CMS constraints, implementation owner, and handoff expectations. For each integration, identify who can confirm its current capabilities.
Keep the brief centered on intent and boundaries. Detailed acceptance checks can live with the implementation plan, linked back to the relevant brief decision.
Webshop module
Add catalog size, category structure, product-data source, variant logic, search and filtering expectations, account states, checkout states, and ownership of payment, shipping, and transactional content decisions. Mark current platform behavior as something the implementation owner must verify.
Conditional modules keep a logo brief from becoming a webshop questionnaire while preserving a familiar structure for the designer.
Turn the document into a controlled briefing workflow
A template becomes easier to operate when each project moves through visible states:
Draft → Awaiting client input → Needs decision → Ready for design → Superseded
Use five steps to move between them.
1. Prefill known facts. The designer enters the project type, agreed deliverables, contact names, and existing assets before sharing the brief. Clients should not need to repeat information already supplied. 2. Show only relevant questions. Start with the core and add the applicable project module. Mark genuinely conditional fields rather than presenting a wall of empty inputs. 3. Collect answers and files together. A shared portal can hold the brief, uploads, and approval route under one project link instead of distributing the record across attachments and message threads. 4. Validate decisions. Review vague answers, assign owners to missing inputs, and calculate the readiness score. The follow-up should target the failed checks. 5. Freeze a version. Record the version, date, decision owner, score, and unresolved assumptions. Later changes create a new version and a short change entry.
A useful change entry contains five fields: date, changed field, previous answer, new answer, and decision owner. Add schedule or scope impact when the project team has assessed one. This turns *the client changed their mind* into a traceable project event.
cluein.me is designed around this route. A designer can send one portal link, and the client can complete the briefing, upload files, and provide approvals without creating an account. The resulting handoff can be exported as an organized ZIP with structured JSON and Markdown brief data. That workflow fits teams that want the template and collected assets to remain connected.
Six ways a brief looks complete while remaining unusable
The risky brief is not necessarily short. It is falsely complete.
| Early signal | Hidden failure | Practical correction |
|---|---|---|
| *Modern and clean* appears as the full direction | Stakeholders may attach different meanings to both words | Ask for observable attributes and annotate references |
| *Increase engagement* is the objective | No one knows which audience action matters | Name one action and a reviewable sign of comprehension |
| *Website redesign* is the scope | Page count, states, and handoff remain open | List countable deliverables and exclusions |
| *Client supplies content* is marked complete | Missing or unapproved files surface during layout | Create an asset manifest with owner, status, and date |
| Five people comment independently | Contradictory instructions reach the designer | Name one collector and one decision owner |
| New answers remain in email after approval | The working brief and current intent diverge | Version the brief and record the changed decision |
A readiness score helps detect missing fields, but it cannot repair a weak answer by itself. A prompt can technically be filled while remaining vague. Read the answer as an instruction: could another designer act on it without requesting the same information again?
Frequently asked questions
What is a design briefing template?
A design briefing template is a reusable question structure for documenting a project's problem, audience, objective, scope, deliverables, inputs, creative direction, constraints, timing, feedback route, and approval owner. The completed answers form the design brief; the blank questions are the template.
Who should complete the brief?
The designer should prefill known project facts and convert client answers into usable design language. The client supplies business context, content, constraints, and decisions. Specialists confirm inputs within their remit, while one named decision owner approves the brief.
Shared authorship does not require committee writing. One person should maintain the current version and resolve conflicting contributions.
How long should a design brief be?
Use decision count rather than page count. The eight-field version fits projects that pass all four quick-brief conditions. The 32-prompt master fits work with more deliverables, stakeholders, dependencies, or technical requirements. Remove questions that cannot affect a decision, input, or approval.
Can I turn this into a Word or PDF template?
Yes. Paste the master into Word or another editable document and save that as the working source. Export a dated PDF after confirming the relevant answers. If the project changes, update the editable source, create a new PDF version, and mark the earlier snapshot as superseded.
Is this a free briefing template for designers?
The template in this article can be copied and adapted for your own client-briefing workflow. It does not include an attached Word or PDF file, so there is no mismatch between a downloadable file and the version published here.
Does a design brief replace a kickoff call?
Not necessarily. Use the submitted brief to decide whether a call is needed. A targeted discussion can resolve conflicting objectives, unclear audience priorities, or technical dependencies. Avoid using a meeting to repeat 32 answers that are already confirmed.
What should happen when the client does not know an answer?
Mark it TBC, assign an owner, add a resolution date, and state which work depends on it. If the client needs design guidance, the designer can present bounded options with consequences. An empty field hides uncertainty; a tracked unknown makes it manageable.
Can clients complete a brief without creating an account?
That depends on the collection method. Check the actual client journey before choosing a tool: open the invitation in a private browser, complete the questions, upload a test file, return later, and submit an approval. cluein.me supports a no-account client route through a shared portal link.
Test the template against one real project
Copy the master into your working system and reconstruct your latest completed project from its emails, files, and decisions. Mark every missing answer as TBC, calculate the score, and inspect the four hard gates. If the score is below 16 or a hard gate is below 2, write the smallest follow-up question that would resolve the gap.
After three projects, review the question set. Keep prompts that changed a design decision, exposed a missing input, or named an approval owner. Simplify the rest. The template should earn its length.