ISO 9241-210. Планирование и внедрение Human-Centered Design

Из опроса в конце предыдущей статьи я узнал, что читателям интересны все три из предложенных аспектов Human-Centered Design (далее — HCD):

• Стандарты,
• Методология,
• Внедрение.

В этой статье я расскажу, как использовать стандарт ISO 9241-210 для планирования и внедрения HCD-подхода. Также я покажу как HCD может дополнить две наиболее часто используемые модели разработки: Scrum и Waterfall.

Стандарт ISO 9241-210

Если вы спросите специалиста Human-Centered Design об основных этапах в рамках HCD, скорее всего нарисует примерно такую картинку:


Данная схема является краеугольным камнем стандарта ISO 9241-210. Он описывает этапы проектирования интерактивной системы в рамках HCD.

Прежде чем разбираться с каждым из этапов, давайте остановимся на принципах HCD, описываемых в стандарте.

Принципы HCD

Стандарт ISO 9241-210 описывает 6 принципов, которые следует учитывать при создании продукта в рамках HCD:

1. Проектирование должно быть основано на точном определении пользователей, их задач и среды. То есть нам надо знать, кто наши пользователи, какие задачи они будут решать и в каких условиях. Также здесь следует обратить внимание на фразу «основано на точном определении». Под этим понимается, что в рамках HCD, проектирование выполняется ни исходя из предположений отделов маркетинга или дизайна, а на основе данных полученных в результате исследований. О том, какие бывают типы исследований, и как их проводить, я расскажу в одной из следующих статей;
2. Пользователи должны быть вовлечены в проектирование и разработку. Вовлечение пользователей в процесс разработки позволяет получить необходимую информацию о контексте использования, задачах и о том, насколько продукт будет принят пользователями после релиза;
3. Проектирование должно быть основано на обратной связи от пользователей. Тем самым мы минимизируем риски того, что будущий продукт не будет соответствовать требованиям пользователей и/или организаций;
4. Процесс должен быть итеративным. Не возможно заранее предсказать, какие из дизайнерских решений окажутся наиболее адекватными. Соответственно, такие итерации должны быть заложены как в календарный план проект, так и в бюджет;
5. Чуть больше чем просто Usability. В оригинале это звучит как «The design addresses the whole user experience». В ГОСТе это переведено, как «учет опыта пользователей», что, на мой взгляд, искажает значение фразы. Смысл в том, чтобы ориентироваться не только на простоту использования, но учитывать также такие аспекты, как удовлетворенность работой, отсутствие монотонности и т.д. Если кто-то сумеет предложить подходящий русский аналог для данного принципа, с удовольствием включу его в статью;
6. Команда должна быть мультидисциплинарной. Теоретически здесь все просто — чем шире общий кругозор у команды-разработчика, тем больше аспектов HCD будет учтено. На практике следует иметь в виду, что у представителей различных профессий могут быть различные походы к решению одних и тех же задач, и разные системы ценностей (например, что важнее функционал или дизайн). Соответственно возможность таких разногласий следует предвидеть и заранее выбрать стратегии урегулирования.

Теперь, когда мы разобрались с основными принципами, давайте перейдем к этапам в рамках HCD-процесса.

Планирование HCD

В рамках планирования HCD, стандарт ISO 9241-210 предлагает выполнять следующие действия:

1. Определение подходящих методов и необходимых ресурсов. Я планирую посвятить методике подбора подходящих методов отдельную статью;
2. Определение того, как вышеуказанные методы будут интегрированы с другими процессами разработки. HCD не должен висеть в воздухе. Это поможет избежать ситуаций, когда вы написали отличный отчет по Usability, но дизайнеры и разработчики его не используют, так как в проект уже сложно/дорого вносить предложенные вами изменения;
3. Определение ответственных. Особенно важно, если команда или компания раньше на занимались HCD. В противном случае процесс будет пущен на самотек;
4. Определение каналов коммуникации и методов разрешения противоречий. Вы написали классный отчет по Usability, проект находится еще в стадии дизайна. Цена изменений сравнительно низка, но дизайнеры, не знают о существовании вашего отчета. Или еще хуже. Дизайнеры читали ваш отчет, но считают ваш предложения ошибочными. Должны существовать процедура решения таких противоречий;
5. Должны быть согласованны временныe рамки отдельных этапов HCD и их интеграция в общий план разработки. Сюда входят сроки итераций, периоды для внесения изменений в проект и т.д.

После того, как все необходимы этапы были запланированы, мы можем перейти к спецификации контекста использования.

Спецификация контекста использования

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

Соответственно, стандарт ISO 9241-210 рекомендует выполнять следующие действия в рамках спецификации контекста использования:

1. Определить основные группы пользователей и заинтересованных лиц (stakeholders). В дальнейшем эти группы будут источниками требований для нашего проекта;
2. Определить цели и задачи вышеуказанных пользователей и заинтересованных лиц. Знание целей поможет нам при описании требований к продукта. Что касается задач, нас будут в первую очередь интересовать те, характеристики которых оказывают влияние на usability или accessability (например, периодичность выполнения, длительность, опасность и т.д), а также те, которые помогут лучше понять контекст использования (например, условия освещенности);
3. Определить техническое, организационное и физическое окружение. Это также позволит нам лучше понять контекст использования и предоставит базис для описания требований к продукту.

После того, как контекст определен, мы можем вырабатывать требования к продукту исходя из этого контекста.

Спецификация требований

В рамках процесса спецификации требований, стандарт рекомендует выполнять следующие действия:

1. Описать требования к продукту. Требования должны быть описаны на основе предполагаемого контекста использования. Также при создании списка требований могут использоваться различные стандарты, требования бизнеса и надзорных организаций.
2. Разрешить противоречия между различными требованиями. При этом задокументировать обоснования для принятых решений. Это особенно актуально в больших организациях с высокой текучестью кадров;
3. Убедиться в качестве сформулированных требований. Требования должны быть
   • Сформулированы таким образом, чтобы в дальнейшем продукт можно было тестировать на соответствие этим требованиям;
   • Согласованы со всеми заинтересованными лицами;
   • Целостными. Надеюсь, что вы уже разрешили все внутренние противоречия в требованиях;
   • Актуальными и обновляемыми в течение жизни проекта. Устаревшие требования это как устаревший антивирус — дают обманчивое ощущение безопасности.

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

1. Мы применяем HCD-подход для доработки уже существующего продукта. В этом случае очевидно, что технические ограничения должны быть отражены в списке требований;
2. Мы разрабатываем новый продукт. В этом случае мы еще не привязаны к конкретной платформе. Поэтому здесь мы можем подгонять платформу под требования дизайна. Например, мы можем решить написать свой графический движок, вместо использования существующих.

После того, как требования сформулированы, пришла пора перейти к проектированию.

Дизайн/проектирование взаимодействия

Для удобства скопировал сюда схему из начала статьи

Стандарт ISO 9241-210 рекомендует включать следующие действия в рамках этого этапа:

1. Спроектировать задачи пользователя, взаимодействие пользователя и системы, а также интерфейс, так, чтобы они соответствовали требованиям, сформулированным в рамках предыдущей фазы. При этом мы говорим не просто о добавлении тех или иных функций, а исходим из того, что у пользователя есть некие цели. Для достижения этих целей пользователь выполняет те или иные действия. Например, пользователь-бухгалтер не хочет просто выполнять абстрактные арифметические операции. Он хочет максимально быстро закончить отчет для налоговой, чтобы избежать проблем с руководством.
2. Детализировать проектные решения. Здесь рекомендуется разрабатывать сразу несколько параллельных решений, чтобы иметь возможность проверить их на пользователях. Также рекомендуется закладывать время на несколько итераций проектирования — это позволит выработать более целостное решение.
3. Использовать обратную связь от пользователей для улучшения проектных решений;
4. Донести проектные решения до тех, кто будет заниматься разработкой/внедрением. В противном случае конечный продукт не будет целостным, даже если был спроектирован таковым.

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

Оценка соответствия требованиям

Проверка на соответствие преследует следующие цели:

1. Получить новую информацию о пользователях. В процессе проектирования у вас возникали новые уточняющие вопросы. На часть из них вы получили ответ, на часть ответили исходя из своих предположений. В рамках данного этапа вы можете проверить свои предположения на практике;
2. Получить обратную связь о слабых и сильных сторонах дизайна. Это позволит расставить приоритеты для следующей итерации;
3. Установить критерии, относительно которых вы будете сравнивать текущую и следующую версии проекта.

Для достижения поставленных целей стандарт рекомендует выполнять следующие действия:

1. Оценка решений на основе тестов с участием пользователей. Например, вы приглашаете пользователей и просите их выполнить те или иные действия в вашей программе;
2. Оценка решений на основе экспертного мнения. Вы приглашаете эксперта и он оценивает ваш продукт исходя из собственного опыта и общепринятых практик. Относительно дешевое решение, однако наиболее критические проблемы скорее всего будут упущены;
3. Длительный мониторинг. Анализ критических ситуаций, обращений в службу поддержки и т.д.

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

Это была теория, но как внедрить данный подход, например, в рамках Waterfall или Scrum моделей?

Применение ISO 9241-210

В данной статье я предполагаю, что читатель знаком с моделями Waterfall и Scrum, поэтому не буду уделять много времени описанию особенностей каждого из подходов.

Waterfall-модель

Ниже вы видите графическое представление модели Waterfall. Мы начинаем с формулирования требований, затем разрабатываем решение, согласно требованиям. Мы внедряем решение, оцениваем его и исправляем ошибки/недочеты.


Как мы можем применить HCD-подход в рамках этой модели?

Например, в рамках описания требований, мы можем выполнить фазы спецификации контекста использования и спецификации требований из HCD-подхода.

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

Также фаза оценки соответствия требованиям может распространяться на этапы оценки и поддержки из модели Waterfall.


Предположу, что основной проблемой, с который вы столкнетесь при внедрении HCD-подхода в рамках модели Waterfall будет отсутствие итераций в рамках модели. Эту проблему можно нивелировать путем зацикливания модели Waterfall. Другой вопрос, на сколько такое зацикливание соотносится с предпочтениями и/или стратегическими целями вашего руководства.

Scrum-модель

Более гибкая модель. К тому же в ней изначально заложена итеративность.

Как HCD-подход может быть интегрирован в эту модель?

Прежде всего, результаты фаз спецификации контекста использования и спецификации требований могут служить источником информации для бэклога проекта. Также исследования в рамках HCD (например, интервью, опросы, diary studies и другие) могут лечь в основу истории спринта (Sprint Story).

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

Фаза проектирования из HCD-подхода, соответственно, может быть внедрена в рамках текущего спринта.

В качестве заключения

Как вы видите, стандарт ISO 9241-210 предоставляет базу для планирования и управления процессами в рамках HCD. При этом он является достаточно абстрактным и может применяться практически в любых ситуациях.

В ближайший год или два выйдет стандарт ISO 9241-220, который более детально будет описывать каждую из фаз HCD. Пока что он не доступен для широкой публики, однако его текст пару раз попадался мне в Интернете. Если кто-то из коллег найдет его и отправит мне ссылку, буду очень благодарен.

В следующий статье я планирую описать подход, позволяющий выбрать тот или иной HCD-метод в зависимости от текущей ситуации (бюджет, временные рамки, относительная сложность проекта и т.д.).