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

Дизайн, ориентированный на пользователя ( UCD ), или разработка, управляемая пользователем ( UDD ) - это структура процессов (не ограниченная интерфейсами или технологиями), в которых задаются цели удобства использования , характеристики пользователя, среда , задачи и рабочий процесс продукта , услуги или процесса. большое внимание на каждом этапе процесса проектирования . Эти тесты проводятся с / без реальных пользователей на каждом этапе процесса, начиная с требований , предварительных моделей и постпроизводства, завершая круг проверок и заканчивая тем, что «разработка идет с пользователем в центре внимания». ^{[1] [2]}Такое тестирование ^[3] необходимо, так как разработчикам продукта часто очень трудно интуитивно понять, как впервые пользователь испытывает свой дизайн и как может выглядеть кривая обучения каждого пользователя . Дизайн, ориентированный на пользователя, основан на понимании пользователя, его требований, приоритетов и опыта и, как известно, при использовании приводит к повышению полезности и удобства использования продукта, поскольку он приносит удовлетворение пользователю. ^[4]

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

История [ править ]

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

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

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

В более поздней книге, эмоциональный дизайн , ^{[7] : стр.5 далее} Норман возвращается к некоторым из его более ранних идей для разработки того, что он должен был прийти , чтобы найти как чрезмерно восстановительными.

Модели и подходы [ править ]

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

Дизайн, ориентированный на пользователя, вдохновлен следующими моделями:

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

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

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

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

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

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

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

Цель [ править ]

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

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

Элементы [ править ]

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

Видимость [ править ]

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

Доступность [ править ]

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

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

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

Язык [ править ]

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

Инструменты анализа [ править ]

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

Персона [ править ]

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

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

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

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

Сценарий [ править ]

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

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

Пример использования [ править ]

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

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

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

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

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

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

См. Также [ править ]

Ссылки [ править ]

Дальнейшее чтение [ править ]

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

Видео [ править ]

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