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

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

Вводная

Система состоит из трёх основных порталов:

• Клиентский портал
• Внутренний портал для сотрудников
• Админ-панель

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

Клиентский портал

На этот ресурс были задействованы основные силы. Клиентский портал даёт возможность клиентам задавать вопросы технического характера и получать на них ответы.

Перед редизайном ставились следующие задачи:

• Снизить нагрузку на саппорт-инженеров. Помочь пользователям находить ответы самостоятельно, если на вопрос уже отвечали ранее или решение описано в документации.
• Улучшить UX. Накопился список проблем, которые нужно было решать:
  • Пользователи выбирают неверный продукт при создании вопроса. DevExpress разрабатывает и поддерживает десятки продуктов. У каждого продукта могут быть разные платформы и версии. Иногда важно знать, какая ОС установлена у пользователя, каким IDE он пользуется. Нужно было сделать так, чтобы у пользователя не возникали проблемы при выборе нужных значений. Помочь ему на этом пути.
  • Возникают проблемы при форматировании текста. Пользователи приходят в поддержку с техническими проблемами. Описание проблемы содержит куски кода или целые архивы с проектами. В старой версии сайта пользователи путались в текстовом редакторе и отправляли не отформатированные куски куда, которые сливались с обычным текстом. Также, пользователи не всегда понимали как аттачить файлы. Всё это приводило к дополнительной нагрузке на саппорт-инженеров.
  • Пользователи не замечают уведомления об ответах в их тикете. Проблема касалась как веб-интерфейса, так и уведомлений приходящих пользователю на почту. Пользователи либо не замечали уведомления, либо не понимали к чему они относятся, либо ранее отключали уведомления и забывали об этом. В связи с этим, среднее время на решение таких тикетов значительно увеличивалось.
  • Клиенты из одной и той же компании не видят вопросы друг друга. Большинство клиентов предпочитает оставлять свои вопросы приватно. Чтобы их могли видеть только саппорт-инженеры. Из-за этого возникала проблема, что вопросы становились приватными полностью и их не могли видеть даже сотрудники одной и той же компании с разных аккаунтов.
  • Неудобные фильтры. Пользователи, что на странице со списком публичных тикетов невозможно ничего найти. Фильтров мало, а то, что есть не всегда работает очевидным образом.
• Переосмыслить встроенный инструмент “Version History”.
• Улучшить аналитику.
• Освежить внешний вид.

Подготовка к работе

Перед началом работы над редизайном была проведена подготовительная работы. Подготовлен общий план работы и проведены встречи со всеми заинтересованными лицами. Был подготовлен итоговый бриф проекта.

Часть работ, которые были проведены на этом этапе:

• Анализ текущего дизайна. UX-тестирование текущего сайта, поиск проблем.
• Ресёрч конкурентов. Изучение как прямых конкурентов, так и решений крупных платформ. Например, Zendesk, Freshdesk, Zoho Desk.
• Сбор и анализ существующего фидбека. За годы работы, накопилось большое количество тикетов, комментарием и другой обратной связи касаемо работы портала. Была проведена большая работу по сбору всей это информации в один документ, её анализу и приоритизации.
• Сбор информации от саппорт-инженеров. Инженеры поддержки активнее всего общаются с пользователями и знают детали и проблемы, которые могут быть неизвестны и неочевидны другим членам команды.
• Изучение текущих данных аналитики и список того, что хотим собирать ещё в новом дизайне. Для работы с данными использовались: Google Analytics (+Google Tag Manager), Matomo, внутренние инструменты.
• Сбор требований от заказчиков и всех заинтересованных лиц.
• Подготовка брифа. Описание проблем, целей и задач. Развёрнутый ответ на вопрос, что мы будем считать успешным редизайном.

Процесс

Работа над сайтом строилась 2-4 недельными спринтами. В конце каждого спринта проводились синхронизационные встречи с заказчиками.

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

Чтобы работа над новым дизайном была эффективной и обратная связь поступала как можно быстрее был принят рад мер:

• Продукт менеджер продукта показывал прототипы и просто картинки небольшой выборке самых активных и заинтересованных пользователей саппорт-центра. Благодаря этому получалось очень быстро собрать много полезной информации, которая помогала намного быстрее замечать точки роста.
• Тесное общение с разработчиками. Так дизайн значительно обгонял разработку, нужно было сразу учитывать технические ограничения. Для этого проводились постоянные встречи между разработчикам, заказчиками и дизайнером. Так мы оценивали техническую сложность каждой фичи и на основе этого принимали решение, будем мы брать её в работу или нет.
• На этапе, когда появилась первая работающая версия сайта, его стали тестировать сотрудники. В первую очередь, к тестированию подключались саппорт-инженеры. На этом этапе было собрано большое количество фидбека как по техническим багам, визуальным багам, так и просто по неудачным UX-решениям.
• На следующем этапе снова к фидбеку снова были подключены активные клиенты. Которые были готовы дать развёрнутый фидбек.
• На одном из финальных этапов сайт стал доступен для всех пользователей, но в виде бета-версии. При этом, каждый пользователь мог вернуться к старой версии сайта. Со временем, пользователей вернувшихся на старый сайт становилось меньше. Также, мы старались собирать фидбек от таких пользователей. Чтобы понять, почему они вернулись на старую версию сайта.
• К новой версии сайта была прикручена продвинутая аналитика.

Примеры реализации

Релевантные подсказки при создании тикета

Упрощена навигация по дискуссии с ветвистой иерархией

Обновлены инструменты фильтра на странице со списком тикетов

Сделана мобильная версия под разные размеры

Внутренний портал и админ-панель

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

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

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

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

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

Результаты

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

Старая версия сайта постепенно была отключена, когда количество её пользователей стало совсем небольшим.

Общая оценка редизайна была оценена как успешная. Как со стороны клиентов, так и со стороны сотрудников. Поставленные перед редизайном цели были достигнуты:

• Уменьшилась нагрузка на саппорт-инженеров.
  • Пользователи стали чаще находить решения самостоятельно: улучшен движок поиска, предлагаются релевантные ссылки при создании тикета, улучшена фильтрация.
  • Пользователи стали реже ошибаться с выбором платформы/продукта и других деталей при создании тикета.
  • Во внутреннем портале появились инструменты, помогающие саппорт-инженерам быстрее отвечать на тикеты, ответ на которые уже давался ранее.
• Не отформатированные тикеты появляются гораздо реже. Решилась проблема с тем, что пользователи не понимали, как отправлять аттачи.
• Уменьшилось количество проблем, когда пользователи не получают уведомления вовремя.
  • В настройках уведомлений появился отдельный чекбокс, для получения уведомлений от саппорт-центра (раньше был единый чекбокс, для всех почтовых рассылок).
  • Даже если пользователь отключил уведомления от таких рассылок, то саппорт-инженер будет об этом знать. И, если у пользователя возникают с этим проблемы, подсказать варианты решения.
  • Сами почтовые уведомления стали понятнее, появилась возможность подключить браузерные уведомления.
  • Появилась возможность подписать на рассылку на любой тикет со страницы этого тикета.
• Более точечно настроена аналитика.
  • Саппорт-инженер теперь может видеть карточку пользователя с историей посещений тикетов и документов в документации. Так инженер поддержки сразу может понять, какие ссылки есть смысл советовать, а какие — нет, так как пользователь их уже посещал.
  • Добавлены ивенты на целевые действия.
  • Созданный внутренние дашборды с анализом различных данных, необходимых для оценки поступаемого количества тикетов и оценки эффективности саппорта.
• Поиск по тикетам стал гибче и проще.
  • Были докручены мета-теги, чтобы тикеты лучше искались поисковиками.
  • Переосмыслены фильтры, добавлены готовые пресеты и возможность подписаться на созданный фильтр.
  • Оптимизирована внутренняя страница поиска.
• Сделана мобильная версия клиентского портала.