Проектирование графического интерфейса пользователя
Время на прочтение
6 мин
Количество просмотров 175K
Введение
В современном мире миллиарды вычислительных устройств. Еще больше программ для них. И у каждой свой интерфейс, являющийся «рычагами» взаимодействия между пользователем и машинным кодом. Не удивительно, что чем лучше интерфейс, тем эффективнее взаимодействие.
Однако далеко не все разработчики и даже дизайнеры, задумываются о создании удобного и понятного графического интерфейса пользователя.
Для себя я начал с постановки вопросов: общие принципы, какие элементы интерфейса(ЭИ) создать, какой у них должен быть дизайн, где их правильно размещать и как они должны себя вести.
Ниже я постараюсь ответить на эти вопросы.
Общие принципы
- Интерфейс должен быть интуитивно понятным. Таким, чтобы пользователю не требовалось объяснять как им пользоваться.
- Для упрощения процесса изучения необходима справка. Буквально — графическая подсказка, объясняющая значение того или иного ЭИ. Полное руководство должно быть частью интерфейса, доступной в любой момент.
- Возвращайте пользователя в то место, где он закончил работу в прошлый раз. Зачем нажимать все заново?
- Чаще всего, пользователи в интерфейсе сначала ищут сущность(существительное), а затем действие(глагол) к ней. Следуйте правилу «существительное -> глагол». Например, шрифт -> изменить.
- Чем быстрее человек увидит результат — тем лучше. Пример — «живой» поиск, когда варианты, в процессе набора поискового запроса. Основной принцип: программа должна взаимодействовать с пользователем на основе наименьшей значимой единицы ввода.
- Используйте квазирежимы. Например, ввод заглавных букв с зажатой клавишей shift — это квазирежим. С включенным capslock — режим. Основное отличие в том, что человек может забыть в каком режиме он находится, а в квазирежиме(с зажатой доп. клавишей) это сделать гораздо сложнее.
- Следует с осторожностью предоставлять пользователю возможность, по установке личных настроек. Представьте, сколько времени потратит сотрудник настраивая Word, если его интерфейс был полностью переделан предыдущим.
- Чем больше пользователь работает с какой-то конкретной задачей, тем больше он на ней концентрируется и тем меньше перестает замечать подсказки и сообщения, выводимые программой. Чем более критической является задача, тем меньше вероятность того, что пользователь заметит предупреждения относительно тех или иных потенциально опасных действий.
Какие ЭИ создать?
- Разработка интерфейса обычно начинается с определения задачи или набора задач, для которых продукт предназначен
- Простое должно оставаться простым. Не усложняйте интерфейсы. Постоянно думайте о том, как сделать интерфейс проще и понятнее.
- Пользователи не задумываются над тем, как устроена программа. Все, что они видят — это интерфейс. Поэтому, с точки зрения потребителя именно интерфейс является конечным продуктом.
- Интерфейс должен быть ориентированным на человека, т.е. отвечать нуждам человека и учитывать его слабости. Нужно постоянно думать о том, с какими трудностями может столкнуться пользователь.
- Думайте о поведении и привычках пользователей. Не меняйте хорошо известные всем ЭИ на неожиданные, а новые делайте интуитивно понятными.
- Разрабатывайте интерфейс исходя из принципа наименьшего возможного количества действий со стороны пользователя.
Какой должен быть дизайн ЭИ?
На самом деле, дизайн ЭИ — тема отдельной статьи. Тут нужно учитывать все: начиная от цвета, формы, пропорций, заканчивая когнитивной психологией. Однако, несколько принципов все же стоит отметить:
- Цвет. Цвета делятся на теплые(желтый, оранжевый, красный), холодные(синий, зеленый), нейтральные(серый). Обычно для ЭИ используют теплые цвета. Это как раз связано с психологией восприятия. Стоит отметить, что мнение о цвете — очень субъективно и может меняться даже от настроения пользователя.
- Форма. В большинстве случаев — прямоугольник со скругленными углами. Или круг. Полностью прямоугольные ЭИ, лично мне нравятся меньше. Возможно из-за своей «остроты». Опять же, форма как и цвет достаточно субъективна.
- Основные ЭИ(часто используемые) должны быть выделены. Например размером или цветом.
- Иконки в программе должны быть очевидными. Если нет — подписывайте. Ведь, по сути дела, вместо того чтобы объяснять, пиктограммы зачастую сами требуют для себя объяснений.
- Старайтесь не делать слишком маленькие элементы — по ним очень трудно попасть.
Как правильно расположить ЭИ на экране?
- Есть утверждение, что визуальная привлекательность основана на пропорциях. Помните известное число 1.62? Это так называемый принцип Золотого сечения. Суть в том, что весь отрезок относится к большей его части так, как большая часть, относится к меньшей. Например, общая ширина сайта 900px, делим 900 на 1.62, получаем ~555px, это ширина блока с контентом. Теперь от 900 отнимаем 555 и получаем 345px. Это ширина меньшей части:
- Перед расположением, ЭИ следует упорядочить(сгруппировать) по значимости. Т.е. определить, какие наиболее важны, а какие — менее.
- Обычно(но не обязательно), элементы размещаются в следующей градации: слева направо, сверху вниз. Слева в верху самые значимые элементы, справа внизу — менее. Это связано с порядком чтения текста. В случае с сенсорными экранами, самые важные элементы, располагаются в области действия больших пальцев рук.
- Необходимо учитывать привычки пользователя. Например, если в Windows кнопка закрыть находится в правом верхнем углу, то программе аналогичную кнопку необходимо расположить там же. Т.е. интерфейс должен иметь как можно больше аналогий, с известными пользователю вещами.
- Размещайте ЭИ поближе там, где большую часть времени находится курсор пользователя. Что бы ему не пришлось перемещать курсор, например, от одного конца экрана к другому.
- Соблюдайте пропорции
- Элемент интерфейса можно считать видимым, если он либо в данный момент доступен для органов восприятия человека, либо он был настолько недавно воспринят, что еще не успел выйти из кратковременной памяти. Для нормальной работы интерфейса, должны быть видимы только необходимые вещи — те, что идентифицируют части работающих систем, и те, что отображают способ, которым пользователь может взаимодействовать с устройством.
- Делайте отступы между ЭИ равными или кратными друг-другу.
Как ЭИ должны себя вести?
- Пользователи привыкают. Например, при удалении файла, появляется окно с подтверждением: «Да» или «Нет». Со временем, пользователь перестает читать предупреждение и по привычке нажимает «Да». Поэтому диалоговое окно, которое было призвано обеспечить безопасность, абсолютно не выполняет своей роли. Следовательно, необходимо дать пользователю возможность отменять, сделанные им действия.
- Если вы даете пользователю информацию, которую он должен куда-то ввести или как-то обработать, то информация должна оставаться на экране до того момента, пока человек ее не обработает. Иначе он может просто забыть.
- Избегайте двусмысленности. Например, на фонарике есть одна кнопка. По нажатию фонарик включается, нажали еще раз — выключился. Если в фонарике перегорела лампочка, то при нажатии на кнопку не понятно, включаем мы его или нет. Поэтому, вместо одной кнопки выключателя, лучше использовать переключатель(например, checkbox с двумя позициями: «вкл.» и «выкл.»). За исключением случаев, когда состояние задачи, очевидно.
Такой переключатель напрямую отражает состояние ЭИ
- Делайте монотонные интерфейсы. Монотонный интерфейс — это интерфейс, в котором какое-то действие, можно сделать только одним способом. Такой подход обеспечит быструю привыкаемость к программе и автоматизацию действий.
- Не стоит делать адаптивные интерфейсы, которые изменяются со временем. Так как для выполнения какой-то задачи, лучше изучать только один интерфейс, а не несколько. Пример — стартовая страница браузера Chrome.
- Если задержки в процессе выполнения программы неизбежны или действие производимое пользователем очень значимо, важно, чтобы в интерфейсе была предусмотрена сообщающая о них обратная связь. Например, можно использовать индикатор хода выполнения задачи (status bar).
- ЭИ должны отвечать. Если пользователь произвел клик, то ЭИ должен как-то отозваться, чтобы человек понял, что клик произошел.
В заключении
Эта статья не претендует на самый полный справочник принципов проектирования интерфейса. Графический интерфейс пользователя — это обширная тема, тесно переплетенная с психологией, занимающая умы ученых и сотни страниц книг и исследований. В столь малом формате, никак не выразить всю полноту затронутой темы. Однако, соблюдение базовых принципов, позволит строить интерфейсы более дружелюбными к пользователю, а так же упростить сам процесс проектирования.
Спасибо за внимание.
Литература
Джеф Раскин, «Интерфейс: новые направления в проектировании компьютерных систем»
Алан Купер, «Об интерфейсе. Основы проектирования взаимодействия»
Алан Купер, «Психбольница в руках пациентов»
Пользовательский интерфейс – это интерфейсное приложение, с которым пользователь взаимодействует для использования программного обеспечения. Пользователь может манипулировать программным и аппаратным обеспечением и управлять им с помощью пользовательского интерфейса. Сегодня пользовательский интерфейс встречается практически во всех местах, где существуют цифровые технологии, включая компьютеры, мобильные телефоны, автомобили, музыкальные плееры, самолеты, корабли и т. Д.
Пользовательский интерфейс является частью программного обеспечения и спроектирован таким образом, чтобы обеспечить понимание пользователем программного обеспечения. Пользовательский интерфейс обеспечивает фундаментальную платформу для взаимодействия человека с компьютером.
Пользовательский интерфейс может быть графическим, текстовым и аудио-видео, в зависимости от базовой аппаратной и программной комбинации. Пользовательский интерфейс может быть аппаратным или программным или их комбинацией.
Программное обеспечение становится более популярным, если его пользовательский интерфейс:
- привлекательный
- Прост в использовании
- Отзывчивый в короткие сроки
- Ясно, чтобы понять
- Последовательный на всех интерфейсных экранах
Пользовательский интерфейс широко разделен на две категории:
- Интерфейс командной строки
- Графический пользовательский интерфейс
Интерфейс командной строки (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 в их книге (Проектирование интерфейса пользователя).
Стремитесь к последовательности – в подобных ситуациях должны быть последовательные последовательности действий. Одинаковая терминология должна использоваться в подсказках, меню и справочных экранах. Последовательные команды должны использоваться повсюду.
Позволяют частым пользователям использовать ярлыки . Желание пользователя сократить количество взаимодействий увеличивается с частотой использования. Сокращения, функциональные клавиши, скрытые команды и средства макросов очень полезны для опытного пользователя.
Предоставьте информативную обратную связь – для каждого действия оператора должна быть некоторая системная обратная связь. Для частых и незначительных действий ответ должен быть скромным, в то время как для нечастых и крупных действий ответ должен быть более существенным.
Диалоговое окно дизайна, чтобы обеспечить закрытие – Последовательности действий должны быть организованы в группы с началом, серединой и концом. Информативная обратная связь по завершении группы действий дает операторам удовлетворение выполнением, чувство облегчения, сигнал об отказе от планов на случай непредвиденных обстоятельств и вариантов их мыслей, и это указывает на то, что путь к будущему ясен для подготовки к следующему группа действий.
Предложите простую обработку ошибок – по возможности, спроектируйте систему так, чтобы пользователь не допустил серьезной ошибки. Если ошибка сделана, система должна быть в состоянии обнаружить ее и предложить простые, понятные механизмы для обработки ошибки.
Разрешить легкую отмену действий – эта функция снимает беспокойство, поскольку пользователь знает, что ошибки можно отменить. Легкое изменение действий стимулирует изучение незнакомых вариантов. Единицами обратимости могут быть одно действие, ввод данных или полная группа действий.
Поддержка внутреннего локуса контроля. Опытные операторы очень хотят ощущать, что они отвечают за систему и что система реагирует на их действия. Разработайте систему так, чтобы пользователи стали инициаторами действий, а не респондентами.
Уменьшите кратковременную нагрузку на память . Ограничение обработки человеческой информации в кратковременной памяти требует, чтобы дисплеи были простыми, консолидировались многостраничные дисплеи, уменьшалась частота движения окна и выделялось достаточное время обучения для кодов, мнемоники, и последовательности действий.
Как написать руководство пользователя программы или сайта — инструкции, советы, помощь, программное обеспечение
Журавлев Денис
Что такое руководство пользователя и для чего его создавать
Ежедневно создаются новые продукты, программы, сервисы и часто пользователям приходится несладко при освоении какой-нибудь сложной программы, поэтому каждому новому продукту желательно собственное руководство. Для чего?
Большинство людей не хочет разбираться с чем-то незнакомым без персонального, всегда доступного и понятного помощника. А именно им и является хорошее руководство пользователя.
Общие советы по созданию пользовательской документации
Перед тем как приступить к созданию руководства, нужно определиться с некоторыми важными моментами. Например, определить, для кого вы его пишете? Кто его будет читать — рядовые пользователи, для которых важны базовые функции продукта, или люди, которым нужны особые, нечасто используемые функции программы/сервиса.
После этого важно подумать о том:
- Где пользователь будет к нему обращаться: дома, на работе, в машине?
- Как часто он будет его просматривать?
- Насколько объективно сложен для понимания продукт?
Из этого можно сделать вывод, насколько интенсивно пользователь будет работать с документацией, а значит уже можно выбрать между сжатым «справочником» или объемным «путеводителем» Также важно, чтобы руководство писал профессионал, знающий продукт. Так что по возможности делегируйте написание техническому специалисту или аналитику, у которого есть полное представление о всех тонкостях продукта.
Определившись со всеми представленными пунктами, станет понятнее, какой нужно использовать стиль изложения, какого объема написать текст. Но помните, что излишне стилистически окрашенные слова мешают пользователю добраться до сути. Так что лучшим вариантом в большинстве случаев будет нейтрально-формальный стиль. Пишите так, чтобы пользователь вас понял. Постарайтесь по возможности избегать технических терминов, но проанализируйте — не сделает ли полное отсутствие терминов ваше руководство бесполезным?
Структура руководства пользователя
После того как вы ответили на предыдущие вопросы, создайте структуру руководства. У любого хорошего «путеводителя» хорошая и логичная структура. Начните с оглавления. Информативное содержание поможет читателю легко ориентироваться в документе.
В первом разделе желательно рассказать общую информацию о программе:
- Для чего создан продукт.
- Какие задачи он решает.
- Какие основные выгоды от использования для клиента.
В следующем разделе можно указать основные элементы пользовательского интерфейса. Пользователю будет трудно разобраться в софте, если он не поймёт для чего служат различные элементы интерфейса, или он не разберётся в основных режимах работы ПО. Опишите понятным языком предназначение экранов и окон.
Создайте раздел, где расскажете о наиболее эффективных способах применения продукта для решения типовых задач. Какие цели стоят перед клиентом, и как ваша программа/сервис помогает достичь их. Укажите информацию о том, как быстро и продуктивно пользоваться программой.
Ни одно руководство не обойдется без таких разделов как: «Частые вопросы» и «Устранение типовых проблем» В них разбираются вопросы и проблемы, с которыми часто сталкиваются пользователи. Для заполнения данного раздела вам скорее всего понадобятся уже готовые отзывы клиентов. Если у вас абсолютно новый продукт, вы можете предугадать проблемы ваших клиентов либо на первое время не включать данный пункт в ваше руководство.
Иногда технические писатели забывают о важном моменте в руководстве пользователя — контактная информация. Этот раздел поможет пользователям связаться с вами, даже если у них нет никаких вопросов и руководство полностью закрывает все их потребности. Клиент может дать совет, поделиться опытом или предложить выгодное вам сотрудничество.
Инструменты для быстрого создания руководства пользователя
Но как создать руководство пользователя, если пишешь его впервые? Или что делать, если руководство пользователя нужно постоянно обновлять и дорабатывать? Или нужны особые функции, которых нет в традиционных текстовых редакторах, например, в MS Word.
Одним из популярных инструментов для создания качественного руководства является программа Dr. Explain (https://www.drexplain.ru), в которой уже есть готовые шаблоны руководств пользователя с готовой структурой разделов и в которой удобно обновлять документацию, как бы часто эти обновления не происходили.
Видео-обзор основных возможностей программы Dr.Explain
Удобной особенностью инструмента является возможность экспортировать один и тот же документ в форматы: HTML, CHM, PDF. Простой и понятный интерфейс сам подскажет, как быстро просмотреть документ в различных форматах и настроить его под вывод в эти форматы.
Любой проект в Dr.Explain вы можете создать с нуля или импортировать уже существующую документацию, например из формата MS Word, HTML или CHM-файла, и буквально за несколько минут создать из нее онлайн-помощь, файл справки в формате CHM, или документ в формате PDF.
При создании руководства важно опираться на заранее составленный план. Дерево проекта в Dr.Explain поможет структурировать документ по вашему усмотрению. Вы можете добавлять, удалять перемещать разделы и переименовывать их. Для каждого раздела вы можете определить, в какой формат он будет экспортироваться. Также в работе удобно использовать статусы готовности разделов.
У программы свой собственный редактор, оптимизированный под работу со сложной документацией. Основные функции редактора вынесены в компактный тулбар. Это — управление стилем текста, форматирование абзацев, вставка ссылок, изображений, видео, таблиц и списков, а также вставка специальных объектов. Dr. Explain экономит время и силы своих пользователей. Разработчики документации часто сталкиваются с проблемой многократного использования одного и того же фрагмента текста и прибегают к очевидным решениям — «Ctrl+c», Ctrl+v». Dr.Explain предлагает решение по повторному использованию контента — текстовые переменные. Это решение экономит время, когда нужно много раз использовать один и тот же текст, особенно, который может периодически изменяться — например, версия документируемой системы.
Многие российские компании сталкиваются с тем, что руководство пользователя нужно писать согласно ГОСТ 19 и ГОСТ 34. Dr.Explain активирует поддержку требований ГОСТ фактически одним кликом. Программа автоматически сформирует структуру обязательных разделов и установит требуемые параметры страницы, стили абзацев, списков и заголовков.
Часто техническим писателям при документировании пользовательского интерфейса приходится снабжать изображения пояснительными выносками. Для таких случаев программа поддерживает специальные графические объекты — аннотированные экраны. Чаще всего аннотируются скриншоты программ и страниц веб-сайтов. Уникальной особенностью Dr.Explain является автоматическая аннотация изображений, получаемых при захвате экранов с окнами программ или сайтов. Программа анализирует структуру окон и добавляет пояснительные выноски ко всем значимым элементам.
Кроме того, Dr.Explain позволяет нескольким авторам одновременно работать над проектом с использованием сервиса www.tiwri.com, учетную запись на котором можно создать бесплатно за пару минут. При внесении правок одним автором сервис блокирует редактируемые разделы проекта для изменения другими авторами. По окончании редактирования изменения отправляются на сервер, и блокировка снимается. Так несколько человек могут одновременно работать над различными разделами проекта без риска помешать друг другу.
Попробовать режим многопользовательской работы в Dr.Explain можно даже с бесплатной лицензией. Вы можете создать общий проект и полноценно работать с ним в многопользовательском режиме до семи дней.
Почему компании выбирают Dr.Explain для создания руководств пользователя
Павел Свиридов, профессиональный военный, полковник, создатель астрологической системы «Вега Матрица»
«Только программа Dr.Explain обладала всеми необходимыми возможностями. А главное — она давала простор для творчества. Можно было выбрать цветовую гамму, вид и форму служебных элементов, настраиваемые шаблоны. Это позволило мне сохранить стилевое единство документации и самой программы. Ну, и конечно, полуавтоматическая обработка материала существенно облегчает и ускоряет работу по созданию хелпа.
Обучение работе в Dr.Explain было наглядным и сделано возможностями самой программы, что безусловно повлияло на мой выбор в ее пользу».
Прочитать полный кейс компании «Вега Матрица вы можете перейдя по ссылке
Наталья Обухова, бизнес-аналитик компании CRM Expert
«По классике жанра был пилотный проект на двух фаворитах (Dr.Explain и HelpNDoc) и муки выбора.
Через неделю справка была полностью готова. Конечно, если мы набивали ее «с нуля», за это время мы бы не успели. Мы просто конвертировали все бумажные инструкции во внутренний формат программ, изменили каталогизацию и организовали систему гиперссылок.
Сначала фаворитом выбора была другая система, но решающим фактором в пользу Dr.Explain стал возглас человека, выполняющего основную часть работы по переносу текста: «Вжух! И вся структура документа перенеслась в файл справки». Функция импорта в Dr.Explain отработала на ура и сэкономила кучу времени.
Также очень подкупил дизайн веб-справки, который формируется Dr.Explain, и красивый способ организации подписей к окнам нашей системы. В Dr.Explain это называется «Аннотирование экрана».
Возможность установки статуса раздела тоже оказалась очень удобной, особенно, после импорта старой версии справки легко отслеживать, какие разделы требуют обновления, в каких еще ведутся изменения, а какие уже обновлены и актуальны».
Прочитать полный кейс компании CRM Expert
Николай Вальковец, разработчик компании 2V
«Мы значительно сократили время работы техподдержки с новыми клиентами на этапе подключения. Раньше требовалось проводить онлайн презентации и видео конференции для новых клиентов, объясняя особенности программы. Сейчас же, один раз постаравшись максимально подробно всё описать, мы избавили себя и нашу техподдержку от этой работы. Нам импонирует простота программы и скорость работы. Можно быстро редактировать, добавить новые пункты в документацию, сохранить в формате HTML и выложить на сайт».
Прочитать кейс компании V2
Подытожим
Создание и написание хорошей пользовательской документации — это труд, который требует много времени и усилий. Но если успешно справиться с задачей, можно навсегда получить лояльных и довольных клиентов. Не забывайте о том, что недовольство от некачественного руководства может быть спроецировано пользователем на сам продукт и повлиять на дальнейшие решения о его выборе. Пользовательская документация должна стать персональным и незаменимым помощником. Используя Dr. Explain, вы сможете быстро создать качественное руководство пользователя, которое будет помогать пользователям разбираться в продукте, а вам позволит сосредоточить свои силы на более важных задачах — разработке и продвижении программного продукта.
Скачать Dr.Explain с неограниченной по срокам возможностью бесплатной работы можно по адресу: https://www.drexplain.ru/download/
Успешных вам разработок!
Смотрите также
- Dr.Explain — инструмент для создания мобильной версии пользовательской документации к программным продуктам
- Шаблоны файлов помощи, руководства пользователя программного обеспечения или сайта, шаблон базы знаний — бесплатные шаблоны и примеры пользовательской документации
В ноябре 2018 года студия «Лайв Тайпинг» рассказывала читателям vc.ru, из чего складывается стоимость мобильного приложения. Эта статья посвящена одному из слагаемых: пользовательскому интерфейсу.
За восемь лет существования «Лайв Тайпинг» выработала подход к дизайну интерфейсов и готова поделиться с вами его версией на текущий день. После прочтения вы сможете построить коммуникацию с дизайнерами любой студии разработки и будете знать, в каких примерно темпах протекает этот процесс и какой результат вы получите.
Пользовательский интерфейс, или UI (User Interface) — это внешний вид продукта, способ общения между пользователем и программой. А ещё интерфейс влияет на то, будет ли продукт приносить деньги и пользоваться уважением и любовью аудитории.
Доказывать важность дизайна как магнита для пользователей удобно на примере соцсетей с миллионами пользователей. Резонансным случаем в рунете стал редизайн «Кинопоиска». 96% негативных отзывов на него говорят сами за себя: владельцы сайта, компания «Яндекс», сделала это без оглядки на мнение пользователей.
Новый дизайн фокусировал внимание пользователей на возможности смотреть фильмы платно через партнёров «Яндекса», и это решало только задачи площадки и партнёров. Но пользователи больше всего ценили сайт за рейтинги, оценки, списки фильмов, топ-250, блоги и всё, что создаётся аудиторией.
В итоге новый сайт просуществовал четыре дня и под напором гнева «Яндекс» вернул старый дизайн. Новый же, по мнению сопричастных, нравился только менеджерам.
Редизайн «Живого журнала» в 2014 году тоже не впечатлял. Его хорошенько почистили от лишних элементов, но в целом он не вызвал восторгов: типографика, модульная сетка, адаптив — всё выглядело сырым и неудобным.
Вы хотите повторить судьбу «Живого журнала» и «Кинопоиска»? Не думаем, поэтому мы и написали эту статью. Вам как клиенту будет полезно знать, как именно создаётся дизайн сайтов и приложений, из каких этапов состоит работа и что вы должны получить. Чувство контроля над этими этапами приблизит ваш проект к успеху.
Итак, разберём особенности разработки пользовательского интерфейса пошагово.
Проектирование
На этом этапе вас ждёт много теории, гипотез и умозрительных заключений, которые предстоит подтвердить или опровергнуть. Эти заключения касаются функциональности продукта и проистекают из вопросов: «Зачем нужен этот продукт?», «Кому он нужен?», «Как с ним будут работать и решать задачи пользователи?» и «Как он будет зарабатывать для своих владельцев?».
Вложить время и деньги в проектирование — это вложить время и деньги в понимание того, что получится на выходе.
Ответить на большую часть этих вопросов поможет составление портрета целевой аудитории (ЦА) — тех самых людей, для которых делается продукт.
Главная задача дизайнеров при изучении аудитории — включить эмпатию на максимум и понять, как эта аудитория думает, дышит, видит, слышит и действует. Этому способствуют следующие методы:
- Коридорный метод. Обратная связь поступает от родных, друзей и коллег дизайнеров. Собрать её легко, но этого недостаточно.
- Разговор с вами. Справедливо предполагается, что вы как никто знаете, что нужно вашей аудитории.
- Полевые исследования. В рамках метода дизайнеры идут в народ: общаются с людьми напрямую, если делают продукт для местного рынка, или читают форумы, если для зарубежного;
- Проблемное интервью. Задавая пользователям вопросы про их жизнь и место проблемы в ней, дизайнеры узнают, как эта проблема решается сейчас и насколько полезным окажется их продукт. То, что он может оказаться бесполезным — тоже ценный результат: не придётся тратить деньги на приложение, которым никто не будет пользоваться.
Собранную информацию дизайнеры перерабатывают и получают, во-первых, ключевые персоны, а во-вторых, пользовательские маршруты.
Ключевые персоны — это характерные представители ЦА. Они могут быть разными по профессии, уровню жизни, мотивации пользоваться приложением и прочим параметрам, но опыт, ожидания и страхи каждой персоны ложатся в основу внешнего вида продукта и его функциональности. Например, типичному пользователю приложения «Киноголик» для покупки абонементов в кино 23 года, он работает в ИТ-компании и любит смотреть фильмы на английском.
Такая персона становится центром user story, или пользовательской истории. Это краткий, в несколько строк, рассказ про персону и то, как она работает с функциональностью приложения и какой цели достигает. User story строится по шаблону:
«Как <роль пользователя>, я <что-то хочу получить> <с такой-то целью>»
Поместив нашего 23-летнего фаната оригинальных версий в этот шаблон, получим:
«Как <23-летний любитель версий с оригинальной озвучкой>, я <ищу через функцию ”Поиск” фильмы с субтитрами> <чтобы сходить фильм на английском>»
Компания Intercom славится не только комплексным решением по внедрению чатов в сайты и мобильные приложения, но и изобретением подхода Jobs To Be Done. В основе подхода лежит не личное качество ключевой персоны, а обстоятельства и мотивация, которые толкают персону пользоваться продуктом. «Размышления» персоны называются Job story, а шаблон выглядит так:
«Когда <я оказался в такой ситуации>, я хочу <что-то сделать по некоторым причинам> <с такой-то целью>»
Ситуация с кинолюбом в рамках такого подхода выглядит иначе:
«Когда <меня раздражают посетители кинотеатров, жующие попкорн и мешающие смотреть фильм своими разговорами>, я <ищу в расписании оригинальную версию фильма>, <чтобы посидеть в полупустом зале, где никто не бубнит>
Подробнее про подход Jobs To Be Done написала в своём блоге платформа Tilda.
От User story и Job story мы переходим к User scenario. Это маршрут взаимодействия пользователя с продуктом и достижения цели.
В погоне за основной целью (покупка, добавление фотографии) пользователь может решать вспомогательные задачи (выбирает способ доставки заказа, редактирует фото) и достигать вторичных целей (удобное получение заказа, фото с контрастирующими деталями); эти дополнительные маршруты дизайнеру тоже необходимо учесть.
Прототипирование
Прототип — это набросок продукта, в котором заключены его внешний вид, логика работы и основная функциональность.
Работа над ним начинается с создания макета. Одним из вариантов макета является вайрфрейм (от английского wireframe — «каркасный»). Внешне он выглядит как куча прямоугольных блоков, опоясанных линиями и стрелочками. В этих блоках и стрелочках заложена структура продукта и порядок взаимодействия пользователя с ним.
Будет ли вайрфрейм грубым наброском, который вы сделали с коллегами ручкой на бумаге для принтера, или созданной в графическом редакторе организованной картой экранов — решать вам. Единственное: готовьтесь объяснить клиенту, что визуально вайрфрейм не имеет отношения к финальному продукту.
Пользуясь терминами электротехнического черчения, все кнопки, тексты, медиафайлы и прочие элементы заменены в вайрфрейме на условно-графические обозначения. Это ещё не интерфейс, но уже что-то близкое — как ёлка, которая станет новогодним деревом, когда её нарядят.
Детализированный прототип — следующий шаг вайрфрейма по лестнице эволюции пользовательского интерфейса. Как и вайрфрейм, это макет, но чуть более конкретный: если в вайрфрейме экран с чатом состоит из окружностей и прямоугольников, только намекающих на свои назначения, то в детализированном прототипе окружность — это ТОЧНО фото пользователя, а прямоугольник — ТОЧНО текст сообщения c прикреплёнными файлами, аудиозаписями и стикерами.
Для презентации прототипа мало показать экраны. Нужно показать, к чему и куда приводит взаимодействие будущего пользователя с элементами интерфейса. Связав элементы линиями с другими экранами, на которые попадёт пользователь, вы получите пользовательские сценарии использования приложения, или user flow.
User flow — карта навигации, по которой видно поведение пользователя мобильного приложения, как он достигает цели и как легко ему это удаётся. Внешне User flow выглядит как логически связанные друг с другом прямоугольники, акцент в которых сделан на действиях пользователя.
В будущем эта карта пригодится тестировщикам для сопоставления с рабочим приложением, чтобы проверить, не потерялось ли какое-то действие, не нарушена ли логика. На этом этапе оптимизируется путь пользователя: исключаются лишние шаги, убираются ненужные функции, а похожие объединяются в один шаг.
В качестве софта для этой задачи мы используем Overflow, чей слоган «User flows done right» даёт понять, что время за этой работой пройдёт продуктивно и с пользой. В Overflow легко импортируются экраны из Sketch или Figma, а сделать flow для 100 экранов можно за час — гораздо быстрее, чем рисовать стрелочки самому.
Нужен дополнительный уровень понимания, как продукт будет работать? С помощью таких сервисов, как Marvel, InVision, POP App и Origami Studio детализированный прототип можно превратить в интерактивный. Его польза в том, что он даёт прокликать (а в случае, если у нас мобильное приложение — прокликать прямо в телефоне) все элементы интерфейса и оценить логику работы продукта до того, как он попадёт в руки конечного пользователя.
Его создание — этап необязательный, так как с презентацией будущей работы справляются макеты и user flow. Но когда нужно показать возможности мобильного приложения и раскрыть перед клиентом предстоящий объём работ в деталях, используйте его.
После утверждения логики и функциональности продукта этап прототипирования можно считать завершённым.
Резюмируем: вы получаете детальный прототип, его кликабельную версию (опционально) и карту экранов. Они соответствуют выработанным и согласованным в рамках этого этапа гипотезам продукта.
Чаще всего также формируется пул пользовательских кейсов, описываются целевые сегменты и моделируется поведение пользователей в системе. Помимо этого, этап сопровождается техническим проектированием, синхронизированный с процессами выше.
Всё оформляется в документы-артефакты: техническое задание, функциональное задание, описание архитектуры и так далее. С помощью этого мы убеждаемся, что то, что мы спроектировали, не только имеет под собой аргументацию со стороны рынка и пользователей, но и технически поддаётся воплощению, и мы имеем представление о том, как именно это сделать и какие могут быть риски.
Разработчики получают от дизайнеров прототип и user flow, чтобы максимально точно оценить этап разработки и ориентироваться в логике продукта. Затем на будущий продукт начинают накатывать стиль.
Стилизация
У прототипа есть логика, но нет своего лица, которое продукт явит пользователям, и голоса, которым он будет с ними говорить. Под лицом и голосом имеется в виду фирменный стиль, который складывается из цветовой палитры, шрифта, иконок и иллюстраций.
В этом месте начинается мини-этап дизайн-концепции, о котором мы говорили выше. Суть его в том, чтобы взять несколько голых экранов прототипа и примерить на них фирменный стиль. Если клиенту понравится то, что он увидит, то команда дизайнеров работает с остальной частью прототипа в том же направлении.
Уважающий дисциплину дизайнер уже давно оценил прелести работы в Sketch — ведь здесь так удобно вести макеты для iOS и Android в отдельных файлах, превращать в легко читаемые символы повторяющиеся элементы интерфейса, заранее присваивать таким элементам стили и отступы от краёв экрана и делать много чего ещё. Всё это складывается в дизайн-систему.
Как и в случае прототипа, готовый дизайн согласовывается с клиентом. Когда всех всё устраивает, дизайн готовится для передачи разработчикам. Сколько времени и сил можно сэкономить, сделав это грамотно посредством Zeplin (спойлер: очень много), можно узнать из нашей статьи.
Вывод
Пользоваться продуктом в первую очередь будут простые люди, а не его создатели. Будучи людьми простыми, во время работы с продуктом они прогонят его через фильтр из трёх вопросов: «Что делать?», «Куда идти?» и «Куда нажимать?». Если вы серьёзно отнесётесь к этапам работы над интерфейсом, ваши пользователи получат ясный ответ на эти вопросы и останутся довольны продуктом.
«Что делать?»
Это вопрос о том, насколько пользователю понятна основная функция продукта. Обозначить её нужно на этапе проектирования — тогда же, когда определяется целевая аудитория.
«Куда идти?»
Путь к цели лежит через взаимодействие пользователя с интерфейсом. Кнопка за кнопкой, поле ввода за полем ввода, экран за экраном — и так до заветной покупки или публикации поста. Грамотно составленный user scenario, отрепетированный на прототипе, уберёт с этого пути все ухабы.
«Куда нажимать?»
Кнопка с целевым действием отличается от остальных элементов на экране. Чем подчеркнуть отличие — цветом, размером или формой — решать дизайнеру на этапе дизайна.
Не менее важно выбрать подходящее слово, которым нужно подписать кнопку. Будет ли это слово глаголом, существительным, прилагательным или другой частью речи, зависит от функции кнопки. Об этом писал в своём блоге Илья Бирман, а на сайте «Бюро Горбунова» он даёт общий совет.
Желаю вам делать хорошие пользовательские интерфейсы и не делать плохие. Если у вас возникли вопросы к нашему процессу или вы хотите поделиться своим подходом к разработке интерфейса — добро пожаловать в комментарии.
#статьи
- 4 июн 2021
-
12
Самое важное о UX-дизайне от мировых экспертов по юзабилити.
Пишет про тексты в интерфейсе, проектирование и дизайн. Развивает направление UX-редактуры в Skyeng. Ведет телеграм-канал про редактуру «Письма от Яны Дворецкой»
UX-дизайн — это сложно, если не знаешь, с чего начать. Мы собрали золотые правила зарубежных специалистов Якоба Нильсена, Бена Шнейдермана и Брюса Тогнаццини и наших — Влада Головача и Ильи Бирмана. Они помогут начинающим дизайнерам, проектировщикам, UX-писателям и продакт-менеджерам создавать качественные, понятные и приятные продукты.
Принцип 1
Дизайн может показаться вам блестящим, но это не имеет никакого смысла, если вы не относитесь к целевой аудитории продукта.
Само понятие UX-дизайна, или дизайна пользовательского опыта, намекает, что работа дизайнера сосредоточена вокруг взаимодействия пользователей с продуктом. Значит, нужно разобраться, удобен ли целевой аудитории этот продукт.
Принцип 2
Хорошо, когда пользователи точно знают, к чему привели их действия и чего ожидать. Например, им не приходится буравить экран взглядом в мучительном ожидании: «Ну что там?» Они могут быть уверены, что данные не пропадут. Якоб Нильсен утверждает, что чем более предсказуема работа с сервисом, тем больше доверия к нему и тем приятнее пользовательский опыт.
Илья Бирман в своей книге «Пользовательский интерфейс» приводит пример о важности обратной связи:
В челябинском почтовом отделении №80 работает электронная очередь. У входа стоит машинка с единственной кнопкой. Нажимаешь кнопку, и через две секунды на чековой ленте печатается номерок. Эти две секунды — целая вечность. Многие решают, что кнопка не сработала, и жмут ещё раз. Рядом с машинкой всегда валяются «лишние» номерки. Если бы машинка делала хоть что‑то сразу в ответ на нажатие — издавала звук или мигала лампочкой, — такой проблемы бы не было.
А Брюс Тогнаццини добавляет: «Хорошо, если пользователям не нужно искать или догадываться о состоянии системы. Они должны взглянуть на интерфейс и сразу понять, что там сейчас происходит».
Не забывайте про обратную связь. Это важно.
Принцип 3
Не придумывайте новое, если можно использовать старый добрый паттерн. Казалось бы, где тут креатив? Вы правы, здесь его нет. Зато есть забота о пользователях.
Чем более знакомым будет для них интерфейс продукта, тем быстрее они начнут пользоваться сервисом. Им не придётся долго учиться для этого, ведь не все готовы тратить много времени. И Бен Шнейдерман, и Якоб Нильсен уверены, что лёгкость на старте и консистентность интерфейса улучшают пользовательский опыт.
А Брюс Тогнаццини добавляет: «Мода [и красота] не должна победить юзабилити».
Принцип 4
В книге «Дизайн пользовательского интерфейса» Влад Головач говорит про сообщения об ошибках:
Большинство сообщений об ошибках в действительности не являются собственно сообщениями об ошибках. На самом деле они показывают пользователю, что система, которой он пользуется:
- недостаточно гибка, чтобы приспособиться к его действиям;
- недостаточно умна, чтобы показать ему возможные границы его действия;
- самоуверенна и считает, что пользователь дурак, которым можно и нужно помыкать.
Все главные специалисты по юзабилити сходятся на том, что лучше не просто показывать хорошие уведомления об ошибках, а предотвращать их.
Существует два типа ошибок: промахи и ошибки.
- Промахи — ошибки по невнимательности.
- Ошибки — сознательное действие, которое произошло потому, что пользователь не понял сервис, дизайн оказался недостаточно очевидным.
Избегайте промахов — задавайте ограничения для действий и корректные значения по умолчанию. А ещё найдите места в интерфейсе, где пользователь по невнимательности может сделать что-то не так. Например, чтобы он попал пальцем на нужную ему кнопку «Сохранить», уберите от неё подальше кнопку «Удалить» или «Выйти без сохранения».
Предотвращайте ошибки — не заставляйте пользователей запоминать действия, давайте необходимую на каждом этапе информацию и возможность быстро отменять действия.
Если ошибку нельзя предотвратить, то напишите понятное сообщение о ней. Якоб Нильсен, известный специалист по юзабилити, рекомендует:
- Расскажите, что пошло не так, на языке своей аудитории. Избегайте технического жаргона.
- Предложите решение, которое может немедленно устранить ошибку или как-то помочь.
Принцип 5
Так много хочется рассказать о продукте, поэтому тянет всё разом выложить на сайт, — а дальше пусть пользователи разбираются в информации и принимают решение.
Якоб Нильсен считает, что польза не в том, чтобы показать как можно больше, а в том, чтобы показать то, что нужно, в правильный момент. Так мы снижаем когнитивную нагрузку: выдаём информацию порционно и раскладываем по порядку. Люди любят порядок.
Помните, что каждая дополнительная информация в интерфейсе конкурирует с другой информацией. А значит, уменьшает её видимость, увеличивает шум, ухудшает восприятие страницы в целом.
Это не значит, что нужно срочно сокращать количество информации на лендингах и в экранах мобильных приложений. Просто определите основные потребности (боли) пользователя, сосредоточьтесь на них. Всё остальное — пусть лишь поддерживает, доказывает главные тезисы и открывается пользователю последовательно.
Именно благодаря этому принципу «Google Справка» до сих пор не превратилась в скучный справочник, в который никто не заглядывает.
Принцип 6
15% населения земного шара — миллиард человек — живёт с инвалидностью. При этом семь из десяти пользователей с ограниченными возможностями сразу уходят с сайта, если он оказывается им недоступен. А это большая аудитория.
Бен Шнейдерман и Якоб Нильсен призывают: подумайте о потребностях и физических ограничениях целевой аудитории и разработайте дизайн, который всё это учитывает. Не забудьте про различия между новичками и экспертами — добавляйте поясняющие тултипы для первых и сложные функции, быстрые клавиши для вторых. Учитывайте возраст, инвалидность, культурные различия пользователей и типы гаджетов.
Используйте контрастные цвета для текста в макете. Это помогает слабовидящим пользователям (а также в условиях низкой освещённости) легче читать содержимое на экране. Вот как Slack.
Как узнать, что удобно пользователям? Тестируйте!
На UX-тестах пользователи взаимодействуют с продуктом, а исследователь наблюдает, возникают ли у них проблемы, где и какие. Если многие люди сталкиваются с похожими проблемами, важно внести изменения в дизайн.
Принцип 7
Информация, необходимая для работы в сервисе (например, метки полей или пункты меню), должна быть видимой или легко находимой. А для этого:
- предлагайте помощь прямо здесь, в контексте, вместо того чтобы тренировать память пользователей;
- сократите количество информации, которую нужно запомнить. Большинству людей легче узнавать предложенный вариант, чем самим вспоминать верный ответ. Вам скорее правильно ответят на вопрос: «Пномпень — это столица Камбоджи?», чем на: «Какая столица у Камбоджи?».
Как удачно обобщил всё это Якоб Нильсен: «Узнавание лучше, чем вспоминание».
Принцип 8
Пользователи часто совершают действия по ошибке. Специалисты по UX разобрались, что им нужно в этом момент: юзеры хотят, чтобы у них был «аварийный выход».
Когда людям легко отказаться от процесса или отменить действие, они чувствуют себя свободно и уверенно. Кнопка отмены позволяет сохранять контроль над системой и избегать страха и разочарования.
Влад Головач в книге «Дизайн пользовательского интерфейса» пишет:
Почти всё время пользователь может что-либо испортить и знает это. Он может отформатировать жёсткий диск, может стереть или испортить нужный файл. Неудивительно, что пользователь часто боится. <…> Пользователей нужно всемерно снабжать ощущением, что ничего не может произойти, пока этого не захочется самому пользователю.
Для этого он рекомендует:
- не делать кнопки, опасные для пользователя, кнопками по умолчанию;
- дать пользователям возможность отменять свои действия.
Пользователь, знающий, что он не может совершить ошибку, испытывает радость и умиротворение.
* * *
Эти принципы — главное, но не всё. Чтобы проектировать удобные интерфейсы, нужно знать гораздо больше. Советуем прочитать по теме:
* Решением суда запрещена «деятельность компании Meta Platforms Inc. по реализации продуктов — социальных сетей Facebook* и Instagram* на территории Российской Федерации по основаниям осуществления экстремистской деятельности».
Научитесь: Профессия UX/UI-дизайнер
Узнать больше