Taking care of the user, or how to protect customers from mistakes
In the modern world, applications are in demand that are able to most effectively observe the interests of all parties. Often this is done through various kinds of restrictions. For example, they do not allow the user to perform actions that will be disadvantageous to him or the owner of the system. It is necessary to minimize the discomfort caused by such restrictions.
For example, the owner of the system needs the phone number in the feedback form to be specified in the format +7 (XXX) XXX-XX-XX for further automated use. For the convenience of the user, it is better to use not just a hint or validation when submitting the form, but an input mask, excluding data being entered in the wrong format. It turns out, and the wolves are fed and the sheep are safe.
In some cases, the system restricts the user to protect against potential losses. For example, like requirements to fasten a seat belt before driving, in online payment services it is necessary not only to enter data from the card, but also to confirm payment with a code from an SMS message, which significantly reduces the likelihood of money theft. And it should be noted that such concern about the user's safety is beneficial to the service owner, as it reduces reputational risks, otherwise it can come out, like in the work of Alexey Apukhtin: “... whether he stole or stole from him ... The main thing is that he was involved in ugly business ... ".
')
Thus, when developing an application, it is necessary to think out the functionality in such a way that it will please both the immediate customer and the ordinary user. With this in mind, there are five levels of system limitations:
On the first and fifth levels, a familiar example is the familiar situation when a cashier in the store shouts “Galya, cancel!”, And the almighty Galya comes to the rescue. In this case, the cashier completely blocked the function of removing the punched goods from the check, and Gali has no restrictions on this operation. That is, these degrees of limitation can often be used in the framework of the implementation of the role model.
And in the case when we are not talking about extremes, one of the intermediate options is created in the system. And then the important task of any project is to introduce all the necessary restrictions, but not redundant ones (the third level). So that, for example, not at each stage of filling in an application fill out a captcha (fourth level), but only before sending the full form. Or that the phone entry field contained not only the input mask (second level), but also a check that the user entered 11 digits of the number.
Let's give an example. We had a project to develop an application to support the collection process (hereinafter - Collector software). As part of the project launch, we have compiled and agreed the terms of reference, after which the work of the analyst was for the most part completed. It is worth noting that the customer was a company that is just starting to engage in debt collection, that is, as it turned out later, the work process is still at the debugging stage.
And at that moment, when the development on the project was carried out for about six months, new information was received about the features of the work of potential users of the system, as well as about the planned modifications. It should immediately make a reservation that at that time, we implemented including the following functional tasks:
Let's clarify that the last of the listed functionalities was as follows: Collector software limited the ability to assign tasks that could potentially violate the requirements of the law. In this case, if the phone could not be reached (the user sets the corresponding call result), the task is postponed and the operator can return to it again later. That is, an unsuccessful call attempt cannot be considered an interaction, and the task can be tried again.
What has become known about the features of the users? It turned out that in the case of an unsuccessful attempt to reach the mobile debtor, the operator would not only postpone the task, but also, if any other numbers were assigned to the debtor, immediately try to call them.
In the context of tight deadlines, it was impractical to re-immerse the analyst in the project, so our QA-specialist was given the task to consider whether the existing implementation is in line with how the application is planned to be used on the customer’s side. During the analysis, we built the following logical chain:
It should be noted that, according to the information from the customer, unsuccessful attempts to dial in practice occur quite often.
In addition, it was planned to develop the functionality for integrating the Collector software with the analytical system for automatic assignment of events (hereinafter ASANM), which was created on the customer’s side. The essence is implied as follows:
According to the conclusion of a QA-specialist, in the existing implementation both the operator and ASANM would not be able to schedule telephone calls to all numbers of the debtor.
In general, it was understood that the fourth level of restrictions was implemented (unnecessary restrictions): to make a call to other numbers, you must manually cancel the pending task. In fact, it turned out that the law limits not the number of attempts to contact the debtor, but the number of successful attempts at interaction. And this meant that the limit interaction should be calculated based on the results of the tasks.
In this regard, we initiated a change in the format of the implementation and a more expedient way of meeting the requirements was chosen:
A whole sprint was spent on making changes, but one can say for sure that this time is not wasted and now ordinary users will not be inconvenienced when working in the application, so the system owner will be able to plan the work of operators using ASANM.
All those who, when implementing the restrictions, take care of the user and the customer, we advise you to follow two simple rules:
1 Requirements are established by the Federal Law of 03.07.2016 N 230-FZ "On the protection of the rights and legitimate interests of individuals when carrying out activities to return overdue debts and on amendments to the Federal Law" On microfinance activities and microfinance organizations. "
For example, the owner of the system needs the phone number in the feedback form to be specified in the format +7 (XXX) XXX-XX-XX for further automated use. For the convenience of the user, it is better to use not just a hint or validation when submitting the form, but an input mask, excluding data being entered in the wrong format. It turns out, and the wolves are fed and the sheep are safe.
In some cases, the system restricts the user to protect against potential losses. For example, like requirements to fasten a seat belt before driving, in online payment services it is necessary not only to enter data from the card, but also to confirm payment with a code from an SMS message, which significantly reduces the likelihood of money theft. And it should be noted that such concern about the user's safety is beneficial to the service owner, as it reduces reputational risks, otherwise it can come out, like in the work of Alexey Apukhtin: “... whether he stole or stole from him ... The main thing is that he was involved in ugly business ... ".
')
Thus, when developing an application, it is necessary to think out the functionality in such a way that it will please both the immediate customer and the ordinary user. With this in mind, there are five levels of system limitations:
- Do not limit the user in any way , that is, expect that he himself will not be mistaken and will not harm himself or the owner of the system.
- Partially restrict - the user may make a mistake, but less likely (or less serious).
- Introduce the necessary restrictions , but not redundant ones - the user is so limited that he cannot make a mistake, but at the same time the restrictions do not create problems in using the system. This is the perfect option.
- Needless to limit - the user is limited so that it prevents him from using the system.
- Fully restrict the user , that is, block the feature.
On the first and fifth levels, a familiar example is the familiar situation when a cashier in the store shouts “Galya, cancel!”, And the almighty Galya comes to the rescue. In this case, the cashier completely blocked the function of removing the punched goods from the check, and Gali has no restrictions on this operation. That is, these degrees of limitation can often be used in the framework of the implementation of the role model.
And in the case when we are not talking about extremes, one of the intermediate options is created in the system. And then the important task of any project is to introduce all the necessary restrictions, but not redundant ones (the third level). So that, for example, not at each stage of filling in an application fill out a captcha (fourth level), but only before sending the full form. Or that the phone entry field contained not only the input mask (second level), but also a check that the user entered 11 digits of the number.
Let's give an example. We had a project to develop an application to support the collection process (hereinafter - Collector software). As part of the project launch, we have compiled and agreed the terms of reference, after which the work of the analyst was for the most part completed. It is worth noting that the customer was a company that is just starting to engage in debt collection, that is, as it turned out later, the work process is still at the debugging stage.
And at that moment, when the development on the project was carried out for about six months, new information was received about the features of the work of potential users of the system, as well as about the planned modifications. It should immediately make a reservation that at that time, we implemented including the following functional tasks:
- assigning a task to make a call to the debtor;
- the implementation of the assigned task;
- fixing the result of interaction (by the user manually);
- ensuring compliance with the requirements of the legislation of the Russian Federation on the frequency of interactions with debtors 1 .
Let's clarify that the last of the listed functionalities was as follows: Collector software limited the ability to assign tasks that could potentially violate the requirements of the law. In this case, if the phone could not be reached (the user sets the corresponding call result), the task is postponed and the operator can return to it again later. That is, an unsuccessful call attempt cannot be considered an interaction, and the task can be tried again.
What has become known about the features of the users? It turned out that in the case of an unsuccessful attempt to reach the mobile debtor, the operator would not only postpone the task, but also, if any other numbers were assigned to the debtor, immediately try to call them.
In the context of tight deadlines, it was impractical to re-immerse the analyst in the project, so our QA-specialist was given the task to consider whether the existing implementation is in line with how the application is planned to be used on the customer’s side. During the analysis, we built the following logical chain:
- A debtor may have several numbers (mobile, home, work), but you can only schedule a call to one number.
- If the operator fails to reach the customer, the task will be postponed, but you will still not be able to call another number, because A deferred task will also block the appointment of a call to other numbers.
- Therefore, to attempt to dial another number, the user must manually cancel the pending task and assign a new one.
- But at the same time and other numbers may not be able to reach. And then the tasks postponed due to a call failure, it turns out, in vain were canceled. You need to assign them again to call again later.
It should be noted that, according to the information from the customer, unsuccessful attempts to dial in practice occur quite often.
In addition, it was planned to develop the functionality for integrating the Collector software with the analytical system for automatic assignment of events (hereinafter ASANM), which was created on the customer’s side. The essence is implied as follows:
- daily (once a day) ASANM creates a list of tasks that must be completed under the contracts, and sends a request to the Collector software;
- The Collector software from the received list assigns those tasks that do not exceed the interaction limit.
According to the conclusion of a QA-specialist, in the existing implementation both the operator and ASANM would not be able to schedule telephone calls to all numbers of the debtor.
In general, it was understood that the fourth level of restrictions was implemented (unnecessary restrictions): to make a call to other numbers, you must manually cancel the pending task. In fact, it turned out that the law limits not the number of attempts to contact the debtor, but the number of successful attempts at interaction. And this meant that the limit interaction should be calculated based on the results of the tasks.
In this regard, we initiated a change in the format of the implementation and a more expedient way of meeting the requirements was chosen:
- count the number of interactions to implement the results of the implementation of activities;
- if the limit is not reached, then allow the user / ASANM to assign events without restrictions;
- if the limit is reached, then cancel unnecessary events and prohibit their appointment.
A whole sprint was spent on making changes, but one can say for sure that this time is not wasted and now ordinary users will not be inconvenienced when working in the application, so the system owner will be able to plan the work of operators using ASANM.
Conclusion
All those who, when implementing the restrictions, take care of the user and the customer, we advise you to follow two simple rules:
- “A sufficient number of babysitters will not lose their eyes” - that is, you need to sufficiently protect the user from making mistakes that could harm him or the owner of the system.
- “To fear wolves, but to go to the forest” - it is necessary to avoid unnecessary restrictions, because otherwise the value of the product being developed for the user is lost.
1 Requirements are established by the Federal Law of 03.07.2016 N 230-FZ "On the protection of the rights and legitimate interests of individuals when carrying out activities to return overdue debts and on amendments to the Federal Law" On microfinance activities and microfinance organizations. "
Source: https://habr.com/ru/post/433860/
All Articles