В бизнесе есть не так уж и много вещей, которые могут быть хуже чем бухгалтер, мнением которого пренебрегли. И это злой бухгалтер, который расстроен тем, что потратил около 20 минут на поиск чего-то настолько простого и очевидного, что должно было быть на своем месте, но отсутствовало.
И этот бухгалтер искал не что иное, как способ вставки двойного подчеркивания.
Статьи доходов и расходов, расположенные в виде столбца, обычно разделяют простым подчеркиванием, а общий итог, который находится ниже, отделяют двойным подчеркиванием. Практика обозначения общего итога двойным подчеркиванием берет начало задолго до эпохи компьютеров и таблиц. Взглянув на регистры индустриальной эпохи, вы увидите двойное подчеркивание, висящее прямо над пресловутой статьей «Итого».
Это и искал наш бухгалтер, аккуратно расписавший как раздел доходов, так и следовавший за ним раздел расходов. Результат формулы по расчету разницы доходов и расходов показывал небольшую строку дохода, которая всем своим видом вопрошала о двойном подчеркивании. Тем не менее, в Google Spreadsheet, который представлял собой аналог таблиц Microsoft Excel, Lotus 1-2-3 и их предшественников, данной возможности обнаружено не было. По непонятной причине разработчики Google Spreadsheet не включили в функционал двойное подчеркивание или просто оставили эту опцию скрытой.
Бухгалтер же не мог представить себе, что разрабатывая продукт, они могли забыть о такой простой вещи, которую он искал. Искал. И еще раз искал. Безрезультатно. Её просто там не было. Разработчики её упустили.
Двойное подчеркивание реализовать не сложно, и возможно они думали о поддержании чистоты интерфейса, опуская реализацию этой функции.
Смерть от тысячи порезов
Так или иначе, ожидания наличия двойного подчеркивания присутствовало, и время на его поиск было потрачено. Эта простая вещь очень расстроила бухгалтера, и она сказала нам, что ей не нравится пользоваться приложением.
Был и другой функционал, который она пыталась найти. Поиск каждого из элементов занял определенное время и отвлекал её от завершения простого отчета о прибылях и убытках, который она уже миллион раз делала, работая бухгалтером.
Разработанный продукт умирал смертью от тысячи порезов, ибо даже с учетом того, что ни одна из отсутствующих возможностей не была критичной, в своем множестве они делали его менее привлекательным для работы. Это и есть проблема «упущенных ожиданий».
Упущенные ожидания и неоправданные ожидания
В парикмахерской, которую мы недавно посетили, секретарь, занимающийся записью клиентов, выглядел довольно подавленным. Когда заходили клиенты, она бросала взгляд на экран со списком записей на день, хмурилась и продолжала общение с клиентом, спрашивая его имя и вид процедуры/услуги, на которую они записаны.
За несколько дней до этого на сервере, который использовался салоном для хранения информации о записях на прием клиентов, полетел жесткий диск. И даже если у них и были бэкапы, никто в компании не знал как восстановить информацию, которая в результате была полностью потеряна. Клиент приходил в салон, но записей о нем не было. Ребята пытались все воссоздать, но этот процесс был довольно удручающим.
Опустить двойное подчеркивание в Google Spreadsheet – это значит не заметить ожидания людей. Потерять данные – значит не оправдать уже замеченные вами ожидания. Пользователи и клиенты не обращают внимание на разницу, но команды разработчиков должны это делать, ибо такие ожидания нужно искать в разных местах.
Ожидания, с которыми мы работаем можно легко оценить путем тщательного анализа своего дизайна. Мы можем посмотреть на каждый функциональный компонент и задать вопрос: «Насколько наших пользователей огорчит или удивит отказ вот этого компонента?». Даже если мы и допустим такую возможность, рано или поздно мы узнаем об отказе и сделаем все от нас зависящее для того, чтобы не допустить это впредь.
Ожидания, которые мы не учли, более коварны, ибо их довольно сложно заметить и интроспекция тут уже не поможет. В этом случае на помощь приходят фундаментальные исследования пользовательской аудитории.
Не ждите чуда от опросов и юзабилити-тестирования
Действительно, это одни из первых методов, использующихся нами, но они не так уж и полезны в поиске «упущенных ожиданий» пользователей.
Например, представьте, что я строю новый отель и спрашиваю вас о том, каким вы видите идеальный номер. Довольно сложно ожидать того, что вы скажете об «исправно функционирующей ванной», ибо вы понимаете, что это уже подразумевается. Готов поспорить, вы удивитесь, если в том номере, куда вы поселитесь, ванной не будет вообще.
Наблюдение за работой пользователей с уже реализованным дизайном (известное как юзабилити-тестирование) не всегда позволяет обнаружить такие ожидания. Будучи уверенными в обратном, мы очень часто сами сбиваем себя с толку тем, как мы готовим и подаем задания респондентам.
Очень часто мы идем от тех результатов, которые хотим получить изначально, желая упростить задачи и полностью контролировать весь процесс. Например, тестируя Google Spreadsheet, мы может и получим замечание о необходимости ввода двойного подчеркивания. Для того, чтобы дать понять о желаемом результате, мы вполне можем и показать, как выглядит итоговая отчетность. И так как мы изначально не подумали о двойном подчеркивании, в нашем итоговом отчете его не будет. Участники нашего исследования, желая соответствовать нашим требованиям, скорее всего не скажут о двойном подчеркивании. В результате тестирования будет отражено только наше предубеждение, и мы упустим имеющиеся у людей ожидания.
Получая пользу от каждого контакта с клиентом
Одним из довольно неплохих каналов поступления информации об упущенных нами ожиданиях являются обращения (звонки, письма и т.д) клиентов в службу поддержки. Огорченные отрицательным результатом своего поиска, они могут регулярно говорить вам о своих ожиданиях от продукта, с которым работают.
Мы знаем, что большинство организаций не слишком заботятся о сборе такой информации, ибо эти недостатки очень сложно или невозможно исправить, а значит структурировать и собрать. Количество поступивших обращений по той или иной теме – это максимум, что мы имеем в большинстве организаций на сегодняшний день. И без поиска ответов и природы этих обращений их положительное разрешение является довольно маловероятным.
Обновление механизмов сбора и категоризации таких обращений в системе службы поддержки может улучшить ваше понимание тех ожиданий пользователей, о которых вы еще не знаете. И как раз это и поможет правильно подойти к последующим исследованиям.
Поднимите уровень ваших этнографических исследований
Вооруженные списком потенциальных «упущенных ожиданий», который вы получили в результате соответствующего сбора информации в отделе поддержки, команды разработчиков и исследователей могут приступить к изучению того, как эти ожидания себя проявляют. Тут мы уже можем начать говорить о том, как действительно улучшить существующий дизайн продукта.
Смотреть на все глазами клиента довольно сложно. Это как проснуться глубокой ночью и включить свет в ванной – слишком ярко, чтобы что-то различить, пока ваши глаза не приспособятся. Поток контекстуальной информации, поступающий от клиента, может показаться чрезмерным и не конкретизированным тем, кто является новичком в этом деле, делая довольно проблематичным какие-либо выводы.
Но с каждым новым интервью с клиентом вы начнете замечать все более явные признаки того, что вы что-то упустили и не учли ряд ожиданий. В каждом отдельном случае такие ожидания будут проявляться по-разному, но общие признаки будут совпадать.
Регулярные этнографические исследования – это критически важный инструмент команд, которые хотели бы привнести в разрабатываемый ими продукт как можно более полное соответствие ожиданиям клиентов. Инвестиции, вкладываемые в данную работу, довольно легко оправдать тем, что на выходе вы получите сниженные расходы на поддержку, большую вовлеченность пользователей и фундаментальную дифференциацию на ряду с конкурентами, которые вообще не занимались этой проблемой.
Продвинутые техники лабораторных исследований: юзабилити-тестирование на основе интервью
Разобравшись с тем, что в действительности происходит при работе пользователей с продуктом, команда может воссоздать похожую среду в лабораторных условиях. И производя юзабилити-тестирования на основе интервью, получить «упущенные ожидания» путем более детальной симуляции того, как пользователи работают с продуктом, понимая что и как, они хотели бы сделать.
Вместо того, чтобы рассказать об определенной последовательности задач, которые должен выполнить каждый из респондентов или участников тестирования, модератор начинает с их интервьюирования. Задаются вопросы о том, как они выполняли задачи, поддерживаемые существующим дизайном продукта, ранее. И задачей модератора является приобретение как можно более глубокого понимания природы и результатов данных задач.
Дальнейшую работу с респондентом модератор строит на основе полученной информации о прошлом опыте, пытаясь его воссоздать в текущем исполнении дизайна.
И именно в процессе воссоздания такого опыта и проявляются «упущенные ожидания» за счет того, что пользователи погружаются в уже привычную среду и с легкостью могут подчеркнуть отсутствие какой-либо необходимой функциональной возможности или её неудобную реализацию.
Все это требует более серьезного подхода чем просто проведение юзабилити-тестирования. Многие из тех, кто их практикует, не всегда готовы к импровизации с задачами и зачастую стремятся привести респондента к ответам, уже реализованным командой разработчиков.
И хорошая комбинация этнографических исследований и продвинутых лабораторных техник (юзабилити-тестирование на основе интервью) позволяет добиться более полного представления об ожиданиях клиента. Даже те ожидания, которые на первый взгляд казались незначительными, но в конце концов приводят к «смерти от тысячи порезов», могут быть обнаружены и интегрированы в дизайн.
Автор: dmitrykabanov
