Методы проектирования графического интерфейса для улучшения пользовательского опыта
Какие техники вы знаете \ используете для создания удобного графического интерфейса?
Я могу назвать следующие методы, которые я считаю особенно полезными:
- Неблокирующие уведомления (плавающие диалоги, как во всплывающих сообщениях Firefox3 или Vista в области уведомлений)
- Отсутствие кнопки "Сохранить"
MS OneNote в качестве примера.
Клиенты чата могут сохранять историю разговоров автоматически - Интегрированный поиск
Ищите не только в файлах справки, но и сделайте элементы пользовательского интерфейса доступными для поиска.
Vista сделала хороший шаг к такому графическому интерфейсу.
Надстройка для скаутов Microsoft Office была действительно отличной идеей. - Контекстно-ориентированный интерфейс (панель ленты в MS Office 2007)
Вы реализуете что-то вроде перечисленных методов в своем программном обеспечении?
Редактировать:
Как отметил Райан П, один из лучших способов создать удобное приложение - это поставить себя на место пользователя. Я полностью согласен с этим, но то, что я хочу видеть в этой теме, это конкретные методы (например, те, что я упоминал выше), а не общие рекомендации.
22 ответа
Если вы задаете вопрос пользователю, не задавайте ему вопрос "да / нет". Потратьте время, чтобы сделать новую форму и поставить глаголы в качестве выбора, как в Mac.
Например:
Would you like to save?
Yes No
Должно быть:
Would you like to save?
Save Don't Save
Здесь есть более подробное объяснение .
Проверьте великую книгу Не заставляй меня думать Стивом Кругом.
Он ориентирован на веб, но многие из них могут применяться ко всему, от блендеров до автомобильных панелей.
Темы охватывали:
- Пользовательские шаблоны
- Проектирование для сканирования
- Мудрое использование копии
- Навигационный дизайн
- Макет домашней страницы
- Юзабилити-тестирование
У него также есть блог под названием Advanced Common Sense
И некоторые случайные ссылки, связанные с пользовательским интерфейсом:
- Дизайн пользовательского интерфейса для программистов от Джоэла Спольски
- 10 кошмаров по юзабилити, о которых вы должны знать
Первые принципы: Уилфред Джеймс Хансен
- Знай пользователя
- Минимизация запоминания
- Оптимизировать операции
- Инженер по ошибкам
Последующие расширения: доктор Тео Мандель
Контролировать пользователей
- Используйте режимы разумно (немодально)
- Разрешить пользователям использовать клавиатуру или мышь (гибкий)
- Разрешить пользователям менять фокус (прерывается)
- Отображение описательных сообщений и текста (полезно)
- Обеспечить немедленные и обратимые действия и обратную связь (прощение)
- Обеспечьте значимые Пути и Выходы (навигационные)
- Приспособьте пользователей с различными уровнями квалификации (доступно)
- Сделать интерфейс пользователя прозрачным (облегчающим)
- Разрешить пользователям настраивать интерфейс (настройки)
- Разрешить пользователям напрямую манипулировать объектами интерфейса (интерактивно)
Уменьшить нагрузку на память пользователей
- Облегчить кратковременную память (помните)
- Положитесь на признание, а не отзыв (признание)
- Предоставить визуальные подсказки (сообщить)
- Предоставить значения по умолчанию, Отменить и Повторить (прощение)
- Предоставить ярлыки интерфейса (частота)
- Продвигать объект-синтаксис действия (интуитивно понятный)
- Используйте реальные метафоры (перевод)
- Прогрессивное раскрытие пользователем (контекст)
- Продвигать визуальную ясность (организовать)
Сделать интерфейс согласованным
- Поддерживать контекст задач пользователя (преемственность)
- Поддерживать согласованность внутри и между продуктами (опыт)
- Сохранить результаты взаимодействия одинаковыми (ожидания)
- Обеспечить эстетическую привлекательность и целостность (отношение)
- Поощрять разведку (предсказуемо)
Чтобы добавить в ваш список, аку, я бы поставил возможность использования в качестве одного из моих главных приоритетов. По сути, я хочу, чтобы пользователь чувствовал себя в безопасности, опробовав функции. Им никогда не следует отказываться от использования чего-либо, опасаясь, что их действия могут быть необратимыми. Чаще всего это реализуется с помощью команд отмены / повтора, но без сомнения доступны другие параметры, например автоматическое резервное копирование.
Кроме того, для приложений, которые в большей степени ориентированы на процессы (нежели приложения для ввода данных), я бы рассмотрел возможность реализации интерфейса, который немного больше ориентировал бы пользователя. Здесь могут помочь рекомендации Microsoft по индуктивному пользовательскому интерфейсу, хотя вы должны быть очень осторожны, чтобы не переусердствовать, так как вы можете легко слишком сильно замедлить работу пользователя.
Наконец, как и для всего, что включает текст, сделайте пользовательский интерфейс как можно более сканируемым. Например, если у вас есть заголовки, под которыми появляются команды / опции, рассмотрите возможность поставить слово действия в начале, а не вопросительное слово. Замечание Maudite также является хорошим примером возможности сканирования, так как текст кнопки "Не сохранять" не зависит от контекста предыдущего абзаца.
Полезный прием, который я никогда не использую, заключается в добавлении всплывающей подсказки для отключенного элемента управления пользовательского интерфейса, объясняющей, почему элемент управления отключен. Поэтому, если есть список, который отключен, и не понятно, почему он отключен, я хочу навести на него курсор, и он скажет мне, почему он отключен. Я хочу видеть что-то вроде "Это отключено, потому что два текстовых поля на экране были оставлены пустыми или потому что я не ввел достаточно символов в какое-либо поле или потому что я не сделал определенного действия".
У меня так много таких ситуаций, и это расстраивает. Иногда я в конечном итоге публикую на форуме программного обеспечения вопрос, почему элемент управления отображается серым цветом, когда всплывающая подсказка могла бы помочь мне за секунду! У большинства этих программ есть файлы справки, которые бесполезны в подобных ситуациях.
Постарайтесь сделать вид, что вы ничего не знаете о своем программном обеспечении и попробуйте его использовать. Однако это не практично, потому что у вас уже есть определенный настрой на приложение. Так что смотрите, как другие разработчики или друзья пользуются приложением, выискивают болевые точки и спрашивают отзывы.
Одной из классических книг, которые помогут вам задуматься о дизайне, является "Дизайн повседневных вещей" Дональда Нормана. Он приводит отличные примеры из реальной жизни. Например, если вы хорошо проектируете дверь, вам никогда не придется добавлять ярлыки с надписью "толкать" и "тянуть". Если вы хотите, чтобы они потянули, поставьте ручку; если хочешь их подтолкнуть, поставь плоскую тарелку. Нет способа сделать это неправильно, и им даже не нужно об этом думать.
Это хорошая цель: сделать вещи очевидными. Настолько очевидно, что пользователю никогда не приходит в голову поступать неправильно. Если на плите четыре ручки, каждая рядом с глазом, очевидно, что каждая ручка контролирует глаз, рядом с которым она находится. Если ручки расположены по прямой линии, все с левой стороны, вы должны пометить их, а пользователь должен остановиться и подумать. Плохой дизайн. Не заставляй их думать.
Другой принцип: если пользователь совершает ошибку, отменить его очень легко. Хорошим примером является программа Google для создания изображений Picasa. Вы можете обрезать, перекрашивать и подправлять свои фотографии так, как вам нравится, и если вы когда-нибудь передумали - даже через месяц - вы можете отменить свои изменения. Даже если вы явно сохраните свои изменения, Picasa сделает резервную копию. Это освобождает пользователя, чтобы играть и исследовать, потому что вы не собираетесь ничего обидеть.
Я нашел шаблоны пользовательского интерфейса, чтобы быть полезным справочным материалом для такого рода вещей. Она очень похожа на классическую книгу "Шаблоны дизайна GoF", где каждое описание шаблона содержит:
- Проблема, которую решает шаблон
- Пример паттерна в действии
- Примеры вариантов использования для шаблона
- Решение для реализации шаблона
- Обоснование решения
Очень хорошая обратная связь очень важна. Даже простые вещи, такие как указание на то, на что можно и нельзя нажимать, могут быть упущены или слишком тонки. Обратная связь, когда что-то может произойти в фоновом режиме, отличная. В gmail замечательно, что в верхней части отображается лента состояния, которая дает вам знать, отправляет или загружает что-то, но еще лучше, если она сообщает, что что-то успешно отправлено или все еще загружается.
Техника "желтого затухания" - еще одна популярность среди толпы RoR, которая выполняет нечто подобное. Вы никогда не хотите, чтобы пользователь задавал вопрос: "Что только что произошло?" или "Что будет, когда я это сделаю?".
Еще одна уловка, которая стала более популярной в последнее время, которую я часто использую, - это редактирование на месте. Вместо того, чтобы иметь представление некоторых данных с отдельным экраном "редактирования" (или пропускать представление и иметь только экран редактирования), часто бывает удобнее иметь хорошо продуманное представление некоторых данных и просто нажать для редактирования части этого. Этот метод действительно подходит только тогда, когда чтение данных происходит чаще, чем редактирование, и не подходит для серьезного ввода данных.
Хорошо, одна вещь, которая может быть очевидна: не меняйте (даже слегка) положение, цвет, размер шрифта и т. Д. Кнопок, меню, ссылок и т. Д. Между экранами, если они выполняют один и тот же тип действия.
Мне нравится следовать этим 3 принципам:
- Стандарт - следуйте известным стандартам / шаблонам, используйте идеи всех продуктов, которые вы уважаете
- Просто - держите ваши решения простыми и легко изменяемыми (при необходимости)
- Elegant - use less to accomplish more
Вот отличный эпизод подкаста DotNetRocks, где Марк Миллер рассказывает о том, как создать Хороший пользовательский интерфейс; Несмотря на то, что название шоу - ".NET", в этом эпизоде рассказывается о том, как создать пользовательский интерфейс для повышения производительности пользователя программы.
Вот пример эпизода
Хороший дизайн пользовательского интерфейса можно сделать, придерживаясь некоторых хороших правил и избегая распространенных ошибок. Вам не нужно быть дизайнером, носящим татуировку с надписью "латте-сиппин", чтобы создавать работающие пользовательские интерфейсы.
Постарайтесь сначала подумать о конечных целях вашего пользователя, прежде чем решать, какие отдельные задачи он будет выполнять при использовании вашего программного обеспечения. В книге " О лице" есть отличные дискуссии о подобных вещах, и хотя она довольно длинная, она очень интересная и проницательная. Интересно отметить, сколько из их предложений по улучшению дизайна программного обеспечения, похоже, используются в Google Docs...
Еще одна вещь, сделайте ваш пользовательский интерфейс как можно более простым и чистым.
Если вы работаете с корпоративным программным обеспечением, у многих пользователей будут небольшие мониторы с низким разрешением. Или, если они старые, у них будет низкое разрешение, чтобы они могли видеть гигантские кнопки (я видел 800x600 на 24-дюймовом мониторе). У меня есть старый 15-дюймовый монитор с низким разрешением (800 x 600), поэтому я могу видеть, как программа будет выглядеть как в условиях простоя время от времени. Я знаю, что корпоративные пользователи в значительной степени должны принять то, что им дают, но если вы создаете winform, которая не вписывается в экран 800x600, это никому не поможет.
Элементы в представленном вами списке действительно зависят от ситуации - они будут различаться в зависимости от приложения. Некоторым приложениям понадобится кнопка сохранения, другим - нет. Некоторые условия требуют модального диалогового окна, некоторые - нет.
Мое главное правило при разработке удобного интерфейса: следуйте существующим соглашениям о пользовательском интерфейсе. Ничто не смущает пользователя больше, чем пользовательский интерфейс, который не работает так, как он когда-либо использовал. Lotus Notes имеет один из худших пользовательских интерфейсов, когда-либо созданных, и это почти полностью, потому что они шли против общих соглашений UI почти со всем, что они сделали.
Если вы задаетесь вопросом, как вам следует разрабатывать определенный элемент вашего пользовательского интерфейса, подумайте о нескольких стандартных / известных приложениях, которые предоставляют аналогичные функции, и посмотрите, как они это делают.
Блог Coding Horror регулярно дает отличные идеи. Просто несколько примеров:
- Поисковое и поэтапное обучение
- Самодокументируемый пользовательский интерфейс
- Инкрементальный поиск функций / Интеллектуальная клавиатура
- Ориентированный на задачи дизайн (лента вместо меню и панелей инструментов)
- Предоставление отмены вместо постоянного подтверждения
Другой аспект: использование масштабируемых значков для решения проблемы разрешения экрана нескольких пользователей без сохранения растровых изображений с различным разрешением.
Сун Мейстер упомянула Марка Миллера. Вы можете найти некоторые из его сообщений в блоге о великолепном пользовательском интерфейсе в экспресс-блоге разработчика. Вот скринкаст его презентации Science of great UI: часть 1 и часть 2. (оба требуют Veoh игрока).
Вы также можете найти его на dnrTV: Наука отличного пользовательского опыта: часть 1 и часть 2.
Вот гугл techtalks о пользовательском опыте Джен Фицпатрик.
ура
Я дам один из моих личных фаворитов: избегайте диалоговых окон любой ценой. Действительно хороший пользовательский интерфейс почти никогда не должен вызывать диалоговое окно. Добавьте их в свою программу только в качестве последнего средства.
Более того, вы можете попробовать легко усваиваемые советы для разработчиков.
При использовании выпадающего меню высота выпадающего меню по умолчанию, как правило, слишком мала (например, по умолчанию используется 8 элементов для winforms).
Увеличение этого значения либо спасет пользователя от клика, если количество элементов невелико, либо облегчит поиск в раскрывающемся списке, если элементов много.
На самом деле, я не вижу смысла не использовать все доступное пространство!
Сейчас это так очевидно для меня, но, например, кажется, что даже дизайнеры VisualStudio этого не поняли (кстати, если вы вручную увеличите высоту Intellisense, она останется такой, но это оффтоп:))
Лучшая техника, которую я нашел, - это поставить себя на место пользователя. Что бы вы хотели увидеть из графического интерфейса и поставить это впереди. Это также дает вам возможность расставить приоритеты, так как эти вещи должны быть выполнены сначала, а затем работать оттуда.
Для этого я пытаюсь найти "слои полезности" и добавлять / вычитать слои, пока они не станут чистыми. В основном, чтобы найти слои, я делаю список всех функций, которые должен иметь графический интерфейс, всех функций, которые он должен иметь, и всех функций, которые он должен иметь. Затем я группирую их так, чтобы у каждой вещи был логический порядок, и группировки стали "слоями". Затем из слоев я добавляю наиболее важные функциональные возможности (или то, что будет использоваться для повседневной работы), и это становится наиболее заметной частью, и я встраиваю элементы в эти элементы.
Одна из самых сложных вещей - это навигация, так как у вас есть так много возможностей, как вы можете сделать ее полезной, и именно здесь слои действительно помогают. Это позволяет легко увидеть, как составлять меню, как взаимодействуют другие элементы, какие элементы можно скрыть и т. Д.
Я обнаружил, что самый простой способ сделать это - начать с того, что и как ваши пользователи работают на ежедневной основе, это облегчит работу (еще лучше - выполнять свою работу в течение нескольких дней)., Затем проведите несколько демонстраций и поставьте их перед пользователями, даже если они являются бумажными прототипами (есть книга об этом процессе, называемая "Бумажное прототипирование" Кэролайн Снайдер). Затем начните создавать его и ставьте перед пользователями, как это часто делается.
Я также буду рекомендовать книгу "Проектирование интерфейсов" Дженифер Тидуэлл, изданную О'Рейли.
Если ваш пользовательский интерфейс включает в себя ввод данных или манипулирование ими (типично для бизнес-приложений), тогда я рекомендую предоставить вашим пользователям возможность как можно больше воздействовать на наборы элементов данных. Также попытайтесь спроектировать таким образом, чтобы опытные пользователи могли взаимодействовать с пользовательским интерфейсом очень случайным образом, а не последовательным способом (клавиши ускорения, гиперссылки и т. Д.).