Привет, Хабр! Меня зовут Даша, я продуктовый дизайнер в Okdesk. В этой статье расскажу, как мы обновляли интерфейс зрелого B2B‑продукта при ограниченных возможностях для пользовательских исследований и без сложных инструментов продуктовой аналитики. Покажу, как выбирали сценарии для редизайна, проверяли решения и постепенно внедряли изменения, чтобы не сломать привычки наших пользователей.

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

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

Кто работает в Okdesk

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

Мы разрабатываем платформу для управления заявками, выездным обслуживанием и ТОиР. С 2015 года Okdesk помогает сервисным компаниям и внутренним техническим службам организовывать обслуживание оборудования и инфраструктуры. Сегодня с помощью платформы обслуживается около двух миллионов единиц техники, а используют её компании из ИТ, ритейла и HoReCa, коммерческой недвижимости, а также сервисные организации, обслуживающие медицинское, климатическое оборудование и технические средства безопасности.

В Okdesk есть несколько групп пользователей:

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

2. Диспетчер. Принимает заявки и передает их исполнителям. В системе — весь день.

3. Инженер или специалист поддержки. Выполняет задачи и общается с клиентами напрямую.

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

Почему отложить редизайн — не вариант

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

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

Сначала — понять, где проблема 

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

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

Для анализа использовали данные и обратную связь, которые уже были внутри компании:

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

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

• Внутренняя продуктовая аналитика — помогает понять, какие разделы и функции используют чаще всего. Мы в Okdesk для этого используем DataLens.

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

Приоритизация: выбираем не самое заметное, а самое значимое

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

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

Проблема была комплексной:

• комментарии сотрудника и клиента было трудно быстро отличить друг от друга;

• статус приватности сообщения был недостаточно заметен;

• визуально терялась информация о том, что к конкретному комментарию добавлен файл.

Проверка гипотез

Дальше начался главный этап — проверка наших гипотез.

Чтобы проверить решения до разработки, использовали три источника обратной связи: SEQ‑опросы, тестирование на сотрудниках техподдержки и немодерируемое тестирование на пользователях:

1. SEQ‑опросы. После отдельных действий — например, отправки комментария или прикрепления файла — пользователь видел всплывающий вопрос: «Насколько легко вам удалось выполнить действие?». Такой опрос добавили после шести ключевых действий в ленте. Средний SEQ составил 4,6 из 7. Для сравнения, бенчмарк для SEQ составляет около 5. Результат оказался ниже выбранного нами ориентира. 

2. Тестирование на сотрудниках техподдержки. Мы подготовили несколько вариантов решения и проверили их на коллегах. Обратная связь помогла отсечь очевидные проблемы до тестирования на клиентах.

3. Немодерируемое тестирование. Для этого мы в Okdesk использовали Pathway: загрузили прототип из Figma, задали сценарии и получили записи прохождений и тепловые карты кликов. Мы разослали тесты выборочно по клиентской базе. Выборка получилась небольшой — 32 пользователя, поэтому результаты использовали как качественный сигнал, а не как репрезентативную количественную оценку.

   В завершение мы доработали макеты и передали в разработку.

Как раскатывали новый интерфейс

Новый дизайн внедряли по принципу поэтапной раскатки (staged rollout): сначала открыли доступ 10% компаний, потом 50%, потом 100%. На каждом этапе отслеживали новые обращения в поддержку, проверяли, связаны ли они с обновленными функциями, и при необходимости корректировали решение.

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

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

Через месяц после релиза повторный SEQ вырос с 4,6 до 5,7. За месяц после релиза количество обращений по этому сценарию оказалось на 33% ниже, чем за месяц до обновления.

Почему мобильную версию обновили только потом

Веб‑ и мобильную версии мы решили не обновлять одновременно. Начали с веба: его аудитория шире, а собрать данные и проверить гипотезы там было проще.

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

Результат подтвердил подход. SEQ вырос с 4,6 до 5,5, а количество обращений по обновлённому разделу снизилось на 72%. 

Что делать с противоречивой обратной связью

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

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

Редизайн при ограниченных возможностях для пользовательских исследований 

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

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

2. Приоритизация. Сопоставляем найденные проблемы по RICE и выбираем сценарий для первого этапа редизайна. 

3. Фиксируем исходную точку. Измеряем удобство ключевых сценариев и определяем базовые показатели для сравнения. 

4. Прототипируем и проверяем. Тестируем решения сначала внутри команды, затем на пользователях.

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

6. Оценка. Делаем повторные SEQ‑замеры и смотрим динамику обращений в поддержку.

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