Quick interface: why should the service fly?
As part of one of my projects, I did a little research - how does a slow interface affect user behavior?
Some conclusions were very obvious, some follow from the obvious, and some very unexpected. I want to share my experience from a successful experiment with the Habrasoobschestvom.
The experiment was conducted quite simply, on the basis of A / B testing. Audience A worked with the service “quickly,” as they work. And for audience B, when every page was returned, sleep was made for 700 milliseconds.
Having observed for some time the movements of the mouse of a user from group B (the benefit of the services is enough for this), we understood: first, the user is afraid to make a mistake in the slow interface, because in case of an error, he will fix it for a long time (+ 700ms for each sneeze). He carefully fills out forms, thinks which button to press. He learns from his mistakes and after 2-3 precedents with errors - he becomes a more accurate user of the interface than those with whom the interface “flies”, makes less mistakes in the forms, makes less useless actions. But he continues to fear "push the wrong way", "choose the wrong."
')
A few days later we learned that the influx of letters to technical support has increased. These were users of audience B. We immediately dismissed the letters “on brakes”, and analyzed the remaining problems. Among them appeared the category of letters of considerable size “how to do something?”. In a regular situation, such questions are asked us extremely rarely - the interface is simple, intuitive, and has nothing superfluous. We made the assumption that the user simply does not want to understand the braking interface - he wants the answer right away. Well, the most persistent are writing to tech support.
Here we asked ourselves a question: where did those who did not write to support go? Everything was even sadder with them - a third of them were irretrievably lost for the service - they just left (apparently they found a quick similar service), two thirds - continued to suffer and wait 700ms. One user started a new account and by chance got into group A. Nothing more slowed him down.
Five days later, we decided not to torment the audience and turn off for 700 seconds B for the B sleep group. Letters to tech support with strange questions “how to do this?” Stopped only after 3 weeks - users are already accustomed to tormenting support.
Here we decided to compare the audience of A and B on the activity of inviting friends and likes in social networks. It turned out that audience B is about 1.5 times less “promoting” our service. Not surprisingly, I would not recommend the service, which slows down.
Briefly, what happened in the end:
And yet there is one place where the benefits of slow work are. We analyzed some parts of the interface (according to the old records of user behavior) and it seemed completely unexpected. We decided to check again. Added sleep for 1500ms in one single place. Two weeks later, we realized that this increased sales!
Previously, we had a very fast subsystem of payment services - it literally flew. The user was not difficult, throw in the account of 100 rubles, every time he needed them.
We added sleep and it became somewhat harder for users to make payment, subconscious laziness appeared. Users could not not pay either. They began to throw into the account not 100 rubles as before, but 500 - in order not to go through the “brake payment” once again.
This produced an interesting, but highly expected effect - having more funds on the account, users began to spend more. Well, respectively, began to replenish more. As a result of the addition of sleep for 1500 milliseconds, sales of services increased markedly. Unbelievable, but it is a fact.
WARN: I understand, and you should understand that this is far from a silver bullet. I even discourage you from a slow payment interface. In your case, it will not work with greater probability than it would not have worked with us - our service has its own specifics.
Some conclusions were very obvious, some follow from the obvious, and some very unexpected. I want to share my experience from a successful experiment with the Habrasoobschestvom.
The experiment was conducted quite simply, on the basis of A / B testing. Audience A worked with the service “quickly,” as they work. And for audience B, when every page was returned, sleep was made for 700 milliseconds.
Having observed for some time the movements of the mouse of a user from group B (the benefit of the services is enough for this), we understood: first, the user is afraid to make a mistake in the slow interface, because in case of an error, he will fix it for a long time (+ 700ms for each sneeze). He carefully fills out forms, thinks which button to press. He learns from his mistakes and after 2-3 precedents with errors - he becomes a more accurate user of the interface than those with whom the interface “flies”, makes less mistakes in the forms, makes less useless actions. But he continues to fear "push the wrong way", "choose the wrong."
')
A few days later we learned that the influx of letters to technical support has increased. These were users of audience B. We immediately dismissed the letters “on brakes”, and analyzed the remaining problems. Among them appeared the category of letters of considerable size “how to do something?”. In a regular situation, such questions are asked us extremely rarely - the interface is simple, intuitive, and has nothing superfluous. We made the assumption that the user simply does not want to understand the braking interface - he wants the answer right away. Well, the most persistent are writing to tech support.
Here we asked ourselves a question: where did those who did not write to support go? Everything was even sadder with them - a third of them were irretrievably lost for the service - they just left (apparently they found a quick similar service), two thirds - continued to suffer and wait 700ms. One user started a new account and by chance got into group A. Nothing more slowed him down.
Five days later, we decided not to torment the audience and turn off for 700 seconds B for the B sleep group. Letters to tech support with strange questions “how to do this?” Stopped only after 3 weeks - users are already accustomed to tormenting support.
Here we decided to compare the audience of A and B on the activity of inviting friends and likes in social networks. It turned out that audience B is about 1.5 times less “promoting” our service. Not surprisingly, I would not recommend the service, which slows down.
findings
Briefly, what happened in the end:
- Users are “afraid” of a slow interface.
- They torment tech support
- They largely leave the service.
"Profit from the brakes"
And yet there is one place where the benefits of slow work are. We analyzed some parts of the interface (according to the old records of user behavior) and it seemed completely unexpected. We decided to check again. Added sleep for 1500ms in one single place. Two weeks later, we realized that this increased sales!
Previously, we had a very fast subsystem of payment services - it literally flew. The user was not difficult, throw in the account of 100 rubles, every time he needed them.
We added sleep and it became somewhat harder for users to make payment, subconscious laziness appeared. Users could not not pay either. They began to throw into the account not 100 rubles as before, but 500 - in order not to go through the “brake payment” once again.
This produced an interesting, but highly expected effect - having more funds on the account, users began to spend more. Well, respectively, began to replenish more. As a result of the addition of sleep for 1500 milliseconds, sales of services increased markedly. Unbelievable, but it is a fact.
WARN: I understand, and you should understand that this is far from a silver bullet. I even discourage you from a slow payment interface. In your case, it will not work with greater probability than it would not have worked with us - our service has its own specifics.
Source: https://habr.com/ru/post/223705/
All Articles