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

Принципы проектирования интерфейсов от команды дизайнеров IntelliJ IDEA.

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

IntelliJ IDEA — популярная среда разработки (IDE) для языка программирования Java. Возможно, вы и сами пользуетесь ей или одной из десяти IDE компании JetBrains: WebStorm, PyCharm, GoLand, Rider и так далее. Все эти продукты построены на платформе IntelliJ и имеют общий пользовательский интерфейс.

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

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

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

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

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

• Скорость доступа к элементам интерфейса.
• Экономия внимания.
  
• Информативность.
  
• Находимость.
  
• Привычки.
  
• Сложность разработки.
  

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

Принципы оставляют пространство для решений. Разберу способы принятия таких решений на примерах пользовательских интерфейсов в IntelliJ IDEA.

Скорость доступа — насколько быстро можно подвести курсор к элементу, насколько быстро прицелиться. Здесь действует Закон Фиттса: время прицеливания прямо пропорционально расстоянию, обратно пропорционально размеру объекта прицеливания. То есть в большую кнопку рядом с курсором прицелиться быстрее, чем в маленькую кнопку далеко.

Такая маленькая кнопка как раз была на тулбаре в главном окне IntelliJ IDEA — кнопка с треугольником на скриншоте:

Добавили кнопке лейбл «Add Configuration». Кнопка стала большая, и целиться стало удобнее:

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

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

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

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

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

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

Чтобы внимание не тратилось, решили расширять само поле:

Ещё внимание можно потратить на слишком заметный элемент интерфейса, когда заметным он быть не должен. Хотели объяснить в нотификации, зачем она появляется, и добавили серый текст:

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

Информативность — это доля полезной информации в общем объеме сообщения, то есть соотношение сигнал/шум. Улучшать информативность можно двумя способами: добавить сигнал или уменьшить шум.

Пример с добавлением сигнала. В IntelliJ IDEA есть возможность перемещаться назад / вперед по местам кода, где находился курсор (действия Navigate Back / Forward). Не всегда легко вспомнить, в каком месте кода каретка была некоторое время назад, и непонятно, нужно ли туда возвращаться. Добавили информацию для решения этой проблемы — показали кусочки кода, где был курсор, в отдельном попапе:

Другой пример, когда убираем шум. Несколько версий назад у нас было много тулбаров с 10–20 иконками. В таком количестве иконок сложно найти нужную. Мы собрали статистику кликов на тулбарах. Те действия, которые использовали меньше 0,1% пользователей (темно-красный), мы убрали с тулбаров, другие действия сгруппировали или переместили, наиболее используемые вынесли в начало тулбара. Теперь шума меньше, найти нужную иконку проще:

Фича может быть полезной, но если пользователи про неё не знают — всё равно, что нет фичи.

В IntelliJ IDEA можно искать файлы, классы и другие сущности проекта или действия самой IDE. Раньше было пять похожих интерфейсов поиска: свой для каждой категории и один поиск для всех. Нужно было знать, как вызывать каждый в отдельности.

Чтобы не нужно было находить каждый из попапов, совместили их в один. Теперь достаточно одного шортката (Shift + Shift), чтобы узнать, какие объекты можно искать — все они перечислены в заголовке попапа, и между ними можно легко переключаться клавишей Tab:

Или ещё случай. Одно из самых полезных действий в IntelliJ IDEA — Show Context Actions с шорткатом Alt + Enter. Оно подсказывает, как сделать код правильнее, позволяет запустить его, снавигироваться в связанные сущности и многое другое. Например, можно поставить курсор на код с проблемой, нажать Alt + Enter и увидеть список действий, которые исправят код автоматически:

Но узнать про Show Context Actions можно, но только если заметишь и нажмёшь иконку–лампочку (она открывает это же меню) или откроешь контекстное меню. Оба способа легко пропустить. Зато по наведению курсора мыши на код с проблемой появляется тултип с описанием ошибки, найти его намного проще:

Логично связать описание ошибки с действиями для ее исправления. Добавили действия в тултип, и количество использований Show Context Actions в IntelliJ IDEA выросло с 60% до 70%.

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

1. Используем важные интерфейсные шаблоны из операционных систем. Например, в macOS кнопка «OK» справа, а в Windows — слева.

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

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

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

Можно нарисовать иконки продукта и плагинов неактивными, но тогда выглядит, будто пункт списка целиком недоступен:

Можно сделать иконки полупрозрачными, передать метафору «чего-то не хватает». Но такой прием не используется в IntelliJ IDEA, вид непривычный, и метафору могут не понять:

Поэтому решили использовать привычный символ знака «стоп» для значения «стой, что-то не так»:

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

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

В файле с кодом, показывающим текст, указываем обращение к идентификатору текста:

Вместо идентификатора удобно показать превью текста — понятно, что именно будет выведено в интерфейс. Такое превью отображается в IntelliJ IDEA автоматически:

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

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

Задача решена, пусть и менее элегантно, но гораздо быстрее.

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

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

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

Рассмотрим вариант посложнее: диалог создания класса, интерфейса или элемента другого типа данных (класс и интерфейс — понятия из программирования). В диалоге можно записать имя элемента и выбрать его тип в списке Kind:

По умолчанию список типов скрыт, и может быть сложно понять, какие есть варианты. Если курсор находится в поле Name, то Kind можно переключать кнопками Вверх/Вниз на клавиатуре, на что намекает иконка ↑↓ справа от Name. Но этот способ подсказки непривычный, метафора иконки непонятная, и в результате найти эту функциональность сложно.

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

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

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

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

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

#юзабилити