Chicken or egg: what used to be, prototypes or TK?
There are situations when the project needs to be prepared in a very short time, and there is absolutely no time to study ways to solve the problem and choose the most optimal one from them. The team simply rushes headlong into the implementation, relying on experience and intuition. It usually works out well. But there remains a feeling that one can do better, there would only be an opportunity to stop and ponder the task.
For example, in our team of developing Internet solutions, not everyone and far from always had an understanding of where to start designing: with prototypes of interfaces or technical specifications. In both cases, there are supporters and opponents, there are pros and cons. Only a consensus is lacking.
We agree that we use prototypes and TK in order to:
- coordinate the scope of work with the customer,
- formulate tasks for designers and developers,
- develop functional testing scenarios,
- write user instructions
- perform acceptance of work.
Prototypes can be of any type. TK can be replaced by diagrams with explanations. Here, content is more important than form. Of course, provided that the format of the document suits both the customer and the team.
It’s better to work out prototypes first
How will it be . We draw. We are discussing. We redraw and discuss. We discuss and finish. We agree.
The result that we see . Many detailed prototypes. Everyone understands how the system will look. Everyone likes.
The result is actually.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 what limitations and functions were discussed when prototyping. In any case, they are not in a format that can be transferred to the customer or team. And if the prototype author suddenly decides to fly to Mars, then decoding his work will take a lot of time. And, most likely, after working through the description, it turns out that someone from the team had a different idea of the actions performed by clicking. Even if the prototype is interactive, it does not reflect internal logic.
Necessary actions. Develop TK. It is important not only to describe what is on the prototypes, but to fully develop the functionality. Correct prototypes. Moreover, it can be either minor changes, or dramatic changes or rendering of the prototype.
Or is TK first?
As it will be. We analyze. We think it over. We describe. We are discussing. We analyze. We add and discuss. We analyze. We discuss and rewrite. We agree.
The result that we see. We have TK. Dozens or hundreds of pages with detailed descriptions.
The result is actually. The author of the document knows how everything should be. Knows what the limitations are. No one can imagine how this description will look visually. It is unlikely that 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 TK after drawing prototypes (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 only be thought out at the stage of description. If TK is in the foreground, then we do not see ways to optimize the interface that are so easy to identify on the prototype. Mistakes arise because we too clearly separate parts of one whole.
Prototypes and TK are not only your creativity, but also the basis for the work of other team members. Discuss bottlenecks and contentious issues with relevant professionals and ensure that prototype requirements and TK requirements are feasible.
Perception difference
It is very difficult to come to a unified vision of the project, focusing only on text or only on prototypes. People imagine different images when they read the same text, and mean different functionality, looking at the same pictures.
Blurring the process
When dividing the design of prototypes and TK into separate stages, we coordinate one document, then the second, and then make corrections to the first, although it has already been agreed. The customer has the impression that the agreement is not important, and the changes to the 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 description and prototypes are being built up gradually, then editing is easier and faster, because you need to edit less. Simple math: 5 prototypes are made on the basis of the main page, which means that in case of changes to the main page, we edit 6 prototypes at once. In the final TK, you need to edit 100 pages, and in the original concept only 10 (all numbers, of course, are conditional, but they reflect the main idea). Creation of comprehensive descriptions, rendering of all prototypes at once and their subsequent edits are a waste of time. But which is much worse - there is a feeling of worthless work that needs to be redone from beginning to end again and again (even if only slightly).
Both prototypes and TK
Recall for what tasks we need prototypes and TK:
- coordinate the scope of work with the customer,
- formulate tasks for designers and developers,
- develop functional testing scenarios,
- write user instructions
- perform acceptance of work.
Prototypes and TK individually will not close all items. We need both documents, and they must be consistent with each other and represent a single whole in meaning and function. Ideally, prototypes and TK are one document. And it’s better not to split it into pieces unless absolutely necessary.
As it will be.
1. Development 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. Correct. We agree.
Discussion with the customer is not necessarily a personal meeting (although this is the best way). To get a quick answer or save time, use Skype, the editing mode in Word, email and other communication methods.
2. Detailing the description and drawing prototypes of all unique pages. We analyze. We expand the description in the ToR. We describe technical aspects at a high level. We draw prototypes of all unique pages, that is, for similar pages, for example, “Creating a Survey” and “Editing a Survey”, at this stage you can draw only one of them. We are discussing. We analyze. Correct. We agree.
3. Full description and drawing of prototypes of all pages.We analyze. We fix in the technical specifications all the nuances of the functionality and technical side of the implementation. We draw all the states of the elements and pages. We are discussing. We analyze. Correct. We agree.
Different people can make prototypes and TK if they are an effective team.
The result that we see. Everyone understands how the system will look. Everyone understands what functionality the system will have.
The result is actually. Documents that are convenient for all team members and the customer to work with. Everything is drawn, everything is described.
Necessary actions. Move further on the project.
Marina Demina, ADV / web-engineering designer