Когда в работе программы происходит что-то нештатное, реакция пользователя непредсказуема. Можно потратить месяцы на шлифовку каждой мелочи, а потом обнаружить, что люди спокойно переживают короткий перебой, но приходят в ярость от пустяковой опечатки в уведомлении.
А бывает наоборот: готовишься к шквалу жалоб после обновления, а пользователи будто и не заметили временных неудобств. Такая непоследовательность способна поставить в тупик любого руководителя.
Особенно остро это противоречие чувствуется, когда запускается заказная разработка: все участники процесса – со стороны заказчика и со стороны команды – обычно сосредоточены на том, чтобы «всё работало без ошибок», и это правильное стремление.
Однако оно порождает избыточное напряжение вокруг неизбежных мелочей, которые на практике не только не разрушают доверие к системе, но иногда даже работают на её пользу – при условии, что они обработаны осмысленно.
В деловых обсуждениях редко всплывает один любопытный парадокс: на мелкие сбои программ люди реагируют гораздо мягче, чем на сопоставимые по масштабу промахи живых сотрудников. Если менеджер перепутает дату в письме, это вызовет сомнения в его компетентности, и осадок останется надолго, а если система не с первого раза загрузила страницу, пользователь скорее пожмёт плечами, обновит её и через минуту забудет о случившемся.
Та же самая минута задержки по вине человека воспринимается как неуважение, а по вине бездушного сервера – как досадная, но простительная случайность.
Это не означает, что можно расслабиться и перестать заботиться о качестве. Скорее наоборот: понимание этого механизма позволяет направить усилия туда, где они действительно критичны, и перестать тратить ресурсы на погоню за недостижимым совершенством в областях, где пользователь заранее готов к небольшим шероховатостям.
Более того, грамотно выстроенная реакция системы на сбой иногда укрепляет доверие к ней сильнее, чем безупречная, но безликая работа в штатном режиме.
Почему так происходит и как вы можете использовать эту особенность восприятия при запуске собственных цифровых продуктов, мы и расскажем в сегодняшней статье.
Разница в принятии человеческих и программных ошибок
Страх из разряда «Сейчас что-то пойдёт не так, и пользователи будут крайне недовольны» – совершенно естественный, и нельзя сказать, что он берётся с потолка. Но если присмотреться к реальному опыту запусков, картина вырисовывается куда более обнадёживающая.
Давайте возьмём две рабочие ситуации и положим их рядом. Первая: менеджер колл-центра второпях внёс в отчёт не те цифры, и ошибка обнаружилась прямо на планёрке. Вторая: автоматическая выгрузка того же самого отчёта один раз дала сбой при обновлении страницы, но после перезагрузки всё встало на свои места.
Если оценивать фактические последствия, вторая история зачастую ещё и безобиднее – многие пользователи её попросту не заметили, но нас интересует не сухой ущерб, а человеческая реакция. Ошибка менеджера почти гарантированно породит волну обсуждений о невнимательности, безответственности и сомнительных навыках.
А однократный сбой системы – при условии, что он не затронул деньги и не уничтожил важные данные, – списывается на «ой, зависло, бывает» и благополучно забывается через час. Чувствуете разницу?
Весь секрет в том, как наш мозг назначает виноватых. Когда ошибается человек, мы моментально связываем это с его личными качествами: не постарался, поленился, отнёсся спустя рукава. А когда сбой выдаёт программа, мы не ищем там злого умысла или слабого характера – техника, что с неё взять. Это не рациональный выбор в духе «давайте проявим к машине снисхождение», а мгновенная реакция, которая срабатывает быстрее, чем мы успеваем её осмыслить.
И вот какой из этого напрашивается практический вывод, особенно для тех, кто принимает работу у команды разработки: бояться каждого мелкого недочёта до дрожи в коленях не нужно – пользователь на той стороне экрана не такой уж суровый, каким его рисует воображение перед запуском. Он готов простить системе то, за что живого сотрудника обсуждали бы на нескольких совещаниях подряд.
Настоящие проблемы начинаются не тогда, когда случается сам сбой, а когда система в ответ делает вид, что ничего не произошло, оставляет человека в растерянности или выдаёт бессмысленные сообщения об ошибках. Поэтому при подготовке к запуску разумнее не вылизывать до блеска каждую второстепенную деталь, а потратить силы на действительно важную вещь: что увидит пользователь, когда что-то пойдёт не по плану, и поймёт ли он из этого сообщения, куда ему нажать дальше.
Причины явления: 3 фактора восприятия
Почему на сбой программы мы реагируем спокойнее, чем на промах сотрудника, даже если последствия одинаковы? Здесь работают три любопытных механизма.
Фактор первый: приписывание намерения
Когда ошибается живой человек, мы почти автоматически дорисовываем в голове его мотивы. Не перезвонил вовремя – значит, не посчитал важным. Перепутал цифры в отчёте – значит, отнёсся халатно.
Наш мозг устроен так, что он ищет за каждым действием чью-то волю и чьё-то отношение. И чаще всего эта воля трактуется не в пользу исполнителя: нам кажется, что человек мог постараться, но не захотел, мог перепроверить, но поленился.
С программой такого не происходит: ей никто не приписывает личного отношения к делу, никто не подозревает её в том, что она «не уважает пользователя» или «работает спустя рукава». Она просто сработала или не сработала – без второго дна. Пользователь не чувствует себя лично задетым, а значит, и злость не включается.
Фактор второй: ожидание гибкости
От человека мы по умолчанию ждём большего: предполагается, что сотрудник способен оценить контекст, проявить смекалку, найти обходной путь, вовремя заметить собственную оплошность и исправить её до того, как кто-то пострадает. Когда этого не происходит, мы разочаровываемся – причём разочаровываемся именно потому, что ожидали лучшего.
С программой история обратная: от неё ждут не гибкости, а стабильного следования правилам. Когда система ведёт себя нестандартно, пользователь сначала удивляется, а не раздражается. Удивление – эмоция короткая и редко переходящая в гнев, если только сбой не повторяется раз за разом.
Более того, кратковременное отклонение от нормы иногда даже вызывает что-то вроде исследовательского интереса: «Хм, странно, а если вот так нажать – заработает?» Это совершенно иная точка старта для пользовательской реакции, и она даёт гораздо больше пространства для манёвра.
Фактор третий: возвращение контроля
Когда ошибается сотрудник, пострадавшая сторона чаще всего вынуждена просто ждать: пока он сам заметит, пока исправит, пока переделает. В этот момент пользователь или клиент чувствует себя полностью беспомощным, а беспомощность – отличное топливо для раздражения.
С программой всё иначе: в большинстве случаев пользователь может немедленно предпринять какое-то действие: обновить страницу, нажать кнопку ещё раз, выйти и зайти обратно. Действие само по себе может быть простейшим, но оно возвращает человеку ощущение управления ситуацией.
Когда пользователь сам «починил» проблему двумя нажатиями, он часто чувствует даже лёгкое удовлетворение – вместо того чтобы копить негатив. Именно поэтому так важно давать людям понятные рычаги воздействия в момент сбоя: это не просто вопрос удобства, это вопрос сохранения лояльности.
Все три фактора действуют не по отдельности, а одновременно, усиливая друг друга. Программе не приписывают злой воли, от неё не ждут чудес сообразительности, и она хотя бы не отнимает у человека последний островок контроля.
В сухом остатке получается картина, которую полезно держать в голове каждому руководителю: случайный единичный сбой не делает систему врагом в глазах пользователя, врагом её делает растерянность, в которую она погружает человека, когда не может внятно объяснить, что случилось и что делать дальше.
Терпение не вечно: когда пользователь перестает прощать?
До этого момента мы говорили о том, что программы в глазах пользователей обладают «форой» по сравнению с живыми сотрудниками, но есть чёткие границы, за которыми терпение заканчивается мгновенно и безоговорочно. И заказчику, который принимает работу у команды разработки, важно знать эти границы не хуже, чем сильные стороны своего будущего продукта.
Критический ущерб
Первая и самая очевидная граница проходит там, где ошибка перестаёт быть мелкой неприятностью. Когда сбой затрагивает деньги клиента, персональные данные, безопасность или физическое оборудование – никакого снисхождения не будет. В таких случаях его и не должно быть, но интересно другое: пользователь, который только что потерял деньги из-за программной ошибки, будет зол ровно так же, как если бы эти деньги потерял из-за ошибки живого кассира.
Более того, возможно, даже сильнее – потому что кассиру можно посмотреть в глаза и потребовать объяснений, а безликий интерфейс просто выдаёт сообщение и замирает. Так что принцип «систему судят мягче» работает исключительно на территории некритичных неудобств. Как только на кону оказывается что-то по-настоящему важное – счёт идёт на равных, а то и против системы. Поэтому при приёмке важно определить зоны, где цена ошибки неприемлема.
Повторяемость
Однократный сбой списывается на случайность и забывается, то же самое, но случившееся второй раз за короткий промежуток, уже вызывает настороженность. Третий раз – и перед нами не досадное недоразумение, а свойство системы, её неотъемлемая черта.
Пользователь перестаёт думать «бывает» и начинает думать «она всегда так». А дальше вступает в силу уже совсем другой механизм: накопленное раздражение. Оно работает без скидок – и против людей, и против программ.
Хуже того, когда сбой становится ожидаемым, пользователь начинает искать обходные пути, теряет доверие к данным и в целом перестаёт считать систему надёжным инструментом, поэтому при запуске стоит с особым вниманием отнестись к тем ошибкам, которые имеют свойство повторяться при определённых условиях. Лучше один раз потратить время на поиск причины, чем получить репутацию «вечно глючащей штуки».
Отсутствие обратной связи
Представьте: пользователь совершает действие, а в ответ – тишина. Кнопка нажалась, но ничего не произошло, форма отправилась, но неизвестно, ушла она или нет, данные вроде сохранились, но где их теперь искать – непонятно.
В такие моменты человек оказывается в информационном вакууме, и это ощущение гораздо хуже, чем прямая ошибка. Прямая ошибка – это хотя бы определённость, а молчание системы – это тревога, помноженная на неизвестность.
Пользователь начинает гадать: это сбой или я что-то сделал не так? Надо подождать или начинать заново? Мои данные потерялись или просто не показываются? И главное – сколько это будет продолжаться? Именно в такие моменты рождается самое едкое раздражение, которое потом выливается в звонки в поддержку, жалобы и общее неприятие системы.
Вывод здесь простой и жёсткий: при приёмке проверяйте не только то, как система работает в идеальных условиях, но и то, как она сообщает пользователю о проблемах. Если сообщает хоть как-то – уже хорошо, если сообщает понятно и с указанием дальнейших шагов – отлично. Если молчит – это повод для серьёзного разговора с командой разработки.
Все три границы объединяет одна общая черта: они превращают случайный сбой из внешнего обстоятельства в личную проблему пользователя, а личные проблемы никто не склонен прощать – ни людям, ни программам. Именно поэтому разумный подход к запуску выглядит не как «сделайте всё идеально», а как «убедитесь, что в критичных местах нет ошибок, а в остальных – нет молчания».
Как применять это на практике?
Разделите зоны нетерпимости и зоны допустимой неидеальности
Самое непродуктивное, что можно сделать на старте – это объявить, что «всё должно работать идеально». Во-первых, так не бывает, а во-вторых, такая установка распыляет силы команды равномерным слоем, и в результате критически важные участки могут недополучить внимания, пока разработчики доводят до блеска что-то второстепенное.
Гораздо практичнее сесть и вместе с командой нарисовать простую карту: где цена ошибки высока, а где пользователь переживёт небольшую шероховатость без последствий для бизнеса.
Платёжный шлюз, авторизация, работа с персональными данными – здесь требования жёсткие, и это не обсуждается.
А вот, скажем, фильтр в каталоге товаров или подсказка в строке поиска – здесь единичный сбой не обрушит репутацию, если он обработан по-человечески. Такое разделение не снижает планку качества, а наоборот — фокусирует усилия там, где они действительно окупаются.
Проектируйте сообщения о сбоях как самостоятельную часть продукта
Часто встречающаяся картина: весь дизайн интерфейса проработан до мелочей, а сообщения об ошибках выглядят так, будто их набросали за пять минут до запуска. «Ошибка 403», «Сбой соединения», «Некорректный запрос» – пользователь видит это и оказывается в тупике.
Он не знает, серьёзно ли это, надо ли звонить в поддержку или просто подождать, а ведь именно в момент сбоя человек наиболее уязвим и наиболее внимателен к тому, что говорит ему система. Поэтому тексты, которые появляются при нештатных ситуациях, стоит прорабатывать не менее тщательно, чем основные экраны.
Хорошее сообщение о сбое делает три вещи: спокойно признаёт, что что-то пошло не так, объясняет, что происходит прямо сейчас, и предлагает простое действие.
Не «Системная ошибка», а «Данные временно не загрузились, обычно это проходит за минуту. Нажмите "Обновить" или вернитесь чуть позже». Разница в восприятии колоссальная: из растерянного и раздражённого пользователь превращается в спокойно ожидающего.
Дайте пользователю рычаг немедленного действия
Этот пункт вытекает из предыдущего, но заслуживает отдельного внимания. Когда что-то идёт не так, человеку жизненно важно что-то сделать – хоть что-нибудь. Простое нажатие кнопки «повторить попытку» даёт ощущение контроля над ситуацией, а это ощущение, как мы помним из второго блока, резко снижает градус недовольства.
Поэтому при приёмке продукта обратите внимание на каждое место, где возможен сбой, и проверьте, есть ли рядом с ним кнопка повторного действия. Если её нет – это повод задать вопрос разработчикам.
И ещё один важный момент: возможность отмены последнего шага без потери уже введённых данных. Нет ничего более бесящего, чем после сбоя обнаружить, что всё заполненное поле пропало и надо начинать сначала. Сохранение черновика – не роскошь, а базовая гигиена взаимодействия с пользователем.
Исключите «тихие» сбои
Есть ошибки заметные, а есть те, которые система проглатывает молча. Пользователь нажал «отправить», форма вроде ушла, а на самом деле данные не сохранились. Или отчёт вроде сформировался, но в нём пропущена половина строк, потому что где-то внутри что-то отвалилось, не подав признаков жизни.
Человек узнаёт о проблеме постфактум, часто от клиентов или коллег, и выглядит при этом глупо. Поэтому на этапе приёмки стоит отдельно протестировать сценарии, где что-то идёт не по плану, и проверить, как система сообщает об этом пользователю.
Увидит ли он предупреждение? Будет ли оно достаточно заметным? Сможет ли он из этого предупреждения понять, что делать дальше? Если ответ хотя бы на один из этих вопросов – «нет», до запуска продукта остаётся недоделанная работа, и лучше закрыть её сейчас, чем разбираться с последствиями потом.
Используйте период пробного запуска
Один из самых недорогих и эффективных способов снизить напряжение вокруг неизбежных шероховатостей – честно назвать вещи своими именами. Если вы запускаете систему в режиме опытной эксплуатации или открытого тестирования, так и скажите пользователям.
Фраза «мы запускаем пробную версию и будем благодарны за сообщения о любых недочётах» творит чудеса. Она заранее настраивает людей на то, что идеальной работы ждать пока не стоит, и переводит возможные накладки из категории «провал» в категорию «ожидаемое».
Более того, пользователи, которых пригласили поучаствовать в обкатке, часто становятся самыми лояльными и конструктивными – они чувствуют себя не жертвами сырого продукта, а соавторами будущей стабильной версии. И это совершенно иная тональность общения, которая окупает себя многократно.
Все пять рекомендаций сводятся, по сути, к одному простому принципу: не пытайтесь сделать систему, которая никогда не ломается. Сделайте систему, которая умеет ломаться перед пользователем – с уважением к его времени, с понятными подсказками и с честностью о происходящем. Это не компромисс с качеством, а зрелый подход к реальности, в которой техника иногда даёт сбой, а люди ценят определённость больше, чем иллюзорное совершенство.
Разработка ПО от 66 Бит
Вот вы и добрались до конца, а арсенал психологических трюков пополнился значительно! Теперь можно смело внедрять полученные советы в процессы разработки собственного ПО для бизнеса, а если его пока нет, советуем обратиться за помощью к 66 Бит.
Наши опытные специалисты проведут глубокий аудит ваших бизнес-процессов и требований и разработают эффективную систему, способную в разы увеличить производительность вашего дела. Читайте подробнее о нас по ссылке!