Joel on Software

Joel on Software Джоэл о программном обеспечении

 

Руководство по UI дизайну для программистов
Глава1
Глава2
Глава3
Глава4
Глава5
Глава6
Глава7
Глава8
Глава9

Другие статьи сайта "Joel on Software" на русском языке

Другие статьи сайта "Joel on Software" на английском языке

Адрес электронной почты автора (пожалуйста, пишите только по-английски)

 

Руководство по UI дизайну для программистов
Глава6: Как создать дизайн для людей, которым есть чем заняться в этой жизни


Автор: Джоэл Сполски
Переводчик: Наталья Лунева
Техническая поддержка и моральная помощь: Алексей Матюшкин
Редактор: Евгений Дурцев
26. 4. 2000

Когда вы работаете над созданием пользовательских интерфейсов, полезно помнить о двух принципах:

  1. У пользователей нет документации, а если бы она и была, они бы ее не читали.
  2. На самом деле, пользователи не умеют читать, а если бы и умели, то не не стали бы.

 

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

Что означает «сделать простым в использовании»? Чтобы измерить простоту использования пограммы, можно представить, какой процент обычных пользователей сможет выполнить ряд заданий в отведенное время. Предположим, что ваша программа позволяет конвертировать фотографии, сделанные цифровой камерой, в веб-фотоальбом. Если вы посадите группу среднестатистических пользователей выполнять эту задачу, окажется, что чем удобнее, чем проще ваша программа в использовании, тем выше процент людей, которые успешно справяться с созданием веб-фотоальбома. Подойдем к вопросу более научно. Представьте себе 100 пользователей. Не обязательно,что они разбираются в компьютерах. Они наделены различными талантами, но некоторые из них совершенно точно не обладают талантами в компьютерной области. Некоторых из них постоянно отвлекают, когда они работают над выполнением вашего задания. Звонит телефон. ЧТО? Ребенок плачет. ЧТО? Котенок прыгает по столу, пытаясь поймать мышь. Я НЕ СЛЫШУ ВАС!

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

Пользователи не читают руководств.

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

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

Вывод из всего вышеизложенного краток: у вас нет иной альтернативы, чем кроме как спроектировать программу так, чтобы потребность в чтении руководства не возникала. Единственное исключение, которое мне приходит на ум, -- когда у ваших клиентов нет никаких базовых знаний, то есть они не понимают, что, собственно говоря, эта программа делает, но осознают, что это знание им необходимо. Хорошей иллюстрацией этого исключения является невероятно популярная программа для бухгалтерского учета в малом бизнесе - QuickBooks от Intuit. Большинство из тех, кто этой программой пользуется -- представители малого бизнеса, которые не имеют ни малейшего представления о том, что такое бухучет. Авторы руководства к QuickBooks знали об этом, как и о том, что им нужно обучить людей основым принципам бухчета. Без руководства пользоваться QuickBooks было бы невозможно. С другой стороны, люди, знакомые с бухучетом, могут спокойно работать с программой без руководства.

На самом деле, пользователи не читают ничего. Даже комиксы.

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

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

 

Аналогичное же диалоговое окно в Windows выглядит так:

 

Интуитивно можно подумать, что версия Juno с 80 словами лучше (т.е. проще в использовании), чем состоящая из пяти слов инструкция Windows. На самом деле, при проведении usability-тестирования подобных вещей можно обнаружить, что:

  • продвинутые пользователи подобные инструкции пропускают. Они знают, что надо делать, и времени на чтение сложных инструкций не имеют;
  • большинство неопытных пользователей подобные инструкции пропускают. Они не любят читать и рассчитывают на то, что установки по умолчанию им подойдут;
  • оставшиеся неопытные пользователи честно стараются прочитать инструкции (некоторые из них просто потому, что участвуют в тестировании и считают себя обязанными выполнять все инструкции). Но их часто приводит в затруднение само количество слов и понятий. Даже если при первом появлении диалогового окна они были достаточно уверены в том, что знают, что с ним делать, многословные инструкции приводят их в большее затруднение.

 

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

Другой важный момент: многие испытывают страх перед компьютером. Вам, наверное, это известно, не так ли? Но вы, скорее всего, не осознаете всех последствий этого страха. Однажды я видел, как одна моя хорошая знакомая пыталась выйти из Juno. По какой-то причине она испытывала при этом большие затруднения. Я заметил, что выход из Juno предваряется диалоговым окном со следующим содержанием:

 

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

Неужели так сложно прочитать несчастные одиннадцать слов? Очевидно, да. Во-первых, выход из Juno не влечет за собой никаких разрушительных последствий, поэтому просьба о подтверждении команды является излишней (примером тому являются все существующие GUI программы, которые обходятся без подтверждения). Если же вы убеждены в том, что подтверждение о выходе жизненно необходимо для вашей программы, эту просьбу можно выразить не в одиннадцати, а в двух словах: «Выйти сейчас?».

 

Диалог, лишенный абсолютно бесполезного «Спасибо» и вызывающей сожаление фразы «Вы уверены?», повлечет за собой гораздо меньше проблем. Человек гарантированно прочтет два слова, вздохнет, и нажмет кнопку «Да».

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

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



> Глава7

В английском оригинале статья называется User Interface Design for Programmers Chapter 6: Designing for People Who Have Better Things To Do With Their Lives  

Джоель Спольски - основатель Fog Creek Software, небольшой компании по
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.


Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky