The post has been translated automatically. Original language: Russian
What should I do if the service is being used "incorrectly"?
There are legends that the documentation and manuals are read about as often as the terms of the license agreement. The user just acts as convenient as possible, and as a result, there are only delays and timeouts.
It is important to understand that the client almost never comes to use the service correctly. He comes to solve his task — quickly, within his limitations, budget and level of expertise. And if the service allows you to do this in the "wrong" way, then it's not the client's fault.
A fairly typical situation is when a user chooses an available service configuration that is not designed for their load scenarios. The configurator calmly accepts the settings and does not issue any warnings. After some time, performance problems start. The client writes to support, and in response he hears that it is not recommended to use this configuration for such loads. The negative reaction of the client is understandable here: if this is a bad option, why was it available at all?
Another example: the user turns on the option, unaware that it is intended for a narrow scenario. In the interface, it looks like a regular checkmark with no comments or restrictions. Later it turns out that it was this setting that caused the problems.
The most dangerous thing in such situations is the habit of attributing everything to the "improper use" of the service by the client. It is convenient, because you can turn a blind eye to the problems of the service, but it is expensive.
What are the possible consequences?
·Support starts working in the mode of constant resolution of emergency situations;
·Exploitation catches unexpected scenarios;
·The user feels like they are being punished for trying to figure it out on their own;
·The team loses an important signal about the stage at which the user is having problems.
"Misuse" does not mean that the client has made a mistake or is incompetent. For the owners of the service, this is an opportunity to collect feedback.
How to work with this feedback?
Sometimes things start to go from one extreme to the other. For example, when developers try to hide dangerous buttons and close opportunities. However, instead of bans, they should consider:
1. Explain the context.
One of the most frequent product troubles is silent interfaces. The button is there, the action is available, the consequences are not visible. It is much more effective not to remove the opportunity, but to show or tell what is going to happen right now.
2. Make the right path the easiest.
Users almost always follow the path of least resistance. If the simplest path leads to an error, then the product highlighted it itself.
For example, in the service, you can quickly create a resource in two clicks, without unnecessary questions and settings. The recommended scenario requires completing the wizard, selecting parameters, reading the prompts, and making several decisions. As a result, the user chooses the quick option because it looks like the main one.
3. To limit, but carefully.
Total freedom is just as harmful as total prohibition. It is better not to forbid, but to protect. For example, you can enter additional confirmations or warnings about risks.
4. Consider improper use as a signal.
If more than one client goes the wrong way, but many — this is no longer a mistake, it is a signal. It is important not to treat the symptoms here: do not write another item in the FAQ and do not send the user to read the documentation again.
A good product is an environment with clear guidelines. It is difficult to make a mistake by accident, it is easy to choose the recommended path. At the same time, there is still room for conscious deviations when it is really necessary.
Что делать, если сервисом пользуются «неправильно»?
Ходят легенды, что документацию и руководства читают примерно так же часто, как условия лицензионного соглашения. Пользователь просто действует как удобно — а в итоге одни задержки и таймауты.
Важно понимать, что клиент почти никогда не приходит использовать сервис правильно. Он приходит решать свою задачу — быстро, в рамках своих ограничений, бюджета и уровня экспертизы. И если сервис позволяет сделать это «неверным» способом, то это не вина клиента.
Довольно типичная ситуация: пользователь выбирает доступную конфигурацию сервиса, которая не рассчитана на его сценарии нагрузки. Конфигуратор спокойно принимает настройки, не выдает никаких предупреждений. Через какое-то время начинаются проблемы с производительностью. Клиент пишет в поддержку, а в ответ слышит, что для таких нагрузок эту конфигурацию использовать не рекомендуется. Негативная реакция клиента тут понятна: если это плохой вариант, почему он вообще был доступен для выбора?
Еще пример: пользователь включает опцию, не подозревая, что она предназначена для узкого сценария. В интерфейсе она выглядит как обычная галочка без комментариев и ограничений. Позже выясняется, что именно эта настройка стала причиной проблем.
Самое опасное в таких ситуациях — привычка списывать все на «неправильное использование» сервиса клиентом. Она удобная, ведь можно закрыть глаза на проблемы сервиса, но дорогая.
Какие последствия могут быть?
·Поддержка начинает работать в режиме постоянного разруливания нештатных ситуаций;
·Эксплуатация ловит неожиданные сценарии;
·Пользователь чувствует, что его как будто наказывают за попытку разобраться самостоятельно;
·Команда теряет важный сигнал о том, на каком этапе у пользователя возникают проблемы.
«Неправильное использование» не говорит о том, что клиент совершил ошибку или некомпетентен. Для владельцев сервиса - это возможность собрать фидбек.
Как работать с этой обратной связью?
Иногда начинаются метания из крайности в крайность. Например, когда разработчики пытаются спрятать опасные кнопки и закрыть возможности. Однако вместо запретов им стоит подумать над тем, чтобы:
1. Объяснять контекст.
Одна из самых частых продуктовых неприятностей — молчаливые интерфейсы. Кнопка есть, действие доступно, последствий не видно. Гораздо эффективнее не убирать возможность, а показать или рассказать, что именно сейчас произойдет.
2. Сделать правильный путь самым простым.
Пользователи почти всегда идут по пути наименьшего сопротивления. Если самый простой путь ведет к ошибке, значит продукт сам его подсветил.
Например, в сервисе можно быстро создать ресурс в два клика, без лишних вопросов и настроек. А рекомендованный сценарий требует пройти мастер, выбрать параметры, прочитать подсказки и принять несколько решений. В результате пользователь выбирает быстрый вариант, потому что именно он выглядит как основной.
3. Ограничивать, но аккуратно.
Полная свобода так же вредна, как и полный запрет. Лучше не запрещать, а остерегать. Например, вводить дополнительные подтверждения или предупреждения о рисках.
4. Считать неправильное использование сигналом.
Если по ложному пути идет не один клиент, а многие — это уже не ошибка, это сигнал. Здесь важно не лечить симптомы: не писать очередной пункт в FAQ и не отправлять пользователя читать документацию еще раз.
Хороший продукт — среда с понятными ориентирами. В ней сложно ошибиться случайно, легко выбрать рекомендуемый путь. При этом остается пространство для осознанных отклонений, когда это действительно нужно.
Share
