Website Project Brief Template for Kenyan Businesses

A website brief is the bridge between what the business wants and what the design or development team needs to build. It prevents the project from relying on memory, WhatsApp threads, scattered screenshots or assumptions made during a first call. The brief does not have to be perfect. It only needs to be clear enough for a supplier to understand the business, ask better questions and prepare a quote that reflects the real scope.

Kenyan businesses often request website quotes with only a few lines: "We need a company website with five pages" or "We want a modern ecommerce site with M-Pesa." That is not enough. Five pages can mean a simple brochure or a serious service website with copywriting, lead forms, SEO structure, case studies, analytics and launch support. An ecommerce site can mean ten products and a simple checkout, or a complex store with product variations, delivery rules, payment testing and integrations.

The template below is built for practical use. You can paste the sections into a document, answer what you know and leave notes where you are unsure. A good web design company should help refine the brief, but it should not have to guess the basics of your business.

Start with a short, direct description of the business. Do not write a long company profile. The aim is to help the website team understand what you sell, who you serve and why the website matters now. Include the business location, service area, current website if one exists, and whether the project is a new build, redesign or expansion.

A brief should explain what success looks like. The goal might be more qualified enquiries, better credibility, improved search visibility, online sales, easier admissions communication, donor confidence or better campaign conversion. Try to avoid vague goals like "online presence." Every website is an online presence. The useful question is what the presence should make easier.

You should also define how you will judge the site after launch. For a service business, that may include quote form submissions, phone clicks, WhatsApp clicks and service page traffic. For an ecommerce business, it may include product views, checkout starts, M-Pesa payment completion and sales revenue. For an institution, it may include downloads, applications, partner enquiries or reduced repetitive questions.

• Primary goal: what the website must improve first.
• Secondary goals: trust, SEO, recruitment, support, downloads or campaign traffic.
• Key actions: calls, WhatsApp, forms, bookings, purchases, downloads or quote requests.
• Measurement: GA4, Search Console, form storage, conversion events or CRM handoff.

The audience section should describe who the website must serve. Do not stop at "everyone." A site that tries to speak to everyone usually speaks with no useful precision. List the main audiences and what each one needs to know before taking action. A school website might serve parents, students, teachers and alumni. A SACCO website might serve members, prospects, employers, board members and regulators. A business website might serve buyers, procurement teams, partners and job seekers.

Buyer questions are important because they become page sections, FAQs, guide topics and calls to action. What does the buyer ask on the phone before buying? What do they worry about? What makes them compare providers? What proof do they request? If those questions are answered on the site, your sales conversations become easier.

This is where many briefs become too thin. "Home, About, Services, Contact" is a starting point, not a complete plan. List each page you think is needed, then write what the page should help the visitor do. If you need help deciding pages, read the guide on what pages a business website should have. The clearer the page plan, the easier it is to estimate content, design and development time.

Content ownership should also be stated. Who will provide text? Who will provide images? Do you need copywriting? Are team photos available? Are project photos high quality? Are testimonials approved? Do service pages need rewriting? If the supplier is expected to write, edit or reorganize content, that should be included in the scope because it affects both quality and cost.

• Homepage: main message, service routes, proof, key calls to action.
• Service pages: offer details, buyer questions, process, pricing context, FAQs.
• About page: company story, team, credibility, location and values.
• Proof pages: case studies, portfolio, testimonials, clients or project examples.
• Contact or quote page: form fields, email routing, phone, WhatsApp and location.
• Guides or blog: topics that support SEO and buyer education.

Functionality is anything the website must do beyond displaying content. Examples include contact forms, quote forms, WhatsApp links, payment buttons, booking calendars, newsletter signup, product catalogue, M-Pesa checkout, CRM connection, downloadable documents, user accounts, search filters, dashboards and analytics events. Some features are quick. Others change the architecture of the project.

Be careful with phrases like "just add M-Pesa" or "just add a portal." Payments, accounts and integrations require planning, testing and support. If your site needs ecommerce, use the ecommerce website cost guide to understand why catalogue size, checkout, delivery and payment logic affect scope. If the website is becoming a workflow system, it may belong partly under software development, not only web design.

A brief should be honest about budget. You do not need to reveal every internal number, but a realistic range helps suppliers recommend the right approach. If a business has a starter budget, the scope should focus on the pages and features that matter most. If the website is expected to support SEO, campaigns, integrations and lead tracking, the budget must reflect that depth. The web design cost guide gives useful ranges before a formal quote.

Deadlines also need context. Is there an event, campaign, school intake, funding deadline, product launch or tender date? If yes, say so. Also explain who approves content, design and payment. A website delayed by internal approvals is still delayed, even if the supplier is moving well. The brief should identify the decision maker and the people whose input is required.

If the business already has a website, the brief should explain what must happen to the old one. Do you want a visual redesign while keeping the same URLs? Are some pages ranking in Google? Are there old blog posts, PDFs, product pages or landing pages that must be protected? Are there pages that should be redirected or removed? These details matter because a redesign can accidentally damage search visibility when old URLs disappear without a plan.

Also list who controls the domain, hosting, email, analytics, Search Console and CMS login. Many projects slow down because nobody knows where the domain is registered or who has access to the hosting account. If the current supplier controls access, say so early. If email runs through the domain, migration needs extra care so the website launch does not break business email. These are not glamorous details, but they are the details that prevent launch-day panic.

For a redesign, include the current site's strengths and weaknesses. What should stay? What must change? Which pages still generate enquiries? Which pages are outdated? Which forms are broken? Which content feels accurate but poorly presented? This helps the team avoid throwing away useful assets while still fixing the structure. A good brief does not only describe the desired future website; it explains the starting point.

Once your brief is written, scan it like a supplier. Could someone estimate the page count? Could they identify content gaps? Could they tell whether the project is WordPress, custom, ecommerce or a simple business website? Could they see the main risk? If the answer is yes, you are ready for a more useful quote conversation.

The brief should also make tradeoffs easier. If the budget is tight, the supplier can recommend which pages should launch first and which can wait. If the deadline is fixed, they can suggest a phased launch. If the content is weak, they can include copywriting or discovery instead of pretending the design will solve unclear messaging. A brief is useful because it makes these decisions visible before production begins.

• Business description and reason for the project.
• Primary website goal and key success measures.
• Target audiences, buyer questions and objections.
• Proposed pages, content sources and proof assets.
• Functionality, integrations, forms and tracking needs.
• Budget range, deadline and approval process.
• Existing website access, hosting, domain and brand assets.

A brief will not replace discovery, but it will make discovery sharper. It helps the web team spend less time extracting basics and more time improving the plan. That is usually where better websites begin.