A useful advocate website project brief records what the site should explain, who supplies and approves its content, and who will control it after launch. This checklist helps organise a developer conversation; it does not advise on what professional rules permit. For a fictional example of a professional information layout, see the lawyer portfolio sample design.
Define the purpose and scope
Start with the questions the site should answer for a visitor. List the pages or sections you expect, such as a profile, practice information, office contact details or directions. For each, note the intended reader and what information is needed. Include only functions you can describe clearly, and mark anything uncertain as a question for discussion.
Decide what is outside the first project as well. For example, an information website and an online matter-management system have different data, access and operating needs. If you want an enquiry route, describe where it should lead and who will handle it. Do not assume a form, appointment service or office workflow exists unless it is explicitly included and connected.
Prepare approved public information
Gather the factual details the practitioner wants considered for publication. Mark each item as supplied, still to be confirmed, or out of scope. Ask the practitioner to verify names, roles, descriptions, contact preferences and any other particulars before they appear on the site. Identify one person who can resolve edits and provide final approval.
This is a content-production step, not a review of professional rules, eligibility or legal compliance. The practitioner should obtain any qualified advice or review needed for the material and its publication. A developer can organise approved copy and implement the agreed pages, but a project brief cannot establish what may be published.
Confirm image and document rights
List proposed portraits, logos, certificates or other supplied assets, who provided each one, and whether it is cleared for the intended website use. Confirm that the people shown have agreed to that use. If permission or provenance is unclear, leave the item out until it is resolved; a developer should not treat a file sent by email as proof of usage rights.
Note whether new photography or design work is part of the project, who will arrange it, and what files will be handed over. Avoid sending confidential matter material when ordinary public information is sufficient for planning the website.
Choose contact and review owners
Write down which public contact destinations the practitioner approves and who controls them. State whether visitors should call, email, use an existing messaging channel, or follow another agreed route. Include the exact destination through the approved project process, and identify who will check that it works. Keep personal and practice contact choices deliberate.
Name a content owner who can provide updates and a reviewer who can approve the completed pages. These may be the same person. Agree how feedback will be collected, how conflicting edits are resolved, and who gives the final go-ahead before launch. Set a realistic review window with the people involved rather than assuming approval.
Include accessibility and phone review
Ask for readable text, clear headings, descriptive links, useful image descriptions, keyboard access and visible focus. Check that contact details and important information remain legible on a small screen and that controls are comfortable to use. Give the developer any known access needs and include time for the owner to review the site on a phone as well as a computer.
Settle domain ownership and handover
Identify who owns the domain, hosting and any other project accounts, who pays for them, and who retains recovery access. Prefer accounts controlled by the practice or its chosen owner, with access granted to the people doing the work. Record what happens if the working relationship or staff responsibilities change.
Ask what will be handed over: for example, account access, source files, a page list, instructions for routine updates and a record of any connected services. Define maintenance separately by naming the tasks included, who can request changes, and how future work will be agreed. Do not leave ownership or continuing support implicit.
A fictional project brief
The following example is invented for planning and is not a real advocate or practice. A practitioner wants a compact profile site with an introduction, approved practice information and a preferred contact route. The practitioner supplies and approves text; a designated practice coordinator gathers it and checks page details. The practitioner arranges an authorised portrait, while the developer confirms the file and its intended use before adding it.
| Decision | Agreed brief item |
|---|---|
| Scope | Profile, approved practice information and one selected contact route. |
| Owner and approver | Coordinator gathers material; practitioner verifies and approves public content. |
| Assets | Portrait supplied by the practitioner after confirming permission for website use. |
| Access and handover | Practice owner controls domain and hosting accounts; handover and maintenance tasks are listed. |
Before review, the coordinator checks the content list, contact choice, image status and phone layout. The practitioner checks the factual details and approves the material. Any unresolved publication or rights question remains open until the relevant person addresses it.
Turn the checklist into a developer brief
Send the purpose, page outline, supplied materials, named decision-makers, contact preference, account owner and handover expectations together. Separate confirmed choices from open questions so a developer can estimate the work without guessing. For a related overview of website scope, see business website services. To discuss a project, use the contact page.