Как не тормозить разработку UX-исследованием

Подготовка исследований к agile-командам

BABAY
BABAY.ME
8 min readDec 4, 2017

--

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

Есть много отмазок для того, чтобы не проводить UX исследование, но самое популярное — “У нас нет на это времени”.
Действительно, можно понять подход типа “Давай просто сделаем это”.

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

Является ли ваш UX-исследователь частью кроссфункциональной agile-команды или он выделен в проекте, как отдельный бизнес-процесс?

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

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

Встроенный, но тормозящий

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

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

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

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

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

Не тормозящий, но абстрактный

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

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

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

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

Как внедрить UX в качестве собственного параллельного процесса

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

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

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

Хорошим решением будет представить UX процесс разделенным на два противоположных лагеря: фундаментальное исследование vs. направленное исследование.

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

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

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

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

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

Направленное исследование проводится в условиях общения команды. Результатом этого исследования должны быть короткие ответы “да/нет”, “готово к внедрению”, а не 14-страничный отчет.

Примеры

Вопрос: Текст кнопки должен быть “Подтвердить” или “Зарегистрироваться и продолжить”?

Ответ: Мы провели A/B тест с 500 посетителями сайта, и кнопка с текстом “Зарегистрироваться и продолжить” показала конверсию лучше на 20%

Вопрос: Есть ли проблемы с юзабилити в текущем дизайне?

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

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

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

Фундаментальное исследование

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

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

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

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

Примеры

  • Этнографическое исследование
  • Интервьюирование пользователей
  • Персоны
  • Journey Maps
  • Empathy Maps

и т.д.

Совмещение параллельного и фундаментального исследований

Эти два потока UX исследований могут протекать независимо друг от друга, позволяя при этом друг другу протекать с той скоростью, с которой это необходимо.

Так как же мне применить это внутри команды?

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

Итак, вот 6 советов, которые помогут вам применить параллельные UX-процессы:

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

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

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

2. Будьте благоразумны в объемах исследований и выделении на это времени

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

- Стив Круг

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

Это нереально. Вы никогда не сможете узнать «все», чтобы постичь какой-то предмет. Возможно, вы заметили, что чем больше вы узнаете о чем-то, тем больше вы узнаете, что вам еще нужно узнать.

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

3. Используйте всю мощь команды для проведения эксперимента

Вы — кросс-функциональная команда. Действуйте именно так.

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

Купят ли клиенты мой продукт?

Запилите лендос и посмотрите как много посетителей нажмут кнопку “Купить сейчас

Будут ли клиенты пользоваться этой фичей?

Запилите кнопку для этой функции и посмотрите как много пользователей на нее нажмут.

Какую кнопку нужно сделать “Зарегистрироваться” или “Авторизоваться”?

Запустите A/B тест и сравните конверсию.

Разработчики тестеры могут быть лучшими друзьями UX исследователей.

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

4. Найдите время на переработку

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

Сокращение времени, затрачиваемого на технический долг, делает код более надежным и устойчивым; удаление нашего долга UX делает то же самое с нашим UX.

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

5. UX — это по-настоящему кросс-функциональный навык и он возлагает большую ответственность

Это слишком важный и ответственный момент, чтобы в команде был только один человек.

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

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

6. Если есть сомнения, то обратитесь к основополагающим принципам UX

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

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

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

--

--