In this article
- What goes into a website project brief?
- Which accounts and records should you gather?
- How do you prepare content and bilingual review?
- How should an example schedule show dependencies?
- What should a change request contain?
- What must be checked before launch and handover?
- How do you turn the checklist into a useful inquiry?
Which accounts and records should you gather?
Inventory the domain, hosting, content system, analytics, search accounts and connected services. Record the business owner of each account and the person who can grant suitable access. Do not email shared passwords or paste credentials into a project inquiry.
For an existing site, collect the important URLs, known redirects and pages that generate inquiries. Record forms, download destinations and integrations as part of the inventory. The working site may contain dependencies that are absent from a design mockup.
Use a secure, agreed access process after the project team is confirmed. Ownership should remain clear throughout the build. Record any license or account that cannot be transferred at handover.
| Record | Owner to identify | Evidence of readiness |
|---|---|---|
| Domain and hosting | Business account owner | Access method confirmed |
| Content and images | Factual reviewer | Approved files and usage rights |
| Existing URLs | Site owner | Keep, change or redirect decision |
| Forms and integrations | Receiving team | Destination and test access |
| Analytics and search | Measurement owner | Account and consent requirements |
| Approvals | Decision maker | Review responsibilities and availability |
How do you prepare content and bilingual review?
For every page, identify the person who can confirm prices, qualifications, service limits and contact details. Supply original images with permission and describe what they show. A draft cannot safely fill missing business facts with a plausible claim.
A bilingual project needs equivalent facts as well as natural wording. Review currency, units, exclusions, examples and contact instructions in both languages. Name the person who can approve Spanish and the team that will answer Spanish inquiries.
Keep a content inventory with draft, review and accepted states. A page marked accepted should have an identifiable version. If the facts change after layout approval, record whether the change affects design, delivery or a quoted integration.
How should an example schedule show dependencies?
Here's an illustrative schedule: brief approved in week 1, layouts in week 2, content in weeks 2 to 3, development in weeks 3 to 5 and acceptance in week 6. It's a planning sketch, and no project of ours is promised on it. The real sequence depends on scope and how quickly inputs arrive.
Separate working time from waiting. If content approval is due on Tuesday but arrives the following week, show the decision delay and its effect on the next task. Do not hide it inside a vague production estimate.
For each stage, name the output, reviewer and acceptance record. Use the existing AI Growth Systems process page to compare delivery stages with the inputs in your brief.
| Gate | Input | Output to review |
|---|---|---|
| Scope | Business task and page inventory | Accepted work and exclusions |
| Layout | Content outline and user task | Mobile and desktop structure |
| Content | Approved facts and assets | Accepted language versions |
| Development | Accepted design and connections | Reviewable working pages |
| Launch | Test results and owners | Release decision and open issues |
What should a change request contain?
A change request should show what was agreed, what is now requested and why the difference matters. Adding a second language, a new payment flow or additional approval teams can affect more than page count. Ask for the price and schedule effect before the change becomes assumed work.
Keep corrections distinct from new requirements using the contract's definitions. A broken agreed form needs repair; a newly requested integration needs scope review. The proposal should state the revision process and who can approve additional work.
Use one decision record when several people give feedback. Conflicting instructions should be resolved by the named approver before the team begins another design cycle.
What must be checked before launch and handover?
Check the agreed tasks on mobile and desktop, including keyboard use, readable errors and the contact path. W3C's form guidance recommends clear feedback for errors and successful actions. A message saying sent still needs separate proof that the business received the record.
Review old-to-new URL mappings for a redesign. Google documents redirect and migration considerations when addresses change. Confirm that the intended pages, language links and search instructions match the release decision. Save the tested URLs and dates.
Handover should identify account owners, editable files, licensed components, backup responsibility and the support boundary. A release with an unresolved blocker needs an explicit decision, not an undocumented assumption that somebody will fix it later.
How do you turn the checklist into a useful inquiry?
Send the public website address, planned user task, approximate page scope and the main readiness gaps. Include the requested timing as a planning constraint. Ask which dependencies must be resolved before work can be scheduled.
You do not need to provide private account access in the first form. Start with the inventory and the people who control it. Confirm a suitable access method only after the receiving team and project responsibilities are established.
Compare the proposal with your brief before signing. Check that deferred work, recurring service terms, outside charges and acceptance gates remain visible. Retain both versions so later changes can be explained.
Sources and further reading
Read the original guidance alongside the practical examples in this article.