Write a directory project brief that prevents hidden scope
A concise brief structure that connects the directory's purpose to data, public journeys, staff operations, architecture, constraints, and acceptance evidence.
The practical answer first
A directory project brief should state the audience and decision, inventory boundary, data sources and schema, public journey, staff workflow, publishing architecture, explicit exclusions, success evidence, owners, and acceptance tests. It should make tradeoffs visible before design or development begins.
For internal project leads, agencies, clients, and vendors aligning scope before estimates, configuration, design, or custom development.
Copy this brief into the team's normal planning system and require decisions or named assumptions for every section before approving implementation.
Brief the problem and boundary
Describe the target visitor, repeated decision, why current alternatives fail, listing supplier, organizational outcome, and exact inventory boundary. Include eligibility and exclusions. Avoid goals such as become the leading directory unless they are translated into a testable user and operating outcome.
- One primary audience and decision.
- One defined listing type or compatible family.
- Clear Not in this release boundaries.
Brief the data and experience
List sources, rights, shared fields, controlled values, categories, required completeness, seed size logic, and correction plan. Outline collection, search, category, card, listing, no-result, submission, and action experiences with accessibility and mobile expectations.
- Attach representative source rows.
- Name the facts needed for comparison.
- Define canonical URL and initial-HTML expectations.
Brief workflow and architecture
Specify roles, imports, editing, review, audit history, approve-or-reject moderation, paid refund behavior, inquiry routing, analytics, domain or existing-path publishing, integrations, exports, security, privacy, and failure handling. Assign ownership to every recurring operation.
- Separate launch from steady-state operations.
- Name payment and data account owners.
- Document unsupported or deferred capabilities.
Brief evidence, delivery, and governance
Define acceptance scenarios, launch checks, primary outcome, quality guardrails, review window, budget model, decision makers, dependencies, risks, and change control. Publication is a milestone, not proof of impact. Include a first post-launch data and search review in the delivery plan.
- Use observable acceptance evidence.
- Record assumptions that could change cost.
- Name the final scope and launch approver.
Copyable directory brief
Use these headings verbatim or adapt them to the team's planning tool. Keep answers concise and link detailed artifacts rather than hiding decisions in long prose.
- 011. Decision
Audience; repeated job; current failure; listing supplier; outcome; inventory boundary; eligibility; exclusions.
- 022. Data
Sources; rights; schema; categories; required fields; seed; validation; provenance; corrections; retirement.
- 033. Experience
Entry; search; cards; details; no results; submission; action; mobile; accessibility; visible trust.
- 044. Operation
Roles; import; edit; review; payment; refunds; leads; analytics; audits; support; cadence; owner.
- 055. Delivery
Architecture; routes; canonical; sitemap; integrations; acceptance; budget; risks; launch; measurement.
Frequently asked questions
How long should a directory project brief be?
Long enough to make important decisions and assumptions visible, but concise enough to review. Use linked field models, route maps, and workflows instead of burying detail in a narrative document.
Should the brief name a specific platform?
It can record a chosen platform and constraints after evaluation, but early briefs should describe required jobs and ownership so technology options can be compared fairly.
What is the most commonly missed brief section?
Ongoing ownership is frequently missing. Name who reviews submissions, corrects records, monitors delivery, examines search gaps, and retires stale listings after launch.