Как визуализировать состояния системы

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

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

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

Видимость состояния системы – это один из 10 эвристических принципов, составляющих основу UX-дизайна.

О чем следует сообщать?

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

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

Несколько примеров полезной обратной связи:

• Новая папка успешно создана
• Сохранение завершено или последнее сохранение было 2 минуты назад
• 35 элементов удалено из избранного
• Подтвердите удаление 5 файлов, после чего 5 файлов будут удалены без возможности восстановления
• Страница или виджет загружается
• Загрузка данных
• Загрузка 6 файлов не удалась из-за превышения максимального размера (500 МБ)
• Выбрано 12 из 100 элементов
• Проверка 5374 единиц данных – осталось 2 часа
• Часть действий отключена из-за настроек прав доступа

Несколько примеров агрессивной или неудачной коммуникации:

• Появление сообщения об ошибке, как только вы начинаете вводить текст в поле «Новый пароль»
• Неясные пустые состояния – это все еще загрузка, или здесь вообще ничего не должно отображаться?
• Любое сообщение об ошибке, в котором просто написано «Ошибка»
• Формы, которые не отправляются из-за отсутствующего или неверного значения, при этом соответствующее поле не обозначено и не сопровождается пояснениями
• Включена возможность множественного выбора, но общее количество выбранных элементов не ясно
• Удаление пользователей с платформы без предоставления достаточной информации о последствиях удаления, а именно: будут ли утрачены все или только часть данных пользователя, предусмотрен ли период восстановления и как это повлияет на выставление счетов / количество доступных мест

Элементы статуса системы

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

Временные рамки

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

Ясность

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

Степень навязчивости

Иногда в дизайне возникает рефлекторная реакция – стремление не «беспокоить» пользователя и не создавать неприятных препятствий. Однако иногда это как раз то, что нужно! В зависимости от ситуации вам следует решить, будет ли статус системы отображаться мягко и ненавязчиво, или же весь рабочий процесс и экран должны быть заблокированы до тех пор, пока пользователь намеренно не нажмет на определенную кнопку. Как упоминалось ранее, при этом следует учитывать и временные рамки. Если ожидается, что какая-то операция займет 24 часа, вероятно, не имеет смысла блокировать пользователю возможность продолжить рабочий процесс до этого момента; возможно, более уместным будет отправка обновления по электронной почте или своевременное уведомление по истечении 24 часов.

Близость и расположение

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

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

Сопутствующее действие

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

Сенсорная обратная связь

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

Микрокопия

Это только мне так кажется, или в последнее время все только и говорят о микрокопии? Ну, на то есть веская причина! Хотя на первый взгляд UX-дизайн, лежащий в основе микрокопии, может показаться чрезвычайно простым, я уверен, что каждый из нас может вспомнить пользовательский тест, который неожиданно сошел с рельсов из-за одного неудачно выбранного слова или несогласованного использования времени глагола. Микрокопия – это то, что может стать камнем преткновения из-за доступности, языка, возраста, опыта и других факторов. Учитывая все эти аспекты, поиск способов четкого и лаконичного передачи информации становится целой наукой. Дополнительный контекст, всплывающие подсказки и описания могут помочь разбить информацию на легко усваиваемые части.

Примеры отображения состояния системы

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

Индикаторы прогресса

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

Уведомления по электронной почте

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

Некоторые признаки того, когда электронное письмо может быть уместным:

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

Индикаторы загрузки

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

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

Гибкие механизмы

Это элементы пользовательского интерфейса, которые могут удовлетворять самые разные потребности, сохраняя при этом единую общую структуру для обеспечения полезности. «Динамический остров» (англ. Dynamic Island) на iPhone – яркий пример визуального элемента, способного изменяться, чтобы предоставлять пользователям своевременную и актуальную информацию. Такая гибкость позволяет адаптироваться к потребностям конкретного момента.

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

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

Индикаторы очереди

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

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

Ограниченный выбор

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

Что дальше?

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