Разработка интерфейса пользователя программного обеспечения

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

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

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

Программное обеспечение становится более популярным, если его пользовательский интерфейс:

• привлекательный
• Прост в использовании
• Отзывчивый в короткие сроки
• Ясно, чтобы понять
• Последовательный на всех интерфейсных экранах

Пользовательский интерфейс широко разделен на две категории:

• Интерфейс командной строки
• Графический пользовательский интерфейс

Интерфейс командной строки (CLI)

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

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

Команда представляет собой текстовую ссылку на набор инструкций, которые, как ожидается, будут выполнены системой. Существуют такие методы, как макросы, сценарии, которые облегчают работу пользователя.

CLI использует меньше ресурсов компьютера по сравнению с GUI.

Элементы CLI

Текстовый интерфейс командной строки может иметь следующие элементы:

• Командная строка — это текстовое уведомление, которое в основном показывает контекст, в котором работает пользователь. Он генерируется системой программного обеспечения.

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

• Команда — команда является исполняемой инструкцией. Может иметь один или несколько параметров. Выходные данные при выполнении команды отображаются на экране в виде строки. Когда вывод получен, командная строка отображается на следующей строке.

Командная строка — это текстовое уведомление, которое в основном показывает контекст, в котором работает пользователь. Он генерируется системой программного обеспечения.

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

Команда — команда является исполняемой инструкцией. Может иметь один или несколько параметров. Выходные данные при выполнении команды отображаются на экране в виде строки. Когда вывод получен, командная строка отображается на следующей строке.

Графический пользовательский интерфейс

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

Как правило, GUI более ресурсоемкий, чем CLI. С помощью передовых технологий программисты и дизайнеры создают сложные графические интерфейсы, которые работают с большей эффективностью, точностью и скоростью.

Элементы графического интерфейса

GUI предоставляет набор компонентов для взаимодействия с программным или аппаратным обеспечением.

Каждый графический компонент предоставляет способ работы с системой. Система GUI имеет следующие элементы, такие как:

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

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

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

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

• Курсор — взаимодействующие устройства, такие как мышь, сенсорная панель, цифровое перо, представлены в графическом интерфейсе в виде курсоров. На экране курсор следует инструкциям от оборудования практически в режиме реального времени. Курсоры также называются указателями в системах с графическим интерфейсом. Они используются для выбора меню, окон и других функций приложения.

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

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

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

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

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

Компоненты графического интерфейса приложения

GUI приложения содержит один или несколько из перечисленных элементов GUI:

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

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

  

• Text-Box — предоставляет пользователю область для ввода и ввода текстовых данных.

• Кнопки — они имитируют реальные кнопки и используются для отправки входных данных в программное обеспечение.

  

• Радио-кнопка — отображает доступные опции для выбора. Только один может быть выбран среди всех предложенных.

• Флажок — функции, аналогичные списку. Когда опция выбрана, поле помечается как отмеченное. Можно выбрать несколько параметров, представленных флажками.

• Список — Предоставляет список доступных элементов для выбора. Можно выбрать более одного элемента.

  

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

Диалоговое окно — это дочернее окно, которое содержит сообщение для пользователя и запрос на выполнение каких-либо действий. Например: приложение генерирует диалог, чтобы получить от пользователя подтверждение на удаление файла.

Text-Box — предоставляет пользователю область для ввода и ввода текстовых данных.

Кнопки — они имитируют реальные кнопки и используются для отправки входных данных в программное обеспечение.

Радио-кнопка — отображает доступные опции для выбора. Только один может быть выбран среди всех предложенных.

Флажок — функции, аналогичные списку. Когда опция выбрана, поле помечается как отмеченное. Можно выбрать несколько параметров, представленных флажками.

Список — Предоставляет список доступных элементов для выбора. Можно выбрать более одного элемента.

Другие впечатляющие компоненты GUI:

• Слайдеры
• Поле со списком
• Данные сетки
• Выпадающий список

Деятельность по разработке пользовательского интерфейса

Существует ряд действий, выполняемых для разработки пользовательского интерфейса. Процесс проектирования и реализации GUI похож на SDLC. Любая модель может быть использована для реализации GUI среди Waterfall, Iterative или Spiral Model.

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

• Сбор требований к графическому интерфейсу — разработчикам может потребоваться список всех функциональных и нефункциональных требований графического интерфейса. Это может быть взято от пользователя и его существующего программного решения.

• Анализ пользователя — дизайнер изучает, кто собирается использовать графический интерфейс программного обеспечения. Целевая аудитория имеет значение, так как детали дизайна меняются в зависимости от уровня знаний и компетенции пользователя. Если пользователь разбирается в технических вопросах, можно использовать расширенный и сложный графический интерфейс. Для начинающего пользователя, больше информации включено в с практическими рекомендациями программного обеспечения.

• Анализ задач — Дизайнеры должны проанализировать, какую задачу следует решить с помощью программного решения. Здесь, в GUI, не имеет значения, как это будет сделано. Задачи могут быть представлены в иерархическом порядке, принимая одну главную задачу и разделяя ее далее на более мелкие подзадачи. Задачи обеспечивают цели для представления GUI. Поток информации среди подзадач определяет поток содержимого GUI в программном обеспечении.

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

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

Сбор требований к графическому интерфейсу — разработчикам может потребоваться список всех функциональных и нефункциональных требований графического интерфейса. Это может быть взято от пользователя и его существующего программного решения.

Анализ пользователя — дизайнер изучает, кто собирается использовать графический интерфейс программного обеспечения. Целевая аудитория имеет значение, так как детали дизайна меняются в зависимости от уровня знаний и компетенции пользователя. Если пользователь разбирается в технических вопросах, можно использовать расширенный и сложный графический интерфейс. Для начинающего пользователя, больше информации включено в с практическими рекомендациями программного обеспечения.

Анализ задач — Дизайнеры должны проанализировать, какую задачу следует решить с помощью программного решения. Здесь, в GUI, не имеет значения, как это будет сделано. Задачи могут быть представлены в иерархическом порядке, принимая одну главную задачу и разделяя ее далее на более мелкие подзадачи. Задачи обеспечивают цели для представления GUI. Поток информации среди подзадач определяет поток содержимого GUI в программном обеспечении.

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

Тестирование — тестирование GUI может быть выполнено различными способами. Организация может провести внутренний осмотр, непосредственное участие пользователей и выпуск бета-версии — это лишь немногие из них. Тестирование может включать в себя удобство использования, совместимость, принятие пользователем и т. Д.

Инструменты реализации GUI

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

Инструменты реализации GUI предоставляют мощный массив элементов управления GUI. Для настройки программного обеспечения дизайнеры могут изменить код соответствующим образом.

Существуют разные сегменты инструментов с графическим интерфейсом в зависимости от их использования и платформы.

пример

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

• ЖИДКОСТИ
• AppInventor (Android)
• Lucidchart
• Wavemaker
• Visual Studio

Пользовательский интерфейс Золотые правила

Следующие правила упоминаются как золотые правила для дизайна GUI, описанные Shneiderman и Plaisant в их книге (Проектирование интерфейса пользователя).

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

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

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

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

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

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

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

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

Проектирование пользовательского интерфейса Windows 95 / Хабр

Три года назад мне попалась интересная научная статья сотрудника Microsoft Кента Салливана о процессе и результатах проектирования нового пользовательского интерфейса для Windows 95. С тех пор веб-страница исчезла — одна из причин, почему я такой цифровой Плюшкин.

Статья описывает некоторые общие проблемы оболочки Менеджера программ в Windows 3.1 и рассматривает варианты разработки отдельной оболочки для «новичков». Я склоняюсь к мнению, что она предположительно создавалась в духе программы At Ease от Apple, довольно популярной во времена System 7. Я хорошо помню, как мы запускали At Ease в начальной школе, так что детишкам не приходилось возиться с жёстким диском в Finder.

Итак, вот что Кент дословно написал в своей статье под названием «Пользовательский интерфейс Windows 95: конкретный пример проектирования функциональности» (The Windows 95 User Interface: A Case Study in Usability Engineering). Публикуем её, чтобы документ никогда не потерялся.

В разработке пользовательского интерфейса для большого коммерческого программного продукта вроде Microsoft Windows 95 участвует много людей. У этого проекта обширные задачи и агрессивный график выполнения работ. Краткое изложение проекта здесь описывает опыт успешного применения принципов проектирования юзабилити, итеративной разработки и отслеживания проблем, чтобы повысить управляемость процессом разработки UI. Также обсуждаются конкретные проблемы дизайна и их решения.
Windows 95 — это обширное обновление продуктов Windows 3.1 и Windows for Workgroups 3.11. Почти во всех частях Windows произошли многие изменения. Не стал исключением и пользовательский интерфейс. В этой статье обсуждается дизайнерская группа, её задачи и процесс работы. Затем объясняется, как в проекте применялись принципы проектирования юзабилити, такие как итеративная разработка и отслеживание проблем. В качестве примеров приведены конкретные проблемы дизайна и их решения.

Дизайнерский отдел

Группу разработки пользовательского интерфейса Windows 95 сформировали в октябре 1992 года на ранней стадии проекта. Я подключился к группе в декабре 1992 года в статусе помощника для обеспечения сервисов юзабилити. Команда была по-настоящему междисциплинарной, со специалистами в области проектирования, графического дизайна, тестирования юзабилити и компьютерных наук. Количество сотрудников колебалось в ходе проекта, но в среднем нас было двенадцать. Ещё столько же программистов для реализации пользовательского интерфейса.

Цели дизайна

Дизайнерская группа работала над двумя очень широкими задачами:

• Сделать проще изучение Windows для людей, которые только начали пользоваться компьютерами и Windows.
• Сделать проще использование Windows для людей, которые уже работали с компьютерами — как для обычных пользователей Windows 3.1, так и для продвинутых, опытных пользователей Windows 3.1.

С более чем 50 млн установок Windows 3.1 и 3.11 плюс практически нетронутым рынком домашних ПК с самого начала стало понятно, что задача выпуска лучшего продукта станет нетривиальным упражнением. Без тщательного дизайна и тестирования мы скорее всего сделаем продукт, который улучшит юзабилити только для определённой категории пользователей, но ухудшит его для миллионов остальных (существующих или потенциальных). Мы хорошо понимали проблемы средних и продвинутых пользователей, но мало знали о проблемах, которые испытывают новички.

Процесс дизайна

С учётом очень широких задач и агрессивного графика работы перед выпуском продукта (на проектирование и программирование пользовательского интерфейса отводилось примерно 18 месяцев) мы с самого начала знали, что разработка по традиционной каскадной модели («Водопад») не предоставит нам достаточной гибкости для достижения наилучшего решения. На самом деле нас беспокоило то, что традиционный подход приведёт к созданию непригодной системы.

В каскадной модели проектирование системы разделяется на части (обычно ограничено фазой написания спецификаций), а тестирование юзабилити, как правило, происходит ближе к окончанию процесса, во время мероприятий по контролю качества. Мы поняли, что этого недостаточно для создания дизайна, его проверки на пользователях (возможно, в сравнении с другими дизайнами), произведения изменений и сбора отзывов. К счастью, наше желание отказаться от каскадной модели в пользу итеративной разработки совпало с аналогичными попытками в других отделах компании, так что у нас имелись конкретные примеры её преимуществ и применимости.

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

Наш процесс итеративной разработки проходил в три основных этапа: изучение, быстрое прототипирование и тонкая настройка.

Рис. 1: Процесс итеративной разработки Windows 95

Этап изучения

На этом первом этапе мы экспериментировали с разными направлениями дизайна и собирали первые отзывы пользователей. Мы начали с прочного фундамента визуального дизайна UI, используя работу, проделанную группой Cairo. Мы унаследовали от них значительную часть фундаментального UI и интерфейсов взаимодействия: рабочий стол, трей (область уведомлений), контекстные меню, трёхмерный вид и проч.). Мы также получили данные из службы поддержки о 20-ти главных проблемах пользователей Windows 3.1.

На рис. 2 показан прототип дизайна рабочего стола Windows 95, юзабилити которого мы тестировали в январе 1993 года. Дизайн основан на Cairo и включает в себя первый проход исправления некоторых известных проблем Windows 3.1 (в частности, управления окнами).

Рис. 2: Ранняя версия рабочего стола Windows 95 (с выносками для ясности)

Верхняя иконка File Cabinet открывала вид в стиле менеджера файлов Windows 3.1 (слева иерархия, справа контент). Вторая иконка World показывала элементы в сети. Третья иконка Programs — это папка с другими папками, полными ссылок на программы, установленные в системе. Вдоль нижей части экрана располагается системный трей с тремя кнопками (System, Find и Help) и областью хранения файлов. Другая иконка Wastebasket представляет собой контейнер удалённых файлов.

Исследования юзабилити этого прототипа рабочего стола проводились в лаборатории юзабилити Microsoft, также как и последующие тесты. Мы провели типичные итеративные исследования юзабилити. От трёх до четырёх пользователей, каждый из которых представлял отдельную интересующую группу (обычно начинающие и средние пользователи Windows 3.1) выполняли задачи на прототипе. Во время тестирования мы хотели получить ответы и на очень широкие вопросы (например, нравится ли интерфейс пользователям), и на очень конкретные (например, обнаружит ли пользователь в течение 10-ти минут возможность копирования файла путём перетаскивания мышкой). Мы собрали типичные данные для итеративных исследований: вербальные протоколы, время выполнения задачи, количество ошибок, типы ошибок и оценки.

Первые результаты

Юзабилити-тестирование этого прототипа принесло много результатов, в том числе несколько неожиданных:

Сравнение с Windows 3.1

С первых лабораторных экспериментов стало понятно, что нам требуется база Windows 3.1 для лучшего понимания, какие проблемы существовали до Windows 95, а какие проблемы уникальны для нового дизайна. Сначала мы собрали данные рыночных исследований о 20-ти самых частых задачах, которые выполняют пользователи Windows 3.1. Затем провели несколько лабораторных исследований, сравнивая Windows 3.1 и Windows 95 с учётом этих 20-ти задач. Мы также провели собеседования с профессиональными преподавателями Windows 3.1 (и Macintosh, для сравнения), чтобы понять, какие аспекты операционной системы они считают простыми и сложными в обучении юзеров.

Ключевые результаты:

• В Windows 3.1 новичкам требовалось в среднем 9,5 минут для поиска и открытия программы, которая не видна сразу на экране. В нашем прототипе Windows 95 результаты оказались ненамного лучше. Такие результаты явно неприемлемы с учётом того, что данные рыночных исследований (и здравый смысл) говорили о том, что запуск программ у пользователей является задачей номер один.
• Новые и некоторые средние пользователи испытывали большие проблемы при использовании мыши, особенно двойного щелчка. В результате они часто не могли найти элементы в контейнерах, доступ в которые открывался только по двойному щелчку.
• Начинающие и многие средние пользователи для поиска команд полагались почти исключительно на визуальную информацию. Они полагались на строки меню и панели инструментов, но не использовали всплывающие (контекстные) меню даже после обучения.
• Все, кроме самых продвинутых пользователей, не понимали, как эффективно управлять множеством перекрывающихся окон. Больше всего проблем возникло у новичков — при сворачивании окна они думали, что оно «ушло», если оно было закрыто другим окном. От преподавателей мы слышали много историй (и наблюдали это в лаборатории), как пользователи исчерпывали всю оперативную память на компьютере, запуская многочисленные копии программы вместо переключения на первую запущенную копию. Средние пользователи проявили больший опыт, но тоже испытывали проблемы, особенно с приложениями Multiple-Document-Interface (MDI), такими как Менеджер программ и Microsoft Word. Данные рыночных исследований подтвердили проблему: оказалось, что 40% средних пользователей Windows не запускали больше одной программы одновременно, потому что испытывали какие-то трудности с этим.
• Начинающих пользователей сбивала с толку иерархическая файловая система. Средние пользователи обычно справлялись с иерархией, но зачастую делали это с трудом и сохраняли все свои документы в директорию по умолчанию для той программы, которую использовали. Эта проблема (особенно у новичков) наблюдалась и у пользователей Macintosh.

Смена направления

Результаты этих исследований и собеседований сильно изменили дизайн пользовательского интерфейса Windows 95. В раннем прототипе Windows 95 мы специально изменили некоторые элементы Windows 3.1 (например, элемент Desktop теперь стал реальным контейнером), а другие оставили без изменений (например, иконки менеджера файлов и менеджера программ на рабочем столе), потому что боялись слишком сильно менять дизайн. Мы знали, что продукт с радикальными отличиями от Windows 3.1 может запутать и разочаровать миллионы существующих пользователей, что явно неприемлемо.

Однако данные, собранные в прототипе Windows 95 и в Windows 3.1, показали невозможность сохранения текущего дизайна. Результаты начинающих пользователей в выполнении базовых задач оказались неприемлемо плохими, а многие средние пользователи выражали мнение, что Windows 95 просто другая, но не лучшая система.

Мы решили отступить и несколько дней подумать над ситуацией. Дизайнерская группа провела выездное собрание вне офиса и рассмотрела все данные, собранные на тот момент: базовые исследования юзабилити, собеседования, рыночные исследования и информацию из службы поддержки. Во время обсуждения данных мы поняли, что нужно сконцентрироваться на самых часто выполняемых задачах. Мы также поняли, что слишком много внимания уделяли связности с Windows 3.1.

По сути мы осознали, что жизнеспособное решение необязательно должно выглядеть как Windows 3.1, но определённо должно быть привлекательным для пользователей любого уровня, потенциально по разным причинам. Мы поняли, что по-настоящему удобная система будет масштабироваться в соответствии с нуждами разных пользователей: её легко освоить и изучить, и в то же время она обеспечит эффективность (через ярлыки или альтернативные методы) для более опытных пользователей.

Этап быстрых итераций

Когда мы начали работать над новым дизайном, то надеялись избежать классического парадокса «легко освоить, но трудно использовать». Мы постоянно держали в уме, что базовые функции UI должны масштабироваться. Мы знали, что для достижения этой цели нужно быстро опробовать много разных идей, сравнить их и выполнить повторение тех, которые кажутся самыми перспективными. Для этого требовались очень эффективные процессы проектирования и оценки.

Эволюция процесса спецификаций UI

Хотя мы с самого начала выбрали процесс итеративной разработки, у нас остался один элемент каскадного метода: монолитная конструкция спецификаций дизайна («спеки»). В первые несколько месяцев спеки стремительно росли и отражали сотни человеко-часов работы. Но из-за проблем, обнаруженных во время пользовательского тестирования, задокументированный в спеках дизайн внезапно устарел. Предстояло принять важное решение: потратить недели на изменение спецификаций для отражения новых идей и потерять ценное время, необходимое для итераций, или прекратить обновление спецификаций и позволить прототипам и коду выполнять роль «живых» спеков.

После некоторых споров группа выбрала второй вариант. Хотя такое изменение в чём-то затруднило сторонним группам возможность следить за нашей работой, но позволило проводить итерации на максимальной скорости. Изменения также привели к неожиданному эффекту: они сильнее сплотили команду, потому что бóльшая часть спецификаций существовала в устной форме и обсуждалась в беседах и на белой доске в кабинетах сотрудников. Последовало много «коридорных» разговоров, которые продолжались на протяжении всего проекта.

Чтобы все заинтересованные стороны всегда были в курсе актуального дизайна, мы организовали следующие мероприятия:

1. Регулярные собрания сотрудников дизайнерского отдела. На еженедельных (иногда чаще) собраниях каждый сверял свою работу с общим проектом и все обсуждали, как работа каждого сотрудника может повлиять на других.
2. Рассылка графиков и результатов тестирования юзабилити по электронной почте. Сотрудники дизайнерской группы получали регулярные уведомления о предстоящих тестах юзабилити и результатах завершённых тестов, чтобы быть в курсе, как продвигается дизайн.
3. Формальное отслеживание проблем юзабилити. С проектом масштаба Windows 95 мы понимали, что требуется стандартный способ записи выявленных проблем юзабилити, когда и как они должны быть исправлены — а затем закрывать тикеты после исправления проблемы и успешной проверки на пользователях. Этот процесс более детально описывается в главе «Отслеживание открытых тикетов».
4. Регулярные презентации дизайна для внешних групп. По мере продвижения проекта всё больше и больше групп (внутри и за пределами Microsoft) хотели посмотреть, что мы делаем, так что мы проводили такие презентации. Они эффективнее, чем рассылка документов, потому что презентации проще поддерживать в актуальном состоянии и они позволяют своевременно обсуждать дизайн.

Отдельный UI для новичков

Первым важным изменением дизайна, которое мы рассмотрели, стал отдельный UI («оболочка») для начинающих пользователей. Дизайн быстро набросали в Visual Basic и протестировали в лаборатории юзабилити (рис. 4). Тестирование показало неплохой результат, поскольку дизайн успешно ограничивал возможный выбор действий пользователя очень маленьким набором действий, но чем больше пользователей участвовали в тестировании, тем отчётливее проявлялись ограничения:

1. Если в оболочке для новичков не поддерживалась всего одна нужная функция, то пользователю приходилось отказываться от использования оболочки (по крайней мере, временно).
2. По идее, большинство пользователей после набора опыта должны оставить оболочку для новичков и перейти в стандартный интерфейс. Но опыт, который они получили в оболочке для новичков, необязательно переносится в стандартную оболочку.
3. Оболочка для новичков вообще не похожа на все остальные программы, которые запускает пользователь (текстовые редакторы, электронные таблицы и др.). В результате пользователям приходилось изучать два способа взаимодействия с компьютером, что вносило путаницу.

Рис. 4. Частичный вид отдельной оболочки для новичков

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

Примеры быстрой итерации

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

1. Запуск программ: меню «Старт». Хотя мы отказались от идеи отдельной оболочки для новичков, мы сохранили её самые полезные функции: доступ по однократному щелчку, хорошая различимость, взаимодействие через меню. Мы набросали много вариантов в Visual Basic и проверили их на пользователях всех уровней, не только на новичках, потому что это дизайнерское решение должно было хорошо восприниматься пользователями любого уровня. Рис. 5 показывает окончательный вариант меню «Старт» и подменю «Программы». Это меню служит не только для запуска программ, но сочетает в себе и другие функции. Все они открываются нажатием одной кнопки.

Рис. 5. Меню «Старт» и подменю «Программы»

2. Управление окнами: панель задач. Наша первая идея по улучшению управлением окнами была не очень амбициозной, но мы не знали, сколько работы понадобится для решения проблемы. Первой идеей было изменить внешний вид свёрнутых окон из иконок на «плитки». (рис. 6).

Рис. 6. Свёрнутые окна в виде «плиток»

Мы надеялись, что проблему можно решить, если свёрнутые окна будут отличаться на вид и иметь больший размер. Мы ошиблись! Пользователи испытывали практически такие же затруднения, как в случае с Windows 3.1. Результаты тестирования показали, что основная проблема в том, что окна не отображаются постоянно, так что пользователи не видят, какие окна открыты, и не могут быстро получить к ним доступ. Поняв это, мы быстро пришли к идее панели задач, показанной на рис. 7. У каждой задачи есть собственное место на панели, которая отображается поверх всех окон. Тестирование на пользователях показало, что это приемлемое решение проблемы.

Рис. 7. Панель задач с кнопкой «Старт», программами и часами

3. Работа с файлами: диалоги «Открыть» и «Сохранить как…». Информация из службы поддержки и результаты лабораторных тестов показали, что новички и средние пользователи испытывают много проблем с системными диалогами открытия и сохранения файлов (рис. 8).

Рис. 8. Диалоговое окно открытия файла в Windows 3.1

Проблемы вызваны тем, что поля диалогового окна находятся не в логическом порядке и имеют сложную методологию выбора. Команда Cairo взяла на себя инициативу в решении этой проблемы и разработала всесторонний прототип на Visual Basic, в том числе макет файловой системы. Мы протестировали несколько вариантов, пока не остановились на окончательном варианте, показанном на рис. 9.

Рис. 9. Диалоговое окно открытия файла в Windows 95

4. Печать: мастер установки. Информация из службы поддержки говорила о том, что установка и конфигурация принтера является главной причиной звонков от пользователей Windows 3.1. Многие проблемы проистекают из интерфейса установки принтера (рис. 10).

Рис. 10. Основное диалоговое окно установки принтера в Windows 3.1

Найти нужный принтер сложно, потому что все они находятся в одном длинном списке. Для выбора порта, особенно в сетевом окружении, требовалось спуститься на 4-5 уровней с нестандартными и сложными вариантами выбора. Примерно в то время, когда мы начали решать эту проблему, сотрудники дизайнерского отдела начали рассматривать мастер (визард) как решение для многоэтапных нечасто выполняемых задач. Установка принтера отлично вписался в это определение, и созданный визард показал хорошие результаты в тестировании на пользователях. На рис. 11 показан экран выбора принтера из окончательного варианта визарда.

Рис. 11. Экран мастера добавления принтера в Windows 95

5. Помощь: диалог поиска и вкладка с индексом. Лабораторное тестирование Windows 3.1 показало, что пользователи испытывают проблемы с поисковом диалогом в справочном разделе (рис. 12).

Рис. 12. Диалог поиска по справочной информации в Windows 3.1

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

Рис. 13. Вкладка индекса в справочном разделе Windows 95

Этап тонкой настройки

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

• Итоговые лабораторные тесты. Используя 20 основных задач из рыночного исследования мы провели комплексное тестирование всего UI. Пользователям разного уровня подготовки предлагали изоморфные наборы задач для измерения скорости обучения и уровня использования после освоения. Мы сравнивали эффективность работы с базовым уровнем Windows 3.1. После проведения собственного пилотного теста для выяснения возможных проблем с процедурой окончательное тестирование осуществил посторонний подрядчик, так что эти результаты можно использовать в официальных документах [3]. Результаты оказались весьма обнадёживающими — пользователи завершали выполнение задач примерно вдвое быстрее, чем в Windows 3.1 и в 20 из 21 категорий показали большее удовлетворение работой Windows 95.
• Длительное полевое исследование. Двадцать человек приняли участие в полевом исследовании на бета-версии Windows 95. Сначала мы изучали, как они работают в Windows 3.1, а затем наблюдали за установкой Windows 95. Дополнительные тесты проводились через неделю и через месяц для проверки уровня обучения и произошедших изменений. Мы не нашли никаких серьёзных пробелов в юзабилити продукта, но подкорректировали формулировки в UI и темах справочного раздела. Некоторые из собранных данных впоследствии использовались при планировании следующей версии Windows, а также сотрудниками службы поддержки, в том числе краткий перечень тем, которые можно ожидать с началом звонков в службу поддержки.

В ходе разработки и тестирования пользовательского интерфейса Windows 95 мы применили различные принципы и практики разработки юзабилити [2] [4]. С проектом масштаба Windows 95 мы понимали, что требуется стандартный способ записи выявленных проблем юзабилити, когда и как они должны быть исправлены — а затем закрывать тикеты после исправления проблемы и успешной проверки на пользователях.

Для этого мы разработали реляционную базу данных (рис. 14).

Рис. 14. Образец записи в базе данных с тикетами

После каждого этапа лабораторного тестирования я вносил туда новые проблемы и положительные результаты и назначал на каждый тикет соответствующее ответственное лицо — обычно одновременно дизайнера и преподавателя, который обучает пользователей. Статус текущих проблем обновлялся — тикет или оставался открытым, если требовалась дополнительная работа, или он закрывался в случае решения проблемы. Каждые несколько недель я выпускал ряд отчётов с распечаткой всех оставшихся проблем, по каждому ответственному лицу, и раздавал их сотрудникам (рис. 15). Мы встречались для обсуждения текущего прогресса и решали, когда изменённый дизайн будет готов для тестирования на пользователях.

Рис. 15. Образец отчёта в базе данных с тикетами

Отчёт

Как и в любом проекте, практика — критерий истины, так что приведу некоторые сводные статистические данные.

Лабораторные тесты

Мы провели 64 этапа лабораторного тестирования с 560 пользователями. 50% из них имели средний опыт работы с Windows 3.1; остальные — это новички, продвинутые пользователи и пользователи других операционных систем. Эти цифры не включают тестирование компонентов, поступивших от других команд (почтовый клиент Exchange, программа для отправки факсов и проч.). Тестирование этих компонентов прошло примерно в 25 этапов с участием 175 человек.

Выявление проблем

Для ключевых компонентов оболочки в ходе проекта в базу данных были внесены 699 «отчётов юзабилити». Из них 148 положительных результатов и 551 проблема. Проблемам присваивался один из трёх уровней серьёзности:

• Уровень 1: Пользователи не могут продолжать выполнение задачи или серии задач.
• Уровень 2: Пользователи испытывают значительные сложности с выполнением задачи или серии задач, но всё-таки способны продолжить её выполнение.
• Уровень 3: Пользователи испытывают незначительные сложности с выполнением задачи или серии задач.

Из 551 выявленной проблемы 15% получили уровень 1, 43% — уровень 2 и 42% — уровень 3.

Резолюции по проблемам

В ходе проекта использовалось пять резолюций по проблем:

• Решено. Команда исправила проблему и успешно испытала решение на пользователях.
• Запланировано. Команда разработала исправление проблемы и мы ожидаем его реализации.
• Под вопросом. Команда не уверена, нужно ли решать проблему, или не знает, возможно ли её решение.
• Частично. Команда разработала решение и оно протестировано на пользователях с удовлетворительными результатами, но всё равно остаются некоторые вопросы.
• Не решено. Команда не собирается решать проблему.

К завершению проекта все проблемы с резолюциями «запланировано» или «под вопросом» перешли в одну из других категорий. 81% проблем завершились успешным решением, 8% остались с резолюцией «частично», а 11% остались нерешёнными. В большинстве случаев причиной отсутствия решения стали технические ограничения, а иногда — ограничения рабочего графика.
Для многих сотрудников отдела проект Windows 95 стал первым опытом итеративной разработки, тестирования юзабилити и отслеживания проблем.

Итеративная разработка

Возможно, лучшим доказательством нашей приверженности итерационной разработке стало то, что буквально никакая деталь изначального дизайна UI для Windows 95 не сохранилась без изменений в конечном продукте. В начале процесса проектирования мы не предполагали того масштаба и объёма изменений, которые придётся сделать. Итеративная разработка с использованием прототипов и продукт в качестве спецификации, а также непрерывное тестирование на пользователях позволили быстро исследовать много разных способов решения проблем.

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

Процесс спецификации

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

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

Тестирование юзабилити

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

Отслеживание проблем

Высокий процент исправленных проблем юзабилити не стал бы возможен без интенсивной самоотдачи всех членов команды. База для отслеживания проблем повысила управляемость процесса и гарантировала, что проблемы не ускользнут из вида. Однако исправления не были бы сделаны, если бы команда не верила в создание продукта максимально возможного качества. В этой вере главным стало наше понимание, что мы, наверное, не получим правильный результат с первого раза — и что неправильный результат настолько же полезен и важен для создания продукта, как и правильный.

Все тикеты с пометками «частично» и «не решено» перенесли в новую базу. Они стали начальной точкой для проектирования следующей версии Windows. Специалисты по планированию и дизайнеры ежедневно работали с этой информацией, а также анализировали отчёты из службы поддержки.

1. Dumas, J. S., Redish, J. C. (1993). A Practical Guide to Usability Testing (стр. 324-325). Norwood, NJ: Ablex Publishing Company.

2. Nielsen, J. (1993). Usability Engineering. San Diego, CA: Academic Press, Inc.

3. Usability Sciences Corporation. (1994). Windows 3.1 and Windows 95 Quantification of Learning Time & Productivity.

4. Whiteside, J. L., Bennett, J, & Holtzblatt, K. (1988). Usability Engineering: Our Experience and Evolution. In M. Helander (Ed.), Handbook of Human-Computer Interaction (стр. 791-817). Amsterdam: Elsevier Science Publishers, B. V.

5. Wiklund, M. E. (1994). Usability in Practice: How Companies Develop User-Friendly Products. Cambridge, MA: Academic Press, Inc.

Руководство по разработке пользовательского интерфейса для телевизионных приложений

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

Для того, чтобы управлять новыми телевизорами, не требуются антенны и кабельные приёмники. Мы используем технологии Smart или стриминговые приставки (такие как Roku или Apple TV), а также игровые консоли вроде Xbox и PlayStation. Каждое из этих устройств имеет гораздо более продвинутый пользовательский интерфейс, чем «старое доброе» экранное меню.

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

Перед вами первые две части из серии статей, посвящённых телевизионным интерфейсам. Вначале мы рассмотрим геймпад в качестве устройства ввода, а также поговорим о базовых принципах использования
Gamepad API. Во второй части речь пойдёт о совместном прототипировании контроллеров и пользовательских интерфейсов.

Экран

Чем телевизоры отличаются от компьютеров, телефонов и планшетов

Первые телевизоры использовали электронно-лучевые трубки — громоздкую технологию с адски нечётким изображением. Особенно остро эта проблема проявлялась по краям экрана, и чтобы от неё избавиться, применяли
переразвёртку. Изображение получалось несколько увеличенным, а края экрана выходили за пределы области просмотра.

Поскольку телевизионщики понимали, что часть изображения будет обрезана, они старались не размещать важную информацию по краям экрана. Постепенно появились понятия Title Safe (область, в которой текст мог отображаться без искажений) и Action Safe (область, где адекватно воспроизводилось изображение).

По каким-то
неведомым нам причинам переразвёртка до сих пор используется в HD телевизорах. Сегодня рекомендуемые границы безопасной области для пользовательского интерфейса составляют по крайней мере 5% от размеров экрана. Однако эти цифры могут меняться. Например, у Google безопасная область несколько уже, а у Apple — шире. Обычно мы устанавливаем границы этой области при построении сетки макета.

Для начала давайте ограничим экран стандартными размерами HDTV: 1920×1080 пикселей. При этом поля сверху и снизу равны 60 пикселям, а по бокам экрана — 90 пикселям.

Навигация

Влияние направленного входа на телевизионный интерфейс

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

Ещё одна традиция — управление телевизионными интерфейсами с помощью D-pad — четырёхкнопочной крестовины со стрелками (исключением является только невероятно красивый и настолько же неудобный
LG Bean Bird). Установленная на пульте или на джойстике система D-pad ограничивает навигацию четырьмя направлениями: вверх, вниз, влево и вправо. Поэтому сетка является наиболее естественной структурой для телевизионного интерфейса.

Apple TV (верхнее фото) для того, чтобы выделить элемент, на котором стоит курсор, делает его более объёмным, а HBO GO (нижнее фото) отмечает его с помощью голубой рамки

Ещё одним важным элементом в телевизионном интерфейсе является курсор. Пользователи должны каким-то образом добраться до того элемента, который они намерены выбрать. Курсор передвигается, когда пользователь нажимает на кнопки D-pad. Разные приложения используют рамки, тени, глубину или их комбинации для того, чтобы обозначить выбранный пользователем элемент. Главное правило: пользователь всегда должен понимать, где именно он находится и куда ещё можно передвинуть курсор.

Давайте воссоздадим обычный макет телевизионного пользовательского интерфейса с одной горизонтальной строкой контента. Поставим курсор на первый элемент.

8 Характеристик удачного пользовательского интерфейса / Хабр

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

1. Доступность
2. Минимализм
3. Уверенность
4. Отзывчивость
5. Соответствие контексту
6. Привлекательность
7. Эффективность
8. Снисходительность

Доступность

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

Что делает эта кнопка? Наведем курсор и прочитаем.

Минимализм

Большая загруженность — враг хорошего пользовательского интерфейса. Легко попасть в ловушку избыточной доступности — добавляя все больше и больше управляющих элементов, вы делаете огромную ошибку — загромождаете интерфейс. Ваш интерфейс растет, и пользователь будет вынужден много читать, чтобы понять что, где и для чего располагается.
Делайте вещи понятными, но с минимальной загруженностью. Если вы можете описать возможности одним предложением, вместо трех — сделайте это. Когда вы можете подписать элемент одним словом, вместо двух — сделайте это. Берегите время ваших пользователей, пусть удобство и минимализм требуют много времени, но ваши усилия будут вознаграждены.

Панель регулировки уровня звука в OS X. Коротко и доступно, ничего лишнего.

Уверенность

Многие дизайнеры стремятся сделать интерфейсы «интуитивно понятными». Но что «интуитивно» в действительности означает? Это означает, что пользователи должны инстинктивно понимать и осмысливать возможности проекта. Но как вы можете сделать что-то интуитивно понятным? Вы проектируете знакомые для себя вещи, и то, что для вас может показаться очевидным, для пользователей может отталкивать и вызывать сложности.
Попросите ваших родственников и знакомых выполнить какие-либо действия через ваш интерфейс, например, заказать товар, если ваш интерфейс подразумевает продажу чего-либо. Наблюдайте за каждым действием пользователя, за ошибками, которые он совершает. Таким образом вы соберете ряд упущений в интерфейсе, которые усложняют взаимодействие системы с пользователем. И только после исправления проблемных мест, ваш интерфейс может быть готов к работе.

Интуитивно понятный интерфейс GoPlan. Надписи на вкладках дают понять пользователю содержимое раздела.

Отзывчивость

Отзывчивость означает несколько вещей. Интерфейс веб-сайта должен работать очень быстро. Длительное ожидание загрузки страницы раздражает. Позаботьтесь о том, чтобы сайт загружался максимально быстро, даже на медленных интернет-каналах.
Так же отзывчивость означает некоторую постоянную форму взаимодействия с пользователем. Интерфейс должен информировать пользователя о происходящем. Например, вы нажимаете кнопку отправки сообщения. Если сообщение отправляется посредством AJAX, было бы разумно выводить состояния отправки, например «Отправка…», «Сообщение отправлено» или «Ошибка отправки сообщения». Когда пользователь видит процесс выполнения, он чувствует себя спокойнее. Особенно это заметно на медленных интернет-каналах.

Во время загрузки Gmail отображается прогресс-бар.

Соответствие контексту

При выборе определенных решений при создании дизайна принимайте в расчет тип содержимого страницы. Разные страницы могут содержать контент разного типа. Адаптируйте каждую страницу под соответствующий ей контент, создайте элементы управления, которые упростят пользователю работы с сайтом, и постарайтесь сделать. Но не забывайте про минимализм!
Таким образом, поработав с вашими элементами управления, пользователь привыкнет к ним и дальнейшая работа с вашим ресурсов будет для него «обыденным» делом.

Элементы управления MS Office, различные для каждого типа контента.

Привлекательность

Хоть это может быть несколько спорным моментом, но я считаю, что хороший интерфейс должен быть привлекательным. Привлекательный пользователю интерфейс делает работу с ним приятной. Да, вы можете сделать интерфейс простым в использовании, эффективности и оперативности, и он будет отлично справляться со своей задачей, — но если вы дополните этот список достоинств еще и привлекательностью — работа с ним будет чистым удовольствием!
Но сложно сделать интерфейс, который будет нравиться всем. У каждого свои предпочтения, и что покажется одному красивым, у другого будет вызывать отвращение. Тем не менее, пользователей можно разделить на некоторые социальные/демографические группы, среди которых будут и группы вашей целевой аудитории. Например, интерфейс для группы «молодые мамы» будет в корне отличаться от «менеджеров по продаже автозапчастей».

Интерфейс Google Chrome.

Эффективность

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

Три самых часто выполняемых действий над фотографиями в Apple Iphone объединены в общий список с моментальным доступом.

Снисходительность

Никто и ничто не совершенно. Будьте готовы к тому, что пользователи будут делать ошибки при работе с вашим проектом. Это может происходить как по вашей вине, так и по вине пользователя. Вы должны грамотно обрабатывать все возможные ошибки — это будет одним из главных показателей качества вашего проекта. Не стоит наказывать пользователя — разработайте «снисходительный» интерфейс.
Вы должны беречь данные от случайных действий пользователя. Например, если кто-то удаляет важную информацию, предоставьте возможность ее восстановления. Когда пользователь переходит на несуществующие страницы, не пугайте его ошибками сервера, вместо этого предоставьте список альтернативных направлений, по которым он может проследовать.
Мне нравится, как сделана страница 404 ошибки у Яндекса.

Случайно удалено важная информация в Gmail. Не проблема, можем отменить действие!

Заключение

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

Оригинал перевода: 8 Характеристик удачного пользовательского интерфейса.

Мои правила дизайна хорошего интерфейса / Хабр

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

Кстати, если вы используете Figma, я рекомендую обратить внимания на наши готовые дизайн-системы. Они помогают фрилансерам завершать больше заказов в месяц, программистам позволяют создавать красивые приложения самостоятельно, а тимлиды «пробегают» спринты быстрее, используя готовые дизайн-системы для командной работы.

А усли у вас серьезный проект, то наша команда готова развернуть дизайн-систему внутри организации на базе наших наработок и подогнать под конкретные задачи, используя Figma. Web / desktop, так и любой мобайл. С React / React Native мы тоже знакомы. Пишите в Т: @kamushken

Акценты и приоритеты

Каждый раз, проектируя интерфейс я задаю себе или клиенту вопрос: “Какая информация сейчас важна для конечного пользователя? Как мы распределим его внимание в конкретном случае?” Для этого в нашем вооружении есть цвет и его оттенки, размер шрифта, его интенсивность. В совокупности, правильно используя эти инструменты, мы “оставляем послание” пользователю, ведём его по нужному нам пути, концентрируя его внимание на самом важном.

Хороший пример, когда дизайнер дал пользователю понимание, что важно видеть отправителя, затем тему, а уже потом содержание или его @ник в системе:

Плохой пример, где дизайнер “утверждает”: важнее всего — аватарки, а с остальным как-нибудь разберётесь:

Отступы и их пропорциональность

Современный дизайн лёгок, прост и “насыщен воздухом”. Он наполнен дыханием. И не самую последнюю роль в формировании этих ощущений играют отступы. Значительные отступы помогают упростить подачу материала. Но они должны быть подчинены некоторой закономерности и пропорциональности. Я определяю для себя N пикселей в качестве базисного отступа, когда начинаю новый проект. Затем я использую 2N, 3N и так далее пропорциональность для создания визуального баланса, если где-то требуется бОльший отступ.

Хороший пример, когда дизайнер более менее соблюдает пропорциональность отступов:

Плохой пример, когда отступы практически базируются на генераторе случайных чисел:

Текст кнопки всегда первичнее иконки

Не забывайте, что именно текст является определяющим фактором того, какое ожидание или реакция предварительно сформируется у пользователя при виде кнопки. И лишь изображение иконки вторичным образом дополняет смысл. Изображение колокольчика с надписью “notifications” даёт нам некоторое представление о назначении этого функциона до того, как мы сделали клик. Аналогичный колокольчик без подписи в другом приложении приведёт нас к будильнику, хотя мы скорее всего будем ожидать появление экрана с уведомлениями. Я советую всегда наделять надпись бОльшим “весом” нежели иконки. Их я вообще считаю надувательством. Многие современные интерфейсы вполне способны обходиться и без них. Просто это было бы слишком скучно!

В целом хорошо:

Но можно сделать лучше:

Тоже выглядит неплохо:

И тут есть, где улучшить:

Не пытайтесь быть слишком понятными

Не все проектируемые интерфейсы обязаны быть интуитивно понятными. Существует множество сложных систем, с которыми мы обучались (!) взаимодействовать какое-то время. Возможно сейчас они кажутся нам простыми, но мы не отдаём отчёт, что были исследователями-первооткрывателями первые минуты, часы или более. И коль мы продолжаем работу внутри некоторой изначально сложной системы, видимо ничего не препятствовало нашему пути первых исследований. Скорее всего, дизайнер сделал свою работу настолько хорошо, что мы без труда освоили новую среду. Яркий пример из жизни: попытайтесь на миг представить, что вы не знаете значение математического знака “равно”. Согласитесь, эти две чёрточки — одна над другой, они совсем не кажутся интуитивно понятными. Просто когда-то в школе учитель математики обучил нас этому. Я призываю не пытаться быть понятнее, чем это требуется на минимально необходимом уровне.

В этом примере дизайнер был чрезмерно понятен с кнопкой закрытия:

А в этом примере дизайнер оказался чрезмерно понятен с возможностью добавления:

Перемещение курсора забирает силы

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

Хороший пример, когда дизайнер предлагает закрыть попап в той же области, которая вызвала его порождение:

Плохой пример, когда дизайнер отдаляет функционал добавления элемента в список от самого списка:

Взаимосвязи расположений или единая плоскость

Это очередной приём балансировки интерфейса. Подобие сетки, если хотите. Например, вы используете трёхколонник. Находятся ли его заголовки в одной плоскости по оси X? Или расположение иконок с кнопками. Можно ли провести мнимую ось Y и обнаружить, что и те и другие аккуратно прилегают к ней? Если ответы утвердительны, дела идут хорошо. Это обусловлено тем, что зрительно человеку легче воспринимать табличный вид из-за структурированности данных. И мы при разработке интерфейса должны располагать элементы с некоторой табличной логикой.

Плохой пример с несостыковками:

Хороший пример с гармонией и соответствием:

Цвет имеет смысл

Избитое напоследок. Красное — тревога, зелёный — всё хорошо. Испокон веков для человека самое лучше восприятие текстовой информации, это чёрным по белому. Если вы используете много цветов без аргументации, вы создаёте хаос. Если вы окрашиваете элементы по смыслу, вы создаёте еще больше порядка.

Пример хаоса: (172 votes зеленым означает ли позитивное состояние? если, да то 280 visitors оранжевым — означает негативное по логике? отнюдь! дизайнер цветом лишь разделил цифры между собой)

Пример создания порядка и обоснование цвета (я просто добавил графики поверх чужого творчества)

Хороший пример незлоупотребления цветами:

В качестве эпилога….

Выражаю благодарность членам сообщества dribbble, за неформальное согласие предоставить свои работы для данного обзора. Хочу напомнить, что вышеизложенные принципы в дизайне интерфейса являются основными для меня. Я всегда держу их в уме при проектировании интерфейсов. Определитесь на чьей вы стороне… Вы хотите создавать интерфейсы для дизайнеров и работать на лайки (пример — 98% работ с behance) или вы стремитесь решать проблемы пользователя (dribbble)? Кстати, по-моему отличный пример того, как закрытость сообщества позволяет сохранять фокусировку на главном предназначении интерфейсов!

20 заповедей дизайна пользовательского интерфейса / Хабр

Это перевод оригинальной статьи Principles of User Interface Design

«Быть дизайнером — значит не просто собирать разрозненные элементы воедино, упорядочивать их или как-то изменять. Тут нужно и создавать некую ценность, и придавать смысл, и освещать, и упрощать, и трансформировать, и облагораживать, и сгущать краски, и убеждать, и даже в какой-то мере развлекать».

— Пол Рэнд (Paul Rand)

1. Обязанность интерфейса — обеспечение взаимодействия

Интерфейсы служат для обеспечения взаимодействия между людьми и окружающим миром. Они помогают нам прояснять, освещать, реализовывать и наблюдать взаимосвязи; они могут объединять и разъединять нас, влиять на наши ожидания; а кроме того, они дают нам доступ к различным услугам. Не стоит принимать процесс разработки интерфейса за искусство в чистом виде, а сам интерфейс — за некий арт-объект. Интерфейсы призваны выполнять определенные функции, и эффективность их работы можно измерить. Но и к одним только утилитарным вопросам роль интерфейсов не сводится. Действительно хорошие интерфейсы способны вдохновлять, пробуждать, окутывать тайной и укреплять наши отношения с окружающим миром.

2. Ясность прежде всего

Любой интерфейс в первую очередь должен быть понятным. Чтобы эффективно использовать разработанный вами интерфейс, люди должны понимать, что он из себя представляет, зачем им его использовать, какие задачи они смогут с его помощью выполнять, к чему приведет то или иное действие — и тогда они смогут успешно с ним взаимодействовать. Да, разобраться в интерфейсе с первого раза может быть непросто, но двусмысленностям в нем места нет. Понятному интерфейсу пользователи доверяют и поэтому, скорее всего, будут использовать его в дальнейшем. В общем, вместо того чтобы запихивать все на один экран и тем самым запутать пользователей, лучше сделайте сотню понятных экранов.

3. Внимание любой ценой

Нас постоянно что-то отвлекает. Даже спокойно почитать уже невозможно без того, чтобы что-нибудь не отвлекло от дела. Внимание пользователей бесценно. Дайте ему сосредоточиться, не засоряйте приложения элементами, отвлекающими внимание от главного назначения того или иного созданного вами экрана. Если пользователям нужно что-то прочитать, то дайте им достаточно времени для этого, а уж потом показывайте рекламу, если это необходимо. Цените внимание ваших пользователей: от этого в выигрыше будут и они, и вы. Для обеспечения использования продукта внимание пользователей — жизненно важный фактор. Старайтесь удерживать его любой ценой.

4. Под контролем пользователей

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

5. Лучшее управление — прямое управление

Лучший интерфейс — никакого интерфейса: например, с объектами реального мира мы взаимодействуем напрямую. Но постепенно появляется все больше объектов цифровой природы, которыми управлять напрямую невозможно, и тут нам на помощь приходят интерфейсы. Очень легко сбиться с верного пути и в итоге перегрузить интерфейс кнопками, финтифлюшками, графикой, параметрами, настройками, окнами, дополнительными вставками и прочим «мусором». В результате пользователи вынуждены вместо выполнения задач заниматься управлением элементами интерфейса. Чтобы этого избежать, возьмите за образец прямое управление: интерфейс должен быть максимально незаметным и способным распознавать естественные человеческие жесты. В идеале у пользователей должно появиться ощущение, будто они управляют объектом напрямую.

6. Один экран — одна основная задача

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

7. Второстепенная задача, знай свое место

Кроме какой-то одной ключевой задачи экраны также могут служить для выполнения нескольких второстепенных задач. Но важно помнить, что главные и второстепенные задачи нельзя валить в одну кучу. Вы же, например, пишите статью не для того, чтобы пользователи делились ею в твитере, правильно? Ваша главная задача в этом случае — чтобы они ее прочитали и осознали прочитанное. Второстепенные задачи не должны выходить на первый план: к примеру, они могут быть оформлены менее заметным образом или отображаться только после того, как была выполнена ключевая задача.

8. Место для шага вперед

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

9. Поведение определяет внешний вид (или «функция определяет форму»)

Люди предпочитают иметь дело с тем, что ведет себя предсказуемым образом: это равным образом относится к другим людям, животным, объектам — и в том числе к программному обеспечению. Когда чье-то поведение совпадает с нашими ожиданиями, мы чувствуем себя на правильной волне. Соответственно, элементы дизайна интерфейса должны выглядеть соответственно своему поведению. На практике это означает, что пользователи должны понимать, как поведет себя тот или иной элемент интерфейса, едва взглянув на него. Элемент, похожий на кнопку, и вести себя должен как кнопка. Не стоит заигрывать с основополагающими аспектами взаимодействий пользователей и интерфейса — приберегите свою творческую энергию для задач другого порядка.

10. Как важно быть последовательным

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

11. Четкая иерархия — всему голова

Четкая визуальная иерархия достигается, когда элементы на экране расположены в определенном порядке. То есть одни и те же элементы отображаются в одном и том же порядке каждый раз. Плохо проработанная визуальная иерархия не приносит никакой пользы и только сбивает пользователей с толку. В постоянно изменяющихся средах не так-то просто поддерживать четкую иерархию элементов, потому что визуальный вес становится относительной величиной: ведь если выделено все, то не выделено ничего. Если на экран нужно добавить заметный элемент, дизайнеру может понадобиться сделать все остальные элементы менее заметными, чтобы сохранить визуальную иерархию. Большинство пользователей не задумываются о визуальной иерархии при работе с интерфейсом, но при этом ее продуманное (или непродуманное) выстраивание — это один из самых легких способов улучшить (или ухудшить) дизайн.

12. Грамотная организация снижает когнитивную нагрузку

Джон Маэда (John Maeda) в своей книге Simplicity пишет, что грамотная организация элементов интерфейса позволяет придать экрану менее загруженный вид. С помощью продуманной организации элементов вы сможете продемонстрировать связи между ними, и освоить такой интерфейс пользователям будет куда проще. Группируйте схожие элементы, располагайте их на экране таким образом, чтобы пользователям стало понятно, как они связаны между собой. Благодаря грамотной организации контента можно значительно снизить когнитивную нагрузку пользователей. Если в самом дизайне будут наглядно продемонстрированы связи между элементами, пользователям уже не придется мучительно в них разбираться! Не заставляйте пользователей лишний раз напрягаться — лучше просто покажите им все эти связи между элементами интерфейса с помощью вашего дизайна.

13. Подсказывай, а не указывай: роль цвета

Цвет физических объектов меняется в зависимости от освещения. Одно и то же дерево, например, в полдень и на закате выглядит совершенно по-разному. В общем, в мире физических объектов цвет включает в себя множество оттенков и вообще довольно относителен, и в интерфейсах цвет также должен играть соответствующую роль. Цветом можно выделять объекты, привлекая к ним внимание пользователей, но при этом элементы нельзя разделять только по цвету. Если предполагается, что пользователи будут работать с каким-либо элементом продолжительное время, или же элемент содержит объемный текст, рекомендуется использовать для оформления бледные или приглушенные тона — а яркие оттенки приберегите для расстановки акцентов. Разумеется, можно использовать яркие цвета и для фоновой заливки, но только там, где это уместно.

14. Не все сразу

На каждом экране должно отображаться только самое необходимое. Если пользователям требуется сделать выбор, предоставьте им ровно столько информации, сколько им для этого нужно. Подробностям можно посвятить последующие экраны. Не надо пытаться объяснить все от А до Я или выложить всю информацию разом. По возможности распределяйте рабочий процесс на несколько экранов, раскрывая информацию постепенно. Благодаря этому взаимодействие с интерфейсом остается ясным и понятным для пользователей.

15. Подсказывай с умом

В идеальных интерфейсах подсказки не нужны вовсе, потому что такой интерфейс легко изучить и использовать. Но если спуститься с небес на землю, то в идеале подсказки должны быть контекстно-зависимыми и появляться только тогда и там, где они нужны, в остальное время оставаясь скрытыми. Заставляя людей открывать справку и искать ответы на возникшие у них вопросы, вы затрудняете их работу с интерфейсом, так как в этом случае им приходится формулировать, что именно они хотят найти. Лучше встраивать подсказки там, где они могут потребоваться. Только убедитесь, что они не будут лишний раз маячить перед носом тех пользователей, которые уже знакомы с интерфейсом.

16. Момент истины: нулевое состояние

Дизайнеры часто упускают из вида такой важный момент, как первое знакомство с интерфейсом. Чтобы помочь пользователям как можно быстрее освоиться, дизайнер должен работать с прицелом на нулевое состояние — тот момент, когда еще ничего не произошло. Первый экран, который видят пользователи, не должен быть пустым, аки чистый лист, — на нем должны содержаться указания и подсказки для быстрого начала работы. Большинство затруднений при работе с интерфейсом возникает на почве непродуманного нулевого состояния. Но стоит пользователям понять правила игры, как их задача сразу значительно упрощается.

17. Текущие проблемы — главные проблемы

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

18. Лучший дизайн — невидимый дизайн

Интересный факт: действительно хорошие дизайны обычно никак не отмечаются пользователями, работавшими с ними. Причина заключается в том, что удачный дизайн позволяет пользователям сконцентрироваться на их задачах, а не на работе интерфейса. Пользователи, успешно выполнившие свои задачи, не станут задумываться над тем, как это так у них все хорошо получилось. Получается, что пользователи обращают внимание на дизайн только в том случае, если у них возникают какие-либо трудности. Да, дизайнеры не в восторге от того, что за удачные решения их никто не хвалит, притом что за косяки им достается по полной. Но действительно хорошим специалистам вполне достаточно того, что их дизайном активно пользуются. Они понимают, что довольный пользователь — это молчаливый пользователь.

19. Расширяем кругозор

Визуальный и графический дизайн, полиграфия, копирайтинг, информационная архитектура и визуализация — все это входит в дизайн интерфейсов. С этими дисциплинами можно ознакамливаться вскользь, а можно углубиться в их изучение. Главное, не стоит смотреть на них свысока или вести язвительные дебаты о важности той или иной дисциплины. Черпайте в них полезные знания — и вперед. Не брезгуйте и на первый взгляд абсолютно не связанными с дизайном интерфейсов сферами. Подумайте, чему полезному можно научиться у издателя, автора программного кода, переплетчика книг, скейтбордиста, пожарного, каратиста?

20. Неиспользуемый интерфейс — плохой интерфейс

Как и в других областях дизайна, в дизайне интерфейсов успешным считается тот результат дизайнерских трудов, который оказывается востребован пользователями. Люди не сядут даже в самое красивое кресло, если оно окажется неудобным, и этот предмет мебели не выполнит свою функцию, как и дизайн, который пользователи обходят вниманием. Таким образом, в дизайне интерфейсов важную роль играет создание не только самого объекта, но и некоей среды его использования. Дизайнер создает интерфейс не для услады собственных очей, а для того чтобы им пользовались!

Автор: Joshua Porter

Прим. пер.: На мой взгляд эта статья является прекрасным чеклистом для проверки проектируемых интерфейсов практически на любом этапе — от отрисовки скетчей до отрисовки готовых макетов и вёрстки работающего продукта.

8 этапов процесса разработки интерфейса мобильного приложения

От переводчика: Роман Гапонов — сооснователь компании Django Stars, которая занимается разработкой веб- и мобильных приложений. Основываясь на личном опыте и опыте своей компании, Роман написал статью о процессе разработки пользовательского интерфейса. Изначально она была размещена на Medium, на английском языке. Перевод этой статьи публикуется нами на Хабре.

Немного приятного: в этой статье (а это уже второй материал о мобильной разработке, первый здесь) есть своеобразная пасхалка, которая позволяет получить скидку на курс Skillbox и агентства Agima по мобильной разработке. Это ребус, который при расшифровке даст слово или название решения из сферы разработки мобильных интерфейсов. Скидка за угаданный ребус — 10%. Ребусы есть и в других наших статьях из этой серии. Скидки суммируются, и если собрать их все, можно получить курс за смешную цену.

Создание концепции

Самый первый этап — это когда идея уже есть, а разработчик имеет все необходимые инструменты для ее реализации. Но с чего нужно начинать? Мы начинаем с изучения ниши, целевой аудитории и кейсов продукта. Это неплохо помогает понять будущих клиентов сервиса и создать пользовательский интерфейс, который оптимален для каждого из них.

На этом этапе могут быть затронуты и такие аспекты, как размеры и расположение кнопок и форм, шрифты и многие другие аспекты структуры интерфейса. Давайте сравним финтех-приложение и сервис такси-компании.

Финтех-приложение. Много иконок, они не слишком крупные, но работать с ними удобно. Обилие разнообразных функций

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

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

Брейнсторминг и эскизы

Как только концепция проекта ясна, двигаемся к следующему этапу — брейнстормингу. Он нужен, чтобы превратить идею интерфейса в реальность. Мы в Django Stars берем ручку и лист бумаги — это быстрее, чем использование таких продвинутых инструментов, как Balsamiq Mockups, Sketch, Photoshop и InVision.

Диаграмма переходов

Создание эскиза дает нам структуру интерфейса. Но как пользователь должен взаимодействовать с ним? Здесь поможет User Flow Diagram. Она проиллюстрирует логику продукта, показав всевозможные способы взаимодействия с интерфейсом, дорожную карту этих взаимодействий и состояние интерфейса на каждом этапе.

Утверждение структуры и диаграммы переходов

Как только мы закончили с эскизами интерфейса и диаграммой переходов, необходимо, чтобы клиент их утвердил. Структура и переходы — основа всей дальнейшей работы с интерфейсом, поэтому мы не двигаемся дальше без получения подтверждения. На этом этапе гораздо проще внести какие-то изменения в будущий интерфейс, а значит, сэкономить и время, и деньги заказчика.

В качестве примера можно взять интернет-магазин или систему управления продажами. Меняя структуру такого проекта после внедрения дизайна, можно попасть в ситуацию, когда ломается цветовая схема сайта, поскольку элементы интерфейса и некоторые другие его части были изменены. В этом случае вам, вероятнее всего, придется отказаться от изменений. Либо всю работу нужно будет переделывать с нуля.

Выбор стиля интерфейса

Когда клиент все утверждает — можно двигаться дальше. Что будем делать? Выберем стиль интерфейса. Есть множество вариантов: от минимализма и Metro до material design и скевоморфизма. На этом этапе мы просим клиентов прислать несколько ссылок на примеры стиля интерфейса, который им нравится, а также спрашиваем об их планах на ближайшее будущее продукта. Мы уделяем внимание текущим трендам, масштабированию интерфейса, определяем время, которое необходимо на разработку и внедрение дизайна.

Подтверждение стиля

На этом этапе мы рассказываем клиенту о том, как видим все сами, а также объясняем, почему приняли то или иное решение. Он может не соглашаться с некоторыми моментами в самом начале, поскольку пока не получил полной информации об интерфейсе — у него не сформировалось представление и еще нет понимания возможных проблем. Цель — завершить обсуждение принятием варианта, который удовлетворяет и нас, и клиента.

Курсы по теме: Fullstack мобильный разработчик.

Курс создан силами Skillbox и Agima. 4-месячная программа обо всех инструментах, без которых невозможна разработка мобильных продуктов.

Прототипирование, дизайн и их демонстрация

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

Wireframe

Самая быстрая форма реализации ваших идей. Это низкоуровневая демонстрация дизайна. Однако такой способ позволяет показать структуру и описание взаимодействия пользователей с разрабатываемым продуктом. Выполняется в форме блочного интерфейса в оттенках серого.

Макет

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

Кликабельный прототип

Это уже детализированный прототип финального продукта. Он эмулирует взаимодействие пользователя с интерфейсом. Например, позволяет кликать по элементам управления, использовать формы и проверять другие моменты, включая анимацию. Тем не менее создание такого прототипа — процесс, который требует большого количества времени.

Так. Пришло время ребуса, вы попали именно в то место, где можно найти скидку. Учитывайте, что английский здесь может мешаться с русским, и главное — не забывайте, что мы будем тщательно следить за комментариями и удалять из них подсказки и ответы! Промослово, зашифрованное в ребусе, следует назвать, когда с вами свяжется наш менеджер после того, как вы отправите заявку на курс. Скидки за разгаданные ребусы суммируются между собой (с учетом этой статьи есть четыре ребуса), но не со скидками на сайте. Слишком медлить не стоит — промо работает до 30 августа 2018 года.

Анимированные flow

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

Утверждение дизайна

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

В качестве вывода

Поэтапная разработка интерфейса позволяет быстро добраться до конечной цели. Все это экономит время, причем в процессе разработки можно без проблем вносить изменения. Также такой способ работы значительно снижает вероятность появления неожиданных правок от клиентов.

Skillbox рекомендует

Обзор разработки пользовательского интерфейса — приложения Win32

• 31.05.2018
• 2 минуты на чтение

В этой статье

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

Пользовательский интерфейс приложения и взаимодействие с пользователем

Для начала необходимо пояснить термины «пользовательский интерфейс» и «взаимодействие с пользователем».

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

Однако пользовательский интерфейс приложения — это только один аспект общего взаимодействия с пользователем.Другие аспекты взаимодействия с пользователем, которые не видны пользователю, но являются неотъемлемой частью приложения и критичны для его удобства использования, включают время запуска, задержку, обработку ошибок и автоматизированные задачи, которые выполняются без прямого взаимодействия с пользователем.

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

Разработка пользовательского интерфейса

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

Ниже описаны типичные этапы процесса разработки пользовательского интерфейса:

Проектирование

• Функциональные требования — определение начальных требований и целей приложения.
• Анализ пользователей — определение пользовательских сценариев и понимание потребностей и ожиданий пользователей для каждого сценария.
• Концептуальный дизайн — моделируйте основной бизнес, который приложение должно поддерживать.
• Логический дизайн — Разработка процесса и информационного потока приложения.
• Физический дизайн — Решите, как логический дизайн будет реализован на конкретных физических платформах.

Реализация

• Prototype — Разработка макетов бумажных или интерактивных экранов, ориентированных на интерфейс и не содержащих отвлекающих элементов визуального дизайна.
• Construct — создайте приложение и подготовьтесь к запросам на изменение конструкции.

Тестирование

• Юзабилити-тестирование — протестируйте приложение с различными пользователями и сценариями.
• Тестирование доступности — протестируйте приложение с помощью доступных технологий и автоматизированных средств тестирования.

,

Домашняя страница разработки пользовательского интерфейса — Финансы и операции | Динамика 365

• 15.10.2019
• 3 минуты на чтение

В этой статье

Важно

Dynamics 365 for Finance and Operations превратился в специализированные приложения, которые помогут вам управлять конкретными бизнес-функциями.Дополнительные сведения об этих изменениях см. В Руководстве по лицензированию Dynamics 365.

Этот раздел содержит ссылки на разделы о разработке элементов пользовательского интерфейса.

Пользовательский интерфейс для приложений Finance and Operation значительно отличается от интерфейса для Microsoft Dynamics AX 2012. Клиент в Dynamics AX 2012 — это приложение Microsoft Win32, которое имеет расширения, использующие элементы управления ActiveX, WinForm или WPF. Логика приложения X ++ выполняется на клиенте для методов формы и таблицы, а некоторая логика выполняется на сервере.Что касается элементов управления, то и интерфейс прикладного программирования логики X ++ (API), и физический элемент управления Win32 тесно связаны с клиентом. Клиент — это веб-клиент HTML, работающий во всех основных браузерах. Эти браузеры включают Microsoft Edge, Internet Explorer 11, Chrome и Safari (см. Системные требования). Переход на веб-клиент привел к следующим изменениям клиентских форм и элементов управления:

• Физическое представление форм и элементов управления теперь в браузере — это HTML, JavaScript и CSS.
• Элементы управления формой разделены на логическую и физическую части. Логический API X ++ и связанное с ним состояние выполняются на сервере.
• Логическая и физическая части синхронизируются посредством сервисных вызовов, сообщающих об изменениях с каждой стороны. Например, действие пользователя на клиенте создает вызов службы к серверу, который либо отправляется немедленно, либо ставится в очередь, чтобы его можно было отправить позже.
• Уровень сервера сохраняет состояние формы в памяти, пока форма открыта.

Метамодель формы продолжает использоваться для определения элементов управления и логики приложения.Этот подход поддерживает почти все существующие метамодели Form, Form DataSource и Form Control, а также методы переопределения X ++. Однако некоторые типы элементов управления, свойства и методы переопределения были удалены либо из-за несовместимости с новой платформой, либо из соображений производительности. Например, элементы управления ActiveX и ManagedHost больше нельзя использовать для добавления настраиваемых элементов управления, поскольку они несовместимы с платформой HTML. Вместо этого была добавлена ​​новая расширяемая структура управления, которая позволяет добавлять дополнительные элементы управления.

Учебники

Формы

Органы управления

Сообщения

Рекомендации по шаблонам формы

Расширяемость управления

,

Проектирование пользовательского интерфейса — приложения Win32

• 31.05.2018
• 6 минут на чтение

В этой статье

В этом разделе подробно описаны некоторые задачи, связанные с проектированием пользовательского интерфейса для приложения Windows.

Введение

Дизайн пользовательского интерфейса

можно разделить на три основных элемента: функциональность, эстетику и производительность.

Чаще всего при разработке приложения основное внимание уделяется функциональности. Можно ли использовать приложение? Позволяет ли это пользователям выполнять задачи? Однако функциональность — это только часть истории.

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

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

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

Функциональные требования

Рассмотрите следующие предложения на ранней стадии проектирования, чтобы оптимизировать взаимодействие с пользователем для максимально широкой аудитории:

• Следуйте рекомендациям по дизайну пользовательского интерфейса.

  Ознакомьтесь с рекомендациями по взаимодействию с пользователем Windows и часто обращайтесь к ним по мере разработки, реализации и тестирования пользовательского интерфейса приложения.

• Убедитесь, что пользовательский интерфейс доступен.

  Обязательно интегрируйте специальные возможности в дизайн пользовательского интерфейса с самого начала жизненного цикла продукта. Модернизация специальных возможностей может быть чрезвычайно дорогостоящей, поскольку часть развития специальных возможностей требует внимания на архитектурном уровне.Для получения дополнительной информации загрузите электронную книгу «Инженерное программное обеспечение для обеспечения доступности».

• Поддержка международного рынка.

  Windows включает технологии, обеспечивающие поддержку многих культур и письменных языков в приложении Windows. Если приложение нацелено на международный рынок, важно с самого начала проекта включить поддержку интернационализации в дизайн пользовательского интерфейса. Дополнительные сведения см. В разделе «Интернационализация приложений Windows».

Анализ пользователей

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

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

Помните, не задавайте наводящих или предвзятых вопросов, так как это напрямую повлияет на качество и достоверность отзывов пользователей. При составлении вопросов на этом этапе помните следующее:

• Кто наши пользователи? Какие навыки и знания у них есть?
• Какие различные источники данных мы можем использовать, чтобы понять их опыт?
• Для решения каких целей и задач они будут использовать наш продукт?
• Какие предположения мы делаем и как мы можем их проверить?
• Какие у нас есть источники данных? (Для начала рекомендуется изучить юзабилити и эвристические оценки.)

Описание проблем

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

Часто бывает полезно составить список из формулировок проблемы одним предложением (с точки зрения пользователей) для каждой проблемы или требования. Например, «Изменить ширину поля редактирования до 15 символов» не проблема. Но фраза «Слишком сложно вводить длинные поисковые запросы» — это верная постановка проблемы.Разница колоссальная. Старайтесь не определять решение и проблему одновременно: часто реальная проблема теряется. В этом примере может быть много других способов решения проблемы условий поиска, включая изменение размера поля редактирования. Всегда помните об альтернативных решениях.

Ниже приведены дополнительные примеры формулировок проблемы:

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

Если формулировка проблемы достаточно широка, вероятно, существует множество инновационных и творческих способов их решения.

Приоритеты

Действие составления списка элементов и их ранжирования по приоритету определяет выпуск.Без четких приоритетов команды могут ссориться и спорить о том, что делать, а что сокращать. Работа по расстановке приоритетов должна быть легче после завершения исследования, но это всегда проблема.

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

Состав и характер команды определяют, какие виды работы можно выполнять. Какие еще обязательства есть у команды? Есть ли в команде дизайнер или юзабилити-инженер? Какими навыками в веб-дизайне или дизайне пользовательского интерфейса обладает команда? И последнее и самое важное — это деловые соображения. Каковы цели по доходам для этого проекта? Кто конкуренты? Каковы преимущества решения определенных проблем? Какие партнерские отношения можно установить? Любые другие соображения также должны быть определены до определения приоритетности списка.

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

Концептуальный проект

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

Логический дизайн

Фаза логического проектирования — это когда разрабатываются начальные прототипы, поддерживающие концептуальный дизайн.

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

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

Физическая конструкция

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

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

,

Что такое дизайн пользовательского интерфейса?

Научитесь разрабатывать с учетом потребностей и ожиданий пользователей, применяя «Десять рекомендаций по пользовательскому интерфейсу» Якоба Нильсена и Рольфа Молича. Эта эвристика нашла отражение во многих продуктах, разработанных некоторыми из самых успешных компаний в мире, такими как Apple, Google и Adobe. Дополнительное свидетельство того, как их проектные группы включают эти правила в свой процесс проектирования, отражено в руководствах по пользовательскому интерфейсу, опубликованных и распространенных этими компаниями.В этой статье вы узнаете, как следовать десяти эмпирическим правилам при проектировании, чтобы вы могли еще больше повысить удобство использования, полезность и желательность своих дизайнов.

10 рекомендаций по дизайну пользовательского интерфейса Нильсена и Молиха

Якоб Нильсен, известный консультант по веб-юзабилити и партнер Nielsen Norman Group, и Рольф Молич, другой известный эксперт по юзабилити, составили список из десяти руководств по дизайну пользовательского интерфейса в 1990-х годах. Обратите внимание на то, что эвристика Нильсена и Молиха во многом пересекается с «восемью золотыми правилами» Бена Шнейдермана.Эти 10 эмпирических правил являются продолжением восьми золотых правил Шнейдермана через 4 года после первой публикации Шнейдермана.

• Просмотр состояния системы . Пользователи всегда должны быть проинформированы о системных операциях с понятным и хорошо заметным статусом, отображаемым на экране в течение разумного периода времени.
• Соответствие системы и реального мира . Дизайнеры должны стремиться отражать язык и концепции, которые пользователи могут найти в реальном мире, в зависимости от того, кем являются их целевые пользователи.Представление информации в логическом порядке и совмещение ожиданий пользователей, основанных на их реальном опыте, снизят когнитивное напряжение и упростят использование систем.
• Контроль и свобода пользователя . Предложите пользователям цифровое пространство, где возможны обратные шаги, включая отмену и повтор предыдущих действий.
• Согласованность и стандарты . Разработчики интерфейсов должны гарантировать, что и графические элементы, и терминология поддерживаются на одинаковых платформах.Например, значок, представляющий одну категорию или концепцию, не должен представлять другую концепцию при использовании на другом экране.
• Предотвращение ошибок . По возможности проектируйте системы так, чтобы возможные ошибки были сведены к минимуму. Пользователи не любят, когда их призывают выявлять и устранять проблемы, которые иногда могут выходить за рамки их уровня знаний. Устранение или отметка действий, которые могут привести к ошибкам, являются двумя возможными способами предотвращения ошибок.
• Признание, а не отзыв. Сведите к минимуму когнитивную нагрузку, сохраняя релевантную для задачи информацию на дисплее, пока пользователи исследуют интерфейс. Человеческое внимание ограничено, и мы способны одновременно поддерживать только около пяти элементов в нашей кратковременной памяти. Из-за ограничений кратковременной памяти дизайнеры должны гарантировать, что пользователи могут просто использовать распознавание вместо того, чтобы вспоминать информацию по частям диалога. Распознать что-либо всегда легче, чем вспомнить, потому что распознавание включает в себя восприятие сигналов, которые помогают нам проникнуть в нашу обширную память и позволяют всплыть на поверхность соответствующей информации.Например, мы часто находим в тесте более простой формат вопросов с несколькими вариантами ответов, чем вопросы с короткими ответами, потому что он требует только распознать ответ, а не вспоминать его из своей памяти.
• Гибкость и эффективность использования . С увеличением использования возникает потребность в меньшем количестве взаимодействий, что обеспечивает более быструю навигацию. Этого можно добиться с помощью сокращений, функциональных клавиш, скрытых команд и макросов. Пользователи должны иметь возможность настраивать или адаптировать интерфейс в соответствии со своими потребностями, чтобы частые действия можно было выполнять более удобными способами.
• Эстетичный и минималистичный дизайн . Сведите к минимуму беспорядок. Вся ненужная информация конкурирует за ограниченные ресурсы внимания пользователя, что может препятствовать поиску пользователем в памяти соответствующей информации. Следовательно, отображение должно быть уменьшено до только необходимых компонентов для текущих задач, обеспечивая при этом четко видимые и однозначные средства перехода к другому контенту.
• Помогите пользователям распознать, диагностировать и исправить ошибки .Разработчики должны исходить из того, что пользователи не могут понять техническую терминологию, поэтому сообщения об ошибках почти всегда должны быть выражены простым языком, чтобы ничего не потерялось при переводе.
• Справка и документация . В идеале мы хотим, чтобы пользователи перемещались по системе, не прибегая к документации. Однако в зависимости от типа решения может потребоваться документация. Когда пользователям требуется помощь, убедитесь, что ее легко найти, она подходит для конкретной задачи и сформулирована таким образом, чтобы помочь им выполнить необходимые шаги для решения проблемы, с которой они сталкиваются.

Google Inc., технологическая компания с многомиллиардным оборотом, безусловно, производит проекты, которые отражают вышеприведенные эвристики. Джон Уайли, главный дизайнер Google Search в 2012 году, однажды сказал:

«Когда я думаю о дизайне и создании отличного пользовательского опыта, я обычно думаю о нем с точки зрения трех вещей: удобство использования, полезность и желательность».

10 рекомендаций Нильсена и Молиха по пользовательскому интерфейсу довольно хорошо охватывают эти три ключевых компонента пользовательского опыта, а это означает, что вы, вероятно, сможете улучшить пользовательский опыт своих проектов, следуя этим рекомендациям!

Узнайте, как Adobe объединяет десять рекомендаций по дизайну пользовательского интерфейса Nielsen и Molich

Adobe Systems Incorporated, крупная североамериканская компания, производящая программное обеспечение, является отличным примером того, как дизайн, отражающий десять рекомендаций Nielsen и Molich по пользовательскому интерфейсу, может привести к успеху компании ,Один из их самых популярных продуктов, Adobe Photoshop, редактор растровой графики, демонстрирует характеристики хорошо разработанного пользовательского интерфейса, который отражает эти рекомендации.

Мы более подробно рассмотрим, как Adobe Photoshop отражает каждое из этих руководящих принципов, чтобы вдохновить вас на повышение удобства использования, полезности и желательности ваших собственных дизайнов путем включения 10 практических правил в свою работу.

1. Видимость состояния системы

Photoshop отлично справляется с задачей, позволяя пользователю узнать, что происходит с программой, визуально показывая пользователю, к чему привели его действия, когда это возможно.Например, когда пользователи перемещают слои в палитре «Слои», они могут визуально видеть слой, представленный как физически перетаскиваемый в пространстве.

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

Изображение курсора переходит от раскрытой руки к зажатой, когда пользователь перетаскивает слой внутри палитры слоев. Это упрощает мгновенное понимание состояния системы.Кроме того, выбор Adobe использования «руки» — отличный пример второго правила, согласно которому система соответствует реальному миру.

2. Соответствие системы реальному миру

Пример Photoshop, имитирующего реальный мир в терминах и представлениях, понятных их целевым пользователям, — это то, где они проектируют информационную структуру и терминологию, отражающие те же формулировки, которые мы использовали бы в мир фотографии или печатных СМИ. Знакомые концепции и термины, такие как RGB, Hue / Saturation / Brightness и CMYK, используются для представления цвета, в то время как различные инструменты, такие как Dodge Tool и Burn Tool, имитируют традиционную технику фотолаборатории для фотографий.

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

Инструменты Dodge и Burn в Photoshop имитируют традиционную технику фотолаборатории для фотографий

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

В Photoshop используется термин «экспозиция», который обычно используется в мире фотографии.

3. Управление и свобода пользователя

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

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

Все в руках пользователей, так как они могут сделать шаг назад или шаг вперед в меню «Правка» или, в качестве альтернативы, они могут использовать сочетания клавиш Photoshop, например, Alt + Ctrl + Z.

4. Согласованность и стандарты

Photoshop поддерживает стандартный макет и внешний вид, когда дело доходит до строки меню. Они также используют общеизвестные термины, такие как «Новый…», «Открыть…», «Сохранить как…» и т. Д.

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

Меню «Файл» в Photoshop отображает множество хорошо знакомых параметров.

5.Предотвращение ошибок

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

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

Пользователь наводит курсор на значок ластика, и Photoshop отображает метку «Инструмент ластика».

6.Распознавание, а не воспоминание

Независимо от того, делает ли он выбор из меню художественных фильтров или открывает новый файл изображения, Photoshop предоставляет пример просмотра, чтобы пользователи могли сделать правильный выбор. Это позволяет пользователю визуально распознать то, что он ищет, вместо того, чтобы вспоминать имя или вводить его для поиска. Возможно, вы встречали другие программы для редактирования фотографий, которые просят вас вспомнить и ввести имя файла, с которым вы хотите работать. Это действительно может быть действительно трудно вспомнить, поскольку часто это что-то вроде: 29412_09342.JPG.

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

Пользователь может визуально распознать изображение заката по его миниатюре и выбрать его.

7. Гибкость и эффективность использования

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

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

Photoshop дает частым пользователям возможность сохранить предпочтительные настройки рабочего пространства.

8. Эстетичный и минималистский дизайн

Панель инструментов в Photoshop отображает только значки и аккуратно спрятана в сторону, чтобы свести к минимуму беспорядок и сохранить эстетику минимализма.

Автор / правообладатель: Adobe Systems Incorporated.Условия авторских прав и лицензия: Добросовестное использование

Панель инструментов Photoshop минималистична и позволяет избежать беспорядка, представляя инструменты только значками.

9. Помощь пользователям в распознавании, диагностике и устранении ошибок

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

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

В этом сообщении об ошибке, связанном с неправильным использованием штампа клонирования пользователем, Photoshop объясняет, что пошло не так, почему и как пользователю следует действовать дальше.

10. Справка и документация

Справка и документация легко доступны через строку главного меню. Оттуда вы можете найти множество разделов справки и руководств о том, как в полной мере использовать программу.

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

В окне отображается информация о том, как создавать ролловеры в контексте веб-графики. Пользователь также может видеть список тем в боковом меню.

10 шагов к повышению удобства использования, полезности и желательности путем внедрения рекомендаций Нильсена и Молиха по проектированию пользовательского интерфейса

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

Скачать PDF можно здесь .

Выводы

Если вы будете следовать 10 рекомендациям Нильсена и Молиха по пользовательскому интерфейсу, вы будете проектировать с учетом удобства использования, полезности и желательности.Так же, как дизайнеры успешных компаний, таких как Apple, Google и Adobe, вы сможете поддерживать свои дизайнерские решения с помощью хорошо изученных эвристических методов и быть уверенными в создании дизайна, который будет одновременно удобен и красив. Чтобы научиться распознавать эти 10 эмпирических правил, продолжайте выполнять упражнение, описанное в прилагаемом файле из приведенного выше раздела.

Где узнать больше

Чтобы найти дополнительную информацию о книге Якоба Нильсена «Повышение объясняющей силы эвристики юзабилити», перейдите по ссылке:

https: // static.aminer.org/pdf/PDF/000/089/679/enha …

Ссылки и где узнать больше

Изображение героя: Автор / Правообладатель: Барри Шварц. Flickr. Условия авторских прав и лицензия: CC BY-NC 2.0

Курс: Шаблоны дизайна пользовательского интерфейса для успешного программного обеспечения:
https://www.interaction-design.org/courses/ui-design-patterns-for-successful-software

Научитесь разрабатывать с учетом потребностей и ожиданий пользователей, применяя «Десять рекомендаций по пользовательскому интерфейсу» Якоба Нильсена и Рольфа Молича.Эта эвристика нашла отражение во многих продуктах, разработанных некоторыми из самых успешных компаний в мире, такими как Apple, Google и Adobe. Дополнительное свидетельство того, как их проектные группы включают эти правила в свой процесс проектирования, отражено в руководствах по пользовательскому интерфейсу, опубликованных и распространенных этими компаниями. В этой статье вы узнаете, как следовать десяти эмпирическим правилам при проектировании, чтобы вы могли еще больше повысить удобство использования, полезность и желательность своих дизайнов.

10 рекомендаций по дизайну пользовательского интерфейса Нильсена и Молиха

Якоб Нильсен, известный консультант по веб-юзабилити и партнер Nielsen Norman Group, и Рольф Молич, другой известный эксперт по юзабилити, составили список из десяти руководств по дизайну пользовательского интерфейса в 1990-х годах. Обратите внимание на то, что эвристика Нильсена и Молиха во многом пересекается с «восемью золотыми правилами» Бена Шнейдермана. Эти 10 эмпирических правил являются продолжением восьми золотых правил Шнейдермана через 4 года после первой публикации Шнейдермана.

• Просмотр состояния системы . Пользователи всегда должны быть проинформированы о системных операциях с понятным и хорошо заметным статусом, отображаемым на экране в течение разумного периода времени.
• Соответствие системы и реального мира . Дизайнеры должны стремиться отражать язык и концепции, которые пользователи могут найти в реальном мире, в зависимости от того, кем являются их целевые пользователи. Представление информации в логическом порядке и совмещение ожиданий пользователей, основанных на их реальном опыте, снизят когнитивное напряжение и упростят использование систем.
• Контроль и свобода пользователя . Предложите пользователям цифровое пространство, где возможны обратные шаги, включая отмену и повтор предыдущих действий.
• Согласованность и стандарты . Разработчики интерфейсов должны гарантировать, что и графические элементы, и терминология поддерживаются на одинаковых платформах. Например, значок, представляющий одну категорию или концепцию, не должен представлять другую концепцию при использовании на другом экране.
• Предотвращение ошибок . По возможности проектируйте системы так, чтобы возможные ошибки были сведены к минимуму. Пользователи не любят, когда их призывают выявлять и устранять проблемы, которые иногда могут выходить за рамки их уровня знаний. Устранение или отметка действий, которые могут привести к ошибкам, являются двумя возможными способами предотвращения ошибок.
• Признание, а не отзыв. Сведите к минимуму когнитивную нагрузку, сохраняя релевантную для задачи информацию на дисплее, пока пользователи исследуют интерфейс.Человеческое внимание ограничено, и мы способны одновременно поддерживать только около пяти элементов в нашей кратковременной памяти. Из-за ограничений кратковременной памяти дизайнеры должны гарантировать, что пользователи могут просто использовать распознавание вместо того, чтобы вспоминать информацию по частям диалога. Распознать что-либо всегда легче, чем вспомнить, потому что распознавание включает в себя восприятие сигналов, которые помогают нам проникнуть в нашу обширную память и позволяют всплыть на поверхность соответствующей информации. Например, мы часто находим в тесте более простой формат вопросов с несколькими вариантами ответов, чем вопросы с короткими ответами, потому что он требует только распознать ответ, а не вспоминать его из своей памяти.
• Гибкость и эффективность использования . С увеличением использования возникает потребность в меньшем количестве взаимодействий, что обеспечивает более быструю навигацию. Этого можно добиться с помощью сокращений, функциональных клавиш, скрытых команд и макросов. Пользователи должны иметь возможность настраивать или адаптировать интерфейс в соответствии со своими потребностями, чтобы частые действия можно было выполнять более удобными способами.
• Эстетичный и минималистичный дизайн . Сведите к минимуму беспорядок.Вся ненужная информация конкурирует за ограниченные ресурсы внимания пользователя, что может препятствовать поиску пользователем в памяти соответствующей информации. Следовательно, отображение должно быть уменьшено до только необходимых компонентов для текущих задач, обеспечивая при этом четко видимые и однозначные средства перехода к другому контенту.
• Помогите пользователям распознать, диагностировать и исправить ошибки . Разработчики должны исходить из того, что пользователи не могут понять техническую терминологию, поэтому сообщения об ошибках почти всегда должны быть выражены простым языком, чтобы ничего не потерялось при переводе.
• Справка и документация . В идеале мы хотим, чтобы пользователи перемещались по системе, не прибегая к документации. Однако в зависимости от типа решения может потребоваться документация. Когда пользователям требуется помощь, убедитесь, что ее легко найти, она подходит для конкретной задачи и сформулирована таким образом, чтобы помочь им выполнить необходимые шаги для решения проблемы, с которой они сталкиваются.

Google Inc., технологическая компания с многомиллиардным оборотом, безусловно, производит проекты, которые отражают вышеприведенные эвристики.Джон Уайли, главный дизайнер Google Search в 2012 году, однажды сказал:

«Когда я думаю о дизайне и создании отличного пользовательского опыта, я обычно думаю о нем с точки зрения трех вещей: удобство использования, полезность и желательность».

10 рекомендаций Нильсена и Молиха по пользовательскому интерфейсу довольно хорошо охватывают эти три ключевых компонента пользовательского опыта, а это означает, что вы, вероятно, сможете улучшить пользовательский опыт своих проектов, следуя этим рекомендациям!

Узнайте, как Adobe объединяет десять рекомендаций по дизайну пользовательского интерфейса Nielsen и Molich

Adobe Systems Incorporated, крупная североамериканская компания, производящая программное обеспечение, является отличным примером того, как дизайн, отражающий десять рекомендаций Nielsen и Molich по пользовательскому интерфейсу, может привести к успеху компании ,Один из их самых популярных продуктов, Adobe Photoshop, редактор растровой графики, демонстрирует характеристики хорошо разработанного пользовательского интерфейса, который отражает эти рекомендации.

Мы более подробно рассмотрим, как Adobe Photoshop отражает каждое из этих руководящих принципов, чтобы вдохновить вас на повышение удобства использования, полезности и желательности ваших собственных дизайнов путем включения 10 практических правил в свою работу.

1. Видимость состояния системы

Photoshop отлично справляется с задачей, позволяя пользователю узнать, что происходит с программой, визуально показывая пользователю, к чему привели его действия, когда это возможно.Например, когда пользователи перемещают слои в палитре «Слои», они могут визуально видеть слой, представленный как физически перетаскиваемый в пространстве.

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

Изображение курсора переходит от раскрытой руки к зажатой, когда пользователь перетаскивает слой внутри палитры слоев. Это упрощает мгновенное понимание состояния системы.Кроме того, выбор Adobe использования «руки» — отличный пример второго правила, согласно которому система соответствует реальному миру.

2. Соответствие системы реальному миру

Пример Photoshop, имитирующего реальный мир в терминах и представлениях, понятных их целевым пользователям, — это то, где они проектируют информационную структуру и терминологию, отражающие те же формулировки, которые мы использовали бы в мир фотографии или печатных СМИ. Знакомые концепции и термины, такие как RGB, Hue / Saturation / Brightness и CMYK, используются для представления цвета, в то время как различные инструменты, такие как Dodge Tool и Burn Tool, имитируют традиционную технику фотолаборатории для фотографий.

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

Инструменты Dodge и Burn в Photoshop имитируют традиционную технику фотолаборатории для фотографий

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

В Photoshop используется термин «экспозиция», который обычно используется в мире фотографии.

3. Управление и свобода пользователя

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

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

Все в руках пользователей, так как они могут сделать шаг назад или шаг вперед в меню «Правка» или, в качестве альтернативы, они могут использовать сочетания клавиш Photoshop, например, Alt + Ctrl + Z.

4. Согласованность и стандарты

Photoshop поддерживает стандартный макет и внешний вид, когда дело доходит до строки меню. Они также используют общеизвестные термины, такие как «Новый…», «Открыть…», «Сохранить как…» и т. Д.

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

Меню «Файл» в Photoshop отображает множество хорошо знакомых параметров.

5.Предотвращение ошибок

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

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

Пользователь наводит курсор на значок ластика, и Photoshop отображает метку «Инструмент ластика».

6.Распознавание, а не воспоминание

Независимо от того, делает ли он выбор из меню художественных фильтров или открывает новый файл изображения, Photoshop предоставляет пример просмотра, чтобы пользователи могли сделать правильный выбор. Это позволяет пользователю визуально распознать то, что он ищет, вместо того, чтобы вспоминать имя или вводить его для поиска. Возможно, вы встречали другие программы для редактирования фотографий, которые просят вас вспомнить и ввести имя файла, с которым вы хотите работать. Это действительно может быть действительно трудно вспомнить, поскольку часто это что-то вроде: 29412_09342.JPG.

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

Пользователь может визуально распознать изображение заката по его миниатюре и выбрать его.

7. Гибкость и эффективность использования

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

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

Photoshop дает частым пользователям возможность сохранить предпочтительные настройки рабочего пространства.

8. Эстетичный и минималистский дизайн

Панель инструментов в Photoshop отображает только значки и аккуратно спрятана в сторону, чтобы свести к минимуму беспорядок и сохранить эстетику минимализма.

Автор / правообладатель: Adobe Systems Incorporated.Условия авторских прав и лицензия: Добросовестное использование

Панель инструментов Photoshop минималистична и позволяет избежать беспорядка, представляя инструменты только значками.

9. Помощь пользователям в распознавании, диагностике и устранении ошибок

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

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

В этом сообщении об ошибке, связанном с неправильным использованием штампа клонирования пользователем, Photoshop объясняет, что пошло не так, почему и как пользователю следует действовать дальше.

10. Справка и документация

Справка и документация легко доступны через строку главного меню. Оттуда вы можете найти множество разделов справки и руководств о том, как в полной мере использовать программу.

Автор / правообладатель: Adobe Systems Incorporated. Условия авторских прав и лицензия: Добросовестное использование

В окне отображается информация о том, как создавать ролловеры в контексте веб-графики. Пользователь также может видеть список тем в боковом меню.

10 шагов к повышению удобства использования, полезности и желательности путем внедрения рекомендаций Нильсена и Молиха по проектированию пользовательского интерфейса

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

Скачать PDF можно здесь .

Выводы

Если вы будете следовать 10 рекомендациям Нильсена и Молиха по пользовательскому интерфейсу, вы будете проектировать с учетом удобства использования, полезности и желательности.Так же, как дизайнеры успешных компаний, таких как Apple, Google и Adobe, вы сможете поддерживать свои дизайнерские решения с помощью хорошо изученных эвристических методов и быть уверенными в создании дизайна, который будет одновременно удобен и красив. Чтобы научиться распознавать эти 10 эмпирических правил, продолжайте выполнять упражнение, описанное в прилагаемом файле из приведенного выше раздела.

Где узнать больше

Чтобы найти дополнительную информацию о книге Якоба Нильсена «Повышение объясняющей силы эвристики юзабилити», перейдите по ссылке:

https: // static.aminer.org/pdf/PDF/000/089/679/enha …

Ссылки и где узнать больше

Изображение героя: Автор / Правообладатель: Барри Шварц. Flickr. Условия авторских прав и лицензия: CC BY-NC 2.0

Курс: Шаблоны дизайна пользовательского интерфейса для успешного программного обеспечения:
https://www.interaction-design.org/courses/ui-design-patterns-for-successful-software

,