INSIGHTS / WEBSITE PLANNING
What to include in a website brief before development
Practical guidance from the NYS Softech team.
NYS SOFTECH EDITORIAL • WEBSITE PLANNING
A website project becomes easier to estimate and deliver when the brief describes the work the site must do. You do not need a long technical specification to start. A clear record of your audience, pages, assets and responsibilities can prevent avoidable revisions later.
Describe the business and its customers
Explain the services or products the website must present and the customers it needs to help. Describe the action you want from each audience: an enquiry, a call, a purchase or a request for information. If several teams use the site, identify their priorities before deciding the menu.
Include your current website and explain what works well. Be specific about what must stay: a logo, font, colour system, useful page layout or established URL. A reference website can communicate a direction, but the brief should state which features you like and how those features support your customers.
List the pages and who owns their content
Create a page list with a short purpose for each page. Separate core service pages from supporting resources and policy information. For every page, decide who supplies the copy, photographs and approvals. Mark any content that still needs research rather than treating an empty heading as completed work.
Existing URLs deserve attention during a redesign. Identify important pages and discuss what happens if their addresses change. The project should include a plan for internal links and any necessary redirects. A redesigned menu should help people reach the right content without leaving older useful pages disconnected.
Document forms and operational integrations
For every form, list the fields, recipient and confirmation message. Describe what should happen after submission and who will answer. If enquiries must enter a CRM, booking system or WhatsApp workflow, include that requirement in the initial scope. An integration is more than placing a logo or link on the page.
Make a list of payment, inventory, scheduling or account requirements where relevant. Identify the service owner and how access will be provided securely. Avoid putting passwords into an ordinary project document. Agree how test transactions and test enquiries will be handled before launch.
Specify how your team will edit the site
Name the parts the team needs to update: text, banners, service cards, menus, forms, header and footer. If your team works with Elementor, request native editable components and an organised Navigator structure. Explain whether interns will need to make routine changes and what permissions they should have.
Discuss mobile behaviour as part of the design, not as a final repair. Ask how menus, card grids and large images will adapt. Also agree which animations are useful and how the site should behave for visitors who prefer reduced motion. Editing simplicity should be tested on a real page during the build.
Agree acceptance and handover checks
Write a short launch checklist covering navigation, mobile layouts, image loading, form delivery and the main customer action. Include who checks business details and who gives final content approval. Keep responsibility for hosting, domain settings, backups and updates clear.
A useful handover includes editing instructions and the location of reusable templates. Confirm that the person maintaining the website can change a page without needing to rebuild it. Record any remaining tasks and account dependencies so that a successful launch also leads to manageable day-to-day operation.
Put the plan into action
Send us your current website and a draft page list. We can help turn the brief into a practical development scope with clear editing responsibilities.
Further reading: Google Search Central — Get started with Search for developers