Ходят легенды, что документацию и руководства читают примерно так же часто, как условия лицензионного соглашения. Пользователь просто действует как удобно — а в итоге одни задержки и таймауты.
Важно понимать, что клиент почти никогда не приходит использовать сервис правильно. Он приходит решать свою задачу — быстро, в рамках своих ограничений, бюджета и уровня экспертизы. И если сервис позволяет сделать это «неверным» способом, то это не вина клиента.
Довольно типичная ситуация: пользователь выбирает доступную конфигурацию сервиса, которая не рассчитана на его сценарии нагрузки. Конфигуратор спокойно принимает настройки, не выдает никаких предупреждений. Через какое-то время начинаются проблемы с производительностью. Клиент пишет в поддержку, а в ответ слышит, что для таких нагрузок эту конфигурацию использовать не рекомендуется. Негативная реакция клиента тут понятна: если это плохой вариант, почему он вообще был доступен для выбора?
Еще пример: пользователь включает опцию, не подозревая, что она предназначена для узкого сценария. В интерфейсе она выглядит как обычная галочка без комментариев и ограничений. Позже выясняется, что именно эта настройка стала причиной проблем.
Самое опасное в таких ситуациях — привычка списывать все на «неправильное использование» сервиса клиентом. Она удобная, ведь можно закрыть глаза на проблемы сервиса, но дорогая.
Какие последствия могут быть?
·Поддержка начинает работать в режиме постоянного разруливания нештатных ситуаций;
·Эксплуатация ловит неожиданные сценарии;
·Пользователь чувствует, что его как будто наказывают за попытку разобраться самостоятельно;
·Команда теряет важный сигнал о том, на каком этапе у пользователя возникают проблемы.
«Неправильное использование» не говорит о том, что клиент совершил ошибку или некомпетентен. Для владельцев сервиса - это возможность собрать фидбек.
Как работать с этой обратной связью?
Иногда начинаются метания из крайности в крайность. Например, когда разработчики пытаются спрятать опасные кнопки и закрыть возможности. Однако вместо запретов им стоит подумать над тем, чтобы:
1. Объяснять контекст.
Одна из самых частых продуктовых неприятностей — молчаливые интерфейсы. Кнопка есть, действие доступно, последствий не видно. Гораздо эффективнее не убирать возможность, а показать или рассказать, что именно сейчас произойдет.
2. Сделать правильный путь самым простым.
Пользователи почти всегда идут по пути наименьшего сопротивления. Если самый простой путь ведет к ошибке, значит продукт сам его подсветил.
Например, в сервисе можно быстро создать ресурс в два клика, без лишних вопросов и настроек. А рекомендованный сценарий требует пройти мастер, выбрать параметры, прочитать подсказки и принять несколько решений. В результате пользователь выбирает быстрый вариант, потому что именно он выглядит как основной.
3. Ограничивать, но аккуратно.
Полная свобода так же вредна, как и полный запрет. Лучше не запрещать, а остерегать. Например, вводить дополнительные подтверждения или предупреждения о рисках.
4. Считать неправильное использование сигналом.
Если по ложному пути идет не один клиент, а многие — это уже не ошибка, это сигнал. Здесь важно не лечить симптомы: не писать очередной пункт в FAQ и не отправлять пользователя читать документацию еще раз.
Хороший продукт — среда с понятными ориентирами. В ней сложно ошибиться случайно, легко выбрать рекомендуемый путь. При этом остается пространство для осознанных отклонений, когда это действительно нужно.
* Изображение создано с использованием ИИ (искусственного интеллекта).
Важно понимать, что клиент почти никогда не приходит использовать сервис правильно. Он приходит решать свою задачу — быстро, в рамках своих ограничений, бюджета и уровня экспертизы. И если сервис позволяет сделать это «неверным» способом, то это не вина клиента.
Довольно типичная ситуация: пользователь выбирает доступную конфигурацию сервиса, которая не рассчитана на его сценарии нагрузки. Конфигуратор спокойно принимает настройки, не выдает никаких предупреждений. Через какое-то время начинаются проблемы с производительностью. Клиент пишет в поддержку, а в ответ слышит, что для таких нагрузок эту конфигурацию использовать не рекомендуется. Негативная реакция клиента тут понятна: если это плохой вариант, почему он вообще был доступен для выбора?
Еще пример: пользователь включает опцию, не подозревая, что она предназначена для узкого сценария. В интерфейсе она выглядит как обычная галочка без комментариев и ограничений. Позже выясняется, что именно эта настройка стала причиной проблем.
Самое опасное в таких ситуациях — привычка списывать все на «неправильное использование» сервиса клиентом. Она удобная, ведь можно закрыть глаза на проблемы сервиса, но дорогая.
Какие последствия могут быть?
·Поддержка начинает работать в режиме постоянного разруливания нештатных ситуаций;
·Эксплуатация ловит неожиданные сценарии;
·Пользователь чувствует, что его как будто наказывают за попытку разобраться самостоятельно;
·Команда теряет важный сигнал о том, на каком этапе у пользователя возникают проблемы.
«Неправильное использование» не говорит о том, что клиент совершил ошибку или некомпетентен. Для владельцев сервиса - это возможность собрать фидбек.
Как работать с этой обратной связью?
Иногда начинаются метания из крайности в крайность. Например, когда разработчики пытаются спрятать опасные кнопки и закрыть возможности. Однако вместо запретов им стоит подумать над тем, чтобы:
1. Объяснять контекст.
Одна из самых частых продуктовых неприятностей — молчаливые интерфейсы. Кнопка есть, действие доступно, последствий не видно. Гораздо эффективнее не убирать возможность, а показать или рассказать, что именно сейчас произойдет.
2. Сделать правильный путь самым простым.
Пользователи почти всегда идут по пути наименьшего сопротивления. Если самый простой путь ведет к ошибке, значит продукт сам его подсветил.
Например, в сервисе можно быстро создать ресурс в два клика, без лишних вопросов и настроек. А рекомендованный сценарий требует пройти мастер, выбрать параметры, прочитать подсказки и принять несколько решений. В результате пользователь выбирает быстрый вариант, потому что именно он выглядит как основной.
3. Ограничивать, но аккуратно.
Полная свобода так же вредна, как и полный запрет. Лучше не запрещать, а остерегать. Например, вводить дополнительные подтверждения или предупреждения о рисках.
4. Считать неправильное использование сигналом.
Если по ложному пути идет не один клиент, а многие — это уже не ошибка, это сигнал. Здесь важно не лечить симптомы: не писать очередной пункт в FAQ и не отправлять пользователя читать документацию еще раз.
Хороший продукт — среда с понятными ориентирами. В ней сложно ошибиться случайно, легко выбрать рекомендуемый путь. При этом остается пространство для осознанных отклонений, когда это действительно нужно.
* Изображение создано с использованием ИИ (искусственного интеллекта).