О чем статья и для каких читателей

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

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

Погружение в контекст

Всем привет, меня зовут Полина. Я UX-дизайнер в компании «Технологии Доверия». Сейчас я работаю в команде, которая занимается разработкой MVP программы для российских аудиторов.

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

Проектирование аудиторского задания

Аудиторское задание представляет собой пространство, где находится общий объем работ по конкретному виду аудиторской проверки. Задачи пользователя:

1. Создать задание

2. Заполнить его и отправить на проверку для дальнейшей работы с ним

Сценарий «Заполнение атрибутов карточки задания»

Цель пользователя:

Подобрать библиотеки по атрибутам и отправить на согласование

Workflow:

• после создания задания пользователь попадает в его карточку

• заполняет ряд атрибутов

• подбирает библиотеки

• отправляет на согласование по кнопке «Отправить на согласование»

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

1. Черновые макеты создания задания прорабатывались без учета представления атрибутов внутри него

2. Карточка задания представляет собой такое же заполнение атрибутов, что и при создании

3. Параметры карточки задания добавляются к уже заполненным при создании атрибутам

Первая итерация

Первые варианты макетов, которые соответствовали нашим условиям.

Гипотезы для коридорного тестирования:

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

2. Вертикальный прогресс (на самом деле степпер) заполнения вкладок в правой части экрана. Прогресс показывает два статуса: не заполнено и заполнено. Он помогает пользователю следить за процессом заполнения, так как часть атрибутов заполнена при создании задания, а часть только появилась и требует заполнения.
   Что напрягает: прогресс спорит по назначению с табами, так как его можно также использовать для навигации. Получается, табы не нужны и остается только прогресс заполнения. Но тогда степпер используется при создании задания и внутри него.

3. Последняя вкладка «Библиотеки» — это результирующая вкладка, которая подбирает рекомендуемые библиотеки исходя из заполненных атрибутов. Так как в ней тоже необходимы действия пользователя, она вошла в набор табов.

Результаты:

1. Табы оказались терпимы, так как действительно хорошую альтернативу пока предложить не удалось

2. Вертикальный прогресс вызывал вопросы и дублировал информацию в табах

3. Абсолютно не очевидно, что вкладка «Библиотеки» — это результат заполненных атрибутов

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

Вторая итерация

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

Гипотезы для пользовательского тестирования:

1. Прогресс справа информирует пользователя о количестве заполненных атрибутов

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

3. Проверка удобства табов также осталась

Результаты:

1. Прогрессом слева не пользовались, а шли по порядку атрибутов и проверяли визуально их заполненность

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

3. Пользователям не хватало кнопки «Вперед» для перехода на следующую вкладку, так как они сразу переходили из модального окна создания со степпером в карточку задания. Хотелось им нажать на кнопку по привычке

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

Третья итерация

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

Гипотезы для тестирования:

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

2. Дополнительные показатели заполненности атрибутов в табах (Отчетность 3/4), чтобы видеть незаполненные атрибуты в каждом разделе

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

4. Библиотеки вернулись в верхний таб бар, чтобы исключить игнорирование вкладки

Результаты:

1. К прогрессу вопросов и дополнительных комментариев не было

2. Дополнительные показатели заполненности в табах (3/4) вызвали вопросы у некоторых пользователей. При первом изучении экрана было не понятно, что это такое

3. Кнопкой пользовались и она давала ощущение завершенности и контроля в разделах

4. Библиотеки действительно не пропускали и логично доходили до них после заполнения всех атрибутов

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

Четвертая итерация. Финал

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

Гипотезы:

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

2. У каждого аккордеона есть статус заполнения атрибутов. Теперь указаны не просто числа (1 из 4), а прописано полностью (Заполнено 1 из 4), что исключает непонимание этого элемента и контроль заполнения каждого раздела

3. Внизу экрана прибиты прогресс заполнения атрибутов задания и кнопка «Отправить на согласование». Это дает ощущение завершенности сценария и действий пользователя на странице

Результаты:

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

Выводы

Основные инсайты, полученные при проработке сценария аудиторского задания:

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

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

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

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

Спасибо за прочтение статьи!