Taking care of the user, or how to save customers from mistakes

    In the modern world, applications are in demand that are capable of maximally observing 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 would be disadvantageous to him or the owner of the system. At the same time it is necessary to minimize the discomfort caused by such restrictions.



    For example, the system owner needs the phone number in the feedback form to be 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, which excludes entering data in the wrong format. It turns out, and the wolves are fed and the sheep are safe.

    In some cases, the system limits 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, as in the work of Alexey Apukhtin: “... he stole or was stolen from him ... The main thing is that he was involved in foul business ... ".

    Thus, when developing an application, it is necessary to think of 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:

    1. Not to limit the user in any way , that is, to expect that he himself will not be mistaken and will not harm himself or the owner of the system.
    2. Partially restrict - the user may make a mistake, but less likely (or less serious).
    3. Enter 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.
    4. Needless to limit - the user is limited so that it prevents him from using the system.
    5. Fully restrict the user , that is, block the feature.

    On the first and fifth levels, a familiar example can be 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 is 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 within 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 every 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 contains not only the input mask (second level), but also a check that the user has 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 launch of the project, we 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 beginning 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;
    • recording 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 dial up attempt cannot be considered an interaction, and you can try the task 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.

    Given the tight deadlines, it was impractical to re-immerse the analyst in the project, so our QA specialist was given the task of considering whether the existing implementation was in line with how the application was planned to be used on the customer’s side. During the analysis, we built the following logical chain:

    1. A debtor may have several numbers (mobile, home, work), but you can only schedule a call to one number.
    2. 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.
    3. Therefore, to attempt to dial another number, the user must manually cancel the pending task and assign a new one.
    4. But at the same time and other numbers may not be able to reach. And then the tasks postponed due to the lack of a call, it turns out, in vain were canceled. You need to assign them again to call again later.

    It should be noted that, according to information from the customer, unsuccessful attempts to dial in practice occur quite often.

    In addition, it was planned to develop a 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;
    • Software The collector 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 does not limit the number of attempts to contact the debtor, but the number of successful attempts at interaction. And this meant that the limit of interactions needed to 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:

    1. “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.
    2. “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 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 amending the Federal Law" On microfinance activities and microfinance organizations. "

    Also popular now: