In this article
Commissioning a website involves more than choosing a design and waiting for publication. Copy, product information, forms and account access may depend on different people. If one contribution is missing, polished screens alone cannot complete the project. This guide makes the responsibilities of the organisation and production team visible from the initial discussion through acceptance. The aim is a shared view of what is ready, what is outstanding and which conditions must be met before launch.
Quick answer
Define the website’s purpose, page types, content owners and required integrations before commissioning production. Agree design approval, development, content entry, testing and handover as distinct stages. A finished project includes working user tasks, accurate information and access for ongoing management. Successful page loading is only one part of acceptance, so establish the other conditions before work begins.
Turn the page list into a readiness register
Identify the question each page answers. If a service page explains scope, working arrangements and the enquiry step, decide who prepares that information. Consider screen reading rather than copying a brochure wholesale. Record source files, owners, approval status and missing imagery. Approving a layout does not approve every claim within it. Specifications, service conditions and team details need organisational review. Handle checks during preparation rather than on the final day, identifying which old information remains valid and which should no longer appear.
Describe integrations through actual tasks
A proposal mentioning forms or reservations may still be ambiguous. Define the recipient, required fields and completion message. For another system, identify access, testing facilities and the person communicating with its provider. Imagine a training business where visitors select a programme before staff arrange a suitability discussion. That differs from automatically reserving a place. Distinguishing the two clarifies development scope and the visitor promise. Also identify who resolves missing access to external services; a connection cannot be completed simply because its name appears in a proposal.
Review design with representative content
Short placeholder headings can conceal problems appearing with real service names. Review the longest heading, an image-light page and an information-heavy example. Examine mobile navigation, headings and contact actions too. Collect feedback through one contact, explaining the difficult task as well as the appearance preferred. If visitors cannot understand service scope or the next step after submission, the revision has a clear purpose. Separate additional functionality from corrections to agreed work, since these may involve different production requirements and approval decisions.
Write acceptance checks as visitor scenarios
Testing should go beyond opening pages. Describe choosing a service, submitting an enquiry, switching to equivalent translated content and using a mobile telephone link. Specify the expected result and reviewer for each. W3C guidance covers understandable labels, instructions and form feedback. Apply these principles to sample submissions: is a missing-field message clear, and is successful completion apparent? Be explicit about scope. Several examples do not establish that every accessibility requirement has been assessed; identify remaining checks and who is responsible for them.
Treat launch and handover as different checkpoints
Before publication, discuss domain administration, redirects and existing content. List important old addresses for a replacement site and agree what moves. Check that initial real enquiries reach their intended recipients after launch. Handover should explain permissions, editing and support. Ask an organisational editor to complete a sample update rather than only watching a demonstration. Agree how future requests are considered so closure does not leave undefined new work. Think of handover as preparation for everyday use, not merely delivery of files.
Key takeaways
- Assign a preparer and approver for each page.
- Specify integrations through visitor and staff workflows.
- Include task checks and account access in acceptance.
Frequently asked questions
Can work start before content is ready?
Planning can begin, but assign missing copy and images to named owners. Discuss schedule effects and approval responsibilities. Placeholder text should not silently become final content because production has moved forward.
Should we review every page?
Review critical information, page types and primary tasks. Where many products share a template, agree a separate validation method. Reviewing the template does not confirm every specification is accurate.
Which accounts should be handed over?
The platform, domain, content system and connected services may be involved. Permissions should support organisational tasks. Distinguish ownership from technical support and record how access transfers when responsibilities change.
