Models of reality in the design of interfaces, or how to increase the efficiency of the process several times
Many today use prototyping, developing prototypes of interfaces at the very beginning of the project. It is well known that the correction of an error at this stage is many times cheaper than at later stages.
However, there is another stage in the development, which plays a very large role, but to which few people pay due attention. And this stage is a model of the project in the head, including the interface. And if errors at all other stages are visible and easy to detect, then the error of the thinking process in the process of thinking through the project and its interface becomes clear only at the very end - when the project is already being tested in combat conditions.
How to find errors of this kind, to deal with them, and an example from real practice read inside.
The essence of the error is simple. Man holds in his head the idea of ​​any aspect of the world, and believes that in reality it will be so. In fact, the difference between the picture in the head and reality turns into hundreds of thousands of rubles and dozens of hours of work of different specialists who go nowhere.
')
First you need to realize that the error itself exists. Usually, a person is sure that he can design the interface exactly the way it will be at the very end, do “all right” and “think everything over”. But to think so is a delusion.
First, everything will change - this is the law in the development of any products. Therefore, the easier the process will be to change, the better. Hence the rule - to do the minimum necessary volume at any stage, say, iteration in one day - so that, if done wrong, it would not be a pity to throw it away and do it first.
At the same time, the test of loyalty or infidelity must take place on the end users of the product, there must be live (and not test) data in the product, everything must be real.
Secondly, it is impossible to think 100% at the initial stage. It can be taken as an axiom - if not the rare case when the interface designer or the designer of the project concept has deep experience in the field of the project, in 99% of cases all complex pieces will be by.
The only possible option is to get used to the role of the end user (you make software for accountants - become an accountant and look at software like an accountant, how to solve problems from an accountant's point of view, and so on). But it requires a lot of experience and great skill, and often time, which is not always possible.
Therefore, it is reasonable to strive to identify the main tasks for the iteration from the mouth of specific users (at the same time, to separate the problems themselves from how the users see the solutions — after all, the users are not professionals, unlike you, in developing projects).
And do the iterations themselves as short as possible and work as closely as possible with live users, supplying them with a project, albeit only partially, with live data, and carefully collecting feedback, observing them.
As an example, consider the automation of the personnel department, which I am now working in the same company, working with a team of excellent professionals. We have built a process where releases go every day, and every day this or that functionality is implemented and tested on live users and real data. Due to such a pace of refinement and really necessary chips arrive the very next day.
So, when we made the automation of resume registration (all resumes coming in the mail, etc., from the girl who seeks and adds them with her hands, and added through the site), were broken down by status (visually tabs - not reviewed, thought sent) test, refused, refused, etc.), there in the process of transferring a resume from one tab to another popup appeared - where to move.
After the transfer, the person threw on the final tab (was, for example, in “not reviewed”, chose the person, clicked to move to “refused”, entered the reason for the refusal - and threw it in “refused”). At the start, it turned out that when the personnel department sorted out hundreds of resumes, it was more convenient for them to stay in the current tab - for it was necessary, after you moved to the final tab, to return to the one where you parsed the resume list.
If the designer had worked with a hundred resumes, and not a dozen, solving a real problem, he would not have made this mistake. Its correction cost a couple of hours of work as a programmer, and they might not have been. Also with the filter by name - if a person tried to work with 1000 resumes, he would understand that a filter by name is very necessary.
Actually, many startups are unnecessary because people consider
themselves are smarter than their users, and create no-use interfaces, engines, and projects for anyone, spending their time and money (and often not only theirs).
It is worth noting that this approach is a pattern in the broad sense of the word. This means that it can be applied in any field. For example, in programming it is to get TK from the customer, to jot down a prototype, correct from the point of view of logic, but in the code “as quickly”. Show right there, get a list of improvements, and so on until the main logic is done. Further to refactor, and to make already precisely. This approach will save from 100% to 1000% of your time and customer time.
I wish you that in your projects the percentage of the desired functionality would strive for 100%!
However, there is another stage in the development, which plays a very large role, but to which few people pay due attention. And this stage is a model of the project in the head, including the interface. And if errors at all other stages are visible and easy to detect, then the error of the thinking process in the process of thinking through the project and its interface becomes clear only at the very end - when the project is already being tested in combat conditions.
How to find errors of this kind, to deal with them, and an example from real practice read inside.
The essence of the error is simple. Man holds in his head the idea of ​​any aspect of the world, and believes that in reality it will be so. In fact, the difference between the picture in the head and reality turns into hundreds of thousands of rubles and dozens of hours of work of different specialists who go nowhere.
')
First you need to realize that the error itself exists. Usually, a person is sure that he can design the interface exactly the way it will be at the very end, do “all right” and “think everything over”. But to think so is a delusion.
First, everything will change - this is the law in the development of any products. Therefore, the easier the process will be to change, the better. Hence the rule - to do the minimum necessary volume at any stage, say, iteration in one day - so that, if done wrong, it would not be a pity to throw it away and do it first.
At the same time, the test of loyalty or infidelity must take place on the end users of the product, there must be live (and not test) data in the product, everything must be real.
Secondly, it is impossible to think 100% at the initial stage. It can be taken as an axiom - if not the rare case when the interface designer or the designer of the project concept has deep experience in the field of the project, in 99% of cases all complex pieces will be by.
The only possible option is to get used to the role of the end user (you make software for accountants - become an accountant and look at software like an accountant, how to solve problems from an accountant's point of view, and so on). But it requires a lot of experience and great skill, and often time, which is not always possible.
Therefore, it is reasonable to strive to identify the main tasks for the iteration from the mouth of specific users (at the same time, to separate the problems themselves from how the users see the solutions — after all, the users are not professionals, unlike you, in developing projects).
And do the iterations themselves as short as possible and work as closely as possible with live users, supplying them with a project, albeit only partially, with live data, and carefully collecting feedback, observing them.
As an example, consider the automation of the personnel department, which I am now working in the same company, working with a team of excellent professionals. We have built a process where releases go every day, and every day this or that functionality is implemented and tested on live users and real data. Due to such a pace of refinement and really necessary chips arrive the very next day.
So, when we made the automation of resume registration (all resumes coming in the mail, etc., from the girl who seeks and adds them with her hands, and added through the site), were broken down by status (visually tabs - not reviewed, thought sent) test, refused, refused, etc.), there in the process of transferring a resume from one tab to another popup appeared - where to move.
After the transfer, the person threw on the final tab (was, for example, in “not reviewed”, chose the person, clicked to move to “refused”, entered the reason for the refusal - and threw it in “refused”). At the start, it turned out that when the personnel department sorted out hundreds of resumes, it was more convenient for them to stay in the current tab - for it was necessary, after you moved to the final tab, to return to the one where you parsed the resume list.
If the designer had worked with a hundred resumes, and not a dozen, solving a real problem, he would not have made this mistake. Its correction cost a couple of hours of work as a programmer, and they might not have been. Also with the filter by name - if a person tried to work with 1000 resumes, he would understand that a filter by name is very necessary.
Actually, many startups are unnecessary because people consider
themselves are smarter than their users, and create no-use interfaces, engines, and projects for anyone, spending their time and money (and often not only theirs).
It is worth noting that this approach is a pattern in the broad sense of the word. This means that it can be applied in any field. For example, in programming it is to get TK from the customer, to jot down a prototype, correct from the point of view of logic, but in the code “as quickly”. Show right there, get a list of improvements, and so on until the main logic is done. Further to refactor, and to make already precisely. This approach will save from 100% to 1000% of your time and customer time.
I wish you that in your projects the percentage of the desired functionality would strive for 100%!
Source: https://habr.com/ru/post/117197/
All Articles