Когда 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-исследование нельзя торопить и ничем не ограничивать.
Некоторые этапы исследования займут больше времени, чем другие, но важнее всего различать ценные в определенный момент исследования от исследований, приносящих результат в долгосрочной перспективе.
Методы основополагающего исследования помогут вам решить, куда вы хотите двигаться, а направленное исследование покажет вам по этапам, как достичь выбранной цели.