Usability.by » Blog Archive Совместная жизнь Agile и UCD на примере реального проекта | Usability.by
Улучшаем взаимодействие пользователей с вашим сервисом Повышаем конверсию
в продажи, заявки или
звонки
Проектируем
новые
продукты
Компания 1Point осуществляет весь спектр услуг в области юзабилити, дизайна, user experience
и веб-аналитики

Совместная жизнь Agile и UCD на примере реального проекта

Первым результатом сотрудничества наших читателей стал совместный перевод статьи «Case study of agile and UCD working together». Сегодня мы публикуем этот перевод:

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

Этот реальный случай демонстрирует, как команда проектирования UX сайта ComputerWeeekly была интегрирована в группу разработки, придерживающейся гибких методологий. Важно заметить, что сами по себе методы, которые мы использовали, не гарантируют успешное завершение проекта. Люди могут как сделать, так и провалить любой проект. Найти и удержать «правильных» людей — ключ к успеху проекта.

Краткое описание

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

Совместная жизнь Agile и UCD на  примере реального проекта 1

Мы преследовали следующие цели:

  1. Сделать содержимое заметным и легким для поиска.
  2. Создать приносящий удовольствие и полезный для пользователя опыт использования системы. Такой, что пользователи затем захотят вернуться
  3. Увеличить количество показов страниц, что принесет прибыль от рекламы.
  4. Предоставить владельцам сайта возможность добавлять различный медиа-контент.
  5. Добавить на сайт индивидуальности и сделать его более интерактивным.

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

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

Связующее звено

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

Совместная жизнь Agile и UCD на  примере реального проекта 2

Чтобы связать эти команды и несопоставимые элементы вместе требуется запускающий менеджер или человек, выступающий в роли «связующего звена». Ризал Себастьян (Rizal Sebastian) писал о роли «связующего звена» в Design Issues в 2005 году. В обязанности «связующего звена» входит быть осведомленным об индивидуальных проблемах проектных команд. Человеку, выполняющему данную роль, не нужно знать детали проблемы, но необходимо знать культурный контекст среды, в которой взаимодействуют команды.

Люди уживаются друг с другом? Все ли взаимоотношения ясны и понятны? Есть ли конфликтные ситуации между членами команды? Собрать вместе разработчиков, дизайнеров интерфейса, бизнес аналитиков, SEO и юзабилити специалистов и ожидать, что они будут спокойно работать вместе — оптимистично, но маловероятно. Кроме того, такая организация требует, чтобы эти люди все свое время посветили только одному проекту, что маловероятно для большой организации, где несколько проектов поддерживаются и развиваются одновременно.

Роль «связующего звена» важнее, чем роль менеджера проекта, потому что пользователь, а не проект, сердце проблемы. Он отвечает за выпуск и постоянное развитие качества продукта. Он не просто отслеживает, соответствует ли реализуемая функциональность запланированной. Пользователь — ядро всех решений при проектировании и развитии сайта. Есть только один путь по которому вы можете гарантировать, что пользователь будет в центра разработки продукта — нанять кого либо, кто будет слушать голоса пользователей и никогда не забудет, что они говорят. Кроме того, он (человек, находящийся в роли «связующего звена») также должен гарантировать, что требования бизнеса и SEO удовлетворены и существует ясно определенная стратегия. «Связующее звено» владеет таким видением и доносит это понимание до каждого члена команды.

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

Определение процесса

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

Совместная жизнь Agile и UCD на  примере реального проекта 3

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

Сбор информации

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

Проведено 30 интервью, 20 этнографических исследований и получены 950 ответов в онлайн-исследованиях по результатам которых были созданы шесть персонажей. Учитывая проведенный аудит содержимого, описанные профили пользователей и бизнес цели мы приступили к созданию таксономии.

Аналитика

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

Совместная жизнь Agile и UCD на  примере реального проекта 4

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

Таксономия, разработанная на основе персонажей

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

Совместная жизнь Agile и UCD на  примере реального проекта 5

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

Совместная жизнь Agile и UCD на  примере реального проекта 6

Мы выделили четыре основных направления(области) исходя из нашей аудитории.

Совместная жизнь Agile и UCD на  примере реального проекта 7

Новости — основное требование для пользователей. Потребность в информации очевидна, и мы провели углубленное изучение этого вопроса. Итог: для каждой из четырёх групп, с учётом их специализации, мы должны были постоянно обновлять новости, оформлять новостную рассылку на электронные адреса, RSS-ленты.

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

Разработка интерфейса

Навигационная схема определила элементы страницы, которые пользователи могли бы использовать для перемещения между разными областями сайта. Это сделало более ясным названия объектов на странице.

Совместная жизнь Agile и UCD на  примере реального проекта 8

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

Ядро и пути

Мы использовали метод Аре Халланда (Are Halland) для проектирования информационной архитектуры «изнутри наружу».

  • Расстановка приоритетов и проектирование ядра — Помочь пользователю достичь его целей, установив приоритеты функциональных и информационных элементов.
  • Проектирование входящих в ядро путей — Следует проанализировать, как пользователи попадают на страницу: с выдачи поисковика, используя фасетную классификацию, меню, поиск, rss, эл.почту и т.д.
  • Предложение релевантных исходящих из ядра путей — Необходимо гарантировать, что как бизнес цели, так и цели пользователя достижимы посредством предоставления явных призывов к действию (call to action) и возможности выполнения задач пользователя.

Совместная жизнь Agile и UCD на  примере реального проекта 9

Для сайта CW.com мы сосредоточились на ядре для домашней (главной) страницы, домашних уровня разделов, новостных страницах и изучили ключевое содержимое: главные новости и «выбор редактора» или «лучшее с внешних ресурсов». Ключевая функциональность и сопутствующее содержимое так же должны быть включены и учтены при установке приоритетов на странице.

Совместная жизнь Agile и UCD на  примере реального проекта 10

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

Совместная жизнь Agile и UCD на  примере реального проекта 11

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

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

Совместная жизнь Agile и UCD на  примере реального проекта 12

Эти исходящие пути включают:

  • Оформление подписки на новости
  • Внутренние ссылки на связанные статьи для повышения посещаемости страниц
  • «Поделиться», напечатать или отправить по электронной почте новостные статьи
  • Ссылки на связанную информацию, такую как видео или аудио
  • Призывы к общению в форумах и блогах
  • Контекстная навигации к агрегированной информации или «выбор редакции»
  • Подписка на RSS-ленту
  • Определение приоритетов содержимого

Совместная жизнь Agile и UCD на  примере реального проекта 13

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

Цикл разработки

Макеты были переданы визуальным дизайнерам и они начали работать над проработкой интерфейса и графическими элементами. Разработчики реализовали отдельные функциональные элементы на старом сайте, до смены дизайна.

Совместная жизнь Agile и UCD на  примере реального проекта 14

Эти гибкие методы позволили на старом сайте почувствовать выгоды от новых функциональных возможностей. Однако, так как сайт изменился радикально в новом дизайне, а мы до сих пор еще должны были выпустить сайт в старом стиле «большого взрыва». В этом, пожалуй, была проблема создаваемая гибкой методологией разработки при запуске новых продуктов. Гибкие методологии сосредоточены на множестве малых изменений и хорошо работают при реализации дополнительных изменений, но не при запуске полностью нового сайта.

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

Совместная жизнь Agile и UCD на  примере реального проекта 15

Целостное решение

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

Совместная жизнь Agile и UCD на  примере реального проекта 16

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

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

——————————————————————————-
Оригинал (английский): Case study of agile and UCD working together

Перевод: © Наталья Харзу, anor, SvetlanaTsikoza, Vetragon, rbugaev, raketablog, Павел Коноплицкий

translated.by переведено толпой

Twitter Facebook Google Buzz Вконтакте МойМир Google Bookmarks delicious Memori.ru БобрДобр.ru Mister Wong Technorati МоёМесто.ru I.ua


5 комментариев

  1. Ishitori:

    Интересно, но в итоге, имхо, все-равно получилось не очень хорошо. Лично меня большое количество блоков разнородной информации вгоняет в тоску, потому что глаза разбегаются.

    Но все стало «по уму» :)

  2. Paul Indx:

    Но вы же учтите что это 2007 год :)

  3. А что в 2007 году не знали особенностей человеческой памяти и восприятия информации?

Комментировать