In the beginning it was - technical task or design?
Sounds like an "egg or chicken", but rest assured that we will not delve into such philosophical jungle. And let's consider a completely practical situation and, perhaps, even change your mind about the established sequence, when a design is created only after a verified and approved TOR.
So what do we have? First of all, the complete absence of regulations. If in mathematics it is always clear that twice two is four, then in the development and promotion of the site, one hundred percent effective formulas have not yet been identified. Therefore, experiments are only welcome - and especially, experiments that lead to success.
That's what the experiment is about. Agree that before any project began with the approval of the TOR. The terms of reference served as a link between the designer and the developer, describing what should happen in the end. He was safely placed in a box, and then had a constructive dialogue in the process.
Then there were agencies - clients turned to them with their technical specifications. But it often had to be redone and coordinated. And after drawing up the terms of reference, they “shifted” it onto the shoulders of the agencies, making it another additional service in the case of proposals.
Until now, most companies do not imagine their work without TK, but the approach to its use can be formal or real. The formal one is when the TOR is drawn up, but is not actually used, but only “loads” the table, and the real one is when a working document is created, as a general package of requirements, regulations.
We structure the terms of reference
TK itself is not a product. This is an image of a future product, but the image is as reliable and unambiguous as possible. Therefore, there will be many pages and a lot of subparagraphs.
- Terminology, general provisions.
- page interfaces.
- Page components (interface blocks).
- Website CMS Requirements.
- Rights, roles.
- Block diagrams, functional descriptions for developers.
- Possible user scenarios, i.e. functional descriptions for users.
- Data structure: list of entities, attributes, objects.
It turns out an impressive TK, with which you should proceed to the development of design and subsequent layout. As a rule, the terms of reference are easily agreed with the client, after which the design is prepared and agreed again. And at this stage there are edits. They can relate to fonts and colors, and be entered freely, without changing the structure and other fundamental parameters.
But there are edits of a different kind - contradicting the TK. When the client remembered the need to configure filters in a different sequence, it became necessary to include a new subsection, and so on. These edits require global changes, since they affect almost all sections of the original structure.
As a result, a discrepancy arises - the design is adjusted to the requirements of the client, and the design layout is approved, which has nothing to do with the previously drawn up and signed (and taken as a basis!) TOR. But the developer was guided precisely by the terms of reference and had already planned his workload.
Dispute resolution method
The inaccuracies that have arisen require solutions. And here companies choose one of three ways. The first one is literally “where the curve will take you”. The specification is successfully postponed, the developer is initiated into a new project - this time according to an agreed design layout. But this is work at your own peril and risk, when the client can again “forget”, “not take into account” and so on.
The second method is an increase in the estimate, the inclusion of additional costs in it. Everything seems to be logical, but the customer is unlikely to understand such logic.
And the third is an obvious charity, when the terms of reference are finalized independently without any additional invoices. But get ready for the fact that such an effort will not be appreciated in any way.
There is a way out of the situation!
If the TK will somehow have to be rewritten for the design, then why not make the design first? And the designer will work on prototypes! After all, the documentation is much less "mobile" compared to the design - it is easier to change the picture than to formulate the next paragraphs of the "guide to action" in a legally and technically competent language. In addition, visualization eliminates inaccuracies in perception.
Moreover, prototypes are quite enough for preliminary approval of the project. Using this technique, you get a product designed in terms of functionality and interfaces. And the TK will already describe it, based on the visualized specifics, fixing the chosen solution.
The benefits are clear
Creating the design first, and then the TK, they get time savings, as well as new opportunities for expanding the base of services. After all, now it is possible to offer prototyping to the client - as a result, this leads to a justified increase in the cost of the project.
The team working on the task, with this approach, will quickly cope with the duties: the designer calmly embodies the ideas of the client, the designer gets rid of constant edits of cumbersome documentation, and the manager “leads” the client without valerian and headache. And the project moves forward to its logical conclusion, and does not return again and again to the stage already passed.
It is more convenient to work with prototypes for both designers and the client. After all, the designer receives pictures for work that are understandable to his perception, and the client has the opportunity to unambiguously evaluate the preliminary “layout”, and not delve into reading a multi-volume of thousands of letters. Thus, the risk of different expectations from the product of the client and the developer company is eliminated.
Developing design prototypes is better for many than constantly editing a letter specification. Indeed, when adjusting many interrelated sections, the risk of making a mistake is so great.