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

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

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

Главный экран 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 и увидеть список действий, которые исправят код автоматически:

Контекстные действия в IntelliJ IDEA подсказывают, как исправить код

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

До: тултип с проблемой в коде

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

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

Привычки

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

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

Кнопки OK и Cancel в разном порядке в macOS и Windows

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

До: три разных интерфейса для одного способа взаимодействия

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

После: одинаковый интерфейс для одного способа взаимодействия

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

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

Иконка выглядит недоступной (disabled)

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

Метафору полупрозрачной иконки сложно понять

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

Дополнительная иконка «стоп» быстрее передает смысл «что-то не так»

Сложность разработки

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

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

Пример файла с текстами для пользовательского интерфейса. Тексты — зеленые, их идентификаторы — синие

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

Тут идентификатор стал зеленым, это корректное поведение, но для примера неважное

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

В файле с кодом вместо непонятного идентификатора показываем понятный текст

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

Удаляем слово Toggle

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

Нажимаем ссылку Edit Property Value, запускается редактирование

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

Все принципы вместе

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

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

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

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

Диалог создания класса и других абстрактных типов данных в коде

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

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

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

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

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

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