Каким хорошим руководствам по юзабилити должен следовать средний разработчик?
Я не специалист по юзабилити, и мне действительно все равно.
Мне просто нужен небольшой набор практических правил, которым я мог бы следовать при кодировании своих пользовательских интерфейсов, чтобы мой продукт имел приличное удобство использования.
Сначала я подумал, что на этот вопрос будет легко ответить "Используй свой здравый смысл", но если бы он был настолько распространен среди нас, разработчиков, у нас как группы не было бы репутации наших ужасных интерфейсов.
Какие-либо предложения?
17 ответов
Прочтите Стив Круг, не заставляйте меня думать. Это отличная отправная точка и легкое чтение.
РЕДАКТИРОВАТЬ: Это в основном для удобства использования в Интернете, но это все равно будет хорошее чтение, даже если вы работаете с богатыми клиентами.
Просто две вещи:
- "Пользовательский интерфейс хорошо спроектирован, когда программа ведет себя именно так, как думал пользователь", - цитирует Джоэла Спольски " Дизайн пользовательского интерфейса для программистов".
- Разместите свои проекты перед пользователем. Реальный конечный пользователь лучше, но для легкой, быстрой обратной связи, вы не можете пройти тестирование юзабилити коридора, то есть захватить коллегу.
Если вы помните совет Джоэла и будете получать отзывы о том, что вы делаете, и будете выполнять его, то есть повторять, вы не ошибетесь. И я бы повторил рекомендацию Стива Круга " Не заставляй меня думать" - это, пожалуй, лучшая книга о работе, которую я когда-либо читал, без исключения, и она так же применима к программному обеспечению для настольных компьютеров, как и к веб-сайтам.
Надеюсь это поможет.
- Не заставляйте вещи работать иначе, чем ожидают ваши пользователи (например, не нажимайте кнопку "назад" при использовании Ajax в веб-формах).
- Следуй принципу KISS
Действительно, любые правила, которые кто-то публикует, будут вариацией темы:не заставляйте пользователей думать
"Не заставляй меня думать" уже опубликовано, см. Также " Дизайн повседневных вещей" и " Разработка с использованием веб-стандартов", которые также отлично подходят для легкого чтения.
Самый важный совет, который я бы дал кому-то, - это сначала поработать над пользовательским интерфейсом. Ручка и бумага и все. Таким образом, вы не будете подсознательно связывать кнопки с функциями, поля ввода с переменными и т. Д.
Лучшим пользовательским интерфейсом может быть боль в коде, и если ваш внутренний код в основном написан, это саботирует ваше мышление.
Кроме этого, я бы указал на рекомендации Apple по человеческому интерфейсу. Конечно, если ваша платформа не OS X, возьмите разделы OS X с большим количеством соли. То, что работает в OS X, может не работать в Windows. Вы должны принять идиомы своей платформы.
Помимо OS X, этот документ имеет довольно хорошие отправные точки по основам.
Избегайте режимов. Это расстраивает пользователя, когда ввод работает иногда, но не работает, или делает разные вещи в разное время.
Вот несколько простых правил:
- Меньше кликов, тем лучше.
- Часто используемые функции должны быть легче найти.
- Функции для "продвинутых" пользователей найти сложнее, чем приведенные выше.
Подумайте о том, сколько нажатий мыши / клавиатуры требуется пользователю, чтобы что-то получить.
PS - пожалуйста, не говорите об этом Microsoft Office 2008; бедные маленькие парни плакали, чтобы спать сегодня вечером!:)
Я разместил похожие вопросы:
Я предлагаю прочитать эти сообщения в блоге от создателей Enso.
Конечно, они повторяют руководства / идеи / советы из книг, таких как
Дизайн повседневных вещей и о лице, но, тем не менее, посты содержат довольно много идей и (IMO) они хорошо читаются.
Подумайте о пользователях, которые будут использовать ваше приложение. Почему они используют это и в каком контексте?
- Будет ли большинство профессиональных пользователей, которые знают домен, в котором используется приложение, и часто его используют? Тогда не бойтесь добавлять много данных на экраны, если они логически упорядочены для пользователей (обычно это не в алфавитном порядке:-). Подумайте о торговых экранах для биржевых маклеров или кабины самолетов.
- Являются ли пользователи случайными пользователями? Будь проще. Избегайте переключений контекста (сохраняйте все / как можно больше необходимых данных для задачи на экране каждый раз). Не нарушайте ожидания того, как обычно работают графические виджеты. Дизайн для сбоев.
- Что-нибудь среднее? Разрешить пользователям расти в пользовательском интерфейсе. Отслеживайте использование, чтобы впоследствии вы могли определить, где пользователи проводят больше всего времени, чтобы вы могли улучшить наиболее используемые области вашего приложения.
- Протестируйте свое приложение на друзьях и коллегах (тест коридора), чтобы увидеть, смогут ли они эффективно его использовать.
Это начало.
Хорошим продолжением "Не заставляй меня думать" является " Проектирование очевидного" Роберта Хукмана. Он больше ориентирован на веб-приложения, чем на веб-сайты, подобные Krug.
В дополнение к другим рекомендациям здесь, я бы порекомендовал Designing Interfaces от Jenifer Tidwell как хороший способ ознакомиться с соглашениями UI.
Кроме того, заключенные управляют убежищем. Алан Купер отлично подходит для понимания того, как подходить к проектированию взаимодействия.
Предоставьте сочетания клавиш для опытных пользователей (даже если это так же просто, как "нажать Enter для поиска")
Не ставьте слишком много на экране сразу.
Если вы откроете окно сообщения, ваши пользователи, как правило, никогда его не прочитают.
Какая информация нужна вашему пользователю, поместите ее на экран и ничего больше. Если вы не можете определить, что нужно пользователю - найдите другого пользователя.
- Простое лучше сложного
- Сложный лучше, чем сложный (исключите "вложенные if")
- Интуитивно понятный (хорошие элементы не нуждаются в объяснении)
- Следуйте соглашению (например, подчеркнутая означает ссылку, красный означает ошибку, вкладка переходит к следующему полю и т. Д.)
- Используйте семантику, чтобы применить логику (заголовок читается первым, параграфы следуют)
- пробел важен
(1) Общие действия должны требовать как можно меньше усилий и быть очевидными; с другой стороны, редко требующиеся действия могут потребовать много шагов и могут быть скрыты за меню и диалогами. Чтобы иметь возможность сделать это, вы должны всегда описывать, что пользователь захочет делать с приложением, перечисляя варианты использования.
(2) Пользовательский интерфейс должен быть самодокументированным. Руководство должно быть интегрировано в диалоги и меню приложения, так как пользователи не читают отдельные руководства. Например, сочетание клавиш должно отображаться в пункте меню, представляющем действие, с которым оно связано.
Помните, что ваше приложение будет одним из многих, с которыми пользователю придется иметь дело. Не делай вещи только для того, чтобы отличаться от других. Не придумывайте необычную графику, поведение, терминологию или взаимодействие. Используйте стандартные элементы управления ОС, соглашения, утилиты и поведения.
Позвольте вашему приложению взаимодействовать с другими приложениями; позволяет вырезать и вставлять данные, сохранять данные в форматах, которые могут прочитать другие приложения, и разрешать импорт данных из других приложений вместо использования вашего пользовательского интерфейса.
Если вы создаете настольное приложение, не пытайтесь захватить компьютер пользователя. Оставьте пользовательскую папку "Документы", панель задач и настройки приложения в покое. Не меняйте ничего, что уже установлено на компьютере. Разрешить взаимодействие по сценарию или из командной строки.
Если вы создаете веб-приложение, не пытайтесь захватить браузер. Не пытайтесь подорвать стандартные строки меню, историю, макет или шрифты. Разрешить пользователю изменять страницу с помощью Javascript.