WikiDer > Дизайн, ориентированный на пользователя

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

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

История

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

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

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
• Дизайн, ориентированный на пользователя, Дон Норман