Chicken or egg: what before, prototypes or TK?

There are situations when the project needs to be prepared in a very short time, and there is no time to study ways to solve the problem and select the most optimal one. The team simply rushes headlong into realization, relying on experience and intuition. Usually it works well. But there is a feeling that you can do better, if only you could stop and think about the task.
For example, in our team of developing Internet solutions, not everyone and by no means always had an understanding of where to begin designing: from interface prototypes or technical tasks. In both cases, there are supporters and opponents, there are pros and cons. Lacking only a single opinion.

We agree that we use prototypes and TK in order to:

• agree on the scope of work with the customer,
• to formulate tasks for designers and developers,
• Develop functional test scripts
• write custom instructions
• Acceptance of work.

Prototypes can be of any type. TK can be replaced with a diagram with explanations. Here the content is more important than the form. Of course, provided that the document format suits both the customer and the team.

At first it is more correct to work prototypes

How it will be . We draw. We are discussing. Redraw and discuss. Talk and draw. We agree.
The result that we see . Many detailed prototypes. Everyone understands how the system will look like. Everyone likes.
The result is really. The goals and objectives of the project are not fixed anywhere, so there is no certainty that the prototypes correspond to them. No one remembers the limitations and functions that were discussed during prototyping. In any case, they are not in a format that can be transferred to the customer or team. And if the author of the prototypes suddenly decides to fly to Mars, then it will take a long time to decipher his work. And, most likely, after working through the description, it turns out that someone from the team had a different idea of ​​the actions performed on click. Even if the prototype is interactive, it does not reflect the internal logic.
Necessary actions . Develop TZ. It is important not just to describe what is on the prototypes, but to fully develop the functionality. Modify prototypes. Moreover, it can be as minor edits, as well as drastic changes or drawing a prototype.
')

Or is it first TK?

As it will be. We analyze. We think over. We describe. We are discussing. We analyze. We add and discuss. We analyze. Talk and rewrite. We agree.
The result that we see. We have a TK. Tens or hundreds of pages with a detailed description.
The result is really. The author of the document knows how everything should be. Knows the limitations. No one imagines how this description will look visually. Hardly anyone except the author has read and understood the document, because a solid text without pictures is dull and difficult to perceive.
Necessary actions . Design prototypes. Simplify and supplement the TZ after prototyping (good prototypes will reveal bottlenecks and logical errors in the description).

What's wrong?

Inevitable errors
In the case of the priority of prototypes, we miss the details that can be thought out only at the description stage. If the foreground of TZ, we do not see ways to optimize the interface, which are so easy to identify on the prototype. Errors arise because we too clearly separate parts of a whole.

Prototypes and TK is not only your creativity, but also the basis for the work of other team members. Discuss bottlenecks and controversial issues with relevant experts and make sure that the requirements for the prototypes and the requirements of the TOR are realizable.

Difference perception
It is very difficult to come to a common vision of the project, focusing only on the text or only on prototypes. People imagine different images when they read the same text, and mean different functionalities, looking at the same pictures.

Process erosion
When dividing the design of prototypes and TZ into separate stages, we agree on one document, then the second, and then make edits to the first, although it has already been agreed. The customer has the impression that the agreement is not important, and edits of TK and prototypes are available at any stage of the project. Under the slogan “let's change this button here”, an endless iteration of changes takes place.

Increased labor costs and reduced motivation
If the build-up of descriptions and prototypes occurs gradually, then edits are easier and faster to do, because you need to edit a smaller volume. Simple mathematics: 5 prototypes are made on the basis of the main page, which means that in the case of changes to the main page, we will right away 6 prototypes. In the final TK, 100 pages need to be edited, and in the initial concept only 10 (all figures, of course, conditional, but they reflect the basic idea). Creating comprehensive descriptions, drawing all prototypes at once and their subsequent editing is a waste of time. But what is much worse - there is a feeling of useless work that needs to be redone from beginning to end over and over (even if only slightly).

And prototypes, and TK

Recall for which tasks we need prototypes and TK:

• agree on the scope of work with the customer,
• to formulate tasks for designers and developers,
• Develop functional test scripts
• write custom instructions
• Acceptance of work.

Prototypes and TK separately will not close all items. We need both documents, and they must be consistent with each other and represent a single entity in meaning and function. Ideally, prototypes and TK are one document. And it is better not to split it into pieces unless absolutely necessary.

As it will be.
1. Elaboration of the concept and prototypes of the main pages. We analyze. In the ToR we describe the concept of the project, indicate the main modules / blocks / functions, think over the roles and indicate the limitations. We draw prototypes of the most complex and most important pages. We are discussing. As a rule, according to the concept, the team has many questions, and the customer has many wishes. We analyze. Adjust. We agree.

Discussion with the customer is not necessarily a personal meeting (although this is the best way). To get a quick response or save time, use Skype, editing in Word, email and other methods of communication.

2. Detailed description and drawing prototypes of all unique pages. We analyze. Expand the description in the TK. Technical aspects are described at a high level. We draw prototypes of all unique pages, that is, for similar pages, for example, “Creating a poll” and “Editing a poll”, at this stage you can draw only one of them. We are discussing. We analyze. Adjust. We agree.
3. Full description and drawing of the prototypes of all pages. We analyze. We fix in the technical specifications all the nuances of the functionality and technical side of implementation. Draw all the states of elements and pages. We are discussing. We analyze. Adjust. We agree.

Prototypes and TK can make different people, if they are an effective team.

The result that we see. Everyone understands how the system will look like. Everyone understands what functionality the system will have.
The result is really. Documents that are convenient for all team members and customers. Everything is drawn, everything is described.
Necessary actions. Move on to the project.

Marina Demina, ADV / web-engineering designer