Ориентированный на пользователя дизайн

Сравните дизайн, ориентированный на использование , и дизайн, ориентированный на использование .

См. Также: Дизайн, ориентированный на человека.

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

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

История

Термин «пользовательский дизайн» был придуман Робом Клингом в 1977 году. и позже принят в Дональда А. Нормана исследовательской лаборатории в Калифорнийском университете в Сан-Диего . Эта концепция стала широко популярной после публикации в 1986 году книги « Проектирование систем, ориентированных на пользователя: новые перспективы взаимодействия человека и компьютера» . Эта концепция получила дальнейшее внимание и признание в основополагающей книге Нормана « Дизайн повседневных вещей» (первоначально называвшейся «Психология повседневных вещей»). ). В этой книге Норман на примерах описывает психологию того, что он считает «хорошим» и «плохим» дизайном. Он превозносит важность дизайна в нашей повседневной жизни и последствия ошибок, вызванных плохим дизайном.

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

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

В более поздней книге « Эмоциональный дизайн » Норман возвращается к некоторым из своих ранних идей, чтобы уточнить то, что он счел чрезмерно упрощенным.

Модели и подходы

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

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

• Совместное проектирование : вовлечение дизайнеров и пользователей на равных. Это скандинавская традиция проектирования ИТ-артефактов, развивающаяся с 1970 года. Это также называется совместным дизайном .
• Совместный дизайн (PD), североамериканский термин для той же концепции, вдохновленный кооперативным дизайном, фокусируется на участии пользователей. С 1990 года два раза в год проводится совместная конференция по дизайну.
• Контекстуальный дизайн , «ориентированный на клиента дизайн» в реальном контексте, включая некоторые идеи совместного дизайна.

Вот принципы, которые помогают обеспечить ориентированность дизайна на пользователя:

1. Дизайн основан на четком понимании пользователей, задач и окружающей среды.
2. Пользователи участвуют в проектировании и разработке.
3. Дизайн определяется и совершенствуется на основе оценки, ориентированной на пользователя.
4. Процесс является итеративным.
5. Дизайн учитывает весь пользовательский опыт.
6. Команда дизайнеров включает в себя многопрофильные навыки и взгляды.

Процесс проектирования, ориентированный на пользователя

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

1. Укажите контекст использования : определите, кто являются основными пользователями продукта, почему они будут использовать продукт, каковы их требования и в какой среде они будут его использовать.
2. Укажите требования : как только контекст определен, пришло время определить подробные требования к продукту. Это важный этап, который может помочь дизайнерам создавать раскадровки и ставить важные цели для достижения успеха продукта.
3. Создание проектных решений и разработка . На основе целей и требований к продукту начните итеративный процесс проектирования и разработки продукта.
4. Оценка продукта . Дизайнеры продуктов проводят тестирование удобства использования, чтобы получить отзывы пользователей о продукте на каждом этапе пользовательско-ориентированного дизайна.

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

Цель

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

• Кто являются пользователями сайта?
• Каковы задачи и цели пользователей?
• пользователей Каков уровень опыта на этом веб-сайте и аналогичных веб-сайтах?
• Какие функции нужны пользователям на сайте?
• Какая информация может понадобиться пользователям и в какой форме она им нужна?
• Как, по мнению пользователей, должен работать сайт?
• В каких экстремальных условиях возможен доступ к веб-сайту?
• Многозадачен ли пользователь?
• Использует ли интерфейс различные режимы ввода, такие как касание, речь, жесты или ориентация?

Элементы

В качестве примера точек зрения UCD, основными элементами UCD веб-сайта обычно являются соображения видимости, доступности, удобочитаемости и языка.

Видимость

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

Доступность

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

Разборчивость

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

Язык

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

Инструменты анализа

Существует ряд инструментов, которые используются при анализе пользовательско-ориентированного дизайна, в основном: персонажи, сценарии и основные варианты использования.

Человек

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

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

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

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

Сценарий

Сценарий , созданный в процессе UCD, представляет собой вымышленную историю о «повседневной жизни» или последовательности событий с основной группой заинтересованных сторон в качестве главного героя. Обычно в качестве главного героя этой истории используется созданный ранее персонаж. История должна быть связана с событиями, которые связаны с проблемами основной группы заинтересованных сторон и, как правило, с основными исследовательскими вопросами, на которых строится процесс проектирования. Это может оказаться простой историей о повседневной жизни человека. Тем не менее, мелкие детали событий должны подразумевать подробности о пользователях и могут включать эмоциональные или физические характеристики. Может быть лучший сценарий , когда у главного героя все складывается наилучшим образом, худший сценарий , когда главный герой чувствует, что все вокруг него идет не так, и средний сценарий , который представляет собой типичную жизнь. человека, где не происходит ничего особенного или удручающего, и день продолжается.

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

Вариант использования

Короче говоря, вариант использования описывает взаимодействие между человеком и остальным миром. Каждый вариант использования описывает событие, которое может произойти в течение короткого периода времени в реальной жизни, но может состоять из сложных деталей и взаимодействий между действующим лицом и миром. Он представлен как серия простых шагов, которые персонаж должен выполнить для достижения своей цели с помощью причинно-следственной схемы. Варианты использования обычно записываются в виде диаграммы с двумя столбцами: первый столбец называется «Актер» , второй — «Мир» , а действия, выполняемые каждой стороной, записаны по порядку в соответствующих столбцах. Ниже приведен пример варианта использования песни на гитаре перед публикой.

Актер	Мир
выбрать музыку для воспроизведения
взять в руки гитару
	показать ноты
исполните каждую ноту в нотах, используя гитару
	передать заметку аудитории с помощью звука
	аудитория дает обратную связь исполнителю
оценивать производительность и корректировать ее по мере необходимости на основе отзывов аудитории
полная песня с необходимыми изменениями
	аплодисменты аудитории

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

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

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

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

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

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

См. также

• Исследование действий
• Активно-ориентированный дизайн
• Внимательный пользовательский интерфейс
• Главный специалист по опыту (CXO)
• Компонентное юзабилити-тестирование
• Контекстуальный запрос
• Дизайнерское мышление
• Эмпатический дизайн
• Экстремальные пользователи
• Компромисс между гибкостью и удобством использования
• Человеко-ориентированные вычисления
• Человеко-ориентированные системы
• Человеко-ориентированный дизайн
• Информационная архитектура
• Дизайн взаимодействия
• Мета-дизайн
• Бумажное прототипирование
• Совместный дизайн
• Процессно-ориентированный дизайн
• Танаточувствительность
• Трансгенерационный дизайн
• Повсеместные вычисления
• Удобство использования
• Всемирный день юзабилити

Дальнейшее чтение

• ISO 13407:1999 Человеко-ориентированные процессы проектирования интерактивных систем.
• ISO 9241-210:2010 Эргономика взаимодействия человека и системы. Часть 210. Человеко-ориентированное проектирование интерактивных систем.

Видео

• Дизайн, ориентированный на человека, Дэвид Келли из IDEO
• Пользовательско-ориентированный дизайн, Дон Норман