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

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

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

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

У меня есть, правда несколько пойнтов.

1. Я легко могу представить, как команда отслеживает такой баклог на уровне достаточно крупных, как называют в Agile, эпических пользовательских историй. Вести трекинг на уровне каждой индивидуальной истории (а их может быть с десяток в каждой итерации) может быть просто адовой работой, притом совершенно бессмысленной из-за мелкости разбиения.
    
2. Основная проблема — все таки различие уровня мышления. Разработчики разбивают задачу на части, в то время как UX-дизайнеры мыслят синтетически, стараются получить картину в целом. С этой точки зрения очень важно отслеживать, как новая пользовательская история влияет на общий опыт пользователя, не нарушает ли она его. В моем опыте очень полезно строить время от времени story map, который и представляет собой мост между индивидуальными пользовательскими историями и общим опытом пользователя.
    
3. И все таки важно помнить, что никакой баклог не заменит прямого общения людей. Очень печально, если UX дизайнер узнает о нереализуемости пользовательской истории из баклога.

«Бритва Оккама» в табличном виде

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

Рассмотрим предпоследний абзац, начинающийся умозаключением «Смысл такой оценки в том :». Из написанного совершенно неочевидно, как постановка задачи 1) превратилась в 2). Трансформация постановки задачи, совершенная автором, имеет корни в японском soft government («мягком управлении»), которое предписывает управляющему обрисовывать цели и образ светлого будущего перед подчиненным, а не выдавать ему дорожную карту с ценными указаниями достижения желаемого. Все уповают на стимуляцию креативной активности у исполнителей и вам сильно повезет с дизайнером, если он не сконвертирует 2) обратно в 1) («Потому что так принято», «Пользователи к этому привыкли», «А как еще-то? По почте отсылать — так прошлый век же ж»), а изобретет свой собственный способ (т.е. станет тем самым творцом, который первым открыл и внедрил кнопку , т.е. привнес в UX что-то действительно новое). Обратите внимание, что в данном описании матрица UXI никак не участвует в процессе выполнения задачи (хотя, вероятно, она участвовала в процессе выбора задачи; но этого мы никогда не узнаем, т.к. все осталось «за кадром»).

По моему сугубо личному мнению, корректной была бы постановка задачи со следующим описанием: «Прочитай User Story #37 и нарисуй нам интерфейсы для нее». Вот и все. Никаких других целеуказаний.

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

UXI — это расширенная модель принятия решений по поводу дальнейшего действия в проекте. В scrum уже есть достаточно полная модель, которая позволяет работать с приоритетами и определять, куда двигаться дальше, но она (как правило, без включения в процесс принятия решений этих факторов сознательно хотя бы на уровне размышлений) не учитывает интересы ваших пользователей. Для некоторых типов бизнеса (см. оригинальную статью) это может быть фатальным.

UXI вносит на уровне метода дополнительные критерии принятия решения и позволяет вам работать с многофакторной моделью требований пользователей и сосредоточиться на их интересах. (Заранее оговоримся, что «точность попадания» во вкусы целевой аудитории будет зависеть от репрезентативности и качества ваших User Stories).

UXI позволяет вам сосредоточиться на действительно важных функциях для самых важных ваших пользователей (какой смысл тратить время на фичу, используемую 5% ваших пользователей 1% времени работы с программой?).

Исходная статья рассматривает процесс проектирования UX гораздо шире, чем в представленной статье. Обратите внимание на пропущенное в таблице данной статьи поле «Staffing»: за UX при данном подходе у нас отвечают несколько ролей, причем каждая из них — за содержательно разные стороны процесса, что опять-таки гипотетически повышает качество вашего UX.

Внедрение количественных метрик (например, количество пользователей, которые «осилили» вашу user story без посторонней помощи) поможет быть хоть сколько-нибудь объективными и не сводить разработку интерфейсов к представлению о прекрасном, существующем в головах разработчиков и дизайнеров.

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

У меня сложилось впечатление, что автор слегка запутался. В Скраме, канбане, UХ и прочих «секси и мимими». И речь в статье (несмотря на название и затравку) не идет о внедрении UX в беклог, а использовании Канбан-доски и приоритетов для упорядочивания работы UX команды. Опять же называть UX аналитиков веб-дизайнерами может быть сильно некорректно, зачастую это разные компетенции.

По логике процесса разработки требований в Agile, UX — это часть разработки требований, то есть потом результат команды UX должен сливаться с работой аналитиков (или мнением ProductOwner, кстати, в статье вообще неясно кто PO и как к нему относится UX команда) и утверждаться PO. UX команда при этом PO не является, она может быть его помощником (и прекрасно когда она есть), но не выполнять его роль. После этого проходит ProductBacklogRefinement с командой и, если история с этим дизайном по приоритету функциональности от PO попала в следующий Спринт, то уже после этого входить в цикл собственно разработки.

То есть надежды что Скрам мастер будет вместе с UX командой и разработчиками проводить стендап, как надеется автор статьи, в общем-то нет. А если будет, то он смешает в одну кучу работу над требованиями и работу над продуктом, имеющие разные Burn-Down и DOD, имхо это неправильно.

Как вариант все же смешать в одном Backlog все работы — это сделать сложный многосоставной DOD для истории (где сначала UX и аналитика, а потом разработка и тестирование), но это слишком сложно для того чтобы быть удобным и обычно не применяется.

Совместная работа PO, UXаналитиков и разработчиков и обсуждение историй —да, конечно, в Scrum для этого есть специальные механизмы. Организация работы UX команды по Kanban — прекрасно, Agile дает много пользы именно участникам команды, делая процесс предсказуемее и работу приятнее. Автор замахнулся на слияние этих процессов, немного неуклюже описав проблемы которые он хочет решить, и таки не решил.

Если смотреть просто как на идею организации UX команды по Agile принципам — тогда у статьи есть шанс. Особенно если не забудут про PO и его роль в процессе.

Статья полезная. Единственная проблема связана не с этой конкретной статьёй, а со всеми Agile-техниками: на словах всё выглядит очень просто и легко. Как только начинаешь внедрять в практику, возникают проблемы. Написать «пользовательскую историю» или описать «персону» — задачи, требующие аналитической работы и сильной решимости отсекать всё лишнее. Если вы только пробуете внедрять Agile, но процесс ещё не устаканился, будьте осторожны. Каждое нововведение с лёгкостью может вызвать непримиримые споры и терминологические разногласия, — время будет улетать в никуда, а результат опечалит своей незначительностью.

Ещё раз — статья полезная, я верю, что применять этот подход можно и нужно. Удачи!

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

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

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