And why do I need TK? I already know!
The problem of _not reading_ TZ rises almost every time when the "writers" of TK and the developers are people from different offices.
This post is about the Terms of Reference for the development of interfaces [for users].
Developers - the same people as everyone. Reading the Talmud about the interface, written in clerical language - certainly not a very pleasant pastime. Interface specialists develop TZs and transfer them to Customers. And they ask to read the technical task (or specification) - how to develop and change the designed interface.
')
Usually it is possible to agree on the degree of detailing of the TZ with the contractor:
1. Is the interface made like this?
2. IS IT POSSIBLE to use it and how can it be used in actual development?
And here comes the factor of experience. An experienced developer sees the implementation, he already has his own vision, his knowledge of the implementation of the system. And then he is asked to "invent a bicycle" and stick to read the TK.
TK is a reference, big, about what should be in the ideal.
TK should be discussed: where you can walk, and where it is undesirable, and why. The TOR on the interface gives advice on what the interface should be convenient for the User.
It is better to start discussing the TOR before the design stage, at the stage of developing the interface concept:
Profit : the developer is more involved and motivated: he just needs to warn the performers about what is not applicable in the new (or modified) interface, in his opinion and in his experience.
So it is to meet the requirements of the user (the user is in the first place), business requirements, development requirements.
A designed interface is an example of how a real system interface should behave when interacting with a user.
Why this is how he behaves - again, it is written in the technical task. The specialist, when writing TZ, focuses on the elements that are not obvious in the context of the entire protype. Especially:
- on key screens (priority and private pages of the interface, arising from interaction with the user);
- on typical screens (with similar functionality and purpose).
If the designed interface interacts with the User not in the way that the development expected and assumed (“... it is NOT possible to apply / do this”), then either the Users are more comfortable or it’s a miscalculation when discussing technical limitations with the developers.
Therefore, the presence of developers in the working group is desirable, necessarily, and familiarization with the results of iterations in the design is important.
Users, of course, ask for or want something (and maybe they don’t ask at all: after all, they don’t voice everything and get used to the inconvenience and stop noticing it) - but technically this is impossible.
Or it’s necessary to show the advertisement in _ this very place where there should be a button_, and then the business will be bent - it means that you have to show the advertisement, at least kill yourself.
Deviations about the real world are possible, and it is these deviations that need to be discussed . This is either provided for in the TOR (at the time of the transfer of the designed interface, which is also being corrected), or is found during development and implementation, which is more sad.
However, if the designed interface needs to be changed in the implementation process, this can also be provided for in the TOR - for this it is necessary to include in the TOR a description of the process of building the interface concept.
And, in the future, when new user requirements arise, you need to update the concept:
- add and describe new users of the system - if such appear;
- describe new user goals;
- add or make changes to user scripts;
- write out and record user requirements, business requirements, technical limitations to the screens arising during the passage of scenarios;
- update the list of key and standard pages, as well as the structure of the navigation and menu interface;
- make changes to the TOR and the designed interface so that, in the future, the developed product can be checked for compliance with all requirements.
0. Not only read, but also participate;
1. Development experience is good, and satisfied users are more important (customers or employees => or money that brings, or time that is saved, or both);
2. In order to avoid mistakes with the unobvious interaction of the user and the system, relying on the user (client) experience, and not the developer;
3. TK should be used as a checklist to check the developed product for compliance with user requirements.
4. TK describes how to change the interface: in what cases and in what sequence, without harm for all parties.
And this is the view of only one side.
I'd like to hear the opinion of the readers of TZ - developers.
This post is about the Terms of Reference for the development of interfaces [for users].
Developers - the same people as everyone. Reading the Talmud about the interface, written in clerical language - certainly not a very pleasant pastime. Interface specialists develop TZs and transfer them to Customers. And they ask to read the technical task (or specification) - how to develop and change the designed interface.
')
What is included in the terms of reference for developing a designed interface?
Usually it is possible to agree on the degree of detailing of the TZ with the contractor:
- It can be a document that describes key and typical interface screens, elements of screens (or pages) and ambiguous behavior of these elements on a specific screen.
- Or a document that includes a methodology for paginating the “collection” of interface screens and explains the relationships between the screens. And also such TK can explain why one or another interface building logic is applied.
- Or, in general, it is documented: a manual on ergonomics, which will tell everything about the interface (and still nobody will read it for sure).
TK helps answer two questions
1. Is the interface made like this?
2. IS IT POSSIBLE to use it and how can it be used in actual development?
And here comes the factor of experience. An experienced developer sees the implementation, he already has his own vision, his knowledge of the implementation of the system. And then he is asked to "invent a bicycle" and stick to read the TK.
TK is a reference, big, about what should be in the ideal.
But you can look at the situation “I already know everything” in a different way.
TK should be discussed: where you can walk, and where it is undesirable, and why. The TOR on the interface gives advice on what the interface should be convenient for the User.
In real life
It is better to start discussing the TOR before the design stage, at the stage of developing the interface concept:
- preferably, it is necessary to discuss the technical constraints, budget possibilities and development resources applicable in reality (or you can think up for a million, or for many, many jobs);
- as a maximum, discuss the perceived difficulties of your existing and future customers, will they use the product developed by you as described in the concept, do they have any restrictions, is it possible to implement?
Profit : the developer is more involved and motivated: he just needs to warn the performers about what is not applicable in the new (or modified) interface, in his opinion and in his experience.
The first question is: “Is the interface made like this?”
So it is to meet the requirements of the user (the user is in the first place), business requirements, development requirements.
- Business requirements are discussed and recorded at the initial stage of the project.
- Development requirements are recorded in the form of technical capabilities and constraints at the initial stage, as well as during iterations (preferably at the stage of developing the interface concept, and at the stage of submitting the draft work).
- User Requirements for the interface - at the initial stage (interviews with users), at the concept development stage (profiles, scenarios, navigation structure, description of interface pages when setting a design task).
The second question is: “CAN YOU use a designed interface for development?”
A designed interface is an example of how a real system interface should behave when interacting with a user.
Why this is how he behaves - again, it is written in the technical task. The specialist, when writing TZ, focuses on the elements that are not obvious in the context of the entire protype. Especially:
- on key screens (priority and private pages of the interface, arising from interaction with the user);
- on typical screens (with similar functionality and purpose).
If the designed interface interacts with the User not in the way that the development expected and assumed (“... it is NOT possible to apply / do this”), then either the Users are more comfortable or it’s a miscalculation when discussing technical limitations with the developers.
Therefore, the presence of developers in the working group is desirable, necessarily, and familiarization with the results of iterations in the design is important.
But there is no ideal
Users, of course, ask for or want something (and maybe they don’t ask at all: after all, they don’t voice everything and get used to the inconvenience and stop noticing it) - but technically this is impossible.
Or it’s necessary to show the advertisement in _ this very place where there should be a button_, and then the business will be bent - it means that you have to show the advertisement, at least kill yourself.
Deviations about the real world are possible, and it is these deviations that need to be discussed . This is either provided for in the TOR (at the time of the transfer of the designed interface, which is also being corrected), or is found during development and implementation, which is more sad.
However, if the designed interface needs to be changed in the implementation process, this can also be provided for in the TOR - for this it is necessary to include in the TOR a description of the process of building the interface concept.
And, in the future, when new user requirements arise, you need to update the concept:
- add and describe new users of the system - if such appear;
- describe new user goals;
- add or make changes to user scripts;
- write out and record user requirements, business requirements, technical limitations to the screens arising during the passage of scenarios;
- update the list of key and standard pages, as well as the structure of the navigation and menu interface;
- make changes to the TOR and the designed interface so that, in the future, the developed product can be checked for compliance with all requirements.
So why read TK?
0. Not only read, but also participate;
1. Development experience is good, and satisfied users are more important (customers or employees => or money that brings, or time that is saved, or both);
2. In order to avoid mistakes with the unobvious interaction of the user and the system, relying on the user (client) experience, and not the developer;
3. TK should be used as a checklist to check the developed product for compliance with user requirements.
4. TK describes how to change the interface: in what cases and in what sequence, without harm for all parties.
And this is the view of only one side.
I'd like to hear the opinion of the readers of TZ - developers.
Source: https://habr.com/ru/post/138505/
All Articles