SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
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>
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>
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>
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>
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>
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 Спасибо за внимание! Есть вопросы?