Когда UX-исследование — не помеха. Как этого добиться?

В лучшем случае UX-исследование выявляет полезные аналитические данные, в худшем — становится просто препятствием.

Против проведения UX-исследования есть много причин, но самая частая отговорка — «у нас на это нет времени».

Я же, скорее, склоняюсь к позиции «просто возьмите и проведите его».

Если говорить не о каскадных проектах с серьезным, неусыпным менеджментом, а о кросс-функциональных agile-командах, то здесь сложно определить, как UX-исследование впишется в работу команды.

Является ли ваш UX-исследователь частью agile-команды или он нанят со стороны?

Каким образом одна команда может одновременно исследовать, проектировать, собирать и тестировать одну и ту же фичу?

Как вообще можно решать, что собирать, прямо посреди процесса сборки?

UX- исследование: встроенное, но тормозящее

Один из популярных компромиссов заключается в том, чтобы внедрить UX-исследования в agile-команду, но так, чтобы исследователь работал на несколько спринтов вперед. Звучит разумно, однако часто такой ход имеет нежелательные последствия — возникает напряженность между остальной частью команды и UX-исследователем.

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

И еще один момент — таким образом, вы только что создали мини-модель каскадного процесса внутри вашей agile-команды.

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

Такое исследование невозможно провести за один или два спринта.

Уже не тормозящее, но все еще абстрактное

Еще один вариант для UX-исследователей — стать обособленным отделом вне agile-команды, на которую они работают, и опережать разработчиков на недели и иногда месяцы.

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

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

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

Встроить UX как отдельный параллельный процесс

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

Нужно решить, какие UX-процессы встроить в структуру agile-команды, а какие вынести на отдельный таймлайн.

Параллельный UX-процесс

Неплохой способ визуализировать этот подход — разделить этапы исследования на два различных вида: основополагающее (foundational) и направленное (directional) исследование.

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

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

Направленное исследование

Направленное исследование занимает короткий промежуток времени и преследует одну цель: ответить на вопросы по юзабилити и целесообразности продукта.

Такое исследование проводится и управляется изнутри agile-команды. Чтобы оно удалось, эксперименты нужно делать маленькими и целостными. Они должны отвечать на один конкретный вопрос или проверять одну определенную гипотезу.

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

Например:

Вопрос

Как должна называться кнопка — «Submit» или «Register and Continue»?

Ответ

Мы провели A/B тестирование на 500 посетителях, и «Register and Continue» оказался на 20% популярнее.

Вопрос

Какие существуют проблемы с юзабилити текущего графического пользовательского интерфейса?

Ответ

Мы провели юзабилити-тестирование с 6 участниками и нашли 4 потенциальные проблемы. Мы советуем 1) сделать кнопку регистрации более заметной; 2) поменять формат поля «адрес», чтобы можно было вводить номер а/я; 3) передвинуть…

Вопрос

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

Ответ

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

Основополагающее исследование

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

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

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

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

Например:

• Открытия или этнографическое исследование
• Пользовательские интервью
• Портреты типичных пользователей
• Карта путешествия потребителя
• Карта эмпатии
• JTBD

Объединяя два подхода

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

И как же распределить работу в моих командах?

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

Поэтому вот 6 подсказок о том, как выстроить и внедрить параллельный процесс:

1. Вся движущая сила — в вашей agile-команде

Помните, что для успеха в agile-среде вашей команде потребуется быть автономной и «самонаводящейся». UX-исследования в таких командах необходимы, чтобы влиять на решения, но команда не должна просто бездумно слушать UX-исследователя.

Это значит, что полномочия agile-команды должны содержать как инициирование, так и проведение исследования.

2. Вдумчиво отнеситесь к нагрузке и тайм-боксингу

Тестировать одного пользователя на раннем этапе проекта лучше, чем тестировать 50 человек ближе к финалу.

– Стив Краг (Steve Krug)

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

Но в жизни такого не бывает. Вы никогда не узнаете абсолютно всё, что можно узнать на определенную тему. Вы замечали, чем больше вы узнаете о чем-то, тем больше вы узнаете, что именно вам нужно узнать?

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

3. Смело экспериментируйте за счет мощной команды

Вы же кросс-функциональная команда. Вот и докажите это.

Лучший способ понять поведение пользователя — это собрать что-то, выпустить и посмотреть, как пользователь ведет себя с продуктом. Опять же, начните с малого: спросите себя, что самое минимальное вы можете собрать, чтобы ответить на ваш вопрос?

Почему пользователи покупают мой продукт?

Создайте лендинг и посчитайте, сколько людей нажмет кнопку «Купить сейчас».

Будут ли люди использовать эту фичу?

Создайте кнопку для фичи и посмотрите, нажимают ли на нее.

Как мне назвать кнопку — «Register» или «Sign Up»?

Проведите A/B тестирование.

Разработчики и тестировщики UX-исследователю в помощь.

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

4. Выделите время на рефакторинг

Разработчики (хорошие) постоянно переписывают и чистят код. Нам полезно перенять эту привычку и делать то же самое в UI и UX дизайне.

Устранять технические недоработки — значит делать код надежнее и жизнеспособнее; постоянная доработка UX творит такие же чудеса с пользовательским опытом.

Дорогие разработчики и руководители продукта, если в каждом спринте вы тратите немного времени на то, чтобы навести порядок в интерфейсе, а не бежать вперед к новым и новым фичам, вы заметите, что UI и UX дизайнеры начнут работать не против вас, а вместе с вами.

5. UX — это действительно про кросс-функционал и ответственность

UX — слишком важная сфера, чтобы ограничиться одним ответственным членом команды.

Нельзя просто так взять и нанять «agile-мастера» и назваться agile-бизнесом. Точно также, вы не сможете просто нанять одного UX-дизайнера в команду и отныне называться ориентированными на пользователя.

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

6. Если сомневаетесь, вспомните принципы Lean UX

Если кратко, то UX-исследование нельзя торопить и ничем не ограничивать.

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

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