Закрыть
E-mail:
Пароль:
Забыли пароль?
В каталоге проекта: 11 599 веб-студий, 934 CMS, 226 712 сайта.
РегистрацияCMS MagazineВход
CMS Magazine CMS Magazine

Внедряем опыт взаимодействия (UX) в Backlog

Автор оригинальной идеи этой статьи — Джон Иннс, консультант в области гибких методологий IT-разработки. С первоисточником можно познакомиться здесь.

Итак, есть такая штука, как опыт пользовательского взаимодействия (тот самый UX, User Experience). В целом, UX — это впечатление пользователя от вашего продукта (например, сайта). Сюда относится внешний вид, удобство расположения кнопок, ссылок и других элементов.

Почему учитывать опыт взаимодействия — важно? Элементарно: пользователю удобно на сайте — вы получаете прибыль. Пользователь заблудился, расстроился и закрыл вкладку в браузере — соответственно, вы ничего не получаете. Просто как дважды два.

И само печальное — если налажать с UX — при разработке, то вы будете терять деньги (маркетинговый бюджет) постоянно. Лучше сразу делать «няшно, секси, мимими ;-)».

Поначалу гибкая разработка (Agile) вообще не учитывала UX. Во многом потому, что влияние UX вообще сложно как-либо измерить. Веб-дизайнеры до сегодняшнего дня стояли в сторонке и наблюдали за тем, как Scrum Master проводит стендапы с программистами. Проблема неучастия решается путем внедрения UX прямо в Backlog проекта. Заполняем табличку перед тем, как поставить задачи на дизайн:

Название колонки Возможные значения Описание
Персона Имя персоны Определяет персону, к которой применима та или иная user story.
Сложность UX от 1 до 5 Оценивает затраты дизайнера на реализацию.
История проверена Да/Нет Эта история — факт или выдумка? Основана ли она на исследованиях и статистике?
Дизайн закончен Да/Нет Соответствует ли дизайн требованиям разработчиков (техническая возможность реализации)
Рейт выполнения задачи от 0 до 100% Процент пользователей, которые завершили историю без посторонней помощи.
Обеспечение кадрами Ресурс Кто отвечает за дизайн

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

Придумываем первую персону, пусть это будет, например, «Студент Вася» (очень сильно помогает небольшое описание персоны, например, «учится на маркетолога, первый курс, любит новые гаджеты, имеет свои аккаунты в социальных сетях»).

Придумываем истории для персоны.

  1. Студент Вася хочет купить книгу, он знает только фамилию автора и то, что в книге мало страниц.
  2. Студент Вася хочет быть в курсе, когда книга N автора X появится в продаже.
  3. Студент Вася хотел бы купить сразу несколько книг и рассчитаться с помощью своего электронного кошелька.
  4. Студент Вася хочет видеть, кто из его друзей прочитал книгу.
  5. Студент Вася хочет добавлять комментарии к прочитанной книге, но не хочет авторизовываться на сайте.

Как и в традиционных Scrum-методах, UX-специалисты разбивают истории на конкретные задачи. Полученные результаты будут в последствие закреплены на канбан-доске, как и задачи по разработке и внедрены в Backlog при помощи интеграционной UX-матрицы.

Важно: персонам присваивается удельный вес. Представитель основной целевой аудитории будет иметь большее влияние (приоритет), нецелевой — соответственно, меньшее. Истории оцениваются Product Owner’ом с точки зрения влияния каждой на цели бизнеса. С учетом всего этого будут упорядочены и задачи в Backlog’e.

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


Смысл такой оценки в том, что задача исполнителям приобретает совершенно новое значение. Сравните:

  1. Раньше: «Нарисовать кнопки социальных рекомендаций под изображением товара»
  2. Теперь: «Добавить инструмент, помогающий пользователю делиться понравившимся товаром с друзьями».

На первый взгляд, одно и то же. Однако в первом случае задача — это простая декламация, «сделай это», без приведения каких-либо аргументов. Во втором — задача содержит не авторитарное указание, а цель, заставляя UX-специалистов искать решение, исходя из реальных потребностей покупателей. Юзабилити-аналитик, если таковой есть в команде, будет заниматься предварительным исследованием, направленным на повышения удобства ПО для пользователей, функциональный дизайнер — проектировать интерфейсную часть, а визуальный дизайнер — производить конечный продукт. Всё основано на пользовательском опыте, а, следовательно, — проект становится более жизнеспособным, ведь его дизайн теперь отражает не представления конкретного человека об удобстве, а основывается на опыте взаимодействия простых пользователей.

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

Автор: Джон Иннс, перевод: Владимир Завертайлов, Сибирикс

Комментарии экспертов

Асхат Уразбаев

Компания: ScrumTrek
Должность: Управляющий партнер

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

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 вы получите хоть какую-то гарантию удовлетворения своего пользователя, как принято говорить у математиков, «по построению».

Анна Обухова

Компания: Luxoft
Должность: Agile consultant/coach

У меня сложилось впечатление, что автор слегка запутался. В Скраме, канбане, 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 и его роль в процессе.

Павел Гертман

Компания: Luxoft
Должность: Юзабилити Эксперт

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

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

Юрий Гугнин

Компания: Бизнес-школа РИК
Должность: Управляющий партнер

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

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

Михаил Дубаков

Компания: Taucraft Limited
Должность: Основатель

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

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

Рекомендуем:

Комментарии (4)

Сергей Гринкевич      Создано: 16.5.2012, 21:41          

Какой примитивизм и узость мышления!

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

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

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

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

Владимир Завертайлов      Создано: 18.5.2012, 15:09          

Хм. Вот именно после таких комментариев иногда опускаются на пару минут руки.

Я расскажу историю.

Когда был только-только готов дословный и точный перевод Джон Иннса, мы (я и Анатолий Денисов) поняли, что оригинальный текст сложноват и перегружен терминами. Обилие терминов не любит никто. Их сложно воспринимать. Несколько часов у нас ушло на то, чтобы переписать и упростить текст, сохранив и сделав основную его идею — понятной и доходчивой для как как можно более широкого круга читателей. И я был практически счастлив, когда наш коллега смог прочитать текст по диагонали и понять суть идеи за пару минут wink.gif

Кстати, вот шаблон матрицы в excel-файле, на русском языке (полезное дополнение, я думаю). http://blog.sibirix.ru/wp-content/uploads/...ate-sibirix.xls

------
Так вот. Чтобы было о чем похоливарить в каментах (кроме перехода на личности и прочий "примитивизм и узость мышления" wink.gif. Я не согласен с вот этим
>> Требования к системе, будь то веб-сайт или большая система, готовятся бизнес-аналитиками. Там не место ни дизайнерам, ни программистам.

Требования к системе действительно формулирует бизнес-аналитик. Но зачастую — в общем виде. В скраме это, как правило, Product Owner (к сожалению, у Джона Иннса его роль упомянута вскользь), который рулит бэклогом.

НО! конкретное воплощение требований в элементах интерфейса для многих agile-проектов — это либо совместная итеративная работа дизайнеров и аналитика, либо решения о многих элементах интерфейса __предлагаются__ дизайнером, а затем уже аппрувятся (или не аппрувятся) Product Owner-ом. После чего проходят валидацию рынком. Или альфа-бета-тестированием. А затем корректируются вновь.

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

В таблице показано, что UX-команда состоит из 3-х специалистов (вернее из 3-х РОЛЕЙ): юзабилити-аналитика, функционального и визуального дизайнера. Первый как раз занимается формированием списка требований, но основная работа ложится на дизайнера, проектирующего функциональную часть. И очень часто он вносит свои предложения, которые затем принимаются к реализации на этапе разработки.

Это далеко не "уровня средней руки веб-студии". Это значительно круче среднего. И во многих крупных поектах эти роли так или иначе ставятся на WEB-дизайнера, иногда — целиком.

Ну например, сходу: Яндекс (на проекте Яндекс.Почта) намеренно искал и выбирал дизайнера, который бы сочетал в себе способности к проектированию интерфейса и его реализации (собственно, — воплощал UX). Даже тестовые задания на эту позицию были составлены соответствующим образом (если я не ошибаюсь — предложить интерфейс для экранов "контактов" или адресной книги).

Сергей Гринкевич      Создано: 18.5.2012, 16:09          

Извините, если затронул Ваши нежные чувства. :-)

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

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

Я же предлагаю взглянуть на задачу шире. Вначале работы над системой (сайтом, мобильным приложением, ERP, CMS, BMP и т.д.) есть бизнес заказчик с руководителем проекта. Они ставят цели и определяют рамки проекта. Дальше идет бизнес-аналитик. Он проектирует бизнес-требования, готовит ТЗ (спецификацию) в заданных рамках для достижения поставленных целей. На базе спецификации архитектор проектирует техническую реализацию системы. А проектировщик интерфейсов проектирует пользовательский интерфейс. Только потом эстафету принимает дизайнер, который из прототипа интерфейса делает вначале концепт-дизайн, а затем конечный пользовательский интерфейс.

Если у вас "средней руки студия", то у вас просто нет столько специалистов, каждый из которых должен выполнять свою отдельную роль. Вы просто вынуждены совмещать разные роли в одном специалисте. Поэтому в результате пользовательским интерфейсом занимается дизайнер. В контексте данной статьи он (дизайнер) выступает в роли и бизнес-аналитика (понимает что и как должно делаться), и в роли проектировщика (придумывает, что и как должно показываться пользователю), и в роли собственно дизайнера (придумывает так, чтобы было красиво).

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

Владимир Завертайлов      Создано: 18.5.2012, 18:12          

Сергей, пожалуйста не надо кратко-неправильно интерпритировать комментарий. wink.gif

Бизнес-требования, аналитика, прототипирование никуда не уходят при изложенном здесь подходе. Они становятся итеративными. И осознанно принимается к сведенью тот факт, что дизайн В ТОМ ЧИСЛЕ влияет и ЗНАЧИТЕЛЬНО на бизнес конечного заказчика. Именно дизайн (как стоят пиксели и какого они цвета) а не только общая схема элементов интерфейса или юзкейсы. При этом важность функциональности и юзабилити так же учитывается и контролируется.

Вот забавный кейс, http://blog.sibirix.ru/2011/06/10/%D0%BA%D...BA%D0%BE%D0%B5/ — где изменение одной картинки (дизайн) на 30% увиличило конверсию (бизнес-цели).

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


CMS Magazine CMS Magazine
RSS-подписка
CMS Magazine CMS Magazine
CMS Magazine