Business Website Brief: 15 Questions to Answer Before Development

A website does not start with the homepage

Before choosing colors, a CMS, or a framework, decide what the website is meant to do. A useful brief is not paperwork for its own sake: it exposes hidden assumptions so the business owner, designer, and developer can make the same decisions.

This checklist works for a company site, a service business, or a lead-generation website. Not every answer must be final on day one, but every open question needs an owner and a decision date.

15 questions to answer

1. What is the primary business goal? Leads, sales, bookings, support, or credibility? Choose one main outcome.
2. Who is the site for? Define the audience, its problem, and its level of knowledge — not only demographics.
3. What is the offer in one sentence? If the business cannot explain it clearly, the website will struggle too.
4. What action should a visitor take? Choose the main CTA: form, phone call, WhatsApp, booking, purchase, or download.
5. Which pages are actually needed? Start with a minimal sitemap and add pages only when they support the user journey.
6. Who supplies and approves content? Assign owners for copy, images, translations, legal review, and future updates.
7. Which languages must the site support? Decide on English, Hebrew, Russian, or others — including RTL, URL structure, SEO, and maintenance.
8. Which systems must connect? List the CRM, email platform, payments, calendar, WhatsApp, analytics, and support tools, plus the owner of each account.
9. Where does a new lead go? Define fields, alerts, assignment, response time, deduplication, and backup. A form that submits but reaches nobody is a business failure.
10. How will success be measured? Select metrics tied to the goal: qualified enquiries, bookings, sales, or product usage — not traffic alone.
11. What should the SEO structure be? Define topics, headings, URLs, internal links, and pages worth indexing. Google’s SEO Starter Guide recommends clear content, descriptive URLs, and making important resources accessible to crawlers.
12. What accessibility target applies? Decide how you will test keyboard navigation, text alternatives, contrast, and form errors. WCAG 2.2 is a useful reference, not a substitute for testing with users.
13. What is the performance target? Specify devices, network conditions, and critical pages. Do not wait until launch to discover that images, scripts, or video slow down the path to a lead.
14. What data is collected and how is it protected? Document form data, access, retention, deletion, third-party providers, and logs. OWASP ASVS provides testable security requirements for web applications.
15. Who owns the site after launch? Confirm ownership of the domain, hosting, code, vendor accounts, backups, updates, and incident response.

What should come out of the meeting?

At minimum: the primary goal, audience, offer, sitemap, CTA, integrations, content owners, languages, success metrics, accessibility and security requirements, and a maintenance plan. Turn disagreements into named open decisions with an owner and due date.

The brief also makes development proposals easier to compare: not only by price, but by scope, responsibilities, and the definition of “ready”. For related reading, see EzraTech’s UX audit guide and its overview of technology choices for business websites.

The bottom line

The best brief is not the longest one. It is the one that prevents expensive decisions from being postponed. Before design starts, make sure the team can answer all 15 questions — even if some answers are explicitly scheduled for the next phase.

Sources: Google Search Central — SEO Starter Guide; W3C — WCAG 2.2; OWASP — Application Security Verification Standard.