Какими хорошими руководящими принципами юзабилити должен следовать средний разработчик?

Я не специалист по юзабилити, и я действительно не хочу быть таким.

Я просто хочу небольшой набор правил, которыми я могу следовать при кодировании моих пользовательских интерфейсов, чтобы мой продукт имел достойную юзабилити.

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

Любые предложения?

Ответы

Ответ 2

Прочитайте Не заставляйте меня думать Стивем Кругом. Это отличная отправная точка и легкое короткое чтение.

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

Ответ 3

Только две вещи:

  • "Пользовательский интерфейс хорошо разработан, когда программа ведет себя точно так, как пользователь считал, что это будет" - цитируется от Joel Spolsky Дизайн пользовательского интерфейса для программистов
  • Поместите свои проекты перед пользователем. Настоящий конечный пользователь лучше всего, но для легкой и быстрой обратной связи вы не можете бить проверку удобства использования прихожей, то есть захватить сотрудника.

Если вы помните совет Джоэля и убедитесь, что получаете обратную связь о том, что вы делаете и действуете на нем, то есть итерации, вы не ошибетесь. И я бы повторил рекомендацию для Стива Круг Do not Make Me Think - это, наверное, лучшая работа, связанная с книгой, которую я прочитал, бар нет, и так же применимо к настольному программному обеспечению, как веб-сайты.

Надеюсь, что это поможет.

Ответ 4

  • Не делайте работу по-другому, чем ожидаете ваши пользователи (т.е. отключаете кнопку "назад" при использовании Ajax в веб-формах
  • Следуйте за директором K.I.S.S

Действительно, любые правила, которые кто-то публикует, будут вариацией на тему: Не думайте, чтобы ваши пользователи думали

"Do not Make Me Think" уже опубликован, см. также Дизайн повседневных вещей и Проектирование с использованием веб-стандартов также хороши для чтения юзабилити света.

Ответ 5

Самый важный совет, который я бы дал кому-то, - это сначала работать с пользовательским интерфейсом. Ручка и бумага и все. Таким образом, вы не будете подсознательно связывать кнопки с функциями, вводить поля в переменные и т.д.

Лучшим пользовательским интерфейсом может быть боль в коде, и если ваш основной код в основном написан, он будет саботировать ваше мышление.

Кроме этого, я бы указал на Руководство по человеческому интерфейсу Apple. Конечно, если ваша платформа не является OS X, возьмите разделы OS X с большим количеством соли. Что работает в OS X может не работать в Windows. Вы должны использовать идиомы вашей платформы.

OS X в стороне, этот документ имеет некоторые неплохие отправные точки на основе.

Ответ 6

Избегайте modes. Это разочаровывает пользователя, когда вход работает иногда, но не другие, или делает разные вещи в разное время.

Ответ 7

Вот несколько простых правил:

  • Чем меньше кликов, тем лучше.
  • Часто используемые функции должны быть проще найти.
  • Возможности для "продвинутых" пользователей могут быть труднее найти, чем выше.

Подумайте о количестве щелчков мыши/клавиатуры, которые требуется пользователю, чтобы что-то сделать.

PS - пожалуйста, не сообщайте об этом сотрудникам Microsoft Office 2008; бедные маленькие ребята будут плакать, чтобы спать сегодня вечером!:)

Ответ 9

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

  • Будет ли большинство пользователей, которые знают домен, в котором используется приложение, и много используют приложение? Тогда не бойтесь добавлять много данных на экраны, если они логически установлены для пользователей (обычно это не в алфавитном порядке:-). Подумайте о торговых экранах для запасных борцов или кабин самолетов.
  • Являются ли пользователи случайными пользователями? Будь проще. Избегайте переключателей контекста (каждый раз сохраняйте все/как можно больше необходимых данных для задачи на экране). Не нарушайте ожидания того, как обычно видят виджеты gui. Дизайн для отказов.
  • Что-нибудь между ними? Разрешить пользователям расти в пользовательском интерфейсе. Отслеживайте использование, чтобы впоследствии определить, где пользователи, как правило, проводят больше времени, поэтому вы можете улучшить наиболее используемые области вашего приложения.
  • Проверьте свое приложение на друзей и коллег (тест в коридоре), чтобы узнать, могут ли они эффективно использовать его.

Это начало.

Ответ 10

Я предлагаю прочитать эти сообщения в блогах из Enso.

Конечно, они повторяют руководства/идеи/советы из таких книг, как:  Дизайн повседневных вещей и О Face, но тем не менее, сообщения содержат довольно много сведений и (ИМО), которые они хорошо читают.

Ответ 11

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

Ответ 12

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

Позвольте вашему приложению взаимодействовать с другими приложениями; разрешить вырезание и вставку данных, сохранять ваши данные в форматах, которые могут читать другие приложения, и разрешать импорт данных из других приложений вместо использования пользовательского интерфейса.

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

Если вы создаете веб-приложение, не пытайтесь захватить браузер. Не пытайтесь подорвать стандартные строки меню, историю, макет или шрифты. Разрешить пользователю изменять страницу с помощью Javascript.

Ответ 13

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

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

Ответ 14

Обеспечьте сочетания клавиш для опытных пользователей (даже если это так просто, как "hit enter to search" )

Не ставьте слишком много на экран сразу.

Если вы всплываете в виде сообщения, ваши пользователи обычно его не читают.

Ответ 15

  • Простой лучше, чем сложный
  • Комплекс лучше, чем сложный (исключить "вложенные ifs" )
  • Интуитивно понятный (хорошие элементы не требуют объяснений)
  • Следуйте за соглашением (например, подчеркнутая ссылка означает, красный означает ошибку, вкладка переходит к следующему полю и т.д.)
  • Используйте семантику для применения логики (сначала заголовок заголовок, параграфы)
  • важна пробел.

Ответ 16

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