66 Бит
Екатеринбург, Добролюбова 16
info@66bit.ru

Оставить заявку на сотрудничество

Перетащите файлы сюда
*Нажимая кнопку "Отправить заявку", вы соглашаетесь с политикой в области персональных данных
Поиск Очистить

Терпят и уходят: почему пользователи молчат о неудобствах, пока не становится поздно?

Человек открывает сайт интернет-магазина, находит нужный товар и переходит к оформлению заказа: на первом экране система просит ввести адрес, хотя он уже указан в личном кабинете, на втором предлагает выбрать способ доставки из выпадающего списка, в котором пятнадцать пунктов, а подходящий – где-то в середине.

Где-то между третьим и четвертым шагом страница подвисает на пару секунд, и человек машинально постукивает пальцем по столу, ожидая, пока всё загрузится. Он не пишет в поддержку, не оставляет гневный отзыв, а просто завершает заказ, закрывает вкладку и идёт заниматься своими делами.

Примерно та же история разворачивается в офисах, на складах и в колл-центрах, где сотрудники изо дня в день работают с внутренними системами компании. Никто из них не идёт жаловаться, они просто работают чуть медленнее, чуть более уставшими и чуть менее довольными своей работой, чем могли бы.

Со временем такое молчаливое терпение начинает восприниматься как норма. Раз нет жалоб – значит, всё в порядке, продукт хороший и зачем что-то менять. Эта логика выглядит убедительно ровно до того момента, пока не обнаруживается, что часть клиентов ушла к конкуренту, часть сотрудников сменила работу, а те, кто остался, давно обходят систему стороной и делают основную работу где-то за её пределами.

И ведь никто не предупредил заранее: ни скандала, ни волны жалоб, ни тревожного письма от начальника отдела. За этим стоит целый набор психологических механизмов, которые редко учитывают при проектировании цифровых продуктов.

Привыкание, рационализация, нежелание тратить силы на обратную связь – всё это работает против создателей системы, создавая ложное ощущение, что пользователи довольны. А между тем молчание большинства – вовсе не знак качества, а скорее показатель того, что боль ещё не стала острой.

О том, как устроено это молчание, чем оно опасно и как научиться слышать то, о чём не говорят вслух, и пойдёт речь дальше.

Привычки молчаливого большинства

Разработчики и менеджеры продукта живут с уверенностью, что пользователь, столкнувшись с проблемой, даст о себе знать: напишет в поддержку, позвонит, оставит комментарий. Это греет душу, потому что создаёт ощущение контроля: если что-то пойдёт не так, мы тут же узнаем и поправим.

Реальность устроена иначе, и цифры это подтверждают довольно отрезвляюще: по разным исследованиям, лишь один из десяти-пятнадцати недовольных пользователей доносит своё недовольство до компании.

Привыкание

Человеческий мозг устроен экономно: всё, что повторяется регулярно и не несёт прямой угрозы, довольно быстро переводится в разряд фона. Гул кондиционера, дребезжание стекла в автобусе, лишние три клика в интерфейсе – спустя какое-то время всё это перестаёт замечаться. Именно это хоронит огромное количество сигналов о неудобстве.

Сотрудник, который каждый день заходит в учётную систему и в десятый раз вбивает одни и те же реквизиты, через месяц уже не воспринимает это как проблему. Если спросить его в лоб, удобно ли ему, он пожмёт плечами и скажет что-то вроде «нормально, привык».

Для бизнеса такое привыкание обходится дорого: минута здесь, полминуты там, помноженные на количество сотрудников и рабочих дней в году, выливаются в сотни потерянных часов, но поскольку никто не кричит и не возмущается, проблема остаётся невидимой.

Рационализация

Человек, столкнувшись с неудобством, склонен искать ему разумное объяснение, даже если объяснения нет: «Наверное, так надо для безопасности», «Видимо, это требование закона». Гораздо легче предположить, что у неудобства есть веская причина, чем признать, что интерфейс просто плохо продуман.

В корпоративных системах этот эффект усиливается многократно. Сотрудник исходит из того, что программа – результат труда профессионалов, которые наверняка знали, что делали.

Ему не приходит в голову, что какое-то поле появилось три года назад по просьбе одного человека и с тех пор ни разу не пересматривалось. Он заполняет его, потому что так принято, и не задаётся вопросом, зачем оно вообще нужно.

Со временем такие поля и процедуры обрастают легендами: «это для налоговой», «это юридический отдел потребовал», «без этого отчёт не сойдётся». Проверить эти легенды никто не берётся, а разработчики тем временем даже не подозревают, что пользователи на том конце придумали целую мифологию вокруг их решений.

Нежелание ввязываться

Чтобы сообщить о проблеме, нужно совершить усилие, найти нужный канал, сформулировать мысль, потратить время, а потом, возможно, ещё и получить в ответ что-то формальное. Большинство пользователей делает в уме короткий расчёт, и результат этого расчёта почти всегда не в пользу обратной связи.

Внешний пользователь в этой ситуации просто уходит, ему не жалко компанию, он не чувствует ответственности за продукт, он хочет решить свою задачу и пойти дальше. Жалоба требует времени и эмоционального вложения, а человеку это не нужно.

С внутренними пользователями ситуация чуть сложнее: сотрудник компании вроде бы заинтересован в том, чтобы его инструменты работали хорошо, но тут вступает в игру опыт предыдущих взаимодействий. Если он однажды уже попытался сообщить о проблеме и получил в ответ молчание, отписку или обещание, которое не выполнили, второй раз он пробовать не станет.

Ловушка отсутствия жалоб

Метрики показывают низкое количество обращений, опросы не выявляют острых проблем, руководители отделов на планёрках не жалуются. Всё это создаёт картину благополучия, которая может годами не иметь ничего общего с реальным положением дел.

Настоящая проблема в том, что отсутствие жалоб – это показатель того, что порог боли ещё не превышен. Пользователь не кричит, это значит, что неудобство пока укладывается в ту зону, которую он готов терпеть без активных действий.

Но когда пользователь переходит от привыкания к отторжению, вернуть его уже почти невозможно. Именно поэтому так важно уметь слышать то, о чем не говорят.

Синдром бабушкиного серванта

Цифровой продукт редко появляется на свет перегруженным, на старте он довольно стройный и понятный, но дальше начинается жизнь: одни пользователи просят добавить поле, другие – кнопку, третьи – дополнительную проверку перед важным действием.

Эти добавления почти никогда не сопровождаются удалениями: поле, добавленное два года назад по просьбе менеджера, который давно уволился, продолжает висеть на экране. Год за годом продукт обрастает слоями, и каждый слой сам по себе логичен, а всё вместе превращается в то, чем никто не хотел это видеть.

Природа этого накопления – в асимметрии ответственности. Добавить элемент легко, особенно если об этом просят, а вот убрать существующий – целая история. Кто-то может пользоваться, кто-то привык, кто-то возмутится.

Чтобы решиться на удаление, нужны аргументы и внутренняя уверенность, а для добавления достаточно одного письма с пометкой «срочно». Пользователи не пишут «уберите лишнее», потому что не знают, что именно лишнее, не видят продукт целиком.

К тому же у пользователя нет информации о том, как часто другие люди взаимодействуют с тем или иным элементом: если кнопка висит на экране, значит, наверное, кому-то она нужна.

Отдельная история – корпоративные системы, где перегруженность часто связана с устройством самой организации. Одно подразделение отвечает за интерфейс, другое за бизнес-логику, третье за отчётность. Каждое добавляет свой слой, не сильно интересуясь, как это выглядит в сборе.

Молчаливое терпение перегруженного интерфейса не длится вечно. В какой-то момент усталость накапливается до критической отметки. Для внешнего пользователя эта отметка часто выглядит как случайная встреча с конкурентом. Для внутреннего пользователя все начинается с избегания системы.

Руководство замечает проблему поздно: отчёты формируются, заказы обрабатываются, сотрудники сидят на рабочих местах. Только темпы почему-то падают, ошибок становится больше, а новые люди входят в курс дела дольше обычного.

Как услышать молчаливых пользователей?

Если пользователи не говорят о неудобствах напрямую, значит, нужно научиться получать эту информацию обходными путями. Задача не то чтобы сложная, но требует некоторой дисциплины и готовности смотреть на продукт под неудобным углом.

Самый естественный порыв – собрать фокус-группу, разослать опрос, позвать на встречу ключевых пользователей. Иногда это даёт результат, но чаще – довольно скромный:

  • Люди не держат в голове перечень неудобств
  • На прямой вопрос человек склонен отвечать то, что от него ждут, а не то, что думает на самом деле
  • Формулировать претензию – это работа, не каждый готов проделывать её бесплатно и без гарантии, что его услышат
  • Пользователь часто не знает, что можно иначе

Полагаться только на опросы – значит собирать тонкий верхний слой сигналов и пропускать всё, что лежит глубже, поэтому мы собрали несколько методик, благодаря которым вы сможете разговорить молчаливых юзеров.

Наблюдение вместо расспросов

Самый надёжный способ – сесть рядом с реальным пользователем и молча смотреть, как он работает. Не подсказывать, не поправлять, не объяснять, это называется теневым наблюдением, и оно почти всегда приносит открытия, которых не даст ни один опрос:

  • Где человек зависает. В этот момент он не думает о смысле операции, он пытается понять, куда нажать, интерфейс его не ведёт, а ставит в тупик.
  • Где совершает лишние движения. Переключается между вкладками без видимой нужды, копирует данные из одного окна в другое, хотя система могла бы подтянуть их сама.
  • Где ошибается и откатывается назад. Если это случается на одном и том же шаге у разных людей – там почти наверняка проблема с расположением элементов или их названиями.
  • Где использует обходные пути. Открыл Блокнот и записал что-то перед тем, как вбить в форму или переслал данные себе на почту, чтобы не потерять.

Ни один из этих моментов не попадёт в отчёт техподдержки, потому что человек не считает их проблемой в привычном смысле.

Анализ обходных путей

Если пользователь систематически делает что-то не так, как задумано, значит, задуманный путь ему не подходит. Задача не в том, чтобы наказать за обход, а в том, чтобы понять его причину и либо поправить интерфейс, либо легализовать тот способ работы, который люди выбрали сами.

На что обращать внимание:

  • Массовая выгрузка данных во внешние инструменты. Бухгалтерия выгружает отчёты в Excel и обрабатывает там, склад ведёт учёт в Гугл-таблицах параллельно с системой.
  • Внутренние инструкции, созданные сотрудниками. Если в отделе появилась самодельная памятка «как правильно оформлять возврат», значит, штатный сценарий слишком сложен или неочевиден.
  • Устойчивые устные договорённости. «Ты мне просто в чат скинь номер заказа, а я в системе потом отмечу» – если такая фраза звучит регулярно, система не поддерживает реальный процесс.
  • Поля, которые заполняют чем попало. Если в поле «Примечание» пишут «аааа» или ставят прочерк, значит, оно не нужно пользователю, но обязательно для отправки формы.

Собрать такую картину можно за пару недель, просто походив по отделам и поговорив с людьми не о системе, а о том, как они решают свои повседневные задачи. Вопросы тут нужны не оценочные, а описательные: «Покажите, как вы оформляете возврат, когда клиент звонит в пятницу вечером». В ответ вы получите историю, из которой станет видно и где система помогает, и где она путается под ногами.

Разговор о прошлом опыте

История – это естественный формат, в котором люди думают о своём опыте. Мы не храним в голове списки плюсов и минусов, зато легко вспоминаем случай, когда что-то пошло не так:

  • «Вспомните день, когда вы задержались на работе дольше обычного из-за программы. Что именно произошло?»
  • «Если бы вы показывали эту систему новичку, о чём бы предупредили его в первую очередь?»
  • «Что вы делаете в программе каждый день, хотя считаете это пустой тратой времени?»

Тихие сигналы в цифрах

Полезно отслеживать на дистанции в месяц или квартал:

  • Время выполнения типовых операций у опытных сотрудников
  • Частоту возвратов на предыдущий шаг в многошаговых формах
  • Долю незавершённых операций
  • Соотношение действий, совершённых через основной интерфейс и через обходные каналы
  • Частоту нажатия на кнопки, которые должны использоваться редко

Ни один из этих сигналов по отдельности не кричит о проблеме, но собранные вместе за два-три месяца, они довольно точно указывают на места, где пользователь тратит лишние силы.

Как проектировать ПО для бизнеса, чтобы пользователи не молчали?

Разобрать накопившееся – это полдела, гораздо важнее сделать так, чтобы через год не пришлось начинать всё заново.

Регулярная ревизия как гигиена

Проблема в том, что в разработке цифровых продуктов ревизия почти никогда не закладывается в планы, есть дорожная карта, в ней расписаны новые функции, а на расчистку старых завалов времени не предусмотрено. В результате новые функции наслаиваются на старые завалы.

Самый простой способ переломить эту логику – зарезервировать под ревизию небольшую, но постоянную долю ресурсов. Скажем, десять или пятнадцать процентов времени команды на каждом отрезке разработки.

Достаточно держать в бэклоге отдельный список мелких улучшений, которые всплыли из наблюдений, обходных путей и разговоров с пользователями, и методично их закрывать:

  • Поля, которые заполняются редко или никогда
  • Кнопки и пункты меню, которыми не пользуются
  • Предупреждения и окна подтверждения, которые пользователи закрывают не глядя
  • Шаги в сценариях, которые можно объединить
  • Дублирующиеся данные

Важно, чтобы такая ревизия не превращалась в бюрократическую процедуру с комиссией и протоколом, это должна быть рабочая встреча команды, на которой за полчаса просматривают конкретный участок интерфейса и принимают быстрые решения.

Сделать обратную связь дешевой для пользователя

Найти форму обратной связи, сформулировать проблему, возможно, приложить скриншот – всё это требует времени и желания, которого у занятого человека обычно нет. Если снизить эту цену до минимума, поток сигналов вырастает кратно:

  • Кнопка «Сообщить о проблеме» прямо в интерфейсе, в фиксированном месте, без перехода на отдельную страницу.
  • Возможность отправить сообщение без заполнения дополнительных полей – просто текст, всё остальное система подхватит сама: какой экран был открыт, какая версия браузера, какой пользователь.
  • Открытое признание полученной информации. Не обязательно немедленно исправлять всё, о чём сообщают. Достаточно показать, что сигнал принят и передан команде.

Не добавлять без проверки

Большинство элементов, которые со временем превращаются в хлам, попадают в продукт не по злому умыслу, а потому что в моменте добавление казалось оправданным.

Чтобы снизить количество таких случаев, достаточно перед каждым добавлением узнавать какую конкретно проблему решает эта фича и кто именно будет этим пользоваться и как часто.

Защитить команду, которая занимается расчисткой

Работа по расчистке интерфейса – занятие неблагодарное: новые функции видны всем, о них докладывают руководству, их показывают клиентам, а то, что форма оформления заказа стала на один шаг короче, заметят немногие.

Более того, любое удаление сопряжено с риском: всегда найдётся кто-то, кто пользовался удалённой кнопкой, и он будет недоволен, поэтому команды, которые занимаются улучшением существующего, а не добавлением нового, часто оказываются в тени и первыми попадают под сокращение при пересмотре бюджета.

Чтобы этого не происходило, полезно закрепить несколько вещей на уровне процессов:

  • Улучшения существующего интерфейса должны иметь такой же статус, как и новые функции. Они попадают в дорожную карту, по ним отчитываются, их результаты замеряют.
  • У каждой расчистки должна быть измеряемая цель. Не просто «убрали три поля», а «сократили среднее время оформления заказа на двадцать секунд» или «снизили долю брошенных корзин на полтора процента». В цифрах ценность такой работы становится видна даже тем, кто далёк от интерфейсных тонкостей.
  • Руководство должно понимать, что отсутствие жалоб после удаления – это хороший знак, а не повод для беспокойства. Если убрали поле и никто не заметил, значит, оно действительно было лишним.

Разработка ПО от 66 Бит

Всего за 10 минут вы узнали как вытянуть из молчаливых пользователей все секретики. А если хотите делегировать аудит системы и мнения юзеров профессионалам, советуем обратиться в 66 Бит!

Наши опытные специалисты не только разговорят клиентов и сотрудников, но применят эту информацию и спроектируют систему, которая кратно повысит продажи и производительность бизнеса. Подробнее о нас читайте на сайте по ссылке!

Поделиться в соцсетях:

Столкновение мнений: как разработать эффективное ПО для бизнеса, когда отделы выдвигают спорные требования?