http://www.jnd.org Don Norman. Licensed under the Creative Commons Attribution, Non Commercial 4.0 International License.
Многие имеют сложности с моей статьёй в журнале Interactions "Человеко-ориентированное проектирование считается вредным" (англ.), перевод на русский.
- (Это преуменьшение! Об этом было сделано более 500 комментариев и записей в блогах)
В частности, я не смог разъяснить, что имел в виду под «проектированием, ориентированным на деятельность» и как это отличается от человеко-ориентированной разработки.
Некоторые люди думаю, что я полностью отверг всё, что говорил в прошлом. Другие просто считают, что я совершенно чокнулся. А другие поторопились в объяснении того, что я, должно быть, имел в виду.
Я не думаю, что что-либо поменялось в том, что я защищал. Я вижу свою работа частью связного шаблона, кочующего среди продуктов и услуг, которые действительно удовлетворяют потребности людей.
Проблема, однако, в том, что человеко-ориентированное проектирование было разработано как ограниченное видение дизайна. Вместо рассмотрения человеческой деятельности в целом оно в основном сфокусировано на постраничном, пошаговом анализе. Как результат, последовательности, прерывания, слабо определённые цели – все аспекты реальной деятельности – проигнорированы. И сообщения об ошибках – не должно быть сообщений об ошибках. Все сообщения должны содержать пояснения и предлагать альтернативные пути продолжения в самом сообщении.
Эти изменения возможны только если кто-то будет иметь более широкий взгляд – взгляд, ориентированный на деятельность.
Но никого такого нет в сегодняшнем человеко-ориентированном проектировании. Они должны быть, но их нет.
Фокусируясь на задачах, которые должны быть выполнены и деятельности, которая на самом деле осуществляется, я надеюсь расширить взгляды людей на то, что должно быть рассмотрено.
Должно быть ещё одно изменение, ставящее скорее акцент, чем делающее обобщение. Должно уделяться больше внимания отдельным людям, должны делаться попытки моделирования их поведения и создания сценариев и «персонажей». Я думаю, большая часть такой работы неуместна, не относится к делу и потенциально вредна, если отвлекает ограниченные ресурсы и время команды разработчиков от того, что действительно может быть полезно.
Сценарии и персонажи бесполезны? Нет, сценарии великолепны для маркетинга. Персонажи великолепны для общения. Но для великого дизайна – разрабатывайте для деятельности.
Сценарии обычно заданы на слишком высоком уровне, чтобы иметь значение для разработки конкретных элементов интерфейса. Диаграммы задач важны.
Задачи – это ситуации с одной, чётко заданной целью, такой как «ответить на это письмо электронной почты». Деятельность – это большие группы, состоящие из множества задач, которые выполняются вместе, такие как «просмотреть корреспонденцию за день», что означает чтение писем электронной почты, ответы, поиск информации, копирование и вставку в письма, проверку календарей и другие связанные задачи.
Для меня анализ ошибок – это хорошее место для улучшений. Обычно разработчики думают о порядке, в котором деятельность будет совершаться. Но они редко хорошо продумывают, что делать, когда пользователь сталкивается с проблемами или когда ситуация непонятна.
Не важно, называется ли анализ анализом задач, диаграммой задач, сценарием, анализом деятельности или диаграммой деятельности. Что важно, так это детальный анализ шагов, совершаемых пользователем в случае, если что-то пошло не так. Что вы должны сказать пользователю? Какие варианты выбора предложить?
Что бы захотел пользователь сделать в каждой ситуации?
Относительно легко проработать случаи, когда всё идёт хорошо или когда вся необходимая информация доступна в соответствующем формате. Хороший дизайн, впрочем, будет обрабатывать неожиданные ситуации, когда встречаются особые случаи, когда информация введена некорректно или не полностью, или корректно, но не в том месте или не в той последовательности.
Это та ситуация, когда возникает разница между приятным и раздражающим опытом.
Один из способов спроектировать обработку неожиданных ситуаций – просмотреть все сообщения об ошибках, определить, почему они могут возникнуть и переделать систему так, чтобы они либо никогда не возникли, либо, если они могут возникнуть, то в виде помощи. Не «справка», которая говорит пользователю, что должно быть сделано, а «помощь», которая предлагает соответствующее действие и делает простым продолжение, даже если пользователь сознательно ввёл неполную информацию, чтобы получить подсказку.
Помните: «превосходное» поведение редко возникает. Практически каждая ситуация – это особый случай. Поэтому разрабатывайте для особых случаев, разрабатывайте для того, чтобы изжить сообщения об ошибках.
Я верю, что мы должны усилить наш фокус на совершаемых задачах и деятельности и ослабить фокус на этих милых, но бесполезных сценариях и персонажах. Если я вправду понимаю задачу, если я вправду понимаю связь задач, которые вместе составляют деятельность, и если я вправду понимаю препятствия, слабо определённый подход большинства людей к их деятельности, то я могу предоставить значительно лучшую поддержку деятельности, чем если бы я фокусировался на тренированности, возрасте или персональности отдельных людей, которые используют продукт
Разработка для деятельности и остального позаботится о себе лучше, чем наоборот – разработка для человека без соответствующей поддержки деятельности.
Однажды, я надеюсь получить возможность расширить это исследование.
Дон Норман является соучредителем «Nielsen Norman Group», профессором в Северо-Западном университете (США), автором. Одна из последних книг – «Emotional Design». Страница Дона Нормана в Интернете – www.jnd.org
Source (EN): Don Norman. Translation (RU): Ales Vilchytski. Licensed under the Creative Commons Attribution, Non Commercial 4.0 International License.