Волшебный интерфейс25.04.2016 08:03

Как-то на днях у меня возникла необходимость распечатать более десяти чеков из моей истории платежей, используя банкомат одного из крупнейших банков. Я перешёл в платежи, выбрал «История», прокрутив скроллер списка до нужного платежа, выбрал его, а затем нажал кнопку «Операции» и выбрал печать. И так повторялось для каждого чека: каждый раз происходил переход в главное меню и всё начиналось заново. Я задумался — неужели, несмотря на обилие источников информации по UX, до сих пор тратятся огромные бюджеты на подобные неудобные интерфейсы? Почему разработчики не хотят делать интерфейс, позволяющий пользователю почувствовать себя волшебником, а делают пользователей беспомощными в достижении своих целей? Возможно, причина в том, что, несмотря на обилие теории, эти источники предоставляют мало примеров из реальных проектов.
Так как мы буквально на прошлой неделе завершили большой Web-проект, в котором как раз стояла цель разработки удобного интерфейса, я решил осветить в статье, на какие основные моменты при проектировании интерфейса стоит обратить внимание, и привёл примеры нашего решения.
Интерфейсом обычно называют набор способов, которыми вы выполняете какие-либо задачи с помощью какого-либо продукта, а точнее совершаемые вами действия и то, что вы получаете в ответ.
Исходя из этого, волшебный интерфейс — это интерфейс, который исполняет то, что вы пожелали. Однако попробуем дать определение, более близкое к реальной жизни.
Психологи заметили, что при использовании различных вещей у пользователей задействовано три уровня когнитивной обработки:

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

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

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

Возможно ли создание волшебного интерфейса в конкретной предметной области? Мы при создании DevExpress Web Dashboard посчитали, что это возможно.

Целью разработки проекта DevExpress Web Dashboard (далее Dashboard) было создание интерактивной аналитической панели с заданным набором элементов визуализации, возможностью фильтрации и группировки. К сожалению, на этапе разработки в силу специфики бизнеса у нас не было доступа к реальным пользователям продукта, поэтому пользователями выступали различные сотрудники нашей компании и вымышленные персонажи.

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

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

Основой положительного внутреннего ощущения является привлекательность дизайна интерфейса со стороны чувств человека (зрение, слух, вкус, обоняние, осязание). Внешнее воздействие стимулирует работу соответствующего органа чувств, который передаёт информацию в мозг. В результате, человек воспринимает это внешнее воздействие, у него возникают позитивные или негативные ощущения. В случае программных интерфейсов, воздействием обычно является внешний вид интерфейса, а чувством — зрение.
Есть ли универсальные рецепты, как сделать так, чтобы то или иное воздействие приводило к нужному восприятию?… Как понять и оценить, сделали ли вы хороший, привлекательный интерфейс? Известный промышленный дизайнер Дитер Рамс в поисках ответа на эти вопросы, сформулировал 10 принципов хорошего дизайна, подходящие для любого вида интерфейса. Также существует множество источников, где описаны модные тенденции и типовые решения в проектировании визуальных интерфейсов. Несмотря ни на что, тот факт, насколько внешний вид интерфейса понравится пользователю, прежде всего зависит от личности дизайнера, который, в свою очередь, ищет вдохновение где угодно. Похоже, здесь как и в живописи — как рисовать портрет описано в любом учебнике по основам изобразительного искусства, но Джоконду нарисовал только один человек.

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

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

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

Новичок

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

Средний пользователь

Эксперт задаст сложные фильтрационные критерии или перейдёт в свойства Dashboard«а для создания собственных вычисляемых полей или параметров.

Эксперт

Сравнивая с аналогичным нашим решением под другую платформу, замечаем, что новичку довольно сложно понять с чего начать. Область перетаскивания полей (Drag Area) не кажется важнее свойств в ленте (Ribbon) и если начать со свойств в ленте, то новый пользователь не увидит изменений в элементе.

Новичок (другая платформа)

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

Средний пользователь (другая платформа)

Эксперт (другая платформа)

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

Эффективность пользователя при работе с интерфейсом должна быть максимальной (должно быть максимизировано полезное действие интерфейса). Это прежде всего означает, что необходимый инструментарий для данного функционала легко находится, расположен близко и доступен без «выцеливания», т.е. как минимум удовлетворяется закон Фиттса. Из этого закона в частности следует, что часто используемые меню и панели инструментов оптимально располагать по четырём сторонам экрана (вспомним Mac с его верхним меню).

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

Меню и панели инструментов

Эффективность напрямую связана с кратковременной памятью, объём которой ограничен. «Кошелёк Миллера» из 7± 2 элементов уже давно служит здесь своего рода законом, но если попробовать обобщить, то всё, что перегружает кратковременную память, будет снижать эффективность пользователя в процессе работы с интерфейсом.

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

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

Нам было довольно сложно сократить количество иерархий в редакторе свойств элементов аналитической панели (гридов, диаграмм и т.п.). Здесь нам помог принцип «разделяй и властвуй» или как сейчас принято говорить — принцип модульности. Мы разделили настройки свойств на разные типы: BindingArea позволяет визуально представить элемент с точки зрения связей с данными, а контекстные PropertyAccordion«ы — с точки зрения свойств (при этом свойства объектов самой BindingArea также редактируются в всплывающем рядом окне с PropertyAccordion). PropertyAccordion отображает свойства, сгруппированные в плоский список в виде элементов-редакторов и позволяет редактировать лишь одну такую развёрнутую группу (слайд).

BindingArea и PropertyAccordion

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

Классический редактор свойств (другая платформа)

Лента и область перетаскивания полей (другая платформа)

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

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

Настройка диаграммы и грида

Избавиться от режимов в интерфейсе иногда бывает довольно сложно. Ведущие специалисты по UX и HCI уже давно активно агитируют за избавление от режимов. Известный сотрудник PARC и Apple Ларри Теслер даже на своём авто имел номерной знак с надписью «NOMODES» (кстати, и в Twitter Ларри Теслера можно найти по имени @nomodes).
Несмотря ни на что, многие современные интерфейсы имеют режимы, и если при переключении между режимами интерфейс должным образом не изменяется, это может ввести пользователя в заблуждение. Например, моя клавиатура Microsoft Natural Ergonomic позволяет отключить F-режим (F Lock находится рядом с часто используемой мною F12) и у меня периодически бывает, что, нажимая F5, я какое-то время не понимаю, почему не происходит то, что я ожидаю. Также во многих современных средах разработки в режиме выполнения приложения нельзя добавлять/удалять/редактировать модули и т.п.

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

Режимы: просмотрщик (для работы бизнес-аналитика) и редактор (для администратора-создателя аналитических панелей)

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

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

Лоадинг-индикатор

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

Поэтому в Dashboard мы реализовали свой скроллинг, который появляется поверх контента при наведении мыши (т.е. по поведению похож на то, что мы видим в последних MacOS).

Обычный скроллинг

Скрывающийся (контекстный) скроллинг

Люди любят экспериментировать, поэтому интерфейс обязан уметь отменять и возвращать действие. В настоящее время системы с undo/redo уже стали стандартом, однако не все из них лишены кучи диалогов с подтверждениями о вводе чего-либо. «Вы уверены?» — спрашивают они. Зачем лишний раз напрягать пользователя, если есть одна простая кнопка «Отмена»?

Dashboard позволяет отменить и вернуть любое действие без лишних вопросов.

Undo/Redo

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

Например, я постоянно пытался свернуть до этого несворачивающийся слайд PropertyAccordion. Ряд пользователей ожидали скрытие панели свойств элемента BindingPanel при повторном щелчке на нём (ранее повторный щелчок не скрывал панель, а приходилось нажимать кнопку »<” в правом верхнем углу этой панели). Изначально меню на элементе появлялось по наведению мыши, и многие пользователи всё равно делали дополнительный щелчок мышью, т.к. ожидали выделения именно по щелчку.

Примеры «desire lines»

Снимая видео для данной статьи, я постоянно ощущал недостаток возможности нажать Esc для закрытия панелей. В документе по юзабилити-тестированию про горячие клавиши упомянули лишь 10% пользователей и речь шла прежде всего про Delete.

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

Мы начинали именно так и сделали не менее 5 прототипов, которые проходили по сценариям разных пользователей. Несмотря на это, мы всё ещё CTP-версия и ждём ваших отзывов.

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

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

© Habrahabr.ru