When we made our first sites, a technical assignment was an obligatory part of the development contract.
Detailed multi-page technical specifications for the mobile game app development company of the site were written more in order not to do anything superfluous within the framework of the project and to prove to the client that "we should not do this."

"Regular" technical task

The terms of reference, if any, is a boring document that describes page by page what should be on the site, listing elements and blocks separated by commas or a list, diagrams are drawn for some pages.
Then, according to the brief and the terms of reference, the designer draws pages, trying to assemble the project from the pieces listed, separated by commas. In the process, some of the blocks are changed, new ones are added, something is deleted, then all this is typeset and programmed. Programmers have been trying for a long time to dock technical specifications with layouts, and as a result, something turns out. And then the project managers start dancing with a tambourine to hand over the project. Everyone is wasting a lot of time and nerves; the project is over budget.

The problem is solved with short iterations and constant negotiations with the client, plus frequent demonstrations. At the same time, it is very important to quickly hand over the project / stage, fix the delivery and move on to the next iteration. The rest doesn't work.

Alternative terms of reference

When drawing up a technical specification for an online store or website, I pursue several goals. First, outline the scope of the project. Secondly, to give the criteria for its completion that are clear to all project participants. Thirdly, get a working document on the basis of which you can calculate the cost with high accuracy and predict the maximum number of risks. The customer feels "in control" over the process. And the team's motivation increases significantly. So, a good technical assignment:

fully describes the result of the work

as simple and understandable as possible

clearly

briefly

measurable in money

interactively

There is only one conclusion: making textual technical assignments for websites is not the most effective activity. In order for the TK to be clear to everyone involved in the process at all stages of work, the terms of reference must include a prototype. You can click on interactive prototypes and see the mechanics of the site from the point of view of an ordinary user. The prototype can be supplemented with a text technical task. It is much more convenient when priority is given to the prototype, since it is more likely that the customer watched it and that he read and understood the technical specification.
Unfortunately, many customers do not understand TK at all what it should be. A technical assignment is a formulation of a task in such a way that an average programming or design specialist can immediately start and complete it without any questions. That is, there is no need to write business strategies there. The purpose of the TK is to help the developer make the project exactly the way the customer would like to see it.

In addition, the TK does not protect the developer, since the client, if he wants, can interpret any item differently, or consider that some functionality should be the default. That is, he will be able, if he wishes, to dispute any point and give any reasons, that “he thought it would be like this,” or that “everyone has it,” or that “it is so accepted in my industry,” or something something else. There is no way to overcome this at the level of formalization of TK. It is necessary to build relationships with the client, understand his needs, and make the work process as interactive as possible.

The client shouldn't have any desire to dig into the wording in the technical specifications for the online store, but should have the feeling that everything is going according to plan and everything is exactly as it should be. This is facilitated by short two-week iterations, which have clear fixed requirements that are clear to both the project manager and the customer.
People understand pictures and visualizations faster - so prototypes are much more effective. However, it is impossible to fully describe the technical aspects and mechanics of web applications on prototypes, so text specifications, statements and diagrams are also needed. These do not have to be separate documents. Sometimes a PowerPoint presentation is enough, sometimes even just comments on the prototype.

Iterations should be short, otherwise, if the result of the iteration is not recorded, the accumulated information is forgotten, and after a couple of months neither the team nor the customer will remember at which phase the project was abandoned, and what exactly to do with it now. “Restarting” such a project is very difficult and expensive. Long and thick terms of reference are needed if it is planned to be developed by another team.

If the risk is not very high, you can make a general short technical assignment for a project with fixing a list of requirements and make a technical assignment for a specific iteration. This adds flexibility in the process of work, but programmers do not like this approach very much. Development of a prototype and technical specifications for it usually eats up 12% of the project budget.
In small projects, the problem in developing a good technical specification is that it needs to be prepared before the contract is ready, but there is a risk that the contract will not be signed in the end.

What else can be optimized when developing technical specifications:

Do not forget to specify user roles and actions available for each type of user.

Site structure - describe which sections and subsections the site includes. We describe the pages. If it is easier to draw a page scheme than to describe which block is where, we draw. If the page is simple, we restrict ourselves to a text description.

If your technical assignment includes a section on design, there is no need to rewrite the brief there. It is enough to fill out the brief with a high quality together with the customer and make a reference to him, including in the contract as a separate annex. In the terms of reference, we fix only the formal requirements for the design, the number of iterations, and the order of work on it. Sometimes it is beneficial to attach a sketch to the TK - a schematic sketch in which the main ideas of the concept are roughly traced, without detailing and color.

If a boxed CMS is used, we do not reinvent the wheel - we indicate the edition, give a link to its description on the official website and list which modules from those included in this edition we customize for the site.

In general, there are a lot of prototyping tools. As a last resort, you can draw a prototype by hand on paper or do it in one of the usual office applications. I have seen prototypes made in Word, Excel and Power Point. But it is much more convenient to use special software. We use Axure Pro or Evolus Pencil for prototyping. Visio and InDesign are also popular.