Создание UX команды. Какие есть варианты?

66 вебинар UX RussiaДмитрий Сатин и Андрей Сикорский

18 марта 2010 года

Зачем и когда нужна команда. Кто созрел?

• Стадии Ю-зрелости (Нильсен):1. Враждебность к юзабилити;2. Юзабилити, поддерживаемая

программистами;3. Изолированный отдел

юзабилити;4. Выделенный бюджет под

юзабилити;5. Управляемая юзабилити;6. Систематические юзабилити

процессы;7. Интегрированный UCD;8. Компания, ориентированная на

пользователей.

Модели внедрения UX

Модели UX-команды

1. Централизованное финансирование;

2. Клиентское финансирование;

3. Распределенная модель;4. Модель «внутреннего

консультанта».

Централизованное финансирование

• Команда получает большие бюджеты от единой организации.

Клиентское финансирование

• Бизнес-подразделения выделяют средства центральному UX-департаменту.

• Он управляет UX-командами и предоставляет ресурсы продуктовым командам.

Распределенная модель

• Вместо одной существуют несколько UX-групп.

• Они отчитываются напрямую продуктовым отделениям.

• Работают исключительно над продуктами этих отделений.

Модель «внутреннего консультанта»

• Высокопрофессиональная команда разноплановых экспертов предоставляет UX-поддержку только для тщательно отобранных продуктов.

Сила и Слабость, Опасности и Возможности

От теории к практике(по результатам CHI’07)

Идеальные модели в реальном мире• Модель 1– Полностью централизованная

• Финансирование и управление сосредоточены в одном месте.

• Модель 2– Гибридная с центральной UX-группой

• Финансирование централизовано, а UX-группа отвечает за все направления развития UX в компании, и предоставляет свои ресурсы продуктовым командам.

• Модель 3– Гибридная модель с распределением

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

☞

$$

$

$

☞$

☞

Модель 1: Сила и Слабость• Сильные стороны

– Широкий спектр навыков;– Карьерный рост;– Целевое использование

людей;– Много разных проектов;– Обмен опытом и

снижение рисков потери компетенций;

– Независимость отдела;– Фасилитация процессов;– Большая роль в

разработке.

• Слабые стороны– Отделённость UX от других

отделов, долгая обратная связь;

– Рассинхронизация по бизнес-целям с разработкой;

– Возможна потеря гибкости;– Конфликты с разработкой;– Несовпадение культуры или

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

$

☞

Модель 1: Опасности и Возможности• Опасности

– Финансирование может попасть под сокращение;

– Бизнес-единицы могут начать игнорировать UX;

– UX-ресурсы «на местах» могут оторваться от основной группы;

– Бизнес-единицы могут нанимать сторонние команды, создавая конкуренцию;

– Возможная текучка кадров.

• Возможности– Стабильное финансирование

на рост и развитие;– Большая заметность;– Проектирование может стать

частью корпоративной культуры;

– Обмен опытом на разных проектах;

– Рост роли и голоса в процессах компании (вплоть до вице-президентов).

$

☞

Модель 2: Сила и Слабость• Сильные стороны

– Более «быстрый» UX;– Большее доверие «на

местах»;– Глубокое знание

предметной области;– Централизованное

финансирование «тяжелых» задач (исследования);

– Более тесная интеграция «на местах».

• Слабые стороны– Большая разобщенность

между UX-командами из-за разделений по работе;

– Усложненная коммуникация между центральной группой и командами «на местах»;

– UX должен иметь «героев» на местах – для убеждения в важности и необходимости;

– Сложности с оценкой производительности из-за двойного подчинения.

$

☞

Модель 2: Опасности и Возможности• Опасности

– Может вызвать настроение «мы против них» у центральной группы и команды «на местах»;

– Непропорциональное финансирование может все испортить;

– Модель неустойчива к политическим манипуляциям;

– Размывание компетенций.

• Возможности– Упрощенная иерархия

позволяет производить более быстрые изменения;

– Централизованные стандарты позволяют контролировать приоритеты;

– Четкая видимость карьерной лестницы;

– Делает возможной инновацию «на местах».

$

☞

Модель 3: Сила и Слабость• Сильные стороны

– Наибольшая гибкость (из-за интеграции с командами разработки);

– Лучшее понимание «на местах»;

– Нет конкуренции за UX-ресурсы;

– Прозрачные компромиссы между UX и разработкой;

– UX «под продукт»;– Эффективность работы

напрямую завязана на успехе продукта.

• Слабые стороны– Много решений принимается

непосредственно разработкой, а не UX;

– Нецелевое использование компетенций (в не-UX работах);

– Тяжело перемещать специалистов между проектами;

– Снижение удовлетворенности специалистов от работы;

– Нет видимости карьерной лестницы.

☞

$$

$

Модель 3. Опасности и Возможности• Опасности

– Меньшее стратегическое влияние;

– Игнорирование мнения локальной группы UX;

– Тяжело устанавливать стандарты;

– Возможное уменьшение финансирования центральной группы;

– Снижение эффективности из-за дисбаланса финансирования;

– Разделение на «мы» и «они».

• Возможности– Гибкость и открытость к

экспериментам;– Тесная коммуникация и

совместная работа между продуктовыми командами может привести к инновации;

– Дополнительное финансирование на уровне проектов;

– Скорость принятия решений на уровне продуктовых команд – сокращение time-to-market. ☞

$$

$

Выбор подхода

Как выбрать подход?

• Есть ли что-то общее между внутренними заказчиками?• Какие требования к формату результатов работы?• Какие методики будут использоваться в работе?• Какие навыки и компетенции есть сейчас и какие

планируется развивать/приобретать?• Каково текущее и будущее позиционирование

команды?• Какие инструменты необходимо создать и

поддерживать в рамках работы (стандарты, библиотеки паттернов и т.п.)?

• Как можно узнать, что проделанная работа была эффективна?

• Что является критерием успеха UX команды?

Бизнес-план улучшения продукта

• Начинать следует с демонстрации– Сначала – результат, а не команда.

• Заручиться доверием топ-менеджмента– Подготовить кейс;– Просчитать ожидаемое количественное и

качественное изменение для организации;– Определить последовательность шагов,

приближающих организацию к желаемому уровню.

Подбор команды

• Команда покрывать все UX-компетенции:– Исследования– Тестирование– Проектирование взаимодействия– Информационная архитектура– Графический дизайн

• Целостный подход – распределенный сбор информации и базы знаний (руководства, паттерны и т.п.)– Формирование общих стандартов внутри команд(ы);– Возможно – выделение лидера, ответственного за этот

процесс.

Внедрение практик

• Итеративное продвижение– Начальная команда – небольшие распределенные

ресурсы;– Разработка стандартов, процессов, шаблонов (по

необходимости);– Постепенное масштабирование:

• В те части организации, где наблюдается недостаток UX;• Доказывать и демонстрировать на основе целевого business

case.

– Всегда помнить о необходимости выделить время на исследование и итерации при проектировании.

Спасибо за внимание