Быстрый интерфейс: почему сервис должен летать?
В рамках одного из моих проектов, я провел небольшое исследование — как медленный интерфейс влияет на поведение пользователя? Некоторые выводы были весьма очевидными, некоторые следуют из очевидных, а некоторые весьма неожиданны. Хочу поделится полученным опытом от удачного эксперимента с Хабрасообществом.
Эксперимент проводился довольно просто, по принципу A/B тестирования. Аудитория A работала с сервисом «быстро», так как они и работает. А у аудитории B при отдаче каждой страницы был сделан sleep на 700 миллисекунд.
Пронаблюдав некоторое время за движениями мышки пользователя из группы B (благо сервисов для этого предостаточно), мы поняли: во первых в медленном интерфейсе пользователь боится ошибиться, т.к. в случае ошибки, он будет долго её исправлять (+700ms на каждый чих). Он тщательно заполняет формы, думает на какую кнопку нажать. Учится на своих ошибках и после 2–3 прецедентов с ошибками — он становится более аккуратным пользователем интерфейса, чем те, у кого интерфейс «летает», совершает меньше ошибок в формах, делает меньше бесполезных действий. Но он продолжает боятся «нажать не туда», «выбрать не то».
Спустя несколько дней мы узнали, что увеличился приток писем в техподдержку. Это были пользователи аудитории B. Мы сразу отмели письма «о тормозах», а оставшиеся проблемы проанализировали. Среди них появилась категория писем значительного размера «как сделать что-то?». В штатной ситуации такие вопросы нам задают крайне редко — интерфейс прост, интуитивно понятен и не имеет ничего лишнего. Мы сделали предположение, что пользователь просто не хочет разбираться в тормозящем интерфейсе — он хочет ответ сходу. Ну и наиболее настойчивые пишут в техподдержку.
Тут мы задались вопросом, а куда делись те, кто не написал в support? С ними все было еще печальнее — треть их безвозвратно потерялась для сервиса — они просто ушли (видимо нашли быстрый аналогичный сервис), две трети — продолжали мучатся и ждать 700ms. Один пользователь завел новый аккаунт и по воле случая попал в группу A. Больше у него ничего не тормозило.
Спустя пять дней мы решили не мучать аудиторию и выключить для группы B sleep в 700 миллисекунд. Письма в техподдержку со странными вопросами «как это сделать?» прекратились только спустя 3 недели — пользователи уже привыкли мучать support.
Тут мы решили сравнить аудитории A и B по активности приглашения друзей и «лайков» в соцсетях. Оказалось, что аудитория B примерно в 1,5 раза меньше «пиарила» наш сервис. Не удивительно, я бы тоже не рекомендовал сервис, который тормозит.
ВыводыКратко, что получилось в итоге: Пользователи «боятся» медленного интерфейса Они мучают техподдержку Они в бОльшем количестве уходят из сервиса «Профит от тормозов» И все же есть одно место, где польза от медленной работы есть. Мы проанализировали отдельные места интерфейса (по старым записям поведения пользователя) и казалось совершенно неожиданное. Мы решили проверить еще раз. Добавили sleep на 1500ms в одно единственное место. Спустя две недели мы поняли, что это повысило продажи! Раньше у нас была очень быстрая подсистема оплаты услуг сервиса — она буквально летала. Пользователю не составляло труда, закинуть на счет в 100 рублей, каждый раз как они ему были нужны.
Мы добавили sleep и пользователям стало несколько тяжелее делать оплату, появилась подсознательная лень. Не платить пользователи тоже не могли. Они стали закидывать на счет не 100 рублей как раньше, а 500 — чтобы лишний раз не проходить через «тормозную оплату».
Это произвело интересный, но весьма ожидаемый эффект — имея больше средств на счете, пользователи стали их больше тратить. Ну и соответственно стали больше пополнять. В результате добавления sleep на 1500 миллисекунд продажи сервисы заметно выросли. Невероятно, но факт.
WARN: Я понимаю, и вы должны понимать, что это далеко не серебряная пуля. Я даже отговариваю Вас от медленного интерфейса оплаты. В Вашем случае это не заработает с большей вероятностью, чем не заработало бы у нас — в нашем сервисе своя специфика.
