Рецепты совместимости динамичного Agile-подхода и длительных UX-исследований
Колонка дизайн-менеджера из IBM Атула Ханда и сооснователя компании Conceptell INC Канупраи Вашишт.
Agile-разработку и UX-дизайн можно сравнить с молодой супружеской парой — они ещё недостаточно знают друг друга, но искренне стремятся к доверию, сотрудничеству и любви. А вот если к этому союзу добавить UX-исследования, ситуация окажется более неустойчивой. Приведём пример типичной беседы UX-дизайнера с заказчиком где-нибудь в середине нулевого спринта:
Руководитель продукта: Эй, Джен, когда мы сможем посмотреть на какие-нибудь прототипы?
UX-дизайнер: Ну, мы как раз сейчас обрабатываем интервью и составляем портреты типичных пользователей — в общем, пытаемся более точно определить нашу целевую аудиторию. У нас уже есть некоторые наброски, но мы узнали кое-что новое и собираемся внести некоторые корректировки.
Руководитель продукта: Это всё хорошо, но мы не можем тратить слишком много времени на исследования. Нулевой спринт заканчивается на следующей неделе, и разработчики ждать не будут. Давай-ка поторопись. Я буду тебе очень признателен, если ты быстро сделаешь прототипы.
Этот сценарий знаком многим членам Agile-команд, особенно UX-исследователям и дизайнерам. Всякий раз, когда не хватает времени, первой жертвой оказываются UX-исследования — их либо сильно сокращают, либо прекращают полностью.
По общему мнению, UX-исследования слишком растянуты во времени, и чтобы успевать за Agile-разработкой, их приходится либо форсировать, либо откладывать в долгий ящик.
Большинство команд, с которыми мы работали, испытывали поистине танталовы муки, пытаясь встроить UX-практики в Agile-вселенную, вращающуюся вокруг разработки. Опыт показывает, что UX-исследования обычно являются наиболее проблемным пазлом — тем самым кусочком, который чаще других заметают под ковёр.
Опасения и заблуждения
Вот самые распространённые заявления, высказываемые Agile-командами при обсуждении UX-исследований:
- «Ни у кого нет времени на то, чтобы встраивать медленные формальные UX-исследования в быструю гонку Scrum-разработки. Команды должны выдавать результаты регулярно и чётко, поэтому быстрые и информативные партизанские исследования гораздо эффективнее».
- «Нам нужно разделить всю работу на отдельные, ограниченные во времени фрагменты. Исследования в этом смысле очень коварны, ведь они могут охватывать не только несколько user stories, но и несколько спринтов и даже релизов».
- «Мы проводим наши исследования заблаговременно, во время нулевого спринта или даже раньше. Когда начинается разработка, у нас уже нет на это времени».
Давайте кое-что проясним. Во-первых, Agile — это не «быстрый способ разработки ПО». Ни один разумный эксперт или автор, пишущий об Agile-разработке, не упоминает о том, что её цель — ускорять ход событий. Возможно, это распространённое заблуждение проистекает из терминов Agile или Sprint в Scrum.
На самом деле Scrum-подход обеспечивает качество, а не скорость. Работа короткими циклами и Time Boxing не дают командам слишком долго блуждать в неверном направлении и позволяют быстро корректировать курс, когда меняются приоритеты.
Эти же принципы применимы и к UX-исследованиям. К сожалению, многие команды этого не знают и не уделяют достаточного внимания UX-исследованиям (а то и вовсе отказываются от них). Попытки провести быстрые, неформальные UX-исследования оборачиваются ненадёжными, потенциально ложными результатами, и стремление справиться с темпом Agile-разработки — слабое оправдание такого подхода.
И хотя эксперименты «на скорую руку» всё же лучше, чем никакие, есть существенная разница между неформальным и небрежным UX-исследованием.
Что касается заблаговременных исследований, возникает вопрос по поводу их полезности для разработки. Не опровергается ли при этом основной принцип Agile-подхода — как можно лучше реагировать на изменения и неопределённости?
Не бойтесь включать в бэклог UX-исследования
Проблема состоит в том, что некоторые считают UX-исследования неуместными в Sprint Backlog. Agile-команды часто рассматривают исследования как нечто постороннее, внешнее по отношению к разработке, имеющей высший приоритет.
Самым большим препятствием к тому, чтобы UX-исследования стали привычной составной частью бэклога, является досадное заблуждение, что это то самое «бутылочное горлышко», которое замедляет ход дизайна и разработки. Члены команды уверены, что дизайнеры и разработчики напрасно теряют время в ожидании, пока закончатся затратные по времени исследования.
Это действительно так, но только в том случае, если вы воспринимаете Agile как серию мини-водопадов. Если ваши спринты состоят из линейной передачи заданий от исследований к дизайну, а затем к разработке, то задержки неизбежны. Но если ваша Scrum-команда мыслит по-настоящему гибко, такого не произойдёт.
Приведём пример. Допустим, некая Agile-команда приступила к созданию сайта о поиске работы. UX-исследования уже проводятся, но далеко не в полном объёме. Портреты пользователей очень схематичны, а их требования не конкретизированы. Команда хочет как можно быстрее выяснить, кто её пользователи, чего они хотят и как лучше всего удовлетворить их нужды, например:
Наш сайт обслуживает студентов университета и колледжа, которые ищут работу на условиях частичной занятости, чтобы окупить своё образование. Предположительно они заинтересованы во временной работе с низким порогом входа. Сайты конкурентов слишком общие и плохо соответствуют этой специфической категории пользователей, к тому же в них не реализована возможность автоматического соотнесения пользовательских профилей с потенциальными вакансиями.
Чем же могут заняться дизайнеры и разработчики в ожидании результатов UX-исследования? Вместо того, чтобы жаловаться на задержку, можно уже на самых ранних стадиях проекта наладить взаимодействие с UX-исследователями: получать инсайты, расширять свои представления о пользователях и даже участвовать в некоторых исследованиях.
Основываясь на первых сведениях, пусть даже самых элементарных, дизайнеры могут сделать предварительные скетчи, а разработчики — приступить к работе над архитектурой и кодом своих программ. Ничего, что потом что-то может измениться. Agile приветствует изменения, и если все будут работать параллельно, никому не придётся ждать. Естественно, такая работа требует от членов команды открытости и сотрудничества — и это ещё один основной принцип Agile.
Предположим, позже обнаружилось, что основным требованием пользователей было не просто найти работу, но сделать это так, чтобы им не приходилось далеко ходить или ездить на велосипеде (только несколько человек из целевой пользовательской группы имеют собственные автомобили).
В этом случае команда просто добавит в бэклог новые user stories и введёт дополнительные функции поиска работы в зависимости от расстояния и местоположения.
Не нужно проводить большие заблаговременные UX-исследования, не нужно ждать их результатов, не нужно экономить за их счёт. Гораздо полезнее относиться к UX-исследованиям так же, как к любой другой работе в рамках текущего спринта: добавлять в бэклог как исследования, так и вытекающие из них практические действия и при этом правильно расставлять приоритеты.
Составляя план проекта, вы должны предусмотреть все виды работ, будь то исследование, дизайн или разработка. Превращайте элементы исследований в пункты бэклога — эпики, user stories и задачи — и позаботьтесь о том, чтобы сотрудники выполняли самые приоритетные из этих заданий. Тогда ваша Agile-команда станет по-настоящему междисциплинарной как по структуре, так и по своим функциям.
Как планировать UX-исследования
В идеале UX-исследования, как и дизайн, должны быть итерационными. В некоторых типах исследований (таких как оценочные) есть смысл делать более короткие циклы, тогда как другие их виды (вроде изучения поведения постоянных пользователей или изменения трендов) могут растягиваться надолго.
Перед тем как сделать UX-исследования частью ритма Agile-команды, полезно категоризировать ваши исследования, а затем посмотреть, каким образом лучше распределить тайм-боксы в плане соответствия бэклогу. Мы предлагаем организовать UX-исследования на трёх уровнях, как показано на первом рисунке:
- Стратегический трек.
- Тактический трек.
- Оценочный трек.
Стратегический трек
Стратегический трек включает в себя любые исследования, которые могут помочь сформулировать видение продукта, стратегические цели и дорожную карту, а также определить целевых пользователей. Исследования этого трека можно сравнить с постоянной разведкой. Их начинают задолго до дизайна и разработки, а затем продолжают в течение следующих итерационных циклов. Весь процесс может занять несколько месяцев.
Тактический трек
В тактический трек входят короткие исследования, выявляющие специфические функции продукта и желаемый пользовательский опыт. С их помощью человек, отвечающий за разработку, может расставить правильные приоритеты в проектном резерве.
Такие исследования проходят итерационно и занимают не одну неделю, порой растягиваясь на несколько спринтов. Они помогают определить, какие функции включать, модифицировать или убирать в каждом конкретном релизе.
Оценочный трек
Как понятно из названия, этот трек содержит оценочные исследования и тесты, которые подтверждают или опровергают предположения, помогают оценить дизайнерские решения, определяют любые вопросы, связанные с доступностью и юзабилити, и измеряют пользовательскую удовлетворённость и эмоциональный отклик.
Они занимают от двух до трёх недель и в идеале должны проводиться в каждом спринте. Оценочные исследования могут включать в себя тестирование юзабилити, когнитивный анализ или эвристические оценки.
Конечно, выбранные нами названия треков условны, и вы можете назвать треки по-другому — так, чтобы это соответствовало динамике вашего проекта. Цель этих треков — помочь вам как можно лучше спланировать и организовать ваши исследования.
Как добавить UX-исследования в бэклог
Каждая Agile-команда имеет свой, непохожий на других список требований к функциональности продукта. Списки отличаются названиями и иерархией входящих в них элементов, а также методами их структурирования и организации. Однако наиболее часто резерв проекта в Scrum включает в себя такие элементы, как эпики, user stories и задачи.
User stories — это те пользовательские требования, которые команда собирается реализовать в течение спринта. Эпики — это слишком большие или слишком сложные user stories — те, которые невозможно завершить за один спринт. Задачи — самые мелкие единицы работы в бэклоге, это те действия, которые должны выполнить члены команды, чтобы удовлетворить пользовательские требования.
Существует несколько формальных подходов, полезных при включении UX-исследований и дизайнерской работы в бэклог продукта. Например, стоит изучить UXI-матрицу Джона Иннеса или User Story-карту Джеффа Паттона. Но если вы предпочитаете простые методики и не хотите увеличивать накладные расходы, организуйте ваши исследования в предложенные нами треки: стратегический, тактический и оценочный.
Начать лучше с тех пунктов бэклога, которые отнимают много времени, например, с UX-исследований для эпиков. Затем, на сессиях бэклог-груминга вы сможете постепенно перевести эпики в user stories. Тогда UX-исследования, посвящённые user stories, войдут в состав более крупного исследования, которое вы сможете завершить в рамках одного спринта.
Добавление элементов стратегического трека
Элементы бэклога, входящие в стратегический трек, вероятно, займут много времени, поэтому вам следует прежде всего сформулировать эпик UX-исследования, который вы позднее разделите на user stories. Имейте в виду, что в каждый спринт должна попасть хотя бы одна такая история (можно несколько).
Эти истории могут касаться формулировки вопросов исследования и гипотез, создания скрининг-анкет, подбора участников, проведения первого раунда интервью или сбора и анализа данных.
Эпик и user stories этого этапа UX-исследования не сильно отличаются от остальных, разве что тем, что вам следует писать их с точки зрения пользователей — команды дизайнеров, проектировщика или лидеров бизнеса. Другими словами, важно ориентироваться на их требования, намерения и желаемые результаты.
Приведённый здесь шаблон вы можете использовать при написании эпика или user stories для стратегического трека.
В контексте ситуации пользователь
хочет отслеживать/понимать или получить ответ на , чтобы добиться . Пример эпика в таком формате:
В связи с пониженным (по сравнению с ожидаемым) 10%-ым уровнем конверсии проектировщик хочет понимать, почему пользователям не удаётся завершить регистрацию и пройти все шаги заполнения профиля, чтобы затем разработать несколько стратегий, поощряющих пользователей к завершению этих процессов.
А вот вариант шаблона для user story, являющейся составной частью этого эпика.
В контексте
мы намерены сделать , который позволит получить . Пример user story, являющейся частью эпика:
В рамках эпика #123, мы хотим провести контекстные интервью с шестью участниками с целью обнаружить проблемы, связанные с регистрацией и заполнением профиля.
Добавление элементов тактического трека
Для тех элементов бэклога, которые входят в тактический трек и не вмещаются в рамки одного спринта, вам также придётся создать эпик исследования, а затем разбить его на отдельные user stories. Если же получается уместить исследование в один спринт, вам нужно создать ещё одну историю с помощью шаблона для эпика.
Вот пример такой отдельной user story.
В контексте выбора местоположения будущей работы руководитель продукта и команда дизайнеров хотят знать, не слишком ли сложен этот выбор и нет ли опасности запутать пользователя и привести к неоптимальному UX. При необходимости команда дизайнеров может рассмотреть способы улучшения или замены этой фичи.
Добавление элементов оценочного трека
Что касается элементов бэклога, входящих в оценочный трек, вам может понадобиться оценить более чем одну user story — например, протестировать дизайн и функциональность нескольких фич, относящихся к разным user stories. В этом случае вы можете добавить в бэклог одну user story, используя приведённый ниже шаблон.
Когда
просматривает или выполняет с помощью , мы хотим , в соответствии с желаемого результата . Ссылка на . Пример такой истории из оценочного трека:
Когда зарегистрированный пользователь ищет работу по местоположению, мы хотим понять, может ли он правильно интерпретировать результаты поиска и понять, до каких мест работы можно добраться пешком или на велосипеде, чтобы UX- и визуальные дизайнеры смогли оценить оптимальность формата и дизайна результатов поиска. Ссылка на: Story #123, Story #456.
В том случае, если вам нужно оценить только одну user story, лучше добавить её в качестве критерия приёмки. Критерии приёмки — это сопровождающие user stories утверждения, которые должны выполняться, чтобы история могла считаться завершённой. Приведём пример такой user story.
Как зарегистрированный пользователь я хотел бы иметь возможность во время поиска работы быстро пересчитывать расстояние из миль в километры и наоборот, чтобы видеть полученный результат в удобных для меня единицах.
Одним из критериев приёмки для этой истории мог бы быть следующий:
Тестовый пользователь, который хочет поменять единицы измерения расстояния, может быстро найти нужную ссылку и успешно поменять мили на километры или наоборот.
Конечно, это примерные шаблоны для эпиков и user stories. Вы можете изменить их, подстроив под свои нужды и обстоятельства.
Приоритеты в UX-исследованиях
Как только вы встроили UX-исследования в бэклог, расставьте приоритеты так же, как вы сделали бы это в любой другой ситуации. Груминг должен включать в себя время для обсуждения историй UX-исследования со всеми релевантными акционерами (в том числе для уточнения их ожиданий и дополнительных деталей исследования, критериев или условий приёмки).
Руководитель продукта должен определить ROI (возврат на инвестиции) для всех пунктов UX-исследования и соответственным образом расставить приоритеты в бэклоге. Во время каждого спринт-митинга обсуждайте и оценивайте истории UX-исследования вместе со всей командой.
Поначалу расстановка приоритетов будет напрягать тех членов команды, которые не являются UX-исследователями. Но вам следует поощрять их делать хотя бы приблизительные оценки и принимать участие в дискуссии, чтобы у них была возможность выработать лучшее понимание сути UX-исследований и временных затрат на их проведение.
Как только члены команды распределят истории между собой, убедите их сформулировать задачи — те конкретные шаги, которые они должны предпринять, чтобы завершить истории. И конечно, они периодически должны отчитываться о своём прогрессе во время стендапов.
Несколько советов по поводу исследований в Agile-разработке
Позаботьтесь о том, чтобы результаты вашего исследования было легко использовать. Не надейтесь на громоздкие отчёты. Результаты, хранящиеся в 100-страничном PDF-файле или в командной базе знаний, скорее всего, никогда не увидят свет, и следовательно, не принесут ощутимой пользы.
Старайтесь доносить результаты своих исследований прямо до продуктовых команд и акционеров во время рабочих сессий, на которых подводятся итоги дискуссий и формулируются конкретные шаги. Хорошей формой для подобного обсуждения могла бы стать демосессия или обзор спринта, на которой присутствуют все члены команды и владельцы продукта.
Заключение
UX-дизайн не происходит в вакууме, но вытекает из контекста, включающего в себя специфические нужды бизнеса, стремления пользователей и технические ограничения. UX-исследования помогают дизайнерам лучше понять этот контекст и чётко сформулировать, чего именно они хотят от дизайна, для кого и почему. Исследование также может помочь согласовать дизайн и подтвердить или опровергнуть предположения команды.
Ключевыми результатами правильно проведённого UX-исследования могут быть получение конкурентного преимущества, лучшее привлечение и удержание пользователей, увеличение возврата на инвестиции, сокращение временных и финансовых издержек.
Другими словами, UX-исследования несут с собой те же преимущества, что и Agile-подход. То есть UX-исследование и Agile являются разными средствами достижения одной цели. Вот почему их сочетание может стать действительно эффективным.
© vc.ru
