Конструктор регистрационных форм

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

В начале февраля я присоединилась к команде «АБОЛЪ» и начала работать над данным продуктом. В первый день тестировщик, Сергей, провел мне пятичасовой онбординг, рассказал о платформе и показал макеты.

Ekit — комплексная платформа для управления мероприятиями: от создания организаций и персон, участвующих в событии, до системы контроля и управления доступом. Продукт разрабатывался компанией ООО «АБОЛЪ», специализирующейся на создании высоконагруженных платформ, корпоративных систем и решений для автоматизации бизнес-процессов.

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

Задача

Краткая справка: в Ekit существует организатор мероприятия, как правило, какая-либо компания (например: Газпром), её сотрудники — это пользователи Ekit.

Документация из Jira по поставленной задаче:

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

Исследование

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

После чего я исследовала реализации подобных конструкторов у других сервисов: Typeform, Google Forms, Tilda и др. основное внимание я уделила функционалу кастомизации формы, так как, в остальном, анкетам Ekit нет аналогов (во всяком случае, я не нашла). Из этого вынесла несколько best practises:

Предпросмотр формы на этапе ее создания. Это позволяет пользователю сразу видеть результат своих действий.

Простые и понятные без подсказок названия полей и функций.

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

Процесс работы

Идеи и реализация

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

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

Целевой пользователь конструктора не взаимодействовал с подобными интерфейсами ранее, поэтому ещё одним принципом, который я для себя обозначила, стала «понятность и простота».

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

Итак, перейдем к итоговому результату, расскажу еще о нескольких изменениях и моей аргументации к ним.

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

Кроме анализа, я написала некоторые идеи нативного направления создателя анкеты на создание аккуратного дизайна:

Анализ

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

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

Чуть позже расскажу, как я закрыла все пробелы в пользовательском опыте.

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

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

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

Принцип автоматического подставления шрифтов: при выборе шрифта для текста автоматически подставляются шрифты для подзаголовка и подсказки.

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

Цвет обводки при наведении на поля ввода равен выбранному цвету кнопки.

Цвет названия поля ввода генерируется автоматически и равен 30% непрозрачности цвета текста.

Автоматический расчет скруглений. Пользователь может настроить скругление подложки всей анкеты, скругления полей ввода и кнопок настраиваются системой по формуле r = R x 0.5, где R — выбранный радиус скругления контейнера.

Результаты и выводы

О личных результатах

Вот такие выводы можно сделать, исходя из результатов моего исследования:

Количество ошибочных кликов сократилось в 3 раза.

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

Конструктор обрел консистентность и последовательность UX.

Время, затрачиваемое на решение задачи пользователем, сократилось на 60%. Так, при решении задачи с переходом непосредственно в интерфейс конструктора пользователи стали затрачивать в 2 раза меньше времени. А при решении одной из задач по кастомизации формы — в 4 раза.

Руководству не удалось заключить достаточное количество сделок на использование Ekit, поэтому инвестор перевел его в статус заморозки (команда была расформирована), однако флоу регформ сверстан разработчиками, ниже прикреплено видео.

A/B тестирование

Результаты тестирования

К сожалению, этап тестирования, анализа метрик и взаимодействия с пользователями не производился в команде. Однако у меня была обратная связь тестировщика, а также, по собственной инициативе, я провела A/B тестирование среди своих знакомых с применением метода первого клика.

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

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

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

Некоторые результаты решения однотипных задач в старой и новой версиях. Среднее время на решение каждой задачи.