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

1. Напишите интерфейс.
2. Отложите его на время, желательно на время, чтобы вы забыли, как именно он работает.
3. Используйте его, чтобы делать что-нибудь, когда вы немного спешите или отвлекаетесь иным образом.
4. Что-то сломается. , или заставить вас делать вещи вручную, которые не были покрыты. Для каждого напишите отчет об ошибке / функции. (Если вы так торопитесь, напишите ровно столько, чтобы напомнить вам позже. )
5. Исправьте / рассмотрите каждый отчет.
6. Перейдите к шагу 2.

Этот опыт даст вам понимание того, как писать лучшие интерфейсы, некоторые из которых могут быть полезны как непрофессионалам, так и техническим специалистам. Однако будьте осторожны; не каждая функция, которая хороша для разработчиков, хороша для не разработчиков. Шаги 2 и 3 предназначены для того, чтобы сформировать у вас мышление, не являющееся разработчиками, и помочь вам в большинстве случаев; на «последней миле» ничто не заменит реального пользователя.

Использование реальных людей: тест, тест, тест.

Быстрый поиск в Google показал следующее:

http://www.asktog.com/basics/firstPrinciples.html

http://www.ambysoft.com/essays/ userInterfaceDesign.html

Пойдите и прочтите Контроль над окружающей средой делает вас счастливым , а затем прочтите Не заставляйте меня думать! Здравый смысл в удобстве веб-использования .

Будьте проще, не игнорируйте соглашения и имитируйте сайты / программы, которые работают хорошо.

Я всегда пытаюсь запомнить «7 элементов (максимум) на страницу / форму». Он возник на моем уроке графического интерфейса в колледже (7 или 8 лет назад).

Мне вспоминается веб-комикс, где был дизайн Apple, за которым следовал дизайн Google (оба очень простые), а затем «наш» дизайн с десятками элементов, засоряющих форму.

Знайте своих пользователей.

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

В произвольном порядке (и из моей головы):

• Соглашение важнее последовательности
• Возможности (по внешнему виду ясно, как и что что-то делает)
• Избегайте режимов
• Разрешить пользователю создать правильную мысленную модель
• Защитить данные (сделать их трудными для разрушения)

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

Это не совсем соответствует вашим требованиям к маркированному списку, но я все же рекомендую прочитать Суть отличного пользовательского интерфейса - Обзор , Почему так сложно достичь отличного пользовательского интерфейса? , Отличный интерфейс, четкость и актуальность информации , Великий пользователь Интерфейсы, четкость и параллельная информация и Отличный интерфейс: четкость и цвет на уровне представления .

Он также рассказывает о некоторых из тех же концепций в dnrTV эпизоды Марк Миллер о науке об отличном пользовательском опыте, часть 1 и , часть 2 .

Я бы добавил последовательность

- Ли

Nielsen предоставляет это список - с которым я в целом согласен

• Видимость состояния системы
• Соответствие между системой и реальным мир
• Контроль и свобода пользователя
• Последовательность и стандарты
• Предотвращение ошибок
• Распознавание, а не отзыв
• Гибкость и эффективность использования
• Эстетичный и минималистичный дизайн
• Помогает пользователям распознавать, диагностировать, а также восстановление после ошибок
• Справка и документация

Джоэл Спольски (соавтор SO :)) написал книгу «Дизайн пользовательского интерфейса для программистов» , а также серию статей на своем веб-сайте. (Joel On Software), относящуюся к этой книге.

Еще один отличный ресурс для начала - веб-сайт Джейкоба Нильсена .

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

2. «Принцип наименьшего удивления».

3. Применить разумные значения по умолчанию

4. Показать реакцию на вводимые пользователем данные в полсекунды.

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

Кроме того, Алан Купер (из Известность Visual Basic) гласила: «Не ставьте might , прежде чем will », что означает, что вы не должны облегчать людям выполнение того, что они могли делать, затрудняя им выполнение действий, которые они будут делать с вашим программным обеспечением.