Когда отличные продуктовые команды создают проблемы в UX: 4 шага для сокращения разрыва между командами
Ссылка на оригинал статьи: https://uxdesign.cc/when-great-product-teams-ship-broken-ux-4-steps-to-mind-the-gap-bfdf6f150f8b
Почему даже богатые компании, обладающие достаточными ресурсами, часто создают UX, вызывающий проблемы? От этого никто не застрахован. Даже звезды дизайна могут оказаться в такой ситуации. Дело в том, что пользователи сталкиваются с результатами работы многих продуктовых команд, когда последовательно осваивают продукт: узнают о нем, изучают, устанавливают, проходят регистрацию, а потом переходят к использованию. А несыгранность различных команд в большой компании — это обычное дело. У каждого из нас есть свои боевые истории. Несколько сайтов и приложений, за которыми пристально следят, работают гладко и имеют высокий траффик. Но рядом с ними есть множество других продуктов, как будто созданных для того, чтобы постоянно испытывать терпение пользователя и его способность ясно мыслить.
Эта статья посвящена тому, как полностью развернуть в сторону пользовательского опыта (UX) даже большую структуру, используя методику Jobs To be Done (Работа, которая должна быть сделана, далее JTBD), User Journey Mapping (Картирование пользовательского опыта, далее UJM), оценочные шкалы, сводные дашборды и презентации для руководства. Этот подход легко воспроизвести, и он будет работать в любой организации.
Свою работу в IBM Cloud в 2014 я начал с того, что отправил талантливых исследователей пользовательского опыта, таких как Дениел Хатчерсон (Daniel Hutcherson (“Hutch”)) в поля, чтобы наблюдать за деятельностью разработчиков и системных администраторов. Мы провели большое этнографическое исследование и создали целый набор артефактов. Наиболее познавательный среди них — User Journey Map, который отражает последовательные шаги пользователя на пути к цели.
😐, 🙂, или😦
Существует много вариантов карт опыта, которые красиво проиллюстрированы и описаны в книге Джима Калбаха (Jim Kalbach) Mapping Experience. Мы же намеренно оставили нашу карту очень простой, чтобы люди не закапывались в ее рассматривании.
Мы использовали линейный график с тремя позициями на шкале, суммирующий настроение пользователей на каждом шаге: нейтральное, позитивное или негативное настроение.
Вот пример самой первой версии этого артефакта:
Самый первый набросок карты обычно бывает спорным. Откуда мы знаем, что правильно понимаем реальную цель пользователя? На чем строится уверенность, что пользователь на самом деле совершает эти шаги? Можем ли мы подтвердить, что адекватно оцениваем каждый шаг? Мы продолжили совершенствовать карту, подкрепляя ее артефактами и доказательствами.
Со временем мы начали создавать пользовательские карты, которые были исчерпывающими в своих выводах и рекомендациях, и при этом легко воспринимались. Я понял, что мы создали что-то хорошее, когда презентовал наши пользовательские карты перед нашими ведущими топ-менеджерами и наблюдал за тем, как они подались вперед, чтобы рассмотреть карту и начали задавать вопросы.
Однако, даже есть вы добились понимания целей пользователя, выявили правильный набор шагов, а потом просто и ясно визуализировали картину, вы можете столкнуться со скептическим отношением тех, для кого предназначена построенная карта, они могут игнорировать актуальность и важность сделанных выводов. Поэтому я направил усилия команды на описание и систематизацию источников для каждого шага ключевых пользовательских сценариев. Таким образом мы дали возможность скептикам изучить детали и убедиться в достоверности выводов, изображенных на карте, даже если они не были изначально с этим согласны.
Хотя возможность углубиться в детали приносит дополнительную ценность, самые важные находки были сделаны, когда мы начали обобщать наши выводы.
Разрыв между командами
Когда мы начали составлять карты пользовательского опыта, которые проходят через зоны ответственности разных команд и подразделений бизнеса, мы обнаружили множество слепых зон. Мы обнаружили разрывы, аналогичные тем, которые часто возникают, когда путь пользователя проходит через две разные организации. Переход пользователя с рекламной страницы на страницу продукта. Переход на экран регистрации — поддерживаемый другой организацией! — и затем возврат к продукту, которым заинтересовался пользователь. Навигация между разными продуктами в рамках одного процесса.
Карты пользовательского пути — как и настоящие пользователи — игнорируют границы между организациями. Пользователь просто хочет, чтобы всё работало. Но отрезки пути, связанные с переходом между организациями, иногда возлагают на пользователя обязанность помнить о существующих разрывах.
Итак, мы обнаружили массу разрывов пользовательского опыта в швах организационной структуры. Первая реакция на такие выводы: “Объединить эти две команды” или “Заставить всех говорить со всеми!”. Однако в организации, где работают тысячи сотрудников, это так просто не сработает. Нам нужен был способ, позволяющий держать людей в курсе полной картины, требующий обращать внимание на соседние кусочки паззла, не теряя фокуса на своих обязанностях.
Нам нужна была абсолютная гласность, не скатывающаяся в разглагольствование.
Абсолютная гласность в организации
Как вы заставите организацию, разрывающуюся между различными приоритетными задачами, сфокусироваться на исправлении длинного списка маленьких UX-проблем?
Я начал внутреннюю PR-кампанию, чтобы убедить людей снизу доверху организационной структуры, в том, что перед нами уникальный шанс.
Я хотел убедиться, что все сотрудники знают основные цели наших пользователей и где они буксуют, когда хотят достичь своих целей. Затем я обобщил всё это, и у меня получился ряд возможностей, которые я и презентовал руководству как потенциальную инициативу для финансирования. Моей целью являлась институциализация абсолютной гласности через публичное обсуждение проблем и преобразования их в возможности.
Вот шаги, которые я предпринял:
- Определение топ-10 работ, которые должны выполнять наши продукты (Jobs To Be Done).
- Составление карты пользовательских путей для каждой из этих 10 работ на основе стандартного шаблона, и оценка успешность каждого пути по 5-ти балльной буквенной шкале (A-F).
- Объединение карт пользовательских путей в единый дашборд, содержащий оценку успешности для каждого пути.
- Распространение дашборда по подразделения компании и привлечение внимания руководства к необходимости вложить ресурсы в совершенствование одного или двух из ключевых пользовательских путей.
Давайте теперь подробно рассмотрим каждый из этих шагов.
- Определение работ, для которых нанимают наши продукты (JTBD)
Для начала я составил список топ-10 работ для наших продуктов, используя методику Jobs To Be Done. Эта концепция, распространенная Клейтоном Кристенсеном (Clayton Christensen), гласит, что потребность в продукте возникает в определенной ситуации, столкнувшись с которой покупатель “нанимает” его для выполнения определенной работы. Демографические параметры покупателя и восприятие бренда вторичны по отношению к основному стимулу потребления, заключающемуся в получении результата этой работы, которая по сути может быть выполнена любым из подходящих продуктов.
Так что я задался вопросом, какую работу пользователи выполняют с помощью нашей платформы и какие продукты на нашей платформе они “наймут”, чтобы получить ожидаемый результат? Я объединил данные полученные от продающих команд, менеджеров продуктов и представителей разработчиков с данными конкурентного анализа и исследованиями поведения пользователей.
Лимит в 10 пунктов был установлен произвольно, чтобы ограничиться самым важным. Для более простых продуктов можно вообще взять только две или три работы. Не начинайте со списка в 50 пунктов. Это всех впечатлит, но и утомит одновременно. Сосредоточьтесь на главном, чтобы сделать более сильный рывок.
2. Картирование и оценка каждого пользовательского пути
После того как я определил работы JTBD Кристофер Гаррисон (Christopher Garrison) взялся за картирование пользовательского пути для каждой из этих работ. Austin Auth создал шаблон в Keynote, который мы использовали как основной инструмент. Вы можете загрузить его здесь и использовать для своих целей!
Каждая карта начинается с короткого описания цели пользователя, оценки успешности пути и количества болевых точек. Далее последовательно описаны шаги на слайдах со скриншотами, таймлайном внизу и анализом справа:
Копию этого слайда можно использовать для описания каждого следующего шага. Надо лишь добавить новый скриншот и относящиеся к нему наблюдения. Совет для профессионалов: Весь путь можно записать за один раз Quicktime Player (File –> New Screencast –> Recording), и затем использовать скриншоты из этой записи.
Редактирование линейной диаграммы
Линейная диаграмма всего пути размещается на мастер-слайде, поэтому можно ее построить один раз, и она будет показана на каждом слайде с описанием шага. Чтобы ее изменить, надо нажать на миниатюру слайда, а затем использовать команду Edit Master Slide в панели Макетов. На мастер-слайде надо кликнуть на диаграмму и выбрать Edit Chart Data:
В открывшейся таблице оставляем такое количество колонок, которое соответствует количеству шагов в пути. Лишние колонки можно удалить, либо добавить, если колонок не хватает:
В каждой ячейке ставим значение, соответствующие оценке впечатлений пользователя: 0 — негативные, 1 — нейтральные, 2 — позитивные. Когда данные для каждого шага будут внесены, диаграмма отразит подъемы и провалы в пользовательской оценке.
Отрезок пути, соответствующий описываемому шагу, надо подсветить на слайде шага. Работая как курсор, подсветка показывает наблюдателю, в каком месте пользовательского пути находится текущий шаг.
Система оценки по принципу абсолютной гласности
Когда карта сделана, проанализируйте болевые точки и проставьте оценку в заголовке слайда. Я выбрал последовательность от A до F для оценочной шкалы, потому что она крупноразмерная, ограничивающая субъективность, но тем не менее интуитивная. Если опыт такой болезненный, что пользователю хочется его прервать, ставим F. Если пользователь может завершить путь, но испытывает при этом большие трудности, ставим D. Если трудности некритичны, ставим C. Если пользователь не испытывал трудностей, ставим B. Если всё прошло без проблем и был хотя бы один повод для радости, ставим A. Несмотря на то что разница между C и D довольно субъективная, ни одна из этих оценок не является такой, где мы бы хотели оставаться вечно.
Наверняка поначалу оценка будет вызывать негативную реакцию. На самом деле, продуктовые команды делают все, что могут, чтобы упростить жизнь пользователей, поэтому низкую оценку их усилий они посчитают несправедливой. Каждый хочет иметь A, особенно, если эту оценку видит также начальник. Наша система оценки делает начальником пользователя. Даже, если мы этого не замечаем, с точки зрения пользователя некоторые фрагменты пути могут действительно иметь оценку D или даже F. Ответственные за этот фрагмент воспринимают эту оценку, как удар в живот.
В оценках старайтесь избегать обвинений, но вместо этого фокусируйтесь на возможностях. Абсолютная гласность формирует новые возможности, благодаря тому, что честное обсуждение проблем формирует понимание необходимости выделить ресурсы на их исправление.
3. Сведение данных на дашборде
Мы создали дашборд, доступный по ссылке всем сотрудникам компании, чтобы каждый мог следить за изменениями. Это позволяет легко использовать данные на любой из встреч, даже если не удалось подготовится заранее.
Дашборд представляет собой простой список топ-10 работ наших продуктов, где каждый из них дополнен оценкой пользовательского пути и именем ответственного. Можно нажать на строку, чтобы увидеть весь слайд с детальным анализом.
Дашборду не нужны тысячи фич и фишек. Нужно только, чтобы его было легко найти, и чтобы он показывал понятную оценку, основанную на актуальных данных. Мы с командой используем для дашборда разработанную нами Carbon Design System, но wiki-страница также хорошо работает, если люди регулярно ее просматривают. Ведь цель дашборда состоит в том, чтобы быстро объяснить руководству, какая часть опыта пользователя вызывает больше проблем, чтобы правильно определить направление инвестиций и приложения усилий.
4. Представление дашборда руководству и предложение направления инвестиций
Пользовательский опыт основан на деталях, но руководство не любит инвестировать в цели с неясными перспективами, такие как исправление мелочей. Им нужно, чтобы вы превратили мелочи, которые по отдельности не стоят упоминания, во что-то большее, что они смогут поддержать. Этому помогает дашборд с 10 основными путями пользователей, некоторые из которых имеют низкую оценку из-за множества маленьких проблем. Этот дашборд представляет собой список из 10 потенциальных инициатив, каждая из которых может значительно повлиять на пользовательский опыт и, следовательно, на прибыль.
Не расстраивайтесь, если первой реакцией будут нападки. Когда я впервые продавал свой список пользовательских путей с не очень лестными оценками, вынесенными на уровень руководства, я слышал, “Разве UX не твоя ответственность? Почему ты не исправил это?”. Это было ожидаемо. Не обвиняя никого, я обсуждал необходимость увеличения финансирования — даже если это приостановит некоторые крупные новые проекты — и необходимость в повышенном внимании к координации усилий разных команд, направленных на сглаживании швов.
Мы также оценили возможность увеличения дохода от улучшения конкретных пользовательских путей. Мы предположили, что можем увеличить конверсию пользователей до 10% в двух конкретных сценариях, и мы запланировали соответствующий рост дохода. Наш запрос приобрел значительность: инвестируйте в наши предложения, и мы обещаем высокий уровень возврата инвестиций.
Когда ты можешь перевести с языка дизайнера на язык финансиста, руководство бизнеса начинает слушать. В итоге, оба наши предложения получили зеленый свет.
(Больше информации о переводе с языка дизайна на язык финансов в статье A Proven Method For Showing the Value of Good UX, by Jared M. Spool )
Сейчас мы знаем, что наши действия оказались правильными. К счастью, мы получили увеличение конверсии больше, чем на 10%, как изначально планировалось. Конверсия оказалась больше на порядок в обоих путях.
Если правильно определить проблемы в пользовательском опыте, улучшать его, а затем подсчитать влияние улучшения, ты получишь право голоса, хочешь ты этого или нет!
