Что говорит Якоб Нильсен: последние 5 из 10 эвристических правил хорошего интерфейса

Мы настолько привыкли к некоторым интерфейсам, что правила нам кажутся очевидными. И зачем об этом говорить?  Но предполагаем, что эта не совсем уж и новость будет нелишней для начинающих разработчиков, которые книгу, являющуюся классикой, не читали. «Классика – вчерашний день, а мы должны идти впереди планеты всей», - таков ход мыслей новичка-разработчика. Что можно на это ответить? Хорошо усовершенствовать велосипед, когда колеса изобретены. Но о том, что они уже изобретены, знать надо.

6. Лучше понимать, чем запоминать

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

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

7. Интерфейс для каждого

Дилемма: интерфейс для новичка или бывалого? Конечно, есть узконаправленные программы для пользователей, которые впервые в интернете и для опытных пользователей. Но их не так много. Некоторые разработчики прибегают к двух- и даже трехвариантным программам (новичок, эксперт, мастер). Это неплохо работает в игровых программах, но не всегда является удобным вариантом для неигровых интерфейсов.

Лучше всего здесь поступить так, функции, способные повлиять на скорость выполнения работы, просто не видны начинающим, либо не мешают им. Как, например, выполнение программы с помощью набора клавиш («горячие клавиши»). Не обременительно и не мешает новичкам, но легкий доступ опытным пользователям. Еще один великолепный вариант: Мастер, который проводит новичка за руку.

В общем, варианты есть, если хорошо подумать.

8. В дизайне ничего лишнего

Сразу оговоримся, подразумевается дизайн интерфейса. Конечно, минимализм в дизайнерском оформлении  приветствуется в программах широкого профиля (Яндекс, например), но на обычном сайте, тем более в игре, надо думать от эстетическом оформлении. Вернемся к минимализму. Любая лишняя деталь отвлекает пользователя от работы. Чем меньше, тем эффективнее.

9. Определение и исправление ошибочных действий

Слова Якоба Нельсона: "Помогайте пользователю распознавать и исправлять ошибки ". Об ошибках надо не только сообщать, но непременно должно быть указано, как эта ошибка может быть исправлена. То есть исправление ошибки должно состоять из двух составляющих:

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

Лучшее решение проблемы – создание справочного раздела с описанием проблемы, иногда это занимает много места и появление подробностей в диалоговом окне загромождает программу. Лучше предусмотреть кнопку обращения к справочному разделу. Создание справочного раздела – очень нудное занятие для программистов, но чего не сделаешь для хорошего интерфейса!

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

Думать, что сообщения типа "Error 404" – это круто, неверно, среднестатистический пользователь, не понимая ничего, закрывает окно и пытается снова открыть программу. Вам такая «крутизна» нужна?

Составление описания ошибок и правильность реакции программы необходимо периодически проверять. Даже известные интерфейсы грешат неправильной идентификацией ошибок.

Не все пользователи догадываются нажать на кнопку помощи (парадокс: в жизни мы, если что-то не понимаем, обращаемся за советом, а вот при работе с программой эта очевидность не срабатывает).

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

10. Документация

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

Правила удобства пользования сформулированы Якобом Нильсеном в 1990 году, но они актуальны по сей день. Разработчики дизайна интерфейса считают их обязательным минимумом. Все остальное – дополнительные «навороты».