Хоттейк: важная проблема работы с UX – нехватка коллективных процессов. Например, аналитики ставят задачи на реализацию интерфейсов без вовлечения дизайнеров, а команды работают изолированно, перебрасывая этапы по цепочке. Такой подход приводит к потере контекста, нестыковкам и лишним итерациям.

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

Меня зовут Света Самойленко, я старший дизайнер-аналитик пользовательского взаимодействия и лид пользовательских исследований в настольных редакторах МойОфис. Это сложный продукт на кросс-платформенном C++17-ядре (Qt5/QML для десктопов, Kotlin/Swift для мобильных платформ), веб-версия использует TypeScript/React с WASM-компиляцией ядра.

Сегодня расскажу, как мы вместе с бизнес-аналитиком наладили процесс проектирования через исследование — на примере одной (очень запутанной) фичи: фильтрации данных. Под катом разберем, из чего раньше состояла наша коммуникация с аналитиками — и к чему мы в итоге пришли. Поехали!

На самом деле, этот кейс – верхушка айсберга! Недавно наша команда сделала большой редизайн настольных редакторов практически с нуля: от первичных ux-тестов до полноценных пользовательских исследований на айтрекере. Подробно об этом я со своей коллегой расскажу уже 26 июня на митапе Frontend&UX Talks, зарегистрироваться можно здесь :)

Что было раньше?

Наш процесс был построен так:

1. Бизнес-аналитики формулируют верхнеуровневые требования на основе информации от ключевых заказчиков и конкурентного анализа.

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

Какие были минусы

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

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

• Дебаты за требования. Спецы в команде убеждали друг друга, что нужно сделать и в какую фазу. Чаще всего возникала патовая ситуация, так как аргументов не хватало (как раз из-за дефицита контекста).

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

Кейс: фильтрация данных

Сначала все выглядело просто: пользователи просят фильтрацию в табличном редакторе. Фича — базовая и давно ожидаемая. Запросов было много, и все формулировались одинаково: «Сделайте фильтрацию, как в Excel». Казалось бы, о чем тут думать?

Но как только мы начали разбираться, стало ясно:

• У разных конкурентов — разные реализации фильтрации (вплоть до отличий между Excel на Windows, macOS и веб-версии).

• Контекста из анализа тикетов не хватало – почему фильтрация по цвету ячейки лидирует, а фильтрация по маске встречается редко?

Также было непонятно, почему мы начинаем дорабатывать фильтрацию с «?» и «*»(символы для настройки фильтров), когда анализ тикетов показывает, что самый частый сценарий — фильтрация по цвету, которую поставили на следующих этапах работы над фичей.

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

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

Анализ текущего поведения показал существующие недоработки и UX-проблемы, которые тоже нужно было решить:

• сложно искать данные;

• несистемный «скроллбар»;

• окно функций вело себя некорректно.

Мы предложили три варианта развития событий:

1. Исправить баги и подготовить архитектуру. Нюанс: при этом подходе проектирование будет вестись с точки зрения разработки, а не пользовательских потребностей.

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

3. Исправить баги и реализовать наиболее востребованный фильтр

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

Готовимся к исследованию

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

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

Сначала я собрала и выписала все вопросы исследования и гипотезы:

1. Для чего пользователю фильтрация?

• Чтобы найти нужные для работы данные.

• Чтобы составлять отчеты.

• Чтобы делиться нужными данными с коллегами.

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

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

• Пользователям нужно показывать все признаки, по которым можно отфильтровать данные.

• Есть набор до пяти условий фильтрации, которые покрывают +/-80% процентов работы.

• Пользователи выбирают сортировку по возрастанию/убыванию методом тыка.

3. В каких случаях фильтр остается, а в каких случаях удаляется?

• Пользователи хотели бы сохранять созданные фильтры, чтобы работать быстрее.

• Пользователи хотели бы выключать фильтр, не удаляя его.

На основании этого я определилась с методом исследования – интервью, и подготовила гайд и упражнения. Вот как они выглядели:

Затем мы запустили поиск внутренних и внешних респондентов:

Внешние респонденты — это участники, набранные через рекрутинговое агентство, а внутренние — сотрудники компании, не вовлечённые в процесс разработки.

«А давайте пойдём вместе и разберёмся?» Не забываем про BA на стадии интервью

Пока шел поиск респондентов, я подумала: «А почему бы мне не позвать бизнес-аналитика на интервью?» Ведь:

1. Две головы лучше, чем одна.

2. Я знала, что дальше идут связанные фичи (сортировка, многоуровневая сортировка, условное форматирование), требования к которым будет писать этот же бизнес-аналитик. Хотелось, чтобы контекст был не только у меня, но и у него.

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

Наш бизнес-аналитик согласился поучаствовать в совместном интервью — за что ему огромная благодарность! На деле это был удачный опыт проведения парного интервью BA&UX в нашей команде.

Коротко об исследовании:

С какими трудностями столкнулись:

1) Позднее подключение к проекту и нехватка контекста

Поскольку бизнес-аналитик присоединился поздно, у него не было времени подготовить свои вопросы. На пробном интервью с внутренним респондентом он задал несколько маркетинговых вопросов, которые отвлекали и могли «закрыть» собеседника. Мы быстро обсудили это и скорректировали формат.

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

2) Отсутствие совместной подготовки и рассинхронизация требований к респонденту

Поскольку гайд разрабатывала только я, бизнес-аналитик во время интервью начал задавать маркетинговые вопросы, будто пытаясь «продать» респонденту наш продукт. Это было опасно: в таких ситуациях собеседник теряет доверие и перестаёт искренне делиться мыслями.

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

3) Нарушение динамики интервью

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

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

Что это все нам дало?

Для фичи:

1. Узнали потребности. Выяснили контекст и пользовательские задачи.

2. Определили скоуп и поделили на фазы. Поняли, что нужно и в каком объеме.

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

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

Для команды:

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

2. Прокачались в интервью. Для меня это был первый опыт интервью с не дизайнером/не исследователем, для Ивана – первый опыт проведения серии пользовательских интервью. Прокачались оба :)

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

Что изменилось после

• Исследования стали запускаться и по инициативе BA.

• UX и аналитики работают как партнёры.

• Внутри команды появилось общее понимание задач и целей пользователей.

Выводы

1. Привлекайте автора первых требований к исследованиям как можно раньше.

2. Работайте над гайдом совместно. Проработайте стоп-темы для вашего конкретного случая.

3. Репетируйте на котиках внутренних респондентах, отлавливайте ошибки, чтобы отточить введение интервью до (почти) идеала.

4. Не стесняйтесь обращаться за помощью к коллегам из другого департамента.

Это история не столько про идеальный процесс, важность исследования и т.д. Она про то, как важно разговаривать, вовлекать людей с другими ролями, не бояться делиться контекстом и выходить за границы своей зоны ответственности. И если этот рассказ показался для вас жизненным – мы знаем, чем вам стоит заняться уже в этот четверг!)

26 июня в 15:00 (МСК) пройдёт митап МойОфис Frontend&UX Talks, посвящённый разбору ключевых аспектов работы со сложными интерфейсами. Мы обсудим JavaScript, методы UX-исследований и другие важные темы.

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

Регистрируйтесь на событие и присоединяйтесь к чату митапа — там вы сможете пообщаться со спикерами и подробнее узнать о программе выступлений :)