Контекстуальное проектирование (Contextual Design, контекстный дизайн) — это структурированный, четко определенный процесс разработки программных решений, ориентированных на конечного потребителя товара/услуги, и предоставляющий дизайнерам методы сбора данных о пользователях, интерпретации и консолидации этой информации, ее использования для создания и прототипирования продуктов/услуг, их дальнейшего итеративного тестирования совместно с пользователями.
Ядро философии контекстного дизайна — понимание пользователей, позволяющее узнать их основные намерения, желания и движущие силы. Но дело в том, что все эти факторы невидимы самим пользователям, поэтому единственный способ собрать такие сведения — опросить целевую аудиторию.
Основанное на теориях, представляющих различные дисциплины, включая антропологию, психологию и дизайн, контекстуальное проектирование было разработано для практического применения с коммерческими целями.
Начиная с момента своего появления контекстный дизайн применялся в самых разных отраслях промышленности, а также использовался в инженерных и дизайнерских программах в качестве средства обучения принципам проектирования, ориентированным на пользователя. Элементы контекстуального проектирования были адаптированы для использования в области методологий оценки юзабилити (Usability).
Контекстный дизайн сегодня обширно применяется для разработки цифровых библиотек и других образовательных технологий. Контекстуальное проектирование также используется во многих других отраслях, включая разработку веб-приложений, реинжиниринг процессов, дизайн потребительских товаров, производство, а также дизайн автомобильных и медицинских устройств — и это лишь некоторые сферы его применения.
Контекстный дизайн получил широкое распространение на университетском уровне в качестве средства обучения человеко-компьютерному взаимодействию и принципам ориентированной на пользователя разработки продуктов/услуг.
1. Основные принципы и мотивации применения
Несколько немногочисленных ключевых принципов легли в основу контекстного дизайна и обеспечили ключевые мотивы его использования в качестве распространенного инструмента проектирования.
1.1. Принцип: дизайн системы должен помогать в решении задач
Контекстуальное проектирование основано на наблюдении, что любая технология или система всегда находится в более широком окружающем контексте, и что внедрение новых решений неизбежно изменяет среду окружения пользователей продукта. В контекстном дизайне термин «рабочие задачи» (Work Practice) относится к сложному и подробному набору моделей поведения, установок, целей и намерений, характеризующему выборку пользователей, находящихся в конкретной рабочей среде. Например, существуют задачи, связанные с бизнес-целями, такими как делопроизводство, и с событиями в повседневной жизни каждого человека, такими как покупка потребительских товаров, вождение автомобиля, воспроизведение музыки и даже просмотр телевизора.
Основным принципом контекстного дизайна является то, что любая технология, продукт или система должны быть разработаны для поддержки пользователей в решении этих задач. Если этот принцип будет воплощен на практике наилучшим образом, это будет принято и оценено целевой аудиторией; если же нет — это вызовет неудовлетворенность, разочарование, уклонение от покупки и поиск обходных вариантов.
1.2. Принцип: люди являются экспертами в том, что они делают, но не могут сформулировать свои задачи
Работу дизайнера усложняют 2 факта, касающихся рабочих задач. Во-первых, люди не отдают себе сознательного отчета о них: они имеют скрытый, непроявленный характер. Это утверждение особенно справедливо для тех ситуаций, когда людей извлекают из контекста их повседневной жизни. Только тогда, когда пользователи погружаются в обычные контексты применения своих навыков, они могут осознавать свои задачи — что они делают и почему. Они «обретают понимание через делание», как выразился по этому поводу в своей книге «Личностное знание» (Personal Knowledge, 1958 г.) английский физик и философ Майкл Полани (Michael Polanyi).
Во-вторых, многие системы не оправдывают ожиданий, потому что они не учитывают, по-видимому, незначительные детали задач — подробности, которые не доступны на сознательном уровне пользователям, не вовлеченным в процесс.
Методология контекстуального дизайна утверждает, что члены команды разработчиков должны выходить на «полевые исследования», наблюдать пользователей и разговаривать с ними в их естественных условиях работы и жизни — в их естественном контексте. Это принцип контекста, от которого процесс и получил свое название. В данном аспекте контекстуального проектирования используются наработки из более ранних этнографических методологий, однако расширенные в ряде важных областей.
1.3. Принцип: хороший дизайн требует партнерства и участия
пользователей
Даже находящиеся в соответствующем контексте пользователи не всегда могут интуитивно постичь и сформулировать свое поведение и подробные мотивации. Поэтому метод контекстуального проектирования предписывает проведение интервью, которые не являются чистыми этнографическими наблюдениями, но привлекают пользователя к обсуждению и размышлению о своих собственных действиях, намерениях и ценностях.
Интервьюер активно обращается к пользователю и партнерам с просьбой подробно обрисовать рабочие задачи и осознать их. Таким образом, интервьюер не пользуется предварительно сформированным списком вопросов — как в ходе опроса или исследования фокус-группы, — а скорее принимает модель отношений между наставником и учеником, стремясь понять действия пользователя с точки зрения подмастерья, обучающегося у мастера в ходе непрерывного трудового процесса.
Эта ключевая концепция партнерства также выходит на передний план контекстуального проектирования при использовании бумажных прототипов и при коротких итерациях с пользователями для разработки детального проекта. Обоснование идеи об итеративном прототипировании, проводимом в рамках контекстуального дизайна, эволюционировало во взаимодействии с развитием методов проектирования на основе участия пользователей в 1980-х и 1990-х годах.
1.4. Принцип: хороший дизайн является системным
Любой хороший дизайн рассматривает систему и ее влияние на пользователей в целом: ручки на Mini Cooper отражают эстетику всего автомобиля; характерные элементы пользовательского интерфейса iPhone (включая жесты) переносятся на весь дизайн и все приложения; все части сайта amazon.com сосредоточены на интересах пользователей, рейтингах сообщества, связанных с ними материалами и простоте покупки. И все страницы сайта выглядят так, как будто они являются частью единого целого — ни одна не может быть изменена.
Контекстный дизайн предоставляет методы, которые помогают команде разработчиков поддерживать согласованность проекта. Концепция контекстуального проектирования предусматривает согласованность руководства на высоком уровне; раскадровки обеспечивают последовательность задач; разработка пользовательского окружения предоставляет структурную согласованность системы. Все эти методы, которые объясняются в следующем разделе, побуждают дизайнера думать о всей системе в целом, а не рассматривать каждую ее часть как отдельную независимую проблему, нуждающуюся в решении.
1.5. Принцип: дизайн зависит от конкретных представлений
Дизайнеры нуждаются в ощутимом представлении своих мыслей, записаны ли они на обратной стороне салфетки или визуализированы при помощи высококачественного инструмента моделирования. Во всем диапазоне — от эскизов до формальных диаграмм — рисунки позволяют разрабатывать свои идеи, выражать свои мысли, делиться ими с другими, обсуждать их и выявлять в них недостатки.
Контекстный дизайн в течение всего процесса проектирования поддерживает эту потребность в физическом представлении. Рабочие модели помогают смоделировать то, как пользователи выполняют свои задачи с их помощью. Дизайн пользовательской среды показывает структуру системы так, как она будет ощущаться пользователем. Эти физические репрезентации в контекстном дизайне описаны в следующем разделе.
2. Описание процесса контекстуального проектирования
Рисунок.1. Процесс контекстуального проектирования (все термины последовательно и подробно объясняются в пункте 2 этого поста ,см. ниже).
Контекстный дизайн в целом разделен на две основные фазы (см. рис. 1). В этом разделе мы опишем начальные части процесса, начиная с контекстуального опроса (Contextual Inquiry) и заканчивая концептуальным видением (Visioning). Эти отправные пункты нацелены на создание структурированного представления задач пользователей, которое может быть применимо для разработки дизайна системы. Позже мы опишем следующий этап, включающий в себя итеративное прототипирование с участием пользователей, направленное на детализацию концепций, разработанных в первой половине процесса.
2.1. Контекстуальный опрос
Для проектирования первой проблемой является понимание клиентов: людей, которые будут использовать решение напрямую (конечные пользователи — End-Users); тех, кто предоставляет им информацию или использует их продукцию (косвенные пользователи — Indirect Users); тех, кто управляет ими и несет ответственность за их успех (менеджеры); тех, кто приобретает продукт и может иметь свои, совершенно независимые критерии. Для большинства проектов основное внимание почти всегда уделяется конечным пользователям, но важно учитывать и оценивать потребности других типов клиентов.
Контекстуальный опрос — прямой шаг к пониманию того, кем на самом деле являются ваши клиенты и как они выполняют задачи на повседневной основе. Трудность состоит в том, что, как мы отмечали выше, работа становится настолько привычной для конечных пользователей, что им часто сложно сформулировать, что они делают и почему они это делают. Поэтому команда разработчиков проводит индивидуальные полевые интервью с пользователями, чтобы узнать, что для них важно. Это не традиционные интервью и ответы на вопросы. Вместо этого контекстный интервьюер наблюдает за пользователями, когда они выполняют задачи, и спрашивает о действиях в тот момент, когда их совершают — это позволяет мотивацию и стратегию потенциальных клиентов. Интервьюер и пользователь путем проведения обсуждения разрабатывают общую интерпретацию. Это действие похоже на активный запрос, отправленный в мир пользователей. Этот опрос, проводимый в контексте — вот откуда метод Contextual Inquiry получил свое название.
Командные сессии интерпретации (Team interpretation sessions) объединяют многофункциональную команду дизайнеров для того, чтобы выслушать всю историю интервью и зафиксировать идеи и знания, соотносящиеся с их проблемами проектирования. Сеансы интерпретации позволяет каждому в команде привносить свою уникальную точку зрения на полученные данные, совместно используемый дизайн, маркетинг и последствия для бизнеса. В ходе этих обсуждений команда приходит к пониманию клиентов, данные которых интерпретируются, узнают пользовательские потребности и в то же время фиксируют имеющиеся проблемы, рисуют рабочие модели и разрабатывают общее понимание внутреннего мира целевой аудитории.
2.2. Моделирование рабочего процесса
Как было отмечено выше, действия пользователей бывают сложны и крайне детализированы. Они, в отличие от их результатов, нематериальны — традиционно не существует хорошего способа записать какую-то деятельность от начала до конца или обсудить ее. Коллективы разработчиков редко обладают важнейшим умением видеть структуру работы, проделанной другими, посмотреть сквозь детали, находящиеся на поверхности, чтобы обнаружить намерения, стратегии и мотивации, которые управляют деятельностью, а типичные методологии проектирования мало чем поощряют эту точку зрения.
Перечисленные выше условия очень важны для разработчиков UI/UX, поэтому в контекстном дизайне рабочие модели используются для захвата отражения действий отдельных лиц и организаций на диаграммах. Пять различных моделей обеспечивают 5 различных точек зрения на то, как выполняются задачи:
- Модель потока (Flow Model) фиксирует связи и координации, устанавливающиеся между людьми для выполнения задач. Она показывает формальные и неформальные рабочие группы и модели общения, имеющие решающее значение. Эта модель демонстрирует, как работа подразделяется на формальные и неформальные роли и обязанности.
- Культурная модель (Cultural Model) отображает культурные и политические условия, ограничивающие процесс работы. Она показывает, как на пользователей действуют эти сдерживающие факторы, которые им приходится преодолевать для выполнения задач.
- Модель последовательности (Sequence Model) подробно освещает шаги, предпринимаемые пользователями для выполнения каждой задачи, важной для результата в целом. Модель отображает различные стратегии, используемые людьми; намерения или цели, которых они пытаются достичь, выполняя свои задачи, и проблемы, возникающие на пути пользователей.
- Физическая модель (Physical Model) воплощает материальную окружающую среду, которая способствует выполнению задач или наоборот, препятствует ему. Эта модель демонстрирует, как люди организуют свое физическое окружение, чтобы облегчить работу.
- Модель артефакта (Artifact Model) показывает артефакты, которые создаются и используются при выполнении работы. Артефакты раскрывают, как люди думают о своей деятельности — о концепциях, которые они используют, чтобы организовать процесс выполнения работы.
Рисунок 2. Пример на картинке выше демонстрирует, как конкретная деятельность (ведение домохозяйства) подразделяется на формальные и неформальные роли и обязанности: пользователь 2 (User 2), для которого будут построены все рабочие модели, одновременно является мамой (Mom) своей дочери (Daughter), партнером по ведению домохозяйства для собственного мужа (Husband), покупательницей, вступающей в маркетинговое взаимодействие с продавцом в магазине продовольственных товаров (Grocery Store Checkout Clerk), и руководителем для приходящей уборщицы (Cleaner). Стрелками обозначены действия, предпринимаемые для выполнения задач: так, например, домохозяйка просит мужа отправиться вместе с ней за покупками (Ask to shop together). Это действие обнаруживает проблему: муж оспаривает просьбу о совместном шопинге (Argue about shopping together). Этот конфликт отмечен на схеме знаком высокого напряжения.
Рисунок 3. Эта модель отображает культурные и политические особенности, лимитирующие деятельность. Она показывает, как на пользователей действуют эти сдерживающие факторы, которые им приходится преодолевать для выполнения задач. Так, во время посещения продовольственного магазина пользователем 2 (U2/Mom) на процесс покупки будут влиять условия, присущие производителю продукта (Product Maker) — «Packaging and size helps determine what I buy» (Упаковка и размер помогут определить, что я куплю) — и культуре данного магазина — «Be open when I want to shop late» (Будьте открыты, когда я хочу делать покупки в позднее время).
Рисунок 4. Модель последовательности подробно освещает шаги, предпринимаемые пользователями для выполнения каждой задачи, важной для результата в целом. Модель отображает различные стратегии, используемые людьми; намерения или цели, которых они пытаются достичь, выполняя свои задачи, и проблемы, возникающие на пути пользователей. В данном случае намерение (Intent) — получить продовольственные товары, необходимые для того, чтобы накормить семью, и запланировать, кто что будет есть. Триггером (Trigger) к совершению действия является начало уикенда — времени совершать покупки. Последовательность завершается оплатой покупок в кассе (Go to checkout counter).
Рисунок 5. Физическая модель воплощает материальную окружающую среду, которая способствует выполнению задач или наоборот, препятствует ему. Эта модель демонстрирует, как люди организуют свое физическое окружение, чтобы облегчить труд.
Рисунок 6: модель артефакта показывает артефакты, которые создаются и используются при выполнении работы. Артефакты раскрывают, как люди думают о своей деятельности — о концепциях, которые они используют, чтобы организовать процесс выполнения работы.
2.3. Консолидация
Системы редко разрабатываются под одного единственного клиента. Но проектирование для целой популяции клиентов — рынка, отдела или организации, которая будет использовать систему, — основывается на понимании общих аспектов в работах разных людей.
Консолидация (Consolidation) объединяет множество данных из индивидуальных интервью с клиентами, поэтому команда разработчиков может видеть общую схему и структуру, не теряя отдельных вариаций. Диаграмма сходства (Affinity diagram) сводит воедино вопросы и знания, общие для всех клиентов, в иерархическую диаграмму, служащую выявлению масштаба проблемы.
Рисунок 7. Фрагмент диаграммы сходства. Диаграмма сходства сводит воедино вопросы и знания, общие для всех клиентов, в иерархическую визуализацию, служащую выявлению масштаба проблемы и возможностей ее решения.
Консолидированные модели объединяют данные по каждому отдельному аспекту задач обособленно — для того, чтобы выявить общие стратегии и намерения, но при этом сохранить и зафиксировать индивидуальные различия. Взятые вместе диаграммы близости и консолидированные рабочие модели создают единую картину популяции клиентов, которой адресован разрабатываемый проект. Они дают команде ориентир для обсуждения проекта, показывая, как задача выглядит в совокупности, а не разбивает ее на списки действий. Диаграммы и модели показывают, какие факторы, условия и объекты критически важны для результата, и отображают структуру последовательных действий, включающую системные функции, поставленные цели и вспомогательные механизмы.
Рисунок 8. Консолидированная модель потока, в которой пользователь показан в нескольких контекстах: управления домашним хозяйством (Managing the House), социальных отношений (Family and Friends) и маркетинговых интеракций (Shopping & Checkout).
Рисунок 9. Консолидированная культурная модель.
Рисунок 10. Фрагмент консолидированной модели последовательности.
Рисунок 11. Консолидированная физическая модель.
Рисунок 12. Консолидированная модель артефактов.
2.4. Персоны, созданные с использованием контекстуальных данных
Персоны, основанные на контекстуальных данных, могут способствовать привлечению реальных пользователей и сосредоточить внимание заинтересованных сторон на актуальных проблемах проектирования.
Популяризированный Аланом Купером (Alan Cooper, американский дизайнер UX/UI и программист) тип персон описывает типичных пользователей предлагаемой системы так, как если бы они были настоящими людьми. Их использование становится все более распространенным, хотя и сопровождается переменным успехом. Согласно исследованиям Харли Мэннинга (Harley Manning), научного руководителя отдела клиентского опыта в компании Forrester, «персона, не подкрепленная богатыми контекстуальными данными, непригодна, что объясняет большую часть неоднозначных результатов».
Контекстуальное проектирование предусматривает создание персон на базе полевых данных, собранных и консолидированных командой дизайнеров. Это делается для того, чтобы сосредоточить внимание разработчиков на персонажах, которых они увидят на следующем этапе проектирования; чтобы помочь заинтересованным сторонам сегментировать свой рынок в соответствии с реальной практикой, а не среднестатистическими демографическими данными; чтобы уточнить брендинг и расставить приоритеты; чтобы донести пользователей и их жизненные потребности до маркетологов и дизайнеров. Персоны контекстуального проектирования строятся на основе подробных данных, собранных через интервью, проведенные в рамках контекстного опроса, поэтому у них есть богатство и глубина, необходимые для управления дизайном.
2.5. Проектируемый ответ: концептуальное видение
До этого момента проект контекстуального проектирования фокусируется на понимании пользователей такими, какими они являются. Но теперь команда должна изобрести проектное решение, использующее технологии преобразования пользовательских задач и, возможно, также разработать новые бизнес-процессы для оптимизации функций или новых сервисы, способствующие поддержанию рынка. Группа контекстного дизайна изобретает эти решения на основе концептуального видения (Visioning).
В процессе разработки концепции команда использует консолидированные данные для ведения дискуссии о том, как можно применить технологии для трансформации задач, и, как следствие — для оптимизации усилий пользователей. Такой подход фокусирует обсуждение на том, как с помощью технологий можно улучшить жизнь людей, а не на абстрактных технических решениях, не оказывающих никакого положительного влияния на целевую аудиторию.
Концептуальное видение отражает историю того, как клиенты будут выполнять свои задачи в новом мире, изобретенном для них командой разработчиков. Видение включает собственно систему, ее предоставление и вспомогательные структуры, позволяющие сделать новую деятельность успешной. Концепция преднамеренно является грубой и высокоуровневой — видение устанавливает лишь возможное направление проектирования, не конкретизируя каждую деталь. Это позволяет команде видеть общую структуру решения и обеспечивать его согласованность.
Рисунок 13. Концептуальное видение воплощает сценарий деятельности клиентов в новом мире, изобретенном разработчиками. Концепция охватывает систему, ее доставку целевой аудитории и вспомогательные структуры.
2.6. Раскадровки
Концепция определяет высокоуровневый проект как ответ на существующие потребности пользователей. Для его осуществления команда должна детально определить функции, поведение и структуру предлагаемой системы. Этот следующий уровень дизайна должен учитывать задачи пользователей и обеспечивать правильную работу функций в соответствующих местах системы для беспрепятственного протекания рабочих процессов. Как будет показано в следующем разделе, контекстуальное проектирование обеспечивает этот структурный дизайн с при помощи раскадровок (Storyboards) и разработки пользовательской среды (User Environment Design), а затем проверяет результат посредством «бумажного» прототипирования (Paper prototyping).
Каждая раскадровка описывает, как пользователи будут выполнять задачу в новой системе. Она показывает шаги, предпринимаемые пользователем, и системную функцию, поддерживающую каждый шаг. Задача может передаваться между от одного пользователя другому и при этом поддерживаться несколькими системами, работающими совместно; раскадровка гарантирует, что задача останется согласованной в этих границах.
Рисунок 14. Фрагмент раскадровки, представленной в виде последовательности эскизов «стоп-кадров» или условных ячеек, каждая из которых фиксирует один шаг в процессе выполнения общей задачи.
2.7. Разработка пользовательской среды
Раскадровки обеспечивают согласованность отдельных задач, но новая система также должна иметь соответствующую структуру для поддержки естественного рабочего потока через систему — независимо от того, какую задачу выполняет пользователь. Так же, как архитекторы рисуют планы этажей, чтобы увидеть структуру будущего дома в объеме, разработчикам необходимо разглядеть «поэтажный план» своей новой системы — основную структуру, которая будет показана как эскиз пользовательского интерфейса, реализована в качества объектной модели и будет отвечать требованиям клиента. Этот «поэтажный план» в процессе проектирования обычно не получает непосредственного отражения.
Дизайн пользовательской среды фиксирует «поэтажный план» новой системы. Он показывает каждую часть системы и то, как она поддерживает работу пользователя, какая в точности функция доступна в данной части, и как пользователь может перейти к другим частям системы — без привязки этой структуры к любому конкретному пользовательскому интерфейсу.
При конкретной разработке пользовательской среды команда может убедиться в том, что структура подходит для пользователя, а также планировать развертывание новых функций в серии релизов и согласовывать проектные работы между инженерными командами на уровне абстракции, находящемся над экранами и диалогами.
Использование диаграммы, которая фокусируется на поддержке согласованности системы для пользователя, уравновешивает другие силы, которые пожертвовали бы системным единством в пользу простоты внедрения или поставки.
Рисунок 15 .Фрагмент структурной разработки пользовательской среды. Проект показывает каждую часть системы, то, как она поддерживает работу пользователя, какая именно функция доступна в этой части общей структуры, и каким образом пользователь перемещается между частями системы — без привязки этой структуры к любому конкретному GUI.
2.8. Создание бумажных прототипов
Тестирование является важной частью разработки любой системы. Общепризнанным является тот факт, что чем скорее проблемы будут найдены, тем дешевле обойдется их исправление. Поэтому очень важно выполнить итеративное тестирование дизайна перед тем, как кто-либо инвестирует средства в разработку и будет затрачено время на написание кода. Чем проще устроен процесс тестирования, тем больше времени доступно для проведения многократных итераций, позволяющих при помощи пользователей детализировать проект.
В процессе создания бумажных прототипов разрабатываются грубые макеты системы, использующие текстовые примечания и сделанные вручную эскизы для представления интерфейсов, диалоговых окон, кнопок и меню.
Использование бумажных прототипов описано во множестве источников, включая книгу Кэролин Снайдер (Carolyn Snyder), наиболее полно раскрывающую эту тему — «Бумажное прототипирование: быстрый и простой способ проектирования и уточнения пользовательских интерфейсов» (Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces, 2003 г.)
Команда разработчиков совместно с пользователями тестирует эти прототипы на местах, воспроизводя в предлагаемой системе выполнение реальных практических задач. Когда пользователи обнаруживают проблемы, то они совместно с дизайнерами переделывают прототип до тех пор, пока он не станет соответствовать их потребностям. «Грубые» бумажные прототипы системного дизайна позволяют протестировать структуру разработанной пользовательской среды и концепцию первоначального графического интерфейса прежде, чем что-либо будет зафиксировано в программном коде. Бумажные прототипы поддерживают итерацию новой системы, сохраняя ее соответствие подлинным потребностям пользователя.
Усовершенствование дизайна при участии пользователей предоставляет дизайнерам ориентированный на клиента способ разрешения разногласий и позволяет выработать следующий уровень требований. После нескольких циклов «бумажного» прототипирования системный проект стабилизируется на более широком уровне. На этом этапе команда разработчиков может продолжить итеративное тестирование отдельных областей пользовательского интерфейса.
Как только структура и дизайн взаимодействия будут в основном стабилизированы, проектная команда может разрабатывать и тестировать варианты интеракции и визуального дизайна, привлекая пользователей к участию в этом процессе.
Рисунок 16. Фрагмент процесса «бумажного прототипирования». При помощи бумажных прототипов с использованием текстовых заметок и нарисованных вручную эскизов разрабатываются «грубые» макеты системы, позволяющие наглядно представить диалоговые окна, кнопки, меню и другие элементы пользовательского интерфейса.
2.9. Управление разработкой продукта
Компании внедряют различные методологии разработки аппаратного и программного обеспечения, которым должен соответствовать их процесс проектирования интерфейсов взаимодействия между пользователем и основной программно-аппаратной частью системы (Front-end Design), будь он ориентирован на пользователя или нет. Большинство методологий устанавливают серии этапов проектирования, каждый из которых оценивается по ожидаемым результатам и основным показателям измерений. Лишь в некоторых из их этих подходов определяются конкретные способы сбора требований целевой аудитории — чаще всего выбор метода оставляют на усмотрение команды разработчиков продукта.
Контекстуальное проектирование обычно включается в этап сбора требований или самые ранние предварительные этапы упомянутых методологий.
«Переводу» любого рода исследований пользовательских потребностей на язык «требований» к проекту часто не хватает порядка и строгости. Структура, предлагаемая методологией контекстуального проектирования, помогает проектным группам управлять некоторыми видами деятельности. Дизайн пользовательской среды отображает требуемую функцию и поведение новой системы, по крайней мере, для основных рабочих случаев. Бумажные прототипы фиксируют предлагаемый пользовательский интерфейс, хотя обычно только на грубом, черновом уровне. Все перечисленные подходы могут использоваться для предоставления задокументированных требований к продукту (Product Requirements Document) и спецификаций пользовательского интерфейса (User Interface Specifications).
2.10. Контекстуальное проектирование и гибкая методология разработки
В настоящее время многие организации переходят к гибкой методологии разработки
(Agile Development). В отличие от традиционных подходов, которые выделяющих анализ требований, разработку и имплементацию в качестве отдельных этапов, agile-методы к минимуму предварительное планирование в пользу быстрого создания рабочих базовых уровней продукта. Обратная связь, исходящая с этих базовых уровней, используется для обеспечения полезности получаемого товара/услуги. Два самых популярных подхода гибкой разработки — это Scrum (2001 г.) и Extreme Programming (2004 г.)
Гибкая разработка хорошо сочетается с дизайном, ориентированным на пользователя. Но команды agile-разработчиков часто пытаются включить достоверное мнение клиента, что, как предполагается в «гибких» методологиях, проектировщики могут сделать. Попытки заменить заинтересованные стороны или владельцев внутренних продуктов реальным конечным пользователем показали, насколько критичен этот пользовательский голос. Контекстуальное проектирование предоставляет проверенные методы сбора и использования пользовательских знаний, которые могут быть приняты компаниями, применяющими Agile Development.
Прежде чем начнется «гибкая» разработка, начальные этапы контекстуального проектирования дадут команде знания, необходимые для написания жизнеспособной истории пользователей. Интервью в рамках исследования контекста, диаграммы сходства и рабочие модели обеспечивают глубокое понимание пользователя, необходимое проектной группе. Концептуальное видение определяет направление проекта и определяет, какие решения необходимо предоставить.
Раскадровки, дизайн пользовательской среды и разработка бумажных прототипов развивают и подтверждают качество нужной функции, которая будет включена в пользовательские истории, на основе которых планируется «гибкий» релиз продукта. Это очень важно — итеративное тестирование бумажного прототипа гарантирует, что команда разрабатывает правильный дизайн, который решает реальные проблемы пользователей. Дешевле и быстрее будет доработать дизайн на этапе «бумажного прототипирования», чем проводить необходимые итерации на середине процесса разработки.
Ключевое различие между поддержкой гибкой методологии и традиционной «каскадной» разработкой заключается в том, что для agile-проекта все перечисленные выше шаги должны быть обязательно выполнены: ведь в этом случае не существует письменных спецификаций для функций системы, для пользовательского интерфейса или информационной архитектуры. Разработка пользовательской среды поддерживается на уровне, необходимом для обеспечения понимания проекта — ее не предполагается использовать в качестве коммуникационного механизма для команды разработчиков.
Взамен этого в качестве источника для написания пользовательских историй в сессии планируемого релиза совместно используются разработка пользовательской среды и бумажные прототипы. Они обеспечивают достаточно подробностей для того, чтобы облегчить написание и оценку истории. Итерации могут быть запланированы таким образом, чтобы каждая из них собирала истории, которые, вместе взятые, обеспечивали бы согласованную пользовательскую значимость — как она определяется разработкой рабочей среды.
В ходе гибкой разработки технологии контекстуального проектирования продолжают оказывать команде критически важную поддержку.
Знания, полученные в ходе полевых исследований, придают команде уверенность в расстановке приоритетов в их пользовательских историях. Детализация пользовательского интерфейса может быть определена во время итераций — они обычно предшествуют разработке. Контекстуальные опросы, проводимые непосредственно на рабочих местах, позволяют детализировать проекты GUI при участии пользователей. Завершенные базовые уровни также могут быть протестированы с использованием методов контекстного опроса, а полученные результаты — использованы для уточнения направления движения проекта.
3. Происхождение и история контекстуального проектирования
Карен Хольцблатт (Karen Holtzblatt) и Хью Бейер первоначально разработали ключевые элементы процесса контекстуального проектирования во время работы в Digital Equipment Corporation (DEC) в начале 1980-х годов. Карен, психолог по образованию, и Хью, разработчик, признали необходимость последовательного и структурированного процесса проектирования, который мог бы интегрировать полезную практику из их соответствующих областей и сделать ее доступной и эффективной для проектных групп коммерческого назначения.
Изначально работа Хольцблатт была ответом на ограничения тестирования юзабилити и человеческих факторов, существовавшие в начале 1980-х годов. В 1988 году Джон Уайтсайд (John Whiteside), Джон Беннетт (John Bennett) и Карен Хольцблатт в статье «Инженерия юзабилити: наш опыт и его эволюция» (Usability Engineering: Our Experience and Evolution) представили и обсудили теоретическую основу использования этнографических и герменевтических методик для понимания действий пользователей с целью проектирования компьютерных систем. В то время методы юзабилити были сфокусированы на лабораторных количественных показателях, но подобные техники всегда были ограничены в объеме воздействия, который они могли иметь, что не приводило к совершенно новым представлениям и направлениям проектирования.
Хольцблатт привнесла методы полевых исследований, используемые в психологии и социологии, в разработку цифровых продуктов, показав, как метод анализа устных протоколов может применяться к данным, собранным от пользователей на местах. Эти данные составляют основу обоснованной теории — как ее определили Глейзер и Страусс в книге «Открытие обоснованной теории» (The Discovery of Grounded Theory) в 1967 году — и как таковые мотивируют проектные действия. Контекстное исследование было определено как структурированный метод сбора и использования полевых данных с использованием этой теоретической основы.
Обусловленные этой теорией методы по своей природе аналогичны технологиям этнографических исследований. Однако контекстуальный опрос ограничен рамками инженерного проекта. Поэтому полевые интервью ограничиваются несколькими часами, а не днями или неделями, а взаимодействие между интервьюером и пользователем определяется как целенаправленный разговор. Цель разговора — выявить и сформулировать характер рабочей практики пользователя, причем эта цель понимается и разделяется обоими участниками.
В то же время Хольцблатт адаптировала для сферы разработки программного обеспечения методы физического макетирования, разработанные скандинавскими дизайнерами. В Скандинавии существовала практика включения представителей рабочей силы в реорганизацию рабочих мест, в ходе которой создавались макеты рабочих станций с использованием больших картонных коробок и других простых физических средств репрезентации. В промышленности широкое распространение получили своеобразные юзабилити-тесты, в которых участвовали рабочие, выполнявшие свои типичные задачи в смоделированной пользовательской среде, оптимизируемой для улучшения деятельности через устранение проблем, обнаруженных в ходе этих тестовых испытаний.
Хольцблатт «масштабировала» этот метод, приспособив его для тестирования программных решений. Она предложила применять нарисованные вручную на бумажных стикерах эскизы пользовательских интерфейсов, чтобы представить предлагаемый проект и прорабатывать собственные задачи пользователей непосредственно на их рабочих местах, чтобы изучить полезность дизайна. Теперь разработчик и пользователь могли совместно работать над модификацией прототипа, устраняя обнаруженные проблемы и добавляя необходимые функции.
Рабочие модели были разработаны Хольцблатт как способ визуального отображения дискуссий о практике работы пользователей, происходящих в проектных группах — как способ сделать элементы трудовой практики понятными для всех участников команды. Дизайн пользовательской среды аналогичным образом был разработан как метод фиксации структуры и функций системы, не требующий преждевременного обсуждения деталей пользовательского интерфейса.
Полученный таким образом процесс контекстуального проектирования впервые использован в корпорации DEC, а затем в течение 1980-х годов затем получил признание в быстро растущем сообществе человеко-компьютерного взаимодействия (Human Computer Interaction, HCI), пройдя тот же путь «ереси по отношению к общепринятой практике», по которому следовала собственно сама отрасль HCI. После серии статей по различным аспектам контекстного дизайна в литературе HCI процесс целиком был описан в публикации 1997 года «Контекстуальное проектирование» (Contextual Design) под авторством Бейера и Хольцблатт. В 2005 году расширенный справочник «Быстрое контекстуальное проектирование» (Rapid Contextual Design) расширил представление об этом методе и предоставил больше практических рекомендаций. В этом издании также были рассмотрены наиболее часто встречающиеся критические замечания насчет того, что для некоторых проектов/бизнесов/компаний контекстуальное проектирование может оказаться слишком трудоемким или длительным процессом.
4. Перспективные направления развития контекстуального проектирования
Ключевые элементы контекстуального проектирования стабилизировались более десятилетия тому назад и вряд ли фундаментально изменятся в ближайшем будущем. Тем не менее контекст, в котором применяется эта методология, изменяет ее саму и, скорее всего, вносит коррективы в процесс ее использования. Вот несколько перспективных направлений, на которые следует обратить внимание.
- Гибкая методология разработки (Agile development). По мере того как agile-методы становятся всё шире распространенными и всё более приемлемыми, можно ожидать, что связь между гибкой методологией разработки и процессами, ориентированными на пользователя, будет развиваться. Гибкая разработка сама по себе укрепилась благодаря мощным инструментам, ориентированным на пользователя, но интеграция последовательно сфокусированного на клиентах дизайна с agile-разработкой по-прежнему воспринимается разработчиками не очень хорошо. И внедрение новых гибких методологий, таких как канбан (Kanban), будет по-прежнему создавать проблемы при разработке хорошего пользовательского опыта (User Experience).
- Количественные методы (Quantitative techniques). В идеальном случае качественные данные, предоставляемые контекстуальным опросом, будут дополнены количественными данными, получаемыми при помощи исследовательских методов, таких как обследования. При составлении бизнес-кейса важно знать не только то, что хотят пользователи, но и сколько существует потенциальных клиентов и сколько они готовы заплатить за решение своей проблемы. Контекстуальное проектирование может и должно быть интегрировано в целостный процесс разработки и внедрения продукта.
- Проекты на уровне предприятия (Enterprise-scale projects). При осуществлении крупномасштабных проектов предприятиям для достижения бизнес-целей приходится координировать несколько рабочих потоков и деятельность сотен людей в течение многих лет. Контекстный дизайн может играть ключевую роль в выявлении наиболее важных проблем, требующих безотлагательного урегулирования, определения приоритетности развертывания решений, поддержания согласованности системного видения и обеспечения того, чтобы по мере итеративной имплементации отдельных частей системы неизбежные инженерные компромиссы не ухудшали ее юзабилити в целом.
Высоких вам конверсий!
По материалам: interaction-design.org Источник картинки: bady_qb
