The terms of reference for the development of the site fixes what exactly the team is creating, how the result should work and by what criteria it can be accepted. It helps the customer and the contractor equally understand the boundaries of the project.
A good technical specification does not have to be a hundred-page document. Its detail depends on the complexity of the product. For a landing page, a compact description of the structure and functions is sufficient, but for a service with user roles and integrations, a formal specification will be required.
How does a technical specification differ from a brief?
The brief collects initial information: what the company does, who its audience is, what problems the site should solve, what materials and restrictions already exist.
The terms of reference describe the agreed upon solution. Pages, functions, states, integrations, and readiness criteria appear in it.
Simplified:
- the brief answers the question “what do we know before starting work”;
- research and design help find a solution;
- TK answers the question “what exactly have we agreed to do.”
If the contractor requires the customer to independently come up with the entire structure and mechanics before getting acquainted with the product, an important part of the design work is transferred to a person without the necessary context.
When to write technical specifications
It is not always possible to completely record the TK before the study. First, the parties determine the goal and preliminary scope, then clarify the structure, and only then detail the solution.
For a project with high uncertainty, it is useful to divide the work into stages. First, conduct analytics and prototyping, get a clear architecture, and then evaluate the design and development.
This way, the estimate is based on real solutions, and not on assumptions made before getting acquainted with the problem.
What to include in the terms of reference for website development
1. Context and purpose
At the beginning, the product and the reason for starting the project are briefly described. There is no need to transfer the entire history of the company into the document. Enough information to influence decisions.
Worth noting:
- what business problem does the site solve;
- who is the main audience;
- what action is the main one;
- what problems does the current solution have;
- what is not included in the project.
The last point is especially important. Explicit restrictions protect against a situation where participants mean different volumes under one wording.
2. Page composition
A site map and the purpose of each page type are provided. For example: the main page explains the offer, the service page reveals a specific direction, the case shows the process and result, the contact page collects requests.
It is necessary to distinguish unique pages from templates. If all articles use the same structure, the terms of reference describe the article template and how to add new materials.
3. Custom scripts
A script describes a sequence of human actions. For example:
- The user opens the service page.
- Study the conditions and suitable cases.
- Clicks the project discussion button.
- Fills out the form.
- Receives confirmation of shipment.
- The application is received by the responsible employee.
Such a description helps to see not only the screens, but also the states between them.
4. Functional requirements
For each function, the expected behavior is described. The wording “add form” is not sufficient. It is necessary to define the fields, mandatory requirements, validation, consent to data processing, success message and method of delivery of the application.
Functional requirements include:
- search and filters;
- forms;
- authorization;
- personal account;
- catalogue;
- payment;
- multilingual;
- integration;
- content management.
You should not dictate the technology in detail if the result, and not a specific tool, is important to the business. The contractor can offer a simpler and more sustainable solution.
5. Content
The TOR records who prepares texts, images, videos and legal documents. It is also helpful to specify the transmission format and deadlines.
If the content is created by a studio, you need to determine the scope: editing the customer’s materials, texts from scratch, interviews, selection of images or organization of shooting.
Uncertainty in this section often delays the project beyond development.
6. Design and adaptability
Instead of the requirement to “make it modern,” it is better to describe the nature of the brand, practical limitations and quality criteria. Examples that explain what is appropriate: typography, density, movement, or the way the product is presented are helpful.
You need to list the key permissions and states:
- desktop;
- tablet, if it requires separate logic;
- mobile screen;
- guidance and focus;
- loading;
- empty results;
- error;
- successful action.
7. Technical requirements
This section includes requirements that affect architecture and verification:
- supported browsers;
- domain and hosting;
- content management system;
- external services;
- uniform safety;
- backup;
- analytics;
- productivity;
- accessibility;
- technical SEO.
The requirement of “100 points in all tests” may be formal and conflict with real functionality. It is better to define measurable priorities: fast loading of the main content, absence of critical errors and the work of key scripts.
8. SEO and migration
For a new site, the title, description, canonical, sitemap, robots.txt and clear heading structure are recorded.
When redesigning, you additionally need a list of old URLs. Pages with accumulated search signals are saved or receive constant redirects to relevant new addresses. After launch, the server’s responses and the absence of random noindex are checked.
9. Analytics
It is not enough to simply install a meter. You need to list events that are important to your business: submitting a form, going to a contact, viewing a tariff, downloading a presentation, or starting a checkout.
Events must be related to the purpose of the page. Then, after the launch, you can evaluate not only traffic, but also the completion of the user path.
10. Acceptance criteria
Acceptance criteria translate wishes into verifiable conditions. For example:
- all routes from the site map are opened;
- the form checks required fields;
- after sending a confirmation appears;
- the application arrives in the agreed channel;
- pages are displayed correctly at the specified resolutions;
- the code contains consistent metadata;
- old URLs are redirected according to the approved table.
Subjective design assessments should be completed earlier - at the stage of agreeing on the concept and layouts.
What should not be added to the technical specification
There is no need to describe each button in the language of software documentation if the layout and prototype already show its behavior. Duplication creates the risk of inconsistency.
Also harmful:
- requirements without connection with the task;
- a random list of technologies from someone else’s project;
- the wording “and other functions”;
- unlimited number of edits;
- links to references without explanation;
- criteria that cannot be measured.
Technical specification should reduce uncertainty, and not create the appearance of completeness.
Short technical specification template
For a small site, you can start with the following structure:
- About the product and task.
- Audience and main action.
- Page map.
- Scenarios.
- Features and integrations.
- Content and responsible parties.
- Design and adaptive states.
- Technical requirements.
- SEO and analytics.
- Acceptance criteria.
- What is not included in the project.
The document can be refined after the prototype. The main thing is that the changes are visible to all participants and affect the timing and cost in a transparent way.
Frequently asked questions
Can the studio prepare the technical specifications itself?
Yes. The client provides facts about the business and constraints, and the studio translates them into structure, scenarios and requirements. This is a normal part of design.
Do you need technical specifications for a small landing page?
We need at least a compact fixation of the structure, form, adaptive states, analytics and composition of work. The title of the document is less important than the same understanding of the result.
Is it possible to change technical specifications during development?
It is possible if the changes are recorded and the team evaluates their impact. The problem arises not from the change itself, but when the new volume is considered part of the previous estimate without reviewing the timing and cost.