Я не специалист по юзабилити, и я действительно не хочу быть таким.
Я просто хочу небольшой набор правил, которыми я могу следовать при кодировании моих пользовательских интерфейсов, чтобы мой продукт имел достойную юзабилити.
Сначала я подумал, что на этот вопрос будет легко ответить "Использовать здравый смысл", но если это так распространено среди разработчиков, мы бы не стали, как группа, иметь репутацию наших ужасных интерфейсов.
Любые предложения?
Источник: http://stuffthathappens.com/blog/wp-content/uploads/2008/03/simplicity.png
Прочитайте Не заставляйте меня думать Стивем Кругом. Это отличная отправная точка и легкое короткое чтение.
EDIT: это, в основном, для удобства использования в Интернете, но это все равно будет хорошим, даже если вы делаете богатых клиентов.
Только две вещи:
Если вы помните совет Джоэля и убедитесь, что получаете обратную связь о том, что вы делаете и действуете на нем, то есть итерации, вы не ошибетесь. И я бы повторил рекомендацию для Стива Круг Do not Make Me Think - это, наверное, лучшая работа, связанная с книгой, которую я прочитал, бар нет, и так же применимо к настольному программному обеспечению, как веб-сайты.
Надеюсь, что это поможет.
Действительно, любые правила, которые кто-то публикует, будут вариацией на тему: Не думайте, чтобы ваши пользователи думали
"Do not Make Me Think" уже опубликован, см. также Дизайн повседневных вещей и Проектирование с использованием веб-стандартов также хороши для чтения юзабилити света.
Самый важный совет, который я бы дал кому-то, - это сначала работать с пользовательским интерфейсом. Ручка и бумага и все. Таким образом, вы не будете подсознательно связывать кнопки с функциями, вводить поля в переменные и т.д.
Лучшим пользовательским интерфейсом может быть боль в коде, и если ваш основной код в основном написан, он будет саботировать ваше мышление.
Кроме этого, я бы указал на Руководство по человеческому интерфейсу Apple. Конечно, если ваша платформа не является OS X, возьмите разделы OS X с большим количеством соли. Что работает в OS X может не работать в Windows. Вы должны использовать идиомы вашей платформы.
OS X в стороне, этот документ имеет некоторые неплохие отправные точки на основе.
Избегайте modes. Это разочаровывает пользователя, когда вход работает иногда, но не другие, или делает разные вещи в разное время.
Вот несколько простых правил:
Подумайте о количестве щелчков мыши/клавиатуры, которые требуется пользователю, чтобы что-то сделать.
PS - пожалуйста, не сообщайте об этом сотрудникам Microsoft Office 2008; бедные маленькие ребята будут плакать, чтобы спать сегодня вечером!:)
Я разместил связанные вопросы:
Подумайте о пользователях, которые будут использовать ваше приложение. Почему они используют его и в каком контексте?
Это начало.
Я предлагаю прочитать эти сообщения в блогах из Enso.
Конечно, они повторяют руководства/идеи/советы из таких книг, как: Дизайн повседневных вещей и О Face, но тем не менее, сообщения содержат довольно много сведений и (ИМО), которые они хорошо читают.
Какая информация вам нужна, поместите ее на экран и ничего больше. Если вы не можете определить, что нужно пользователю - получите другого пользователя.
Помните, что ваше приложение будет одним из многих, с которым придется иметь дело. Не делайте ничего, чтобы быть другим или kewl. Не придумывайте необычную графику, поведение, терминологию или взаимодействия. Используйте стандартные элементы управления ОС, соглашения, утилиты и поведение.
Позвольте вашему приложению взаимодействовать с другими приложениями; разрешить вырезание и вставку данных, сохранять ваши данные в форматах, которые могут читать другие приложения, и разрешать импорт данных из других приложений вместо использования пользовательского интерфейса.
Если вы создаете настольное приложение, не пытайтесь взять на себя компьютер пользователя. Оставьте папку "Документы" пользователя, панель задач и настройки приложения. Не изменяйте ничего, что уже установлено на компьютере. Разрешить взаимодействие по сценарию или командной строке.
Если вы создаете веб-приложение, не пытайтесь захватить браузер. Не пытайтесь подорвать стандартные строки меню, историю, макет или шрифты. Разрешить пользователю изменять страницу с помощью Javascript.
(1) Общие действия должны требовать как можно меньше усилий и должны быть очевидными; с другой стороны, действия, которые редко нужны, могут потребовать много шагов и могут быть скрыты за меню и диалогами. Чтобы это сделать, вы всегда должны описывать, что пользователь захочет делать с приложением, перечисляя примеры использования.
(2) UI должен быть самодокументирован. Руководство должно быть интегрировано в диалоги приложений и меню, так как пользователи не читают отдельные руководства. Например, ярлык клавиатуры должен отображаться в элементе меню, представляющем действие, с которым оно связано.
Обеспечьте сочетания клавиш для опытных пользователей (даже если это так просто, как "hit enter to search" )
Не ставьте слишком много на экран сразу.
Если вы всплываете в виде сообщения, ваши пользователи обычно его не читают.
В дополнение к другим рекомендациям здесь я бы рекомендовал "Проектирование интерфейсов" Jenifer Tidwell как хороший способ ознакомиться с соглашениями пользовательского интерфейса.
Кроме того, Заключенные управляют убежищем. Алан Купер отлично подходит для понимания того, как подойти к дизайну взаимодействия.
Хороший подход к Do not Make Me Think Роберт Хекман Проектирование очевидного. Он больше ориентирован на веб-приложения, в отличие от веб-сайтов, таких как в Krug's.
