How to Write a Proper Website Development Brief

How to Write a Proper Website Development Brief

A website development brief is a document that defines in advance what the future website should look like, which pages and features are included and what result the client should receive.

Many business owners think that they need programming knowledge to prepare a brief. In reality, a client does not need to know HTML, PHP, JavaScript or other technologies. What matters most is clearly describing the goal, structure and expected result.

A good brief helps define the project scope in advance and reduces the risk of new pages, features and requirements appearing during development.

1. Start with the purpose of the website

First define why the company needs a website and what problem it should solve.

The website may be intended to present the company, generate inquiries, sell products, present services, publish information or create a catalogue.

You do not need complicated terminology. A simple statement is enough: “The website should present the company and its services and allow customers to submit an inquiry.”

2. Define the website structure

The next step is to list the pages and sections that should be included in the project.

• Home;
• About the company;
• Services;
• Contacts;
• Blog;
• Catalogue;
• other required pages.

For each page, it is useful to specify whether it is included in the project. This helps define the scope before development begins.

3. Specify the language versions

If the website needs to work in several languages, this should be specified in the brief from the beginning.

State which languages are required and how many language versions the website should have. For example: Russian, Romanian and English.

It is also useful to decide who provides the translations. If translation is not included in the project, this should be stated separately.

4. Describe the design requirements

You do not need to be a designer to describe your preferences for the website’s appearance.

You can specify the preferred style, colours, brand elements and several websites as references.

If the company already has a logo, corporate colours or other branding elements, these should also be mentioned in the brief.

5. Do not forget the mobile version

The brief should specify which devices the website needs to work correctly on.

This normally includes desktop computers, laptops, tablets and smartphones.

This makes responsive behaviour a specific project requirement rather than a general request to make the website work on phones.

6. Describe the required features

Functionality can seem like the most difficult part of a website brief. However, you do not need technical terminology.

Simply list what visitors should be able to do on the website.

• submit an inquiry;
• find a service;
• browse a catalogue;
• pay online;
• contact the company through Telegram or WhatsApp;
• find the company’s address on a map.

Depending on the project, the brief may include forms, maps, galleries, sliders, search, blogs, filtering, user accounts, registration, authentication, shopping carts, online payments, catalogues, CRM and integrations with external services.

7. Specify the CMS and technologies if necessary

If you have a specific CMS requirement, include it in the brief. For example, the website should be built with WordPress.

If the technical implementation is not important to you, there is no need to choose the frontend, backend or database yourself. Simply describe the desired result.

8. Define who provides the content

Website development can be delayed if the required materials are missing. This responsibility should therefore be decided in advance.

Specify who provides:

• texts;
• photographs;
• logo;
• videos;
• prices;
• product or service descriptions;
• contact information;
• other required materials.

If necessary, you can also specify the date by which the materials must be provided to the developer.

9. Specify integrations separately

If the website needs to work together with other services, this should be included in the brief.

This may include a CRM, Google Analytics, Google Search Console, Telegram, WhatsApp, online payments or another external service.

It is better to explain what should happen instead of simply writing “CRM integration”. For example: a new inquiry submitted through the website should automatically be transferred to the CRM.

10. If you do not know the technical solution, describe the result

A client does not need to know which technology is required for every feature.

Instead of writing a technical requirement, describe what the user should be able to achieve. For example: “The user should be able to select a product category and immediately see the relevant products.”

The technical implementation can then be selected by the developer.

11. Define the project boundaries

A good brief should define both what is included in the project and what is not.

If a page or feature is not specified in the brief, it should not automatically be assumed to be part of the agreed scope. Additional features may require separate approval.

It is better to define the main requirements before development starts than to add numerous new tasks during the project.

12. A simple structure for a good website brief

If you do not have an IT background, use this simple structure:

• Goal — why the website is needed;
• Structure — which pages should exist;
• Languages — which versions are required;
• Design — how the website should look;
• Features — what visitors should be able to do;
• Responsiveness — which devices the website should support;
• Content — who provides the materials;
• Integrations — which services the website should work with;
• Project boundaries — what is included and what is not.

Conclusion

You do not need to be a programmer to write a proper website development brief. The most important thing is to clearly describe the project goal, structure, required features and expected result.

Define the pages, language versions, design, responsive requirements, functionality, content and integrations in advance. If you do not know the technical solution, simply describe what the user should be able to do.

The more clearly the project scope is defined before development begins, the fewer misunderstandings are likely to arise between the client and the developer.