Remember the law of Murphy? If you can get it wrong, you will definitely get it wrong. This is true not only in communication between people, but also in creating websites. The client wanted a second “Facebook”, and received a forum for young dog breeders. The developer did not guess the customer's wish - I wasted my time.
In this guide, I will tell you what and why you need to write in the technical specifications. At the same time I will show how to write it is not necessary so that the creation of the TK does not turn into wasted time.
The article will be useful:
- Anyone who has to do with the creation of sites: developers, designers, layout designers.
- Project managers.
- Heads of digital studios.
- Entrepreneurs who plan to order the development of the site.
To make the material useful, I collected comments from several developers, designers, project managers and owners of digital studios. The most valuable added to the end of the article. Let's go figure it out.
- Terms of reference are performer
- Write uniquely and accurately
- Enter general information
- Explain difficult terms
- Describe the tools and hosting requirements
- List site requirements
- Specify the site structure
- Explain what will be on each page.
- Write down the scenarios of using the site
- Determine who is responsible for the content.
- Describe the design (if you can)
- Instead of output: the structure of the technical task
- I also recommend reading
- Developer Comments
What is a technical assignment and why is it necessary?
The terms of reference is a document that sets out the requirements for the site. The clearer and more detailed these requirements are, the better all the participants in the process understand what it should be. So, there is a growing chance that everyone will be satisfied with the result.The main objective of the technical task: to make sure that the client and the performer correctly understood each other.
The benefits of the technical specifications a lot. For each side it has its own.
- Understand what he pays money for, and what the site will be like. You can immediately see the structure, understand what will work and how. To estimate whether everything suits. If not, change without any problems even before the start of development.
- See the competence of the performer. If the terms of reference is clear and clear - the credibility of the developer increases. If there is written porridge - perhaps it is worth running and not looking around.
- Insure against the performer’s bad faith. When the site is ready, it can be checked according to the technical task. Any inconsistencies? The developer is obliged to fix them. If you cooperate officially and entered into an agreement, you can even be forced through court.
- Simplify the replacement of performers. If the client and the developer quarreled and fled, the creation of the site can be very delayed. When there is a detailed technical task, it can be transferred to a new team - it will be involved in the work many times faster.
- Learn the cost of developing a complex product. Estimate the exact time and cost of developing a complex web service outright impossible. First you need to understand how the service will work, and what functions it will have in it. For this, you need to prepare a technical task.
Benefit for performer:
- Understand what the customer wants. The client is asked dozens of questions, show examples, offer solutions. Then write everything in a single document and agree. If everything is okay - hooray, you get it right.
- Insure against a sudden client wish. Sometimes there are customers who want to change the task halfway. If you agreed and signed the TK, you are not afraid of this. In which case, even the court will be on your side.
- Show your competence. Well-prepared technical project will show the client the expertise of developers. If the company doubted whether to trust you with the development of the site, doubts are likely to fade.
- To earn money. Some studios and developers offer TK compilation as a separate service.
- Facilitate and speed up the development process. A good TK indicates the structure of the site, the necessary functions and elements on each page. When all the requirements are already before your eyes - it remains only to design and write the code.
Now let's see how to make a good technical task that performs all these functions.
Technical Specification is a performer
In general, the technical project can make anyone. "I need a business card site for a dental clinic" - this is a technical task. But will it fulfill its functions? Hardly.
A good TK is always an executor: a project manager or a developer. Obviously, the web developer understands the creation of sites more than the owner of a cafe or dental clinic. Therefore, he will have to describe the project.
This does not mean that the client disappears and appears at the very end in order to write: “ЗБс, I approve”. He should also be involved in the process:
- To acquaint the performer with the company, products and target audience.
- Explain why he site.
- Tell what he wants, share ideas.
- Show examples of good sites from his point of view.
- Answer any other questions the artist.
Of course, the customer can sketch his version of the TK. Perhaps this will speed up the process of creating a final technical task. And perhaps it will turn out the garbage, which is quietly thrown into the garbage.
Write uniquely and accurately
This advice derives from the main goal of the technical project - “To make sure that the client and the performer correctly understood each other”.
In the technical task there should not be quality adjectives: beautiful, reliable, modern. They can not be clearly understood. Everyone has their own concepts of beauty and modernity.
Take a look. Someone thought this design was beautiful and allowed to use it on its website:
The same is with vague formulations that do not in themselves mean anything:
- The site should appeal to the customer. And if he has a bad mood?
- The site should be user friendly. What does it mean? Convenient for what?
- The site must withstand heavy loads. 10 thousand visitors? Or 10 million?
- High-quality expert content. Well, you understand.
Check for ambiguities in the text. If there is - rewrite. Your wording should be clear and precise:
- The site should load quickly → Any page of the site should have more than 80 points in Google PageSpeed Insights.
- Large loads → 50 thousand visitors at the same time.
- The main page displays a list of articles. → The main page displays a list of the last 6 published articles.
- Minimalistic user-friendly subscription interface → Leave e-mail field and Subscribe button → * drawn sketch *.
With the wording sorted out, let's go over the structure.
Enter general information
All team members must correctly understand what the company is doing and who its target audience is. So that no one is confused, it is better to register at the very beginning of the technical project.
And it is worth indicating the purpose of the site and describe its functionality in two words - in order not to get an online store instead of a blog.
Explain difficult terms
The first rule of a technical task is that it should be clear to everyone for whom it is intended. If you are going to use terms that your client, the owner of a children's toy store, may not understand, be sure to explain them. Understandable language, not copy-paste from Wikipedia.
Describe the tools and hosting requirements
Imagine that you have been making a cool website for 2 months. Each stage was coordinated with the client - he was delighted. And now it's time to take the job. You show the admin area, and the client shouts: "What is that? Modex? I thought you would do it on WordPress!"
To avoid such problems, describe the tools, engines and libraries used. At the same time specify the requirements for hosting. You never know, you do it in PHP - and the client has a server on .NET.
List site requirements
The site should work in all browsers of current versions and on all types of devices. Yes, it is obvious to any developer and any customer. But it is better to write to protect the client from unfair work.
Here, write the requirements for the speed of loading the site, resistance to stress, protection against hacker attacks and similar things.
Specify the site structure
Before you start designing and layout you need to agree on the structure of the site with the client.
Communicate with the customer, find out what he wants. Gather developers, SEOs, marketers, Glavred - and decide which pages are needed on the site. Think about how they will be interconnected, which one you can go to.
You can show the structure of the list, you can draw a block diagram. As you prefer.
This is one of the most important stages of work on the site. Structure is the foundation. If it is unsuccessful - the site will turn out to be a curve.
Explain what will be on each page.
The client must understand why each page is needed and what elements will be on it. There are two ways to show it.
Prototype - a more visual and unambiguous way. The artist draws sketches of each page and attaches them to the terms of reference. The client sees what the interface of his future site will look like and says what he likes and what should be changed.
Enumeration of elements - lazy alternative to the prototype. Just write what blocks should be on the page, and what they do.
Write down the scenarios of using the site
If you are doing some kind of non-standard interface, just showing the structure and thumbnails is not enough. It is important that the entire team of performers and the client understand how visitors will use the site. Scripts are great for this. The script is very simple:
- User action
- Site response.
Of course, if you are doing a standard business card or landing, you do not need to write scripts. But if there are any interactive services on the site, it is very desirable.
Read more about usage scenarios in Wikipedia.
Determine who is responsible for the content.
Some developers make the site immediately with content. Others put fish. Still others can write texts, but for an additional fee. Agree on this ashore and record in the technical specifications what content you should prepare.
To come up with objective criteria for assessing the quality of texts is quite difficult. Better not write anything than "Quality, interesting and selling content useful for the target audience." This is rubbish, nobody needs it.Indicating that all content should be unique is useful. Another client protection from unscrupulous performers.
Describe the design (if you can)
As in the case with the text, it is difficult to come up with objective criteria for evaluating the design. If you agreed with the client about the color scheme - write it. If he has a brand book in which fonts are written, indicate them as well.
Write about the beautiful and modern design is not necessary. It does not mean anything, does not have the power and generally fu.
Instead of output: the structure of the technical task
For different tasks, the structure of the TOR will be different. It is foolish to do the same terms of reference for a new social network and landing on the wholesale of carrots. But in general, you need these sections:
- Information about the company and the target audience, the goals and objectives of the site.
- Glossary of terms that may not be clear to the client.
- Technical requirements for the layout and operation of the site.
- Description of the technologies used and a list of requirements for hosting.
- Detailed site structure.
- Prototypes of pages or descriptions of the elements that should be on them.
- Scenarios for using a custom interface (optional).
- List of content that makes the developer.
- Design requirements (optional).
I also recommend reading
- Rules for compiling Software Requirements Specification. SRS - the next step in the evolution of technical specifications. Needed for large and complex projects.
- Standards and templates for software development. Descriptions of different GOSTs and methodologies for creating specifications.
This is the end of the part that I wrote. But there is another one - the comments of specialists who helped to make the guide. Read, this is also interesting.
I talked to several developers to find out how they make up the terms of reference. I pass the microphone to them.
Asha Sahakyan, web designer, freelancer
The technical project must be written by the project manager, team leader or the developer himself (if he is a freelancer and works alone). The client does not understand the sites - he can not take into account everything important.
I write TZ so that it is understandable to the customer. I explain the terms, describe the structure, design, functionality, technologies used. Often I attach prototypes of pages so that the client understands what his site will look like. Then I create a separate task for the layout designer - with technical details and explanations that will help in his work.
The more complex the task, the more should be the TZ. When I participated in large projects, I saw technical specifications for 30 pages.
Guram Sipki, founder of Udix Media Digital Studio
First of all, TK needs a client - so that he will understand what his site will be like and what the money will cost. If something is done wrong - he can refer to the TK and ask for a remake.
TK is the project manager after talking with the client and discussing the problem with the designer.
Large customers often ask for very detailed TZ, in which each button is described. Small companies on the contrary do not like meticulous documents on 100 pages. Long to read and easily miss something important. More often we make concise terms of reference for 10-15 pages.
- Information about the company and the purpose of the site.
- Design requirements, color range.
- Used technologies and CMS.
- Who is engaged in content - we or the client.
- The structure of the site down to each page.
- Descriptions of each page. We do not make prototypes, but we indicate what elements should be on the page, and how they should work.
The last 2 sections are the most important. They provide an understanding of what the site will be and how it will work.
A very important point - you can not just give the technical task to the developers and hope that they will do everything well. TK is a list of site requirements; it cannot replace communication. It is important to make sure that each team member understands a common goal, and not just performs tasks on the stream. If something is not clear - it is necessary to explain, discuss, give detailed comments.
Dmitry Kuzmin, Project Manager
The technical assignment should be written by the developer or the project manager. It is necessary to indicate only specific completed formulations that cannot be challenged. And avoid evaluative adjectives: beautiful, effective and so on.
If something is not specified in the TOR, it is necessary either to clarify with the client or implement at the discretion of the developer. But separately we report this moment to the client. It is necessary to discuss in advance, and even better to register at the end of the technical specifications.
And still need to draw approximate sketches of what should happen. With detailed comments.
Alexander Kurochkin, the founder of the studio Etalon Idea
The technical assignment is always, without it there is no work. "I need an online store" - this is a technical task. The problem is that this is a very vague TK, it gives almost no understanding.
The task of the project manager is to collect all the necessary information, to think out a solution, to create a website in your head. And then describe it in the document. In fact, TK is already halfway to the finished product.
A terms of reference is a benchmark with which you and your customers will compare a site. It is necessary for everyone:
- The developer is on the things described in the TK.
- The tester checks whether everything works as planned.
- The client understands that he will receive in the end.
- The project manager can estimate the cost and development time.
With a business card site or store everything is simple. It is unlikely that there will be something new, therefore, it is easy to estimate its cost at the discussion stage. If we do something similar, we can do without TK at all. We discussed the problem, we wrote a formality in the contract, we did it. Everyone is happy.
If a customer needs a complex product, no one can immediately estimate the time and cost. First you need to figure out what exactly is needed. Then how things will work. Then figure out how to do it. And only after that it will become clear how many man-hours will be spent on implementation.
In TK we indicate:
- the purpose of the site;
- server requirements;
- description of the site and its individual elements;
- used technologies and libraries;
- interface design layout;
- structure and logic of internal transitions;
- roles and scenarios of working with the site for each of them;
- database architecture (optional).
My advice to readers is first of all to establish communication. If team members can not understand each other and the client - no terms of reference will not help you.
Yuri Ketov, frontend developer, freelancer
I do not like to work on TK. Most of the TK I have seen are overly cumbersome and ineffective. For me, the ideal situation is when the client in one paragraph formulates the task of the site and the context in which it will be used.
Site for the Puppet Theater. The task is to tell visitors about the theater and repertoire, to provide the opportunity to book a ticket online.
In this case, the main thing for me is the references. I will see what Studio Lebedev Studio, Nimax, RedCollar, ONY, Sibiriks and about 10 other companies have done on this topic, choose 2-3 most successful projects, agree with the client and will be guided by them.
Promotional page for the sale of henna for biotatuazha.
Here the main thing is to make a website with which you can achieve the necessary KPI. We look at what sites IT-Agency and Convert Monster are doing and we also do, we don’t have to invent anything.
The more content a client gives, the better. Если вы дадите мне 1000 фотографий, 20 видео, 50 страниц текста - супер. Я сам все отфильтрую и выберу то, что нужно. Я немного утрирую, но, в общем, это так. Чем больше контента на входе, тем лучше, но оставьте за мной право выбирать.
Александр Белов, проект-менеджер Texterra
The technical task is necessary for any project. Each TZ must include:
- Goals and objectives that the site will perform.
- The target audience.
- Worked out in detail, the structure of the site.
- Interface elements of the site.
The client must clearly represent his site in the final version, its appearance and future development strategy.
The technical task should not tell the developers "how to do it, what to do and what code to insert" - this is fundamentally wrong. In general, you need to describe what the site should be, and not how to do it. This should be taken into account as a minimum because the customer, most often, does not have proper expertise.
As for the approach, we always listen to the client's opinion, but there are times when we understand that this is not worth doing. In this case, we try to convince the customer, based on expert data. In general, we welcome any customer vision.
How we prepare the technical project:
- We analyze the TK sent by the client.
- We study the prototype and design layout of the site.
- Based on the data obtained, we begin to select functional modules for the site that will be used 100% and which may need to be used.
- We register elements which will be necessary during the work with the interface.
- Based on these data and the assessment of the "weight" of the site, we calculate the appropriate system requirements for site hosting.
- After these basic points we begin to paint the TOR in more detail for each page.