Человеко-ориентированное проектирование (Human Centered Design, HCD)
— подход к разработке различных продуктов и систем, который на первое место ставит пользователя с его целями, задачами, ограничениями и контекстом работы. Формальное описание HCD дано в стандарте ISO 9241-210 (на русском языке это ГОСТ Р ИСО 9241-210ー2012):
Стандарт описывает, как использовать HCD для создания «компьютеризированных интерактивных систем». Примеры таких систем — интернет-сайты, компьютерные программы и мобильные приложения, интерфейсы банкоматов и терминалов самообслуживания, а также сами устройства (компьютеры, телефоны, банкоматы и т.п.). Однако на самом деле сфера применения HCD гораздо шире, чем указано в стандарте. HCD подходит для создания практически любых продуктов, сервисов или услуг.
Этапы HCD
Этапы человеко-ориентированного проектирования (на основе ГОСТ Р ИСО 9241-210—2012)
Процесс HCD состоит из пяти этапов, причем этапы 2-5 составляют цикл:
- Планирование процесса человеко-ориентированного проектирования: выбор команды проекта и активностей, которые будут происходить на каждом этапе.
- Понимание и определение условий использования: сбор информации о целях, задачах, ограничениях и контексте работы пользователей.
- Определение требований пользователей: обобщение полученной на предыдущем этапе информации и формулировка пользовательских требований к продукту.
- Разработка проектных решений, соответствующих требованиям пользователей: создание макетов, прототипов и различных версий дизайна в соответствии с пользовательскими требованиями.
- Оценка соответствия проекта установленным требованиям: оценка созданных решений силами экспертов или с привлечением реальных пользователей. Если оценка обнаруживает какие-либо проблемы, то пользовательские требования необходимо уточнить и доработать макет, прототип или дизайн продукта в соответствии с новыми данными.
Реализация процесса HCD в USABILITYLAB
Стандарт ГОСТ Р ИСО 9241-210 ставит в центр процесса разработки пользовательские требования. Однако концентрация исключительно на пользователях может привести к тому, что продукт окажется невыгодным для бизнеса или трудно реализуемым с технической точки зрения. Поэтому для создания успешного продукта надо учитывать также бизнес-требования и техническую составляющую.
Если продукт создается внутренними силами, то у разработчиков, скорее всего, есть BRD (business requirements document или другие подобные документы) и представление о возможностях выбранной технической платформы. В таком случае необходимость в полномасштабном исследовании потребностей бизнеса может и не возникнуть.
Однако USABILITYLAB — аутсорсинговая компания, изначально мы не знаем особенностей бизнеса и внутренних процессов заказчика. Поэтому перед началом проекта нам необходимо познакомиться с командой заказчика, четко определить бизнес-цели продукта и понять, с какими техническими, юридическими и другими ограничениями мы можем столкнуться в ходе работы. Поэтому HCD выглядит в нашей компании следующим образом:
1. Сбор информации о проекте и планирование процесса
Еще до заключения договора наши менеджеры собирают основную информацию о продукте и о целях, которые хочет достигнуть заказчик, обратившись к нам. Опираясь на полученные знания, они составляют план проекта и выбирают методы работы на каждом этапе.
После начала проекта наши аналитики проводят интервью с представителями команды заказчика. Чтобы получить разностороннюю картину, мы стремимся опросить сотрудников из разных областей деятельности: руководителей, разработчиков, маркетологов, сотрудников технической поддержки и т.п. Результаты интервью мы фиксируем в отдельном документе, где описываем то, как со слов заказчика мы поняли:
- cпецифику продукта;
- цели и задачи проекта;
- технические, законодательные, идеологические и другие ограничения.
Также на этом этапе нередко оказывается, что видение проекта среди разных представителей заказчика немного отличается. Все найденные противоречия мы обязательно указываем в отчете и просим заказчика разрешить их до того, как мы приступим к дальнейшей работе.
2. Понимание и определение условий использования
Получив представление о продукте, мы начинаем изучать его пользователей. В зависимости от специфики проекта, это делается разными методами. Вот некоторые из них:
- Наблюдение: Обычно мы используем полевое наблюдение для изучения пользователей сложных внутрикорпоративных систем. Наши сотрудники приезжают на рабочее место пользователя и наблюдают за тем, как он решает свои рабочие задачи при помощи данной системы, или, если система еще не разработана, — ее аналогов.
- Дневниковое исследование: Мы просим пользователей на протяжении нескольких дней записывать в специальный протокол то, как они решают определенную (связанную с бизнес-целями проекта) задачу. Это дает возможность глубоко изучить контекст и мотивацию использования продукта.
- Карточная сортировка: Обычно используется при работе с интранетами, крупными интернет-сайтами и другими системами со сложной и разветвленной структурой. Мы готовим карточки с названиями разделов меню и просим пользователей сгруппировать их. Это необходимо для того, чтобы оценить, насколько структура существующей системы понятна для пользователей и при необходимости разработать новую.
- Интервью: Мы задаем представителям целевой аудитории (обычно это 8-12 человек) специально подобранные вопросы об их работе с продуктом. Как правильно, именно этот метод оказывается оптимальным для большинства проектов. Не претендуя на репрезентативность полученных ответов, он все же дает полезную информацию о целях, задачах, страхах и ограничениях пользователей.
- Онлайн-опрос: Мы создаем опросник и привлекаем пользователей к его заполнению, либо размещая его на заранее согласованных с заказчиком площадках в интернете, либо рассылая его подходящим к требованиям исследования респондентам. Обычно в опросе принимает участие 300-1000 человек. Как правило, мы используем опрос в сочетании с интервью. Опрос помогает выделить основные типажи пользователей, а интервью — уточнить и дополнить полученную информацию.
- Юзабилити-тестирование: В строгом смысле слова юзабилити-тестирование является методом оценки и должно применяться на пятом этапе. Однако на этапе исследования пользователей, особенно в сочетании с интервью или наблюдением, юзабилити-тестирование дает много ценной информации о том, с какими проблемами пользователи сталкиваются при работе с существующей системой.
3. Определение требований пользователей
Всю полученную на предыдущем этапе информацию мы обобщаем и составляем портреты типичных пользователей продукта (так называемые «персонажи»). «Персонаж» олицетворяет группу пользователей, объединенную характерными целями, задачами, потребностями, страхами и т.п. Главная функция персонажей — облегчить принятие и обсуждение принимаемых в ходе проекта решений. Гораздо удобнее говорить о потребностях некой Наташи (27 лет, администратор в салоне красоты, из-за нарощенных ногтей медленно печатает, из-за любых всплывающих диалоговых окон вызывает системного администратора, не читая их), чем о «группе женщин 25-35 лет, работают в сфере услуг, заботятся о внешности, компьютерная грамотность ниже среднего».
Для каждого персонажа мы описываем один-два сценария работы с системой. Опираясь на сценарии, мы составляем список пользовательских требований к интерфейсу. Далее мы дополняем этот список требованиями заказчика, зафиксированными в начале проекта, и передаем полученный документ проектировщикам.
4. Разработка проектных решений, соответствующих требованиям пользователей
Результатом предыдущего этапа является документ, где описаны ключевые сценарии использования продукта и требования к интерфейсу как со стороны пользователей, так и со стороны заказчика. Опираясь на этот документ, мы приступаем к проектированию.
Обычно проектирование проходит в две стадии. Сперва мы создаем макеты низкой детализации. Это нужно для того, чтобы быстро визуализировать наши главные идеи и обсудить их с заказчиком.
Пример прототипа низкой детализации. Основные блоки на странице обозначены прямоугольниками, количество текстов и надписей минимально.
На втором этапе макет обрастает деталями, а при необходимости, например, чтобы на следующем этапе оценить его удобство при помощи юзабилити-тестирования, мы добавляем в него интерактивность.
Пример прототипа высокой детализации. Добавлены тексты, гиперссылки и другие элементы интерфейса.
Подробнее о процессе проектирования можно прочитать в отдельной статье на нашем сайте.
Теперь необходимо оценить, насколько макеты соответствуют сформулированным на предыдущем этапе требованиям.
5. Оценка соответствия проекта установленным требованиям
Самый лучший способ оценить, насколько полученный прототип соответствует пользовательским требованиям — провести юзабилити-тестирование. Для этого мы приглашаем в нашу лабораторию представителей целевой аудитории продукта (обычно это 5-8 человек) и просим их выполнить при помощи прототипа специально подобранные задания, связанные с ключевыми сценариями использования продукта.
Юзабилити-лаборатория (вид из комнаты модератора)
Также в процессе тестирования мы можем проверить, насколько выполняются некоторые заданные заказчиком KPI (ключевые показатели эффективности), например, выполнение определенного действия за определенное количество шагов.
Если юзабилити-тестирование выявляет какие-либо проблемы, то мы возвращаемся на шаг 4 и корректируем макеты.
Иногда бывает, что сроки или бюджет проекта ограничены настолько, что провести тестирование невозможно. В таком случае макеты оценивает один из наших ведущих специалистов. Из-за того, что в оценке не участвуют реальные пользователи, повышается риск упустить некоторые проблемы, однако самые главные из них этот метод все же позволяет обнаружить.
Оценив и скорректировав макеты, мы подробно описываем их и передаем заказчику.
6. Консультации и поддержка разработчиков на этапе внедрения
У дизайнеров и разработчиков, занимающихся воплощением наших макетов в жизнь, могут возникнуть уточняющие вопросы о пользовательских сценариях или желание внести в макеты некоторые изменения. Поэтому мы предлагаем своим заказчикам услугу авторского надзора. В рамках этой услуги наши специалисты проводят консультации для занимающихся внедрением прототипов сотрудников заказчика. За счет этого можно гарантировать, что разработанные нами интерфейсы будут реализованы максимально адекватным образом.
Зачем строить проект по методологии HCD
Соблюдение методологии HCD позволяет построить продукт, соответствующий требованиям пользователей. Такой продукт будет успешно продаваться, потому что пользователи будут предпочитать его менее удобным для них конкурентам. Конечно, есть факторы, которые могут вынудить пользователей работать с самыми бесчеловечными интерфейсами: цена, законодательные ограничения, служебные инструкции и т.п. Однако в условиях свободного рынка наиболее успешным будет тот, кто лучше сможет удовлетворить потребности своей целевой аудитории. Кажется, что соблюдение методологии HCD излишне усложняет проект: нужно искать пользователей, собирать с них требования, согласовывать действия юзабилити-специалистов и разработчиков. Однако на самом деле, и это неоднократно подтверждается зарубежными исследованиями, при правильной организации HCD позволяет существенно сократить сроки и бюджет проекта. Это происходит за счет того, что:
- вся команда, работающая над проектом, видит единый список пользовательских требований — снижаются временные затраты на взаимодействие внутри команды и уточнение различных вопросов;
- прототипы, в отличие от текстового документа, позволяют точно определить сроки и сложность реализации пользовательских требований;
- обратная связь от пользователей, полученная на ранних этапах проекта, позволяет исправить недочеты, которые в дальнейшем исправить будет гораздо сложнее (добавить недостающие функции, изменить элементы интерфейса, изменить структуру приложения и т.п.).
Правильная организация процесса подразумевает, что все активности, предполагаемые методологией HCD, будут заложены в план проекта еще до его начала, а специалисты по HCD станут полноценными участниками проекта. Бессмысленно собирать требования пользователей и пытаться построить цикл HCD, если разработка уже идет полным ходом, а план работ расписан на год вперед.
Наконец, стандарт ГОСТ Р ИСО 9241-210 указывает, что HCD несет также и социальную функцию, поскольку позволяет улучшить благополучие пользователей, в том числе людей с ограниченными возможностями.
Применяется в Проектировании интерфейсов
