Проектирование интерфейсов что это

Очерки о юзабилити: Часть 6. Проектирование взаимодействия

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

В этой статье мы перейдем к более конкретным темам и обсудим, во-первых, понятие «Проектирование взаимодействия», во-вторых, такие инструменты как пользовательские сценарии (user scenarios) и карты сценариев (scenario maps). Мы не будем спускаться еще на уровень ниже и говорить о таких вещах, как ментальные модели, метафоры и аффорданс, главным образом потому, что эти знания в меньшей степени касаются аналитиков. Но, тем не менее, для тех, кому хочется знать немного больше, могу посоветовать почитать Джефа Раскина и Инди Янг .

Проектирование взаимодействия

Итак, начнем с определения. Которое, вообще говоря, звучит достаточно туманно:

«Проектирование взаимодействия (Interaction Design, IxD) — область знаний, направленная на проектирование поведения продуктов и систем, с которыми пользователем осуществляется взаимодействие». Wikipedia

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

а) о смежных областях:

б) о результатах деятельности проектировщиков взаимодействия.

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

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

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

• варианты использования;
• персоны и пользовательские сценарии;
• диаграммы деятельности;
• макеты, а особенно – прототипы систем.

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

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

Одним из мощнейших инструментов проектирования взаимодействия являются пользовательские сценарии. Я начала использовать этот инструмент относительно недавно, ранее отдавая предпочтение описанию в виде Use Case-ов (Варианты использования или Прецеденты использования). Однако на текущий момент сценарии зарекомендовали себя исключительно положительно. Во-первых, в процессе разработки сценариев остается гораздо больше пространства для воображения и условий для придумывания уникальных решений и мощных фич (что только плюс, если вы не просто документируете будущую систему, а и пытаетесь учесть / улучшить опыт взаимодействия). Сам процесс построен так, что стимулирует творческую деятельность. Во-вторых, это не обезличенные сценарии, а взаимодействия, привязанные к реальным персонам. Персоны, напомню, иллюстрируют собой живых людей, с их мотивами, целями, задачами, опытом, эмоциями (см. Очерки о юзабилити. Часть 1: Введение). А значит, процесс взаимодействия в результате получится естественным, а не искусственным и чуждым пользователю алгоритмом. Ну и в-третьих, как показала практика использования сценариев, этот инструмент вносит тот самый fun в процесс.

Тем, кто не проникся таким инструментом, как персоны, настоятельно советую посмотреть презентацию Санжара Кеттебекова «Новое лицо персоны. Аналитика поведения для дизайна», в которой рассказывается, как именно при помощи персон команда Санжара добилась повышения прибыли сайта Los Angeles Times (http://latimes.com/) вдвое.

Вот как выглядит профиль персоны (пример на английском с реального проекта; имена, пароли и явки изменены):

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

Для описания сценариев я использую следующий шаблон (его можно скачать по ссылке «шаблон описания сценариев»):

В этом разделе нужно определить, с одной стороны, чего пытается достичь пользователь, а с другой – как задачи пользователей вписываются в цели организации. Если вы провели всю предварительную работу (например, создали Vision & Scope документ и персоны), эти цели у вас уже где-то задокументированы. Остается только включить их сюда. Это позволяет заодно проконтролировать, что никакие цели не остались «за бортом» и вы учли интересы всех сторон (фактически – еще один вариант трассировки требований).

Это самый главный раздел сценария. Здесь обычно по шагам расписывается, каким образом пользователь будет достигать своих целей. Если вы хотя бы раз описывали Use Case-ы, с описанием сценария у вас едва ли возникнут трудности. Если нет, то вам понадобится всего лишь чуть больше практики. Главное отличие в том, что в сценариях допустимы «лирические отступления»: любые детали о контексте использования системы, о мыслях и эмоциях пользователя, приветствуются.

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

Какие похожие вещи делал пользователь в прошлом? Как раньше организация обходилась без этого решения?

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

Какие физические, временные или финансовые ограничения проявят себя во время работы пользователя?

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

Где находится пользователь? Что у него на столе? Как у пользователя обстоят дела с доступом к необходимой информации (например, пользовательским мануалам)? Что написано на стикерах, прикрепленных к его монитору?

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

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

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

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

1) Какие вопросы, в том числе – технические, вызывает шаг?

2) Комментарии к шагу (например, пожелания заказчика)

3) Идеи: самое интересное и приятное, именно на этом этапе зачастую обнаруживаются хитрые решения и уникальные «фичи».

Обсуждение может выглядеть вот так:

Артефакт, который получается в результате, называется Scenario Map. Пример (не мой):

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

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

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

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

Дальнейшее чтение и полезные ссылки:

1. Сообщество проектировщиков взаимодействия: Interaction Design Association

2. Онлайн-библиография статей на тему проектирования взаимодействия http://www.interaction-design.org/references/authors/

3. Джеф Раскин «Об интерфейсе»

Предыдущие статьи по теме:

Проектирование интерфейсов

Интерфейс — это вся видимая пользователю часть сервиса, с которой он взаимодействует, решая свои задачи.

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

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

1. Глубинное исследование всего, что окружает продукт
2. Решение, которое учитывает интересы бизнеса и клиента
3. Финальный дизайн и поддержка внедрения на этапе разработки

Создать сервис с нуля
Создать принципиально новый интерфейс существующего сервиса
Добавить в сервис новые функции и возможности для пользователя
Исправить локальные проблемы и интерфейсные ошибки

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

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

Моделируем

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

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

Синтезируем

Строим Customer Journey Map: схематично визуализируем логику взаимодействия пользователей с сервисом при решении разных задач.

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

Детализируем

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

Итеративно детализируем пользовательские сценарии и презентуем заказчику. Собираем обратную связь и вносим корректировки.

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

Проектирование интерфейса: 8 принципов, которые должен знать каждый UX-дизайнер

Самое важное о UX-дизайне от мировых экспертов по юзабилити.

Яна Дворецкая

Пишет про тексты в интерфейсе, проектирование и дизайн. Развивает направление UX-редактуры в Skyeng. Ведет телеграм-канал про редактуру «Письма от Яны Дворецкой»

UX-дизайн — это сложно, если не знаешь, с чего начать. Мы собрали золотые правила зарубежных специалистов Якоба Нильсена, Бена Шнейдермана и Брюса Тогнаццини и наших — Влада Головача и Ильи Бирмана. Они помогут начинающим дизайнерам, проектировщикам, UX-писателям и продакт-менеджерам создавать качественные, понятные и приятные продукты.

Принцип 1

Опирайтесь на нужды реальных пользователей, а не на свои домыслы

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

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

Объясняйте, что происходит

Хорошо, когда пользователи точно знают, к чему привели их действия и чего ожидать. Например, им не приходится буравить экран взглядом в мучительном ожидании: «Ну что там?» Они могут быть уверены, что данные не пропадут. Якоб Нильсен утверждает, что чем более предсказуема работа с сервисом, тем больше доверия к нему и тем приятнее пользовательский опыт.

Илья Бирман в своей книге «Пользовательский интерфейс» приводит пример о важности обратной связи:

В челя­бин­ском поч­то­вом отде­ле­нии №80 рабо­тает элек­трон­ная оче­редь. У входа стоит машинка с един­ствен­ной кноп­кой. Нажи­ма­ешь кнопку, и через две секунды на чеко­вой ленте печа­та­ется номерок. Эти две секунды — целая веч­ность. Мно­гие решают, что кнопка не сра­бо­тала, и жмут ещё раз. Рядом с машин­кой все­гда валя­ются «лиш­ние» номерки. Если бы машинка делала хоть что‑то сразу в ответ на нажа­тие — изда­вала звук или мигала лам­поч­кой, — такой про­блемы бы не было.

А Брюс Тогнаццини добавляет: «Хорошо, если пользователям не нужно искать или догадываться о состоянии системы. Они должны взглянуть на интерфейс и сразу понять, что там сейчас происходит».

Не забывайте про обратную связь. Это важно.

Делайте интерфейс продукта похожим на аналоги

Не придумывайте новое, если можно использовать старый добрый паттерн. Казалось бы, где тут креатив? Вы правы, здесь его нет. Зато есть забота о пользователях.

Чем более знакомым будет для них интерфейс продукта, тем быстрее они начнут пользоваться сервисом. Им не придётся долго учиться для этого, ведь не все готовы тратить много времени. И Бен Шнейдерман, и Якоб Нильсен уверены, что лёгкость на старте и консистентность интерфейса улучшают пользовательский опыт.

А Брюс Тогнаццини добавляет: «Мода [и красота] не должна победить юзабилити».

Предотвращайте ошибки

В книге «Дизайн пользовательского интерфейса» Влад Головач говорит про сообщения об ошибках:

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

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

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

Существует два типа ошибок: промахи и ошибки.

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

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

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

Если ошибку нельзя предотвратить, то напишите понятное сообщение о ней. Якоб Нильсен, известный специалист по юзабилити, рекомендует:

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

Снижайте информационную нагрузку

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

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

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

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

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

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

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

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

Используйте контрастные цвета для текста в макете. Это помогает слабовидящим пользователям (а также в условиях низкой освещённости) легче читать содержимое на экране. Вот как Slack.

Как узнать, что удобно пользователям? Тестируйте!

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

Не заставляйте запоминать много информации

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

• предлагайте помощь прямо здесь, в контексте, вместо того чтобы тренировать память пользователей;

• сократите количество информации, которую нужно запомнить. Большинству людей легче узнавать предложенный вариант, чем самим вспоминать верный ответ. Вам скорее правильно ответят на вопрос: «Пномпень — это столица Камбоджи?», чем на: «Какая столица у Камбоджи?».

Как удачно обобщил всё это Якоб Нильсен: «Узнавание лучше, чем вспоминание».

Дайте ощущение контроля над ситуацией

Пользователи часто совершают действия по ошибке. Специалисты по UX разобрались, что им нужно в этом момент: юзеры хотят, чтобы у них был «аварийный выход».

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

Влад Головач в книге «Дизайн пользовательского интерфейса» пишет:

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

Для этого он рекомендует:

• не делать кнопки, опасные для пользователя, кнопками по умолчанию;
• дать пользователям возможность отменять свои действия.

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

Эти принципы — главное, но не всё. Чтобы проектировать удобные интерфейсы, нужно знать гораздо больше. Советуем прочитать по теме:

• О самых распространенных ошибках в UX
• О том, что делает интерфейс человечным и дружелюбным
• Об UX-писательстве
• О профессии UX-дизайнера и полезных инструментах и ресурсах

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

10 правил проектирования интерфейсов, которые нельзя нарушать

Лучшие практики UI-дизайна. В жизни есть определенные правила, которые нельзя нарушать. В дизайне пользовательского интерфейса тоже есть правила, по которым нужно жить. Их называют «эвристикой» или общими принципами, улучшающими юзабилити интерфейсов. Это повторяемые паттерны, проверенные временем и помогающие пользователям ориентироваться в интерфейсе. Хорошо спроектированный интерфейс всегда учитывает изложенные ниже принципы. В не очень хорошо спроектированном интерфейсе наверняка не хватает одного или нескольких принципов. Вы UI дизайнер, так зачем вам нарушать хотя бы одно из этих правил и создавать проблемы для пользователей ​​? Этот список был взят из статьи Norman Neilsen «10 эвристик для проектирования интерфейса».

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

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

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

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

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

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

3. Последовательность и стандарты

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

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

4. Контроль и свобода пользователей

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

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

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

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

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

6. Пользователи должны узнавать, а не вспоминать

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

Одна из целей UI дизайнера – снизить когнитивную нагрузку на пользователей. Психическая память – это огромный ограниченный ресурс. Память работает двумя способами: узнавание и воспоминание. Узнавание – это то, что вам сразу знакомо. Как лицо человека. Вы смотрите на лицо друга и сразу понимаете, что видели его раньше. Механизм воспоминания работает иначе. Это то, что вам нужно извлечь из памяти, например, имя человека. Воспоминание обычно требует больше времени и усилий, потому что разуму нужно обрабатывать больше информации, чтобы расшифровать то, на что он смотрит. С другой стороны, узнавание происходит мгновенно. Мы хотим больше узнаваемости в интерфейсе и меньше воспоминания. Хороший пример этого принципа – использование для функций универсально узнаваемых кнопок и иконок, например, дом для «ДОМОЙ» или карандаша для «РЕДАКТИРОВАТЬ». А если вам нужно спроектировать для интерфейса новые иконки, которые большинство людей никогда раньше не видели, используйте текстовый дескриптор, чтобы объяснить их и уменьшить когнитивную нагрузку.

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

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

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

8. Минималистский дизайн и эстетика

Диалоговые окна не должны содержать неактуальную или редко используемую информацию. Каждая дополнительная единица информации в диалоговом окне конкурирует с релевантными единицами информации и снижает их относительную заметность.

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

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

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

Ошибки будут. Это неизбежно. Обязанность UI дизайнера, определить, что произойдет после того, как пользователь обнаружит ошибку. Таким образом, мы можем помочь пользователям, проектируя понятные страницы ошибок и предупреждения, предоставляющие варианты решения проблемы. Например, давайте рассмотрим широко распространенную страницу 404. Мы, как дизайнеры, знаем, что означает страница с ошибкой 404, но обычно пользователи этого не знают. Чтобы помочь им, мы должны перевести код 404 на простой язык, добавив текст, поясняющий, что только что произошло. Например: «Извините, но мы не смогли найти страницу, которую вы искали. Вот несколько страниц с похожим контентом…».

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

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

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