Technical task of the site.
TT is not just a list of requirements, it is a document. If the contract governs the process of organizational and financial relationships, then the TT regulates the development process and the final result.
In this case, it doesn’t make any difference whether a site is being developed or small. The problem of mismatch of expectations may arise regardless of the amount of money spent, only the consequences may be different.
What is this article about.
This article is about what can be useful in the process of writing TT to the site. But this article is not about how to write project documentation. Ultimately, the main task of the designer is not to write a cool document, but to design a website. A good document is only a reflection of the approach and respect for all participants in the development.
Add restrictions.
Always when we talk about writing TT, we mean, of course, a cascade development technique. In the case of other options (for example, extreme programming) other documents are prepared and often on different principles. This is - time.
It is necessary to separate the TT for small and large sites. This is two. Differences between small and large projects are not in the volume of the document at the output, but in the process of their development. If you have only 4 people in the project team, everyone has known each other for a long time, then we can assume the absence of formalism. If several “departments” are engaged in the development, and the project team consists of more than 10 employees (ad infinitum), then only a process can manage this horde. The process creates a formalization, and the formalism leaves its mark on the format of the documentation.
In fact, the thickness of documents depends on the complexity of the process to a greater extent than on the size of the project.
We will follow the most difficult path.
TT answers questions
TT is initially created for several development participants:
Project developers (designers and programmers).
Project Manager.
Customer.
Bureaucrats (they may not participate in the project, but they must also count on them).
Looking back at the listed groups of participants, it can be assumed that the TT should first of all answer their questions. Ideally, all the pre-project documentation in the cascade method is created so as to remove questions in the development process.
So, what questions answers TT.
For whom the site is created and for what?
The site is created for the customer and for his clients. These are based users of the future project.
The best option would be if in the Terms of Reference you describe all users of the site, both internal and external. This description may include marketing, demographic, social data, goals and objectives of potential users, their requirements for the future site.
How will the tasks of the customer and users be solved?
Actually, if you do not answer this question, then the writing of the TT can be recognized as paperwork. This is the main and significant question. A separate article may be devoted to it, so we will not dwell on it in detail yet.
How will the project be created?
As already stated above, the TOR (and maybe a separate document) sometimes describes the project development process. This is absolutely necessary if we take into account that a site can be developed according to a different development methodology from the company’s one, which is usually not described in any document. One may torture oneself with dreams about ISO standardization for as long as you like, but what can one show to a meticulous customer?
According to GOST, a separate section “System Development Stages” is provided. In this section, you can not describe the process in too much detail and install the milestones.
What will be taken at the exit?
TT begins development and puts an end to it.
Ideally, you should go through all the points of the TT together with the customer, check with the received system and say a week later: “Uh-f. It seems everyone did. ”
“TT is a means of verifying the work performed.” - such a phrase is recorded in the introduction of many of my TT.
What is required for the further launch of the project?
This is a question that the customer should receive in an amicable way. This is a consulting, but in some cases it must be carried out in the design process. It is necessary to plan the number of workplaces, the required software and hardware, etc.
What is the TT
It took me a whole hour to make a decision: to describe the composition of the TOR in the form of a specific clear structure or just to tell about what should be there. Recalling all my TT, I came to the conclusion that the structure of this document changed so often depending on a number of factors, that a clear indication of the structure would resemble poor advice on choosing a suit. Imagine that you are advised to wear something for the evening, without even knowing where you are going.
general information
The first part of the ToR contains an introduction and general information about the document and the project as a whole. Introduction should be written once and for life. As a rule, such abstract phrases are written there that in each new project it is only necessary to correct a few words.
General information includes:
Information about the customer and the performer.
It is necessary to indicate the responsible persons from each side. Specify the documents on the basis of which the development is made. As a rule, such a document is a contract. Status of current document and confidentiality.
Purpose of the project.
Specified: what will be used for the resulting product.
The goals of the creation and the tasks that the resource must solve.
On the one hand, this is a rather short section, but it ranks first in importance of study. If the goals and objectives are not clearly and immeasurably set, then it can be quite difficult to follow them.
Description of the project audience.
Critically important information for developing good and correct sites. It is clear that information about the audience is not only necessary to properly collect, but even more important is to be able to use this information.
Audience description should contain not only information that marketers love so much (demographics, needs, segmentation, etc.), but also information that is useful for designers and designers: what tasks the user solves, what are his goals in working with the site, what his attracts. Alan Cooper recommends describing the site’s audience not in the form of a faceless mass, but highlighting the characters - describing the collective image of specific people.
Terms and Definitions.
In a large document, you will be able to use a huge amount of terms and slang expressions that marketing experts or major executives rarely understand. They can read this document, so it’s best to provide a list of definitions for them. I do not amuse myself with the hope that this list has been read at least once in my life, but then I can always refer to it.
The introductory general part of the document contains information on where we started in the design. Of course, in the process of questioning the customer’s specialists, information accumulates an order of magnitude more, but it is not interesting for anyone to read it.
This information is collected in the scope of the project.
Project scope
If you move far away from your house and, turning, look at it, then from a distance you will not be able to discern the details of the structure. You can count the windows, but you can’t disassemble what material they are, you can admire the architecture (you can not “admire” every house), but you can only guess about the principles of its construction; the doors.
The scope of the project is about the same. After reading this chapter, everyone should imagine what will be obtained in the development process, but without going into details at all. You write that a “user registration” will work on the site, but do not write how exactly it will be arranged, or what fields the user will have to fill out.
The frame level of design in any case passes any project, so it will not be superfluous to write it down. In addition, great chefs from both the developers and the customer do not like to read for a long time, but they love to be aware of everything that is happening. This section should be written including for them.
The project framework is written in the form of scripts for users of the site and describes the overall functionality and interaction with the interface.
Information architecture and interface
The section devoted to information architecture (IA) sites is not standardized by any known standard (the author is not familiar with such yet). But anyone who has developed websites understands that IA is almost the main thing you need to know to develop a website. IA will determine how the site will look and work with users.
To describe the IA you need to describe from top to bottom:
Site structure. These are the so-called high-level prototypes.
Page templates. Low-level prototypes that describe the site interface itself.
Content inventory. Tabular description of the content of each page of the site.
Site structure
The site map is executed graphically in one of the well-known notations: Visio or Garrett. I advise you to draw a site map, because in this case, the resulting structure is the most visible and convenient to use in the future. On the one hand, it may seem that in the form of a list it will be much easier to write a site map, but when you yourself think about the links between different areas of the site, you will, willy-nilly, begin to strike squares on paper.
On how to draw the structure of the site using notations using Visio, written whole articles, so we will not dwell on this. The articles are written, however, in English, but you can easily use them.
Do not forget to assign the number of each individual page of the site map. This will be required at the stage of description of the content.
Useful tips when drawing a sitemap:
Do not feel sorry for the place. Try to place the blocks so that they are separated from each other. This will help map readability.
Do not shrink. In principle, it is possible to read the text printed in 4 size, but this is already a reason for hatred.
Align the "squares" of the pages relative to each other, lining up in lines. This will improve the perception of page nesting levels.
Do not cross the lines. Try to avoid a large number of cross lines. If they intersect, they must “jump over” one above the other. Whoever was engaged in drawing functional schemes at the university, will understand me.
Sign the card. Sign the card itself, as well as individual blocks. This will allow less confusion in the future.
Save the file often. Trite, but you just have to remember this. It is not worth remembering once again the relatives of the developers of the Visio program; in fact, they are not to blame for anything.
Sample sitemap
Sample sitemap.
I usually put the site map in the “Applications” section. As a rule, it is so large that it becomes unreal to place it in the middle of the TT.
