View All
web-dev

Website Brief Template: How to Write One Developers Love

Jawad Hakimi6 min read

A website brief template is a short, structured document that tells a developer what your business does, what the website must achieve, which pages and features it needs, who will supply the content, and what budget and deadline you are working with. A good brief takes one or two hours to write and saves weeks of back-and-forth, surprise costs and redesigns. Below is the exact structure we ask clients to fill in, with notes on what each section should contain.

Key Takeaways

  • A brief is not a technical specification; it explains goals, audience and constraints in plain language so the developer can propose the right solution.
  • The most useful sections are goals, audience, page list, features, content ownership, languages, budget range and deadline.
  • Sharing a realistic budget range up front gets you a better proposal, not a higher price.
  • Examples of websites you like (and dislike) communicate design taste faster than adjectives.
  • Decide who writes the text and supplies the photos before work starts; missing content is the most common cause of delays.

What Is a Website Brief and Why Does It Matter?

A website brief is the single document a developer reads before quoting, so it decides whether the quote you receive is accurate. Without one, every agency guesses differently, and you end up comparing proposals that describe different projects. One quote assumes five pages and a contact form; another assumes online booking and a blog. The prices look wildly different because the imagined websites are different.

A brief also protects you during the project. When a question comes up in week three, such as whether the site needs a Pashto version or whether product prices should be shown, the brief is the reference both sides return to. It turns "I thought you knew" into a clear record of what was agreed.

What Should a Website Brief Include?

A complete brief covers ten sections, and most of them need only a few sentences. Use this as your template:

  1. About the business. What you sell, where you operate, how long you have been running, and what makes you different from competitors. Two or three sentences are enough.
  2. Goal of the website. Pick one primary goal: more phone calls, online bookings, quote requests, product sales, student admissions or credibility with partners abroad. Secondary goals can follow, but one must lead.
  3. Target audience. Who will visit, which languages they read, which devices they use, and whether they are local customers in Kabul or Herat or Afghans living in Europe, North America or Australia.
  4. Page list. For example: Home, About, Services, individual service pages, Portfolio, Blog, Contact. Count them; page count drives price.
  5. Features. Contact forms, WhatsApp button, booking calendar, online payments, product catalogue, student portal, multilingual switcher, admin panel. Mark each as must-have or nice-to-have.
  6. Content. Who writes the text, who supplies photos and logos, and whether anything needs translating into Dari, Pashto or English.
  7. Design references. Three to five websites you like and one or two you dislike, with a sentence on why.
  8. Technical details. Existing domain, hosting, email, and any old website that must be redirected without losing search rankings.
  9. Budget range. A minimum and maximum you are comfortable with.
  10. Deadline and decision-maker. The launch date, why it matters, and the one person who approves designs and content.

How Detailed Should the Feature List Be?

Describe features by what the user does, not by technology. "A parent can submit an admission form with documents and receive a confirmation email" is far more useful than "we need a database". The developer will choose the right tools; your job is to describe the behaviour and who manages it afterwards.

For each feature, add who uses it and how often. A booking calendar that the owner updates once a month is a very different build from one that ten staff members update every hour. When we built online admissions and course management for Etrat Elm Educational Center, the most valuable part of the early discussion was mapping exactly who submits, who reviews and who gets notified.

Separate must-haves from nice-to-haves honestly. A clean first version that launches on time beats an ambitious one stuck in development. Nice-to-haves can become phase two once you see how visitors actually use the site.

Should You Share Your Budget in the Brief?

Yes, share a range, because a budget is a design constraint, not a negotiating weakness. With a range, a good developer can tell you what fits: perhaps a strong five-page site now and a booking system later, rather than a rushed version of everything. Without it, proposals tend to either overbuild or underbuild.

For reference, Sheen's web design packages start from AFN 21,000 for a Basic five-page site, AFN 28,000 for a Professional ten-page site, and AFN 35,000 and up for Enterprise projects with custom features. Our guide to website cost in Afghanistan explains what pushes a project from one tier to the next. Whatever range you give, ask the developer to show what is included and what would cost extra.

What Local Details Should Afghan Businesses Add?

Businesses in Afghanistan should state their language needs and their visitors' connection conditions explicitly, because both change the build. A site in Dari and Pashto needs right-to-left layout, suitable fonts and a translation workflow; adding English for partners or the diaspora adds a third version of every page. Say which language is the default and whether all pages must exist in all languages.

Mention that many visitors browse on mobile data, which is often slow or expensive. That tells the developer to prioritise lightweight pages, compressed images and fast loading over heavy animations. Also note how customers prefer to contact you. In many Afghan businesses, a WhatsApp button or a phone number at the top of the page brings more enquiries than a long form.

If you serve customers abroad, say so: time zones, currencies, and whether foreign visitors will find you through Google in English all affect structure and SEO.

Common Brief Mistakes to Avoid

Most weak briefs fail in the same few ways, and each is easy to fix:

  • Too vague: "A modern, professional website" describes every website. Use references instead.
  • Too technical: dictating frameworks or plugins without explaining the goal limits the developer's ability to recommend something better.
  • No content owner: if nobody is responsible for the text and photos, the project stalls at the content stage.
  • Several decision-makers: feedback from five people that contradicts itself doubles the revision rounds. Name one approver.
  • Forgetting the old site: if you are replacing a website that already ranks on Google, say so early. Read our checklist on redesigning a website without losing SEO before you start.

A Quick Pre-Send Checklist

Before sending the brief, check that a stranger could read it and answer these questions: What is the one main goal? Who is the visitor and which language do they read? How many pages? Which features are essential? Who supplies content, and by when? What is the budget range? When must the site go live, and who approves it? If any answer is missing, add it. Then attach your logo, brand colours if you have them, and links to reference sites.

Work With Sheen

Send us your brief, even a rough one, and we will reply with questions, a clear scope and a fixed quote for your web design project. You can also book a short call and we will fill in the template together. Reach us at info@sheen.af or +93 784 966 018.


Frequently Asked Questions

How long should a website brief be?

Most good website briefs fit on two to four pages. What matters is that each section answers a clear question: the goal, the audience, the pages, the features, who supplies content, the budget range and the deadline. A short brief with concrete answers is far more useful to a developer than a long document full of general wishes or technical jargon.

Is a website brief the same as a requirements document?

No. A brief is written by the business owner in plain language and explains goals, audience, content and constraints. A requirements document or technical specification is usually written afterwards by the developer, based on the brief, and describes exactly how each feature will be built. The brief comes first; it gives the developer what they need to propose the right solution.

What if I don't know which features my website needs?

Describe what you want customers to do and what your staff do today. For example, customers call to ask prices, and staff write bookings in a notebook. A developer can translate that into features such as a price list, a booking form or a WhatsApp button. Mark anything you are unsure about as a question, and discuss it during the first call.

Should I send the same brief to several agencies?

Yes. Sending one identical brief to two or three agencies is the fairest way to compare quotes, because everyone is pricing the same project. Pay attention to the questions each agency asks back; thoughtful questions about your goals and content are often a better sign of quality than the lowest price. Ask each one to list what is included and excluded.


Keep reading

Read More