Путеводитель по человеко-компьютерному взаимодействию: контекстуальное проектирование

Posted on by riasevastopol

Контекстуальное проектирование (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. Принцип: дизайн зависит от конкретных представлений

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

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

Эти физические репрезентации в контекстном дизайне обрисованы в следующем разделе.

Просматривайте кроме этого: Тестирование UX-прототипов как нужное звено разработки продукта

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) и маркетинговых интеракций (ShoppingCheckout).

Рисунок 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. Разработка пользовательской среды

Раскадровки снабжают согласованность отдельных задач, но новая совокупность кроме этого должна иметь соответствующую структуру для помощи естественного рабочего потока через совокупность — независимо от того, какую задачу делает пользователь. Так же, как архитекторы рисуют замыслы этажей, дабы заметить структуру будущего дома в количестве, разработчикам нужно рассмотреть «поэтажный замысел» собственной новой совокупности — главную структуру, которая будет продемонстрирована как эскиз интерфейса пользователя, реализована в качества объектной модели и будет отвечать требованиям клиента. Данный «поэтажный замысел» в ходе проектирования в большинстве случаев не приобретает яркого отражения.

Дизайн пользовательской среды фиксирует «поэтажный замысел» новой совокупности. Он показывает каждую часть совокупности да и то, как она поддерживает работу пользователя, какая в точности функция дешева в данной части, и как пользователь может перейти к вторым частям совокупности — без привязки данной структуры

Случайные статьи:

07 02 Лекция «Ай-трекер и человеко-компьютерное взаимодействие»


Подборка похожих статей:

riasevastopol

More Posts