Website Project Brief: Template and Checklist

“We need a modern website that brings in applications” is an understandable goal, but it’s difficult to assess the scope of development. One contractor will present a page with a form, the other will present a catalog, personal account and integration with CRM. Offers will differ in price, and it will be difficult to compare them.

The terms of reference for website development should describe for whom the website is being created, what tasks it solves, what pages and functions are needed and how the customer will check the result. Below is a sample for a service website, SEO requirements and a template that can be transferred to your document.

This is a practical framework for discussing a project, not a universal specification for any business. The online store will need additional payment, delivery and returns scenarios; for a complex service - user roles and a detailed description of working with data.

How does technical specification differ from brief and design?

The brief helps you get to know the business: what we sell, to whom, in what regions, with what budget and restrictions. The technical specification turns these answers into a specific scope of work. The design shows how the pages and interface states will look.

For example, in the brief you can write: “Clients send drawings for calculations.” The technical specifications need to clarify where the form is located, what files are accepted, what their size limit is, who receives the request, and what the visitor sees after sending. The layout shows this form, tooltips, and error messages.

For a small site, all this can be collected in one document with links to layouts. What is important is not the volume of technical specifications in pages, but the absence of different interpretations between the customer and the contractor.

Start with the business problem and project boundaries

Describe the service and the main action of the visitor. “Find out the installation conditions and send a request for calculation” is more useful than “increase the company’s recognition”: the first scenario can be checked on the finished website.

Record five initial conditions:

Audience: who chooses the contractor and what information he needs to make a decision.
Geography: where the company actually operates and what restrictions there are on departure or delivery.
Suggestion: which services are launched immediately, which remain outside the scope of the first version.
Messages: form, call, letter, appointment or other primary method of communication.
Development: what sections and functions are planned later, but are not yet included in the assessment.

The “Not included in the project” section is especially useful. For example: personal account, online payment, transfer of the old catalog and multilingualism are not included in the first version. This is not a ban on development, but a way to agree on the same expectations.

If the format has not yet been selected, first compare what kind of website does a business need: landing page, corporate website or web service.

Make a list of pages and materials

List pages not only by title, but also by purpose. For a service site, the initial structure may include the main page, individual areas of work, projects, company information and contacts. An articles section makes sense if it is clear who will prepare and update the materials.

Do not create a separate page for each permutation of words in the query. “Air conditioner installation” and “air conditioner installation” may describe the same service. And installation in a finished apartment and maintenance of an industrial system require checking: are the offer, process, cost and client questions different enough to separate the pages.

For each page, indicate:

visitor task and main action;
content: composition of the service, limitations, stages, cost or calculation principle;
necessary photographs, documents and examples of work;
responsible for the preparation and approval of materials;
update method after launch.

For example, for the “Air Conditioner Maintenance” page, the customer submits a list of works and photographs of equipment, the editor prepares the text, and the manager checks the technical wording. The terms of reference separately indicate whether this work is included in the cost of development.

Also ask to separate the number of pages and the number of templates. Ten services can use one design template, but filling out ten pages still takes time.

Describe functions using scripts, not names

The wording “feedback form” does not explain what happens if the phone number is incorrect, the server is unavailable, or the button is pressed again. For each important function, describe the input data, successful outcome, and errors.

Conditional example of a requirement for an application form:

Fields: name, phone, comment. Required field - phone; other rules are agreed upon prior to development.
Before submitting, the visitor sees the purpose of the form and the necessary explanations for data processing. Texts and requirements for consents are agreed separately with the person responsible for this issue.
If you fill it out incorrectly, a clear error appears next to the field; already entered data does not disappear.
During a request, pressing again does not create another request. Repeated processing of one request on the server should also not create a duplicate.
The success message appears after the server confirms that the request has been saved, and not immediately after clicking the button.
If the transfer to CRM fails, the request is not lost: storage, error notification and retransmission are provided.
The successful request event in analytics is sent once for a successfully accepted request. Phone, name and comment are not passed in the parameters of this event.

This is an example of a design solution and not a description of the required architecture for all sites. For a simple project, the mechanism may be different, but the way to store hits and check delivery must be determined in advance.

For integrations, specify the specific system, transfer direction, list of fields and person responsible for access. “Integration with CRM” without these details does not provide a comparable estimate of labor costs.

Include SEO requirements before development begins

SEO in the terms of reference is, first of all, requirements for the structure, content and accessibility of pages. The promise “the site will be at the top” cannot be used as a criterion for technical acceptance: the release of a site in itself does not provide position and appeal.

Include checkable points in the document:

Commercial pages have consistent permanent URLs and links from relevant sections of the site.
Each indexed page has its own title, description and clear main heading H1.
The main content is accessible to the search robot; the service description does not exist only inside the image or after submitting the form.
There is no accidental prohibition of indexing on work pages, and canonical indicates the agreed primary address.
The XML Sitemap includes searchable canonical pages; technical addresses are processed according to separately agreed rules.
Non-existent pages return a valid 404 response rather than masquerading as working pages with a 200 response.

Google recommends clear site organization, descriptive headings, and accessible links between pages. This helps search find and understand content, but does not guarantee specific rankings. See Google's Guide to SEO Basics.

Google also recommends linking documents with regular HTML links and thinking through the address structure. Therefore, it is better to replace the “do SEO” item with a list of specific checks. See Google recommendations on site structure.

If an existing site is being replaced, add a map of old and new addresses, transfer of useful content and check for redirects. There is a separate section dedicated to this. redesign checklist without losing SEO. For a new project you can use a common SEO optimization plan.

Sample technical specifications for the website of an air conditioning installation company

Below is a fictitious project that shows the level of specificity. The names of services, terms and composition of functions must be replaced with your own.

Task: help the apartment owner choose a service and request an installation estimate. The company operates in one city and an agreed exit area. The online equipment store is not included in the first version.

Structure: home, installation, maintenance, examples of work, about the company, contacts and agreed information documents. The two services use a single template with different content. On each page there is a transition to the calculation form.

Service page content: what work is included, what is paid separately, what the price depends on, how the visit takes place, real photographs and answers to questions. The customer provides facts and original photographs; preparing the text is a separate task.

Applications: the form saves the phone number, selected service and comment. The manager receives a notification. If there is a delivery error, it is still possible to restore the request from the agreed storage. Successful submission is verified by a test application from the beginning until it is received by the manager.

Control: an employee can change prices and descriptions of services without editing the code. To update the structure, contact the developer. If independent editing is not required, instead of a CMS, you can agree on an update schedule - this is a different amount of work.

Acceptance: all pages, mobile version, form submission, filling errors, application delivery and analytics events are checked. Access, instructions for updating and backup are transferred to the customer. Texts and photographs on working pages have not been replaced by temporary placeholders.

Terms of reference template to fill out

Copy the items into the document and complete before requesting a final estimate. Mark unknown solutions as “to be determined” rather than leaving them to the implicit discretion of the contractor.

Company and offer: [what we sell, to whom, in which regions].
Purpose of the site: [what action should the visitor take].
First version: [what's included; which is clearly not included].
Pages: [list, purpose, main blocks, templates].
Materials: [who prepares texts, photographs, prices; transfer deadlines].
Design: [examples with explanations; branded materials; mobile version layouts].
Functions: [scripts, fields, checks, successes and errors].
Integrations: [systems, transmitted data, failure handling, accesses].
SEO and analytics: [addresses, metadata, indexing, counters and measured events].
Operation: [who updates the site; domain, hosting, backups and recovery].
Verification and transmission: [devices and browsers, test scripts, instructions, sources and accesses].
Stages and changes: [what is submitted at each stage, who agrees, how new wishes are assessed].

A list of pages, layouts and descriptions of integrations can be attached to this document. Specify application versions so that the contractor does not use an outdated layout after the next approval.

How to check readiness and avoid controversial requirements

Replace evaluative words with verifiable conditions. Instead of “convenient mobile version,” list the main scenarios on the phone: open the service, read the terms, press the number, fill out the form, see the result. Coordinate the devices and browsers on which the reception is carried out.

Instead of “fast site”, define pages, test conditions and targets. Measuring an empty home page on a powerful computer does not describe the behavior of a page with photos and connected analytics on a mobile network. One automated test point also does not replace script review.

Instead of “turnkey”, list the results of the transfer: working version on the domain, sources, accesses, update instructions, backup setup and recovery check - to the extent agreed upon for the project.

Determine the order of changes in advance. If a calculator appears after approval, its scenarios, cost and impact on deadlines are first assessed. This helps differentiate a new feature from a fix for something that was already promised in the specification.

Frequently asked questions about technical specifications

Is it possible to order a website without a ready-made technical specification?

Yes. For the first conversation, a description of the business and task is sufficient. Then the customer and the contractor clarify the requirements and fix the scope of work. Preparation of detailed technical specifications may be a separate stage; its result and cost should be discussed in advance.

Do you need technical specifications for a landing page?

Yes, but it may be short. We need page blocks, content, form, mobile states, analytics and readiness criteria. One URL doesn't mean no integrations or complex scenarios.

Who should draw up the technical specifications - the customer or the developer?

The customer is responsible for business facts, constraints and priorities. The contractor offers technical solutions, clarifies scenarios and verification methods. A document is useful when both parties understand it in the same way, rather than when it simply contains a lot of technical terms.

Is it possible to immediately get an exact price using this template?

It helps prepare the initial data, but the price depends on the features, materials, design and integrations. Compare offers for the same list of works. More details in the article about what does the cost of website development consist of?.

If you are preparing a project, collect a list of pages and tasks using a template. It can be used when applying for website development in SEOLIFT: this makes it easier to discuss the scope of the first version and the requirements for further promotion.