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-метод в зависимости от текущей ситуации (бюджет, временные рамки, относительная сложность проекта и т.д.).

    Похожие публикации

    Средняя зарплата в IT

    111 111 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 6 720 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 13

      0
      «The design addresses the whole user experience»

      Проектирование направлено на создание целостного пользовательского опыта.
        0
        Также думал про этот вариант.

        На мой взгляд, слово «опыт» описывает навыки и знания, полученные пользователем ранее. Возможно подошел бы «переживаемый опыт», но это словосочетание звучит слегка шероховато.
          0
          Есть устойчивые выражения вида «хочу получить опыт» и т.д. Так что вполне может относиться и к будущему.
        +1
        Как вы себе понимаете сочетание рекомендаций:

        Этап 2. Спецификация контекста использования
        … Определить цели и задачи вышеуказанных пользователей …


        Этап 4. Проектирование
        … Спроектировать задачи пользователя…

        Почему задачи пользователей сначала: 1) определяются, а потом 2) проектируются?
        Что это значит?
          0
          Спасибо за интересные вопросы.

          На этапе спецификации контекста, мы получаем перечень целей и задач на основе исследований (интервью, опросы, наблюдение и т.д.) После этого, мы используем эти данные для описания требований к продукту.

          Например, если пользователь выполняет некую задачу в условиях плохой освещенности, мы можем включить требование комфортной работы в условиях плохой освещенности в список требований к продукту.

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

          Например, у пользователя есть задача попасть из Петербурга в Москву. И он описывает ее так: сначала запрячь лошадей, взять ружье, еды на неделю и т.д., мы учтем цель, но предложим совсем другие задачи: купить билет на самолет, запаковать багаж и т.д.
            0
            «есть задача попасть из Петербурга в Москву» — в терминологии стандарта это больше похоже на цель, а не задачу.

            «сначала запрячь лошадей, взять ружье, еды на неделю и т.д.» — если «попасть из СПб в Москву» задачу, то эта цепочка уже больше похожа на ТЕХНОЛОГИЮ решения задачи (текущую).

            но если представить, что «попасть» — это цель, то да, способы её достижения через задачи (запрячь, купить) сейчас и в будущем будут давать разные наборы задач.

            тогда было бы более правильным считать, что на Этапе 4 происходит не проектирование задач, а ПЕРЕ-проектирование.
              0
              Согласен. Это опечатка. Имелась в виду «цель».
            +1
            Да перевод стандарта кривой (об этом тот же Сатин говорил).

            Взять фразу «Designing user tasks, user–system interaction and user interface to meet user requirements, taking into consideration the whole user experience». Как её разобрать по частям? Главная часть — «designing… to meet», т.е. именно «подгон» или «ре-дизайн», о котором сказали чуть выше. А перевели: «проектирование… с учётом того-то».

            Поэтому лучше читать всё в оригинале (хотя в данном случае это несколько затратно).
            0
            Теперь про

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

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

            Я правильно понимаю, что стандарт 9241 считает, что разработка ВСЕХ требований к продукту является этапом HCD-процесса?

            Т.е. исполнители HCD-процесса должны уметь разрабатывать все возможные виды требований, согласно, например, ISO/IEC 29148:2011. Systems and software engineering — Life cycle processes — Requirements engineering?
              0
              В идеале, перечень требований должен быть полным на столько, чтобы давать возможность создать жизнеспособный продукт.

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

              Если у нас команда из 5-10 человек, то все просто — все решили работать в рамках HCD-подхода и вместе формулируют требования.

              Если у нас корпорация, в которой работают 20.000-30.000 сотрудников, скорее всего, HCD будет поддерживать какой-то отдел. И этот отдел будет консультироваться с другими отделами для написания требований. Кроме того, отдел будет приглашать специалистов со стороны. Например, Siemens, который разрабатывает решения для медицинской отрасли, нанимает на полную ставку врачей, для того, чтобы они участвовали в процессе HCD.
              0
              И ещё про проектирование:

              Проектирование

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

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

              Судя по всему, в состав проектных решений на этом этапе не попадают, как минимум:
              1. Ключевые свойства системы/продукта
              2. Устройство бизнес-процессов
              3. Архитектура системы/продукта
              4. Устройство подсистем продукта/системы

              Т.е. тут речь идёт только о некотором подмножестве проектных решений про продукт/систему. Что же является предметом проектирования? Вот этот неоднородный безымянный набор «задачи + взаимодействие + интерфейс»?
                0
                Совершенно верно, здесь упор делается именно на то, какие задачи пользователи будут выполнять в рамках нашего продукта, как они будут взаимодействовать с системой и как интерфейс будет поддерживать это взаимодействие.

                Возможно, слово «проектирование», взятое из ГОСТа, вводит в заблуждение. Заменил там, где это необходимо на «дизайн/проектирование взаимодействия».
                  +1
                  Спасибо за статью. В идеале хочется увидеть советы по практическому внедрению HUD-подхода, например в JIRA.
                  Особенно порадовало "Если все хорошо, или у вас кончаются деньги, вы выпускаете продукт" :)

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое