Дизайн и UX в гибких методологиях
Зачем, и главное — как
Будем откровенны — дизайнеры терпеть не могут гибкие методологии. А ещё — дневной свет, работу с 9 до 18, таск-трекеры и всё, что мешает свободе творчества. Но если дать им волю, многие отложили бы всю работу на последний день последнюю ночь перед дедлайном. А потом с утра, с красными глазами и напившись энергетиков, презентовали своё детище (и не факт, что успешно).
Поэтому рамки всё-таки нужны (для их же блага). Другой вопрос, что интегрировать дизайн и UX в Scrum и Agile непросто из-за особенностей дизайн-процесса: эта тема несколько холиварная, и вызывает сложности даже у опытных практиков. Хотя парочка решений всё-таки есть — каких именно, поговорим в этой статье.
Поэтому рамки всё-таки нужны (для их же блага). Другой вопрос, что интегрировать дизайн и UX в Scrum и Agile непросто из-за особенностей дизайн-процесса: эта тема несколько холиварная, и вызывает сложности даже у опытных практиков. Хотя парочка решений всё-таки есть — каких именно, поговорим в этой статье.
Интеграция дизайна и UX в Scrum
Дизайн и UX — последнее, для чего предполагали использовать Cкрам его создатели, поэтому практики с многолетним опытом иногда по-прежнему задаются вопросом их интеграции в скрам-процесс. Ключевая причина таких затруднений — в самой идее фреймворка: он создавался не столько для того, чтобы сделать продукт более ориентированным на клиента (за что по факту отвечает дизайн и UX), сколько — чтобы ускорить разработку.
Но некоторым командам удаётся победить это противоречие и выстроить дизайн-процесс в рамках Cкрама органично. Один из вариантов решения проблемы — аккуратно наложить дизайн- и UX-активности поверх scrum-модели. Результат может выглядеть как-то так (оригинал схемы взят у Джеффа Готхельфа):
Но некоторым командам удаётся победить это противоречие и выстроить дизайн-процесс в рамках Cкрама органично. Один из вариантов решения проблемы — аккуратно наложить дизайн- и UX-активности поверх scrum-модели. Результат может выглядеть как-то так (оригинал схемы взят у Джеффа Готхельфа):
Джефф сознательно делает некоторые допущения и несколько упрощает:
К каждой группе UX-активностей автор схемы даёт пояснения:
- приводит далеко не исчерпывающий список дизайн-активностей;
- использует слово «Дизайн» как общий термин для всех видов дизайн-деятельности для дизайнеров всех мастей;
- не слишком разводит понятия «Дизайн» и «UX», предлагая обсудить это когда-нибудь потом.
К каждой группе UX-активностей автор схемы даёт пояснения:
1
Бэклог продукта
Содержит тезисы более широкого видения продукта, над которыми в текущем спринте работать не планируется. Фундаментальные идеи, видение и гипотезы — всё здесь. Активности вроде «Дизайн-спринтов», «Исследований» и написания гипотез помогают придать элементам бэклога как реальность, так и ориентированность на клиента.
Содержит тезисы более широкого видения продукта, над которыми в текущем спринте работать не планируется. Фундаментальные идеи, видение и гипотезы — всё здесь. Активности вроде «Дизайн-спринтов», «Исследований» и написания гипотез помогают придать элементам бэклога как реальность, так и ориентированность на клиента.
2
Планирование спринта
Ежедневная командная «рутина». Примерный круг вопросов: «Как это будет выглядеть?», «Как пользователь будет переходить от экрана к экрану в продукте?», «С какими исключениями нам придется иметь дело?». В поисках ответов на эти вопросы можно применить инструменты проектирования — скажем, совместный скетчинг или коллективные мозговые штурмы, которые UX-дизайнеры очень любят.
Ежедневная командная «рутина». Примерный круг вопросов: «Как это будет выглядеть?», «Как пользователь будет переходить от экрана к экрану в продукте?», «С какими исключениями нам придется иметь дело?». В поисках ответов на эти вопросы можно применить инструменты проектирования — скажем, совместный скетчинг или коллективные мозговые штурмы, которые UX-дизайнеры очень любят.
3
Тактический Дизайн (под большой буквой Д скрывается всё многообразие продуктового дизайна)
Должен закладываться в бэклог спринта и выполняться, прежде всего, дизайнерами, но без отрыва от скрам-команды. Идея в том, чтобы расставить приоритеты в этой работе так, чтобы все члены команды могли работать параллельно.
Должен закладываться в бэклог спринта и выполняться, прежде всего, дизайнерами, но без отрыва от скрам-команды. Идея в том, чтобы расставить приоритеты в этой работе так, чтобы все члены команды могли работать параллельно.
4
Штатный дизайнер в скрам-команде
По классике он отсутствует в скрам-команде, но для интеграции UX-дизайна в скрам-процесс, по мнению Джеффа Готхельфа, он там необходим. Почему так? Только в в сотрудничестве с разработчиками, менеджерами продукта и скрам-мастерами может получиться годный тактический дизайн.
По классике он отсутствует в скрам-команде, но для интеграции UX-дизайна в скрам-процесс, по мнению Джеффа Готхельфа, он там необходим. Почему так? Только в в сотрудничестве с разработчиками, менеджерами продукта и скрам-мастерами может получиться годный тактический дизайн.
5
Ревью спринта
Это возможность вместе с командой взглянуть на результат работы, созданный во время спринта. Ревью также даёт пересмотреть то, что команда выяснила в ходе спринта (и каким был результат этих открытий). Дизайн-ревью, поисковый синтез и качественный анализ дают представление о дальнейшем ходе работы и помогают расставить приоритеты как в продуктах, так и в следующем спринте.
Это возможность вместе с командой взглянуть на результат работы, созданный во время спринта. Ревью также даёт пересмотреть то, что команда выяснила в ходе спринта (и каким был результат этих открытий). Дизайн-ревью, поисковый синтез и качественный анализ дают представление о дальнейшем ходе работы и помогают расставить приоритеты как в продуктах, так и в следующем спринте.
Автор схемы Джефф Готхельф уверен, что дизайн и UX могут существовать в скрам-системе только если дизайнер в штате компании — с аутсорсными ребятами рано или поздно всё кончится водопадной моделью.
Интеграция дизайна и UX в Agile
У Agile с UX и дизайном, в общем-то, те же проблемы, что и у Cкрама: программистам легко и комфортно работать итерациями, а дизайнерам — нет. Потому что дизайнеру проще продумать концепцию полностью, а не дробить эту задачу на более мелкие, теряя при этом глобальное видение решаемой проблемы клиента.
Получается дилемма: либо качественно и долго (когда концепция продумывается целостно), либо сыроватый продукт, но быстро (когда на глобальное видение нет времени, зато работа подчинена законам Agile).
Вообще-то компромиссное решение давно придумано — мы стали его применять ещё в далёком 2012-м. Основная идея — параллельные потоки дизайна и разработки, где поток дизайна идет впереди на одну итерацию (так называемый «нулевой спринт»).
На этапе планирования проекта проводится аналитика, выясняются потребности клиента и рынка, формируется структура будущего сайта, разрабатывается прототип. На нулевом спринте создаётся дизайн-концепция и утверждается с заказчиком. Дальше — параллельно ведется программирование по уже согласованным макетам и дизайн новых страниц в рамках основной концепции.
Что даёт такой подход?
- включение дизайнеров в гибкую разработку плюс сохранение качества создаваемых интерфейсов;
- вовлеченность всех специалистов и отсутствие «простоев», даже если в работе всего один проект;
- регулярная обратная связь от заказчика и правки на нижних уровнях (чем раньше обнаружили проблему, тем дешевле исправить).
Схема годами проверена на практике в студии, процесс управляемый, клиентам нравится результат. Хотя в интернетах можно встретить критику идеи нулевого спринта.
Дизайн- и UX-спайк — зачем нужен в agile и scrum
Адепты дизайн- или UX-спайка критикуют нулевые спринты за то, что за отведенное на этот спринт время дизайнеры зачастую успевают решить лишь самые базовые проблемы. Другая его проблема в том, что это разовое событие в самом начале работы по проекту — не очень-то похоже на гибкость. Также есть мнение, что результата нулевого спринта якобы может не хватить команде разработки в 1-м спринте.
Spike (с англ. «всплеск») — активность в Agile, которая помогает получить знания, необходимые для снижения рисков, лучшего понимания требований и оценки задачи. Спайк используют, когда в спринте появляется неясная задача с массой возможных проблем и неопределенной сложностью. Вместо нее в работу берется спайк, то есть работа, необходимая для того, чтобы дать ответ или решение, а не выкатить фичу.
Поэтому на сложных проектах придумали прерываться на спайки. Тема эта старая, но иногда «всплывает» по сей день. По факту, это дополнительное время на исследования, изучение информации для более четкого понимания подхода дальнейшей разработки и более точных оценок текущей задачи.
Для дизайн-спайка вводится дополнительная роль — Design Owner, или Владелец Дизайна (тимлид отдела дизайна, например). Для UX-спайка, соответственно, — UX Owner, Владелец UX. Эта роль нужна, чтобы отстаивать UX- и дизайн-решения перед Владельцем Продукта (конфликт интересов здесь — довольно частая история).
Такие спайки сфокусированы на дизайнерских или UX-задачах из бэклога — разработка на этом этапе ни при чём. Время таких «дизайн-перерывов» никак не регламентировано, но команда должна стремиться завершить спайк как можно скорее (ну-ну). И конечно, на начальном этапе Владелец Дизайна или Владелец UX должны утвердить критерии готовности, при достижении которых спайк можно будет считать завершенным. После завершения — продолжается обычный Agile и/или scrum-процесс.
Такие спайки сфокусированы на дизайнерских или UX-задачах из бэклога — разработка на этом этапе ни при чём. Время таких «дизайн-перерывов» никак не регламентировано, но команда должна стремиться завершить спайк как можно скорее (ну-ну). И конечно, на начальном этапе Владелец Дизайна или Владелец UX должны утвердить критерии готовности, при достижении которых спайк можно будет считать завершенным. После завершения — продолжается обычный Agile и/или scrum-процесс.
Асхат Уразбаев, управляющий партнер в ScrumTrek, уверен, что введение новой роли, которая будет спорить с Владельцем продукта по поводу дизайн-решений, ничего не решит. Проблема, по его мнению, в неумении команды общаться с самим Владельцем продукта, и в том, что дизайнер в скрам-команде не может объяснить, что такое UX-дизайн и зачем он нужен. Так что, прерывать ли спринт ради такого сомнительного удовольствия, решать только вам. У нас всё работает без этого, например :)
Выводы
- Для интеграции UX и дизайна в Cкрам достаточно наложить их базовые активности на стандартный скрам-процесс.
- Штатный дизайнер внутри скрам-команды — обязательное условие для интеграции UX и дизайна в скрам-процесс.
- Для интеграции UX и дизайна в Agile нулевой спринт и запараллеливание потоков — хорошее рабочее решение (мы проверили).
- Дизайн-спайк — костыль для команд, не умеющих общаться с Владельцем продукта, и для дизайнеров, которые не могут донести свои идеи до команды в рамках стандартного спринта.