Создаем дизайн с человеческим лицом. Принципы

Основатель Fancy Interactive Илья Розовский объясняет, как внедрить human-centered design Изображение: Unsplash.

Постоянный автор Теплицы Илья Розовский рассказывает о подходах к решению задач, встающих перед социальными проектами. В прошлый раз Илья описал основные принципы дизайн-мышления. Теперь пришла очередь человеко-ориентированного дизайна (human-centered design, кратко — HCD). Что такое HCD и зачем использовать принципы этого подхода в работе — в нашем материале.

HCD не просто популярен, но еще и стандартизирован под кодовым номером ISO 9241-210:2019(Е). ISO — международная организация по стандартизации почти с вековой историей, отвечающая за стандарты в большинстве отраслей. В ИСО входят 120 стран, включая Россию. Поэтому мы можем пользоваться достаточно точными определениями. В случае со стандартом HCD определение сформулировано следующим образом.

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

ISO 9241-210:2019(Е)

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

Стоит сразу обратить внимание, что HCD по определению не синонимичен инклюзивному дизайну и сильно отличается от него на уровне принципов применения и внедрения (несмотря на то, что эти понятия часто путают и подменяют). Инклюзивный дизайн, по существу, представляет собой набор правил, применение которых необходимо для обеспечения доступности разрабатываемых систем для определенных групп пользователей. Инклюзивный дизайн весьма обширен и разнообразен, но по сути своей внедрим на любой стадии и без вовлечения представителей самих групп.

Говоря просто, чтобы сделать мобильное приложение доступным для людей с дальтонизмом, достаточно проверить, проходят ли системы цветокодирования проверку на различимость по специальным таблицам, продублировать цветовую навигацию символьной и провести еще несколько таких же незначительных тестов и внедрений. Это заметно (примерно на 6%) повысит инклюзивность приложения, что соответствует целям инклюзивного дизайна, но не будет иметь ни малейшего отношения к методам HCD.

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

Истоки HCD восходят к школе дизайна Стэнфордского университета, где в 1958 году профессор машиностроения и бизнес-администрирования Джон Э. Арнольд выдвинул идею, что дизайн должен быть приоритетно ориентирован не на функцию, а на человека.

Идея быстро набрала популярность и удачно совпала по времени с возникновением концепции дизайн-мышления. Нередко эти два метода даже объединяют в одну сущность. Однако я разделяю эти явления, воспринимая их не более чем родственными. В конечном итоге, сегодняшние первые лица HCD скорее говорят о противодействии машино-центрическому и дата-центрическому подходам, когда дизайн-мышление сосредоточено на развитии прикладных методик и моделей, что ставит их на разные уровни влияния…

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

  1. Начало проекта — это проектирование не системы, но процесса создания системы.

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

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

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

  1. От понимания проекта переходим к пониманию контекста его применения.

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

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

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

  1. От понимания проблематики к пониманию желаний.

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

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

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

  1. От понимания к последовательному воплощению проекта.

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

Из отличий стоит разве что выделить тот аспект, что удачными могут оказаться сразу несколько разных подходов и в таком случае правильным будет параллельное их внедрение в систему. Как пример, можно вспомнить ставшую популярной последнее время “темную тему” для сайтов, или знакомый всем выбор формата выдачи файлов операционными системами: таблица, иконки или список.

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

  1. От воплощения к оценке результатов.

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

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

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

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