1.
Я рослав Перевалов Экстремальные юзабилити-методы

2.
<ul><li>Юзабилити-проектирование: жизненный цикл </li></ul><ul><li>Экспресс-аналитика </li></ul><ul><li>Экспресс-экспертиза </li></ul><ul><li>Коридорное юзабилити-тестирование </li></ul>П лан

3.
П роцесс юзабилити-проектирования ( classic ) 1 человеко-месяц 1 человеко-месяц 1 человеко-месяц 1/4 человеко-месяц 1 человеко-месяц 1 /2 человеко-месяц 1 человеко-месяц 1 человеко-месяц

4.
П очему человечки красные и бегут? Вам отвечает Стив Круг:

5.
П роцесс юзабилити-проектирования

6.
М аркетологический анализ продукта <ul><li>Выполняется маркетологом, который ищет ответы на вопросы: </li></ul><ul><li>Каков облик будущего продукта? </li></ul><ul><li>Какое место займёт на рынке (в ряду конкурентов)? </li></ul><ul><li>Почему он будет востребован? </li></ul><ul><li>Каковы ключевые конкурентные преимущества продукта? Слабые и сильные стороны конкурентов/аналогов/прототипов </li></ul><ul><li>Почему его захотят? </li></ul><ul><li>Какая от него польза? </li></ul><ul><li>Какая от него выгода пользователям? </li></ul><ul><li>Какая от него выгода компании? </li></ul><ul><li>Сколько людей его захотят? </li></ul><ul><li>Сколько людей станут им пользоваться? </li></ul><ul><li>Какие эмоции/ощущения/переживания при использовании этого продукта будут испытывать? </li></ul><ul><li>Каковы ключевые потребительские свойства продукта? </li></ul><ul><li>Какой продукт мы будем считать успешным? </li></ul><ul><li>Какой продукт мы будем считать качественным? </li></ul><ul><li>Как это всё посчитать/измерить? </li></ul><ul><li>Как мы будем продвигать/производить/продавать/поддерживать/совершенствовать продукт? </li></ul>

7.
П роцесс юзабилити-проектирования

8.
Ч то такое бизнес-требования и зачем их надо собирать и анализировать? <ul><li>Бизнес-требования – это описание стратегических факторов, условий, ограничений и критериев развития проекта . </li></ul><ul><ul><li>Выполняется бизнес-аналитиком , который формализует: </li></ul></ul><ul><ul><li>Цели и задачи компании-заказчика при реализации продукта </li></ul></ul><ul><ul><li>Бизнес-модели (механизмы реализации задач) </li></ul></ul><ul><ul><li>Модели пользователей (внутренние и/или внешние) </li></ul></ul><ul><ul><li>Архитектурная концепция </li></ul></ul><ul><ul><li>Описание основных маркетинговых характеристик продукта (рынок, преимущества, ценность, уникальность и т.п.) </li></ul></ul><ul><ul><li>Описание ключевых критериев оценки качества и успеха продукта (не только внутренние, но и внешние, такие как потребительские свойства продукта) </li></ul></ul>

9.
Ц ели сбора и анализа бизнес-требований <ul><ul><li>Получение единой и однозначной концепции развития продукта </li></ul></ul><ul><ul><li>Ознакомление и согласование концепции со всеми ключевыми фигурами проекта (заказчики, идеологи, разработчики, бизнес-эксперты и пр.) </li></ul></ul><ul><ul><li>Применение полученных данных в качестве основы для принятия проектных решений и учёт описанных факторов при проектировании взаимодействия. </li></ul></ul>

10.
В иды работ (бизнес-анализ) <ul><li>Работы, выполняемые в ходе сбора и анализа бизнес-требований (все пункты опциональные): </li></ul><ul><li>Сбор: </li></ul><ul><ul><li>Структурированные интервью с бизнес-экспертами </li></ul></ul><ul><ul><li>Полевые исследования </li></ul></ul><ul><ul><li>Маркетинговые исследования </li></ul></ul><ul><ul><li>Анализ потребностей пользователей, характер их взаимодействия с продуктом </li></ul></ul><ul><li>Формализация: </li></ul><ul><ul><li>Описание бизнес-процессов </li></ul></ul><ul><ul><li>Описание модели данных </li></ul></ul><ul><ul><li>Описание моделей пользователей (цели, задачи, сценарии взаимодействия) </li></ul></ul><ul><ul><li>Высокоуровневое описание архитектурных решений </li></ul></ul>

11.
П роцесс юзабилити-проектирования

12.
П олевые исследования,моделирование пользователей <ul><li>Изучение и формализация характера взаимодействия пользователей с продуктом. </li></ul><ul><li>Выполняется специалистом по полевым исследованиям (экзопсихолог, инженерный психолог, психолог-этнограф и т.п.) </li></ul><ul><li>Методы: </li></ul><ul><ul><li>Наблюдения </li></ul></ul><ul><ul><li>Интервью с пользователями и экспертами </li></ul></ul><ul><ul><li>Анкетирования, опросы </li></ul></ul><ul><ul><li>Фокус-группы </li></ul></ul><ul><ul><li>Эксперименты (моделирование ситуаций, испытания) </li></ul></ul><ul><li>Методологии моделирования: </li></ul><ul><ul><li>Персоны </li></ul></ul><ul><ul><li>Ролевые модели (юзкейсы) </li></ul></ul><ul><ul><li>Базовые сценарии взаимодействия </li></ul></ul><ul><ul><li>Юзер-сториес </li></ul></ul>

13.
Э кстремальная аналитка: карточка продукта <ul><li>Принципы: </li></ul><ul><li>Карточка продукта заполняется на этапе анализа и сбора требований для фиксации бизнес-требований к проекту </li></ul><ul><li>Все требования и описания карточки должны быть согласованы с ключевыми идеологами продукта (маркетинг / менеджмент / разработка). </li></ul><ul><li>Рекомендуется любую проектировочную деятельность начинать с заполнения такой карточки. </li></ul><ul><li>Карточка фактически является элементом ТЗ на проектирование интерфейса. </li></ul><ul><li>Без систематизации и утверждения концептуальных и стратегических положений, изложенных в карточке, бессмысленно что-либо проектировать. </li></ul><ul><li>Ограничения и условия применения: </li></ul><ul><li>В команде нет выделенного аналитика, маркетолога, полевика </li></ul>Подробности тут: http://usability.ru/Articles/Cheap-BA.html

14.
К арточка продукта: копилка исходных знаний <ul><li>Общее короткое описание проекта </li></ul><ul><li>Цели проекта </li></ul><ul><li>Бизнес-модель (зачем продукт нужен компании) </li></ul><ul><li>Описание целевой аудитории сервиса и контекста использования продукта </li></ul><ul><li>Модели пользователей (цели, мотивация, задачи, сценарии…) </li></ul><ul><li>Основные, стратегические направления развития продукта </li></ul><ul><li>KPI – критерии успешности и качества продукта </li></ul><ul><li>Конкуренты (сильные и слабые стороны) </li></ul><ul><li>Сильные стороны, конкурентные преимущества нового продукта </li></ul><ul><li>Дополнительные требования к продукту </li></ul><ul><li>Текущие интерфейсные решения, их недостатки </li></ul>

15.
К арточка продукта: плюсы и минусы <ul><li>Плюсы: </li></ul><ul><li>Важные, ключевые требования к продукту фиксируются на бумаге, согласуются с заказчиком и доводятся до всех членов команды (инструмент согласования и информирования) </li></ul><ul><li>Внятное ТЗ для проектировщика интерфейсов (сокращает количество циклов проектирования) </li></ul><ul><li>Обнажает бреши в аналитике, заставляет думать в нужных направлениях и добывать информацию </li></ul><ul><li>Дёшево, быстро, масштабируемо </li></ul><ul><li>Минусы: </li></ul><ul><li>Требования в карточке могут быть «неправильными»: неправильно собранными или неправильно оформленными, не подкреплёнными результатами исследований </li></ul><ul><li>Наличие карточки может создавать иллюзию, что аналитика не нужна </li></ul>

16.
П роцесс юзабилити-проектирования

17.
Ю забилити-экспертиза <ul><li>Юзабилити-экспертиза (эргономичекая экспертиза, ю-экспертиза , ю-аудит) – один из методов анализа и оценки пользовательского интерфейса. </li></ul><ul><li>Выполняется экспертом . </li></ul><ul><li>Цели ю-экспертизы: </li></ul><ul><ul><li>Получение качественной оценки юзабилити-характеристик системы </li></ul></ul><ul><ul><li>Получение перечня эргономических проблем системы и рекомендаций по их устранению </li></ul></ul><ul><li>Работы, выполняемые в ходе ю-экспертизы: </li></ul><ul><ul><li>Экспертная оценка ключевых юзабилити-характеристик продукта </li></ul></ul><ul><ul><li>Анализ существующего продукта на предмет наличия недостатков и проблем уровня: </li></ul></ul><ul><ul><ul><li>Информационной архитектуры (ИА) </li></ul></ul></ul><ul><ul><ul><li>Пользовательского интерфейса и взаимодействия (ПИ) </li></ul></ul></ul><ul><ul><ul><li>Графического оформления, дизайна и вёрстки (ДВ) </li></ul></ul></ul><ul><ul><li>Ранжирование недостатков и проблем (по важности, сложности, и т.п.), количественный анализ замечаний . </li></ul></ul><ul><ul><li>Пример: Отчёт по экспертизе МЯК образца 2008 г </li></ul></ul>

18.
Э кспресс-экспертиза: ещё быстрее и дешевле? <ul><li>Упрощённый отчёт: указываются только проблемные, сомнительные места в интерфейсе, без чёткого ранжирования и, возможно, без рекомендаций по улучшению </li></ul><ul><li>Исследование продукта не глубокое и не системное: экспертиза тех макетов, что есть. </li></ul><ul><li>Для повышения достоверности увеличивается количество экспертов </li></ul><ul><li>Требования к профессионализму экспертов – невысокие </li></ul><ul><li>Условия и ограничения: </li></ul><ul><li>У команды нет выделенного эксперта </li></ul><ul><li>Есть задача получить быструю-качественную оценку интерфейсным решениям </li></ul>

19.
Э кспресс-экспертиза: пример

20.
Э кспресс-экспертиза: плюсы и минусы <ul><li>Плюсы: </li></ul><ul><li>Получение быстрой-дешёвой оценки </li></ul><ul><li>Получение свежих идей от незамутнённых экспертов </li></ul><ul><li>Минусы: </li></ul><ul><li>Кредит доверия к экспертам низкий </li></ul><ul><li>Как сделать лучше, не совсем ясно </li></ul>

21.
П роцесс юзабилити-проектирования

22.
Д етальное проектирование интерфейса <ul><li>Выполняется проектировщиком : </li></ul><ul><li>Много, очень много версий детальных прототипов </li></ul><ul><li>Согласование прототипов с командой проекта (поиск компромиссов) </li></ul><ul><li>Проверка прототипов на реальных/потенциальных пользователях и экспертах. </li></ul><ul><li>Специфицирование утверждённых прототипов: описание поведения интерфейсных элементов, описание форматов полей и сообщений. </li></ul>

23.
К оридорное тестирование <ul><li>Принципы, условия, ограничения: </li></ul><ul><li>Выполняется в рамках быстрого прототипирования </li></ul><ul><li>Важное условие: наличие потенциальных респондентов внутри компании </li></ul><ul><li>Планирование: описание цели исследования, требования к респондентам, сценарии/контекст применения, задания. </li></ul><ul><li>Протоколы: только бумажные: утром в куплете, вечером – в газете. Команда не отвлекается на наблюдение, только на чтение кратких протоколов. </li></ul><ul><li>Задания: направлены на применение конкретного интерфейсного решения </li></ul><ul><li>Сессия тестирования: 10-20 минут </li></ul><ul><li>~10 пользователей в эксперименте </li></ul><ul><li>Оперативные выводы с рекомендациями по улучшению интерфейса </li></ul><ul><li>2 человеко-дня на всё </li></ul>

24.
К оридорное тестирование: плюсы-минусы <ul><li>Плюсы: </li></ul><ul><li>Помогает обоснованно принимать интерфейсные решения и быстро-дёшево получать экспериментальную оценку. </li></ul><ul><li>Минусы: </li></ul><ul><li>Не заменяет итоговое юзабилити-тестирование (или всё-таки заменяет?) </li></ul><ul><li>Примеры: </li></ul><ul><li>Большие карты: коридорное ю-тестирование нового интерфейса панорам улиц </li></ul><ul><li>Мобильные карты: коридорное юзабилити-тестирование сценариев прокладки маршрутов на Андроиде </li></ul><ul><li>Большие карты: исследование по сравнению наборов иконок </li></ul>

25.
К оридорное тестирование: ещё дешевле? <ul><li>Литература: </li></ul><ul><li>Стив Круг. Не заставляйте меня думать! Глава «Юзабилити-тестирование за 10 центов в день» </li></ul>

26.
Д ополнительный хинт <ul><li>– Поместить юзабилити-специалиста внутрь разработки: </li></ul><ul><ul><li>Сокращаются итерации во взаимодействиях между проектировщиком и разработчиком </li></ul></ul><ul><ul><li>Проектировщик становится членом команды </li></ul></ul><ul><ul><li>Повышается доверие к решениям </li></ul></ul>

27.
Я рослав Перевалов эксперт по проектированию пользовательских интерфейсов yarik @yandex-team.ru Спасибо за внимание! Есть вопросы?