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

Меня зовут Витя, я проектировщик интерфейсов в Selectel. Так вышло, что мне поручили разработать интерфейс формы создания облачного сервера. Задача не из самых простых: конфигуратор достаточно функционален и гибок, но должен оставаться понятным.

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

Паттерны в дизайн-системах

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

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

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

Цель паттерна

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

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

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

Наши результаты

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

Сегодня наши проектировщики переиспользуют описанные решения и фокусируются на особенностях своих продуктов. С помощью паттернов удалось сократить время на проектирование и ревью страниц на 20%. Кроме того, вырос уровень консистентности форм создания новых объектов в разных продуктах.

Знакомство с объектами

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

Возможно, пока что кажется, что непонятных слов больше, чем конкретной пользы. Если правила, шаблоны, паттерны, формы — слова привычные, то не совсем понятно, что такое объекты. Давайте познакомимся с ними поближе.

Где рождаются объекты

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

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

Какие сущности являются объектами?

1. Файловое хранилище — ?

2. Метрика мониторинга — ?

3. Кластер Managed Kubernetes — ?

4. Группа нод того же Managed Kubernetes — ?

1. Да.

2. Да.

3. Да.

4. Тоже да!

Подробнее

Неужели можно сказать, что все виртуальные сущности — объекты? По сути, да. Но отсюда следует другой вывод. Во время создания основного объекта мы порождаем дополнительные, которые позволяют получить решения для наших задач. Яркий пример — Managed Kubernetes и группа нод, которая обязательно будет создана в кластере. И первое, и второе — объекты.

Паттерны и объекты

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

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

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

Принципы паттернов

Мы обозначили, что объекты в панели могут быть самыми разными. Требования и контекст у команд также индивидуальны. В то же время мы хотим сделать путь пользователя до «цели» максимально простым и дружелюбным. Поэтому решили регламентировать базовые элементы и формы, через которые ему придется создавать объекты. А поиск оптимального решения ловко делегировали командам — пусть сами думают, как применить наш паттерн. Шутка.

Итак, основная цель паттерна в том, чтобы он состоял из распространенных компонентов и упрощал создание объектов. Чтобы достичь эту цель, мы определи следующие принципы.

Принцип 1. Форму создания объекта необходимо выбирать в зависимости от контекста и объема настроек.

Принцип 2. Поля важно объединять в логические блоки и располагать в форме от наиболее важных до дополняющих и второстепенных.

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

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

Принцип 5. Нельзя забывать и про другие особенности: время загрузки, обработку запросов, частоту использования и прочее.

Применение паттернов

С принципами — понятно. Но как их применить на практике? Посмотрим на примере.

Шаг 1. Выбираем форму создания объекта

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

Модальное окно

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

Яркий пример — форма добавления SSH-ключа при создании облачного сервера. Логически ключ не связан с контекстом страницы и для его добавления нужны несколько полей.

Вложенная форма

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

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

Одиночная страница

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

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

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

Пошаговый мастер создания

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

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

Шаг 2. Планируем структуру страницы

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

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

Шаг 3. Снижаем когнитивную нагрузку

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

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

Шаг 4. Сокращаем время ответа системы

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

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

Например, если пользователь при создании облачного сервера добавляет видеокарту в произвольную конфигурацию, то мы сразу предлагаем изменить ОС на версию, подготовленную к работе с GPU. Так мы исключаем или, как минимум, сокращаем возвратные перемещения пользователя по форме создания объектов.

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

2. Учитываем особенности создания объектов. Для этого смотрим на контекст пользователя и формируем список вопросов.

• В какой момент пользователь создает объект?
• Как часто пользователи создают объект?
• Вся ли информация доступна для создания объекта?

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

Практические кейсы

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

Запоминание ввода

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

Настройки запоминания

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

Подстановка тегов

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

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

Заключение

Спасибо, что дочитали до конца! Это была моя первая публикация. Надеюсь, вы нашли для себя что-то полезное.

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