Недавно прочитал "Дизайн привычных вещей" Дональда Нормана. Норман – computer scientist, и когнитивный психолог, известный и авторитетный специалист по эргономике. Он популяризовал сам термин "user experience", и был, вероятно, первым User Experience Architect – в Apple, что совершенно не удивляет.
На его книгу я наткнулся совершенно случайно, и залип с первых страниц. Книга написана в 1986 году, и Норман в предисловии пишет, что сознательно не переписывал разделы про кнопочные телефоны и видеомагнитофоны – технику того времени, давно уже канувшую в лету. Я немного опасался, что читать про проблемы интерфейса вещей, которые уже 20 лет никем не используются, будет скучно – но нет, наоборот. Вещи из 80-х проще, и ошибки дизайна на их примере понятнее – и но совершенно очевидно, что современные дизайнеры, проектируя гораздо более сложные вещи, продолжают делать ровно такие же ошибки.
Вообще, возникает ощущение, что все дизайнеры пользовательских интерфейсов книгу Нортона прочитали еще в 80-х – а потом организовались в тайное общество с целью доказать, что Нортон ошибался. Что можно сделать все ровно наоборот, и мир не провалится в ад, и пользователи не поедут кукухой, а даже будут говорить, что довольны. И за 34 года это тайное общество добилось впечатляющих успехов – дизайн большинства вещей отвратительный, кукухой поехали не все, и мир действительно никуда не провалился.
Может быть, лучше бы провалился.
Но я пишу про его книгу не для того, чтобы обсудить ошибки дизайна дверных ручек и водопроводных кранов, и даже не для того, чтобы обсудить, как он в 80-х видел компьютерные интерфейсы будущего – поверьте, в изложении Нортона это очень интересно, но для этого блога немного мимо. Меня поразило другое: насколько легко все, о чем говорит Нортон, переносится на backend & serverside, на проектирование софта и API.
Чтобы не быть голословным, вот чеклист хорошего дизайна вещей из книги:
- Насколько легко можно определить функцию устройства на глаз?
- …указать возможные действия пользователя
- …определить, какому намерению какое действие соответствует
- …выполнить действие
- …понять, находится ли система в нужном состоянии?
- …сказать, в каком состоянии находится система?
- …определить соответствие между состоянием и его интерпретацией
Если заменить "пользователя" на "прикладного программиста", а "устройство" на API, то этот чеклист можно хоть сейчас вписывать в code guide.
В общем-то, это и не удивительно – хотя канонически API это интерфейс прикладного программирования, но гораздо точнее было бы его называть интерфейсом для прикладного программиста. И в этом смысле для прикладного программиста API какой-то системы – это ровно то же самое, что панель управления видеомагнитофоном для пользователя видеомагнитофона.
А вот 4 принципа хорошего дизайна, в версии Нортона:
- Наглядность
- Ясная концептуальная модель
- Хорошее соответствие (между действиями и результатами, между кнопками и их функциями, между состоянием системы и его отображением)
- Обратная связь о результате действий
Может, уже не так очевидно переносится на программный дизайн (хотя по-моему вполне), но это все-таки принципы – что-то более философское и более размытое, чем пункты чеклиста.
Большую часть книги Нортон разбирает конкретные ошибки дизайна – на примере дверных ручек, водопроводных кранов, и пультов управления телевизорами. Эти конкретные ошибки уже не всегда имеют прямые аналоги в программном дизайне – но пересечений и тут достаточно много.
Ценность этих пересечений не в том, чтобы еще раз увидеть, как не надо делать – по проектированию ПО написано достаточно много книг, и почти все, о чем пишет Нортон, не является новым (как-никак, с 1986 года прошло немало времени).
Ценность для меня вот в чем: на примере дизайна материальных объектов становится очевидно, что принципы хорошего (человеко-ориентированного) дизайна гораздо универсальнее и шире программной инженерии. До сих пор многие программисты всерьез считают, что вопросы хорошего или плохого дизайна, хорошего или плохого стиля программирования – это субъективная вкусовщина. Мол, кому поп, кому попадья, а кому верблюд сойдет, и вообще все фломастеры на толщину разные.
Но это не так. Да, какие-то части хорошего стиля субъективны – но многие из правил хорошего стиля и хорошего дизайна опираются на когнитивную психологию, на то, каким образом наш мозг воспринимает и обрабатывает информацию. В какой-то форме информацию ему воспринимать удобнее, и обрабатывать ее проще, а в какой-то форме воспринимать информацию менее удобно, и обрабатывать ее тяжелее – когнитивная нагрузка растет, мозг быстрее устает, и чаще делает ошибки.
Например, основная идея у Нортона (как я ее понял) в том, что мозг всегда пытается поменьше думать делать сам, и побольше полагаться на подсказки окружающего мира (кажется, в современной когнитивной психологии это называется концепцией extended/situated cognition). Чем больше этих подсказок, и чем они вернее – тем мозгу легче, и тем быстрее и точнее он справляется с задачами:
"Не все знания, которые определяют точность действий, удерживаются в памяти … часть хранится в уме (внутренние знания), часть – в окружающем мире (внешняя информация) и часть – в ограничителях окружающего мира. … поведение определяется сочетанием внутренних знаний с внешней информацией и ограничителями окружающего мира. … человек так организует свою жизнь, чтобы его окружали напоминания о том, что ему нужно сделать."
И поэтому "правильные" предметы внешнего мира (а для программистов – артефакты кода) должны помогать мозгу – подсказывать ему верные действия, дополнять его знания, и ограничивать неверные действия.
И смотрите, насколько это пересекается с общеизвестными правилами хорошего стиля и дизайна: ясные имена (подсказка), инкапсуляция (ограничение), immutability (ограничение), комментарии (подсказка), ясные абстракции (простая концептуальная модель, подсказка)…
(Конечно, то, о чем пишет Нортон в "дизайне привычных вещей" – это далеко не все, что известно когнитивной психологии о том, как делать вещи для людей – это, в конце-концов, популярная книга, а не учебник)
P.S. Книгу рекомендую – помимо всего прочего она написана очень просто, читается легко и быстро, а идей содержит изрядно.
Комментариев нет:
Отправить комментарий