Делаем сплав гибкой разработки и User Experience (UX)

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

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

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

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

Поначалу гибкая разработка (Agile) вообще не учитывала UX. И неудивительно — ведь пионеры Agile работали над собственными ИТ-проектами (специальное ПО) или писали корпоративное программное обеспечение. Учитывать привычки пользователей? Каких еще, простите, пользователей?

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

Назначение UX-матрицы — решить эти проблемы путем связывания Project Backlog и UX. Сначала заполняем вот такую табличку — данные понадобятся для построения матрицы в будущем:

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

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

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

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

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

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

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

Итогом нашей работы должна стать вот такая матрица:

«История выполнена самостоятельно»- какой процент испытуемых пользователей смог завершить историю без посторонней помощи.

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

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

На первый взгляд, одно и то же. Однако в первом случае задача — это простая декламация, «сделай это», без приведения каких-либо аргументов.

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

Далее — проект уйдет в разработку, программисты по всем правилам Agile оценят реализацию (к слову, в качестве инструмента оценки рекомендуется Planning Poker) и, в конце концов, — увидит свет в лице пользователей.

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

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

ЗЫ. Тем, кто любит Agile так же, как мы, в подарок достается бонус — та самая матрица в excel-файле: docs.google.com/a/sibirix.ru/spreadsheet/ccc?key=0AmFQKnqjkGFKdHhpY0dJYldQTS16M3Q1OEIyQ1lYdFE#gid=0.

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

Автор: zevvssibirix