A website redesign proposal is easier to evaluate when every supplier is pricing the same work. For an architecture firm, that means defining more than the visual direction. Your brief needs to explain which projects will move, who can approve their publication, what happens to existing URLs and how a prospective client reaches the right person.
Use the checklist below to prepare an architecture website redesign brief before requesting proposals. It is for principals, practice managers and marketing leads commissioning a website project. It does not replace the supplier’s technical review or your firm’s approval of project information.
1. State the decision the new website should help a client make
Name the project types, clients and locations the practice wants to be considered for. Separate that objective from recruitment, awards or publishing news; those may require different journeys. Explain how a visitor should recognize relevant experience and start a useful conversation.
Describe the immediate problem using examples: a prospect cannot find comparable projects, a service is missing, the gallery is difficult on a phone, or requests reach the wrong inbox. Ask the supplier to respond to these problems rather than quote only a page count.
2. Create a project inventory before choosing a layout
Make one row for each project under consideration. Start with a small, representative selection so the supplier can assess the content work. Use these fields:
- Current project URL and proposed action: retain, update, combine or retire.
- Project type, location, stage and the services your firm actually provided.
- Approved text, photographs, drawings and any missing material.
- Required credits, publication restrictions and the person approving release.
- Relevant service or sector page that should link to the project.
Identify completed work, concepts and work in progress accurately. Do not assume a photograph already on the old site can be reused without checking the firm’s permission records. Mark unresolved rights or confidentiality questions for the person authorized to resolve them.
3. Ask suppliers to price the same content responsibilities
Separate designing a project template from populating it. A proposal that includes one reusable layout is different from one that also writes and uploads every project. Specify who prepares copy, edits images, writes captions and checks credits.
Ask for a sample using an approved project with enough content to reveal layout problems. Review a short description, a longer project narrative, a drawing and a gallery on both a phone and a desktop. Agree how additional projects and review rounds will be charged before treating them as included.
4. Include an old-to-new URL map when addresses change
Request a list of existing pages and hosted assets that may be affected. For each changed URL, identify its relevant new destination. Include project images and downloadable documents where applicable, rather than considering only menu pages.
Ask who will implement and test redirects, update internal links and check canonical URLs and indexing settings at launch. Google’s guidance on site moves with URL changes explains these migration tasks and warns that search visibility can fluctuate. Keeping a domain does not remove the need to plan changed page addresses.
5. Define the enquiry route and its acceptance checks
Record the recipient and backup owner for project enquiries. Decide which initial details are useful: reply information, project location, broad type and a short outline. Budget and timing fields should follow your qualification process, with a suitable option for someone who does not know yet.
Do not require confidential drawings through the first public form. Ask how spam controls, error messages, acknowledgement and delivery will be checked. Agree how an authorized, clearly labelled test is handled so it is excluded from genuine enquiry reporting.
6. Make usability checks part of the deliverable
Require a review of navigation, project filters, galleries, text readability and the contact route on agreed devices. Include keyboard operation and visible form labels. For project images, distinguish informative images from decoration when planning alternatives; the W3C image alternative decision tree provides a useful starting point.
Ask the supplier to record performance checks on representative pages, including an image-heavy project. Agree the test conditions and which issues will be resolved before launch. One speed score does not establish that the whole website is usable or accessible.
7. Put launch, restoration and handover in writing
Confirm who approves launch, holds the backup and can restore the affected site if needed. Record how the old content, media and relevant settings will be retained. Identify who handles incoming enquiries during the change and checks delivery afterwards.
List the accounts, source files, licenses and editing instructions included in handover. Separate one-time build fees from hosting, maintenance, software, photography and ongoing marketing. Ask what support is available after launch and how additional requests are approved.
Use the brief to compare proposals
Send the same inventory and requirements to shortlisted suppliers. Compare omissions, responsibilities and acceptance checks alongside fees. If you are also buying search work, use the architecture SEO service scope to separate that work from the website build.
For broader positioning and enquiry priorities, review our architecture firm marketing approach. Bring your public site and draft requirements to discuss a website and marketing scope for your practice; specific deliverables and fees belong in the written proposal.
