Помогли 20 000 сотрудникам банка перейти с Confluence на новую базу знаний

Сбер · внутренняя база знаний для поддержки клиентов · дизайнер продукта, senior IC · единственный дизайнер в команде из 18 человек · октябрь 2023 — октябрь 2025

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

Так технический лид кластера позвал меня в команду внутренней базы знаний Сбера. По ней операторы поддержки бизнес-клиентов ищут ответ, пока клиент ждёт на линии. За год на систему предстояло перевести из Confluence около 20 000 сотрудников — и не остановить при этом работу линий.

За два года CSI — индекс удовлетворённости пользователей системы — вырос на 48 пунктов, активная аудитория — примерно в десять раз. Мой вклад — ежеквартальный разбор обратной связи всей командой и четыре решения по главным запросам: спокойная цветовая система, повторный вход без потери работы, компактное дерево разделов и адаптивная версия за месяц вместо года-полутора.

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

Метрики приведены относительными или примерными — точные значения закрыты NDA.

Динамика CSI и MAU по кварталам.

Вход в проект

База знаний создавалась для линий поддержки бизнес-клиентов: оператор находит ответ и возвращается к разговору. Чем дольше поиск, тем дольше ждёт клиент. Систему ввели в промышленную эксплуатацию до моего прихода, но опыт первых пользователей показал, что работа идёт мимо неё. Операторы держались за Confluence, редакторы писали статьи в Word и загружали их файлами — так было проще.

К концу 2024 года на систему предстояло перевести из Confluence около 20 000 пользователей. Команде нужно было заместить продукт с его макросами и плагинами, не воспроизводя всю экосистему — и не останавливая работу линий. Фичи выпускали без права на ошибку и шаг назад.

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

От меня ждали одного: «усилить команду экспертизой». Рамки и приоритеты предстояло определить самому. Цель команды задавал квартальный уровень CSI — его я и принял как точку опоры.

Свою цель я сформулировал так: заслужить доверие пользователей во время раскатки. Определил наблюдаемые критерии успеха: операторы открывают базу вместо Confluence, редакторы пишут статьи в редакторе базы вместо Word. Для этого нужно было встроить дизайн в процесс принятия решений команды и убрать из интерфейса трение, которое мешало рутинной работе пользователей.

Диагностика

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

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

Удовлетворённость в банке измеряют квартальными опросами: пользователь ставит оценку от одного до пяти и пишет комментарий. Оценки усредняют, а среднее выражают в процентах от максимума: средняя оценка 4 из 5 соответствует 80 из 100. Этот опрос показал CSI ниже 40.

Отчёт по опросу был обзорным: уровень в разбивке по ролям и подразделениям, без указания причин. Я попросил у CSM сырую выгрузку и разобрал комментарии вручную. Больше тысячи отзывов с текстом сложились в три главные жалобы:

1. Цвета. Больше четверти комментариев — о том, что долго смотреть на экран невозможно: резь в глазах, головная боль после смены.
2. Разлогин каждые 15 минут — с потерей навигации в дереве разделов.
3. Потеря несохранённых правок при редактировании.

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

Как выбирали, что делать

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

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

Мандата на такой контур не было: команда ждала от меня макетов по готовым запросам, предлагать новые изменения в мою роль не входило. Поэтому я завёл дизайн-бэклог и копил в нём проблемы, чтобы брать в работу те, что близки к текущим задачам команды. Пополнял его из разборов опросов и данных CSM — писем на сервисный ящик, интервью с пользователями, запросов стейкхолдеров. В работу отбирал по двум критериям:

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

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

Решение 1. Доказательность: спокойная цветовая система

Январь 2024

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

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

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

Разница становится заметной при длительной работе.

Светлая тема вышла с первым релизом нового года, а следующим — тёмная с переключателем. Я переопределил те же переменные и перепроверил контрастность, поэтому получилось быстро. Жалоб на обновления не поступило.

Я упустил одно: новые цвета сломали скриншотные тесты. Я извинился за это перед тестировщиками; они обновили тесты.

Следующий опрос показал рост удовлетворённости более чем на 10 пунктов за квартал, а цвета пропали из комментариев. Сотрудники ночной смены отдельно благодарили за тёмную тему. То, что сначала казалось делом вкуса, оказалось вопросом «сколько часов подряд человек может работать с базой?».

Решение 2. Коммуникация: повторный вход без потери работы

Август 2024

Система разлогинивала пользователя после 15 минут бездействия. Таково было требование безопасности, и обойти его было нельзя. Оператора выбрасывало на страницу входа, а после ввода пароля он возвращался на стартовую страницу базы. Страница, на которой он остановился, терялась. Путь к нужному разделу приходилось проходить заново от корня базы — клиент всё это время ждал. Редакторов это тоже касалось: в такой момент они теряли набранный текст; один разлогин мог стереть работу за полчаса-час.

Снизили «налог на безопасность».

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

Самым сложным было согласовать это с безопасностью. Подобные согласования вёл аналитик, и требования ИБ в них воспринимались жёсткими: как сформулировано в инструкции — буквально так их и следует исполнять. Я попросился на встречу аналитика со специалистом ИБ и заранее подготовил три вещи: что видит оператор при разлогине, во что это обходится консультации и как будет выглядеть окно. На встрече попросил слово и привёл главный аргумент: программно ничего не меняется, меняется только организация интерфейса.

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

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

Редактор возвращается к набранному тексту. Именно потеря правок при повторном входе подрывала доверие редакторов к базе — поэтому статьи и готовили в Word. Когда база перестала терять текст, редакторы перестали пользоваться Word.

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

Решение 3. Ограничения: дерево разделов без пересборки контента

Май 2025

Дерево разделов жило в узкой колонке слева и служило основным инструментом навигации для всех пользователей базы. Я заметил, что огромные отступы и рваные переносы замедляют поиск нужной строки. Прикинул потери: один скролл обходится примерно в 3 секунды; на каждой сотне таких операций набегает 5 минут — есть, за что бороться.

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

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

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

Я предложил изменить отображение дерева и не трогать контент — и показал готовый прототип: уплотнённая компоновка, обработка переносов, управление шириной колонки. На экране стало помещаться примерно в полтора раза больше строк дерева.

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

Скролл дерева разделов — незаметная утечка времени.

Решение 4. Управление скоупом: адаптив за месяц

Июнь 2025

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

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

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

Результат

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

Что это дало продукту. Раскатка шла волнами, без остановки линий — и уложилась в план. Оба моих критерия из начала выполнены: операторы работают в базе вместо Confluence, редакторы пишут в её редакторе вместо Word. К концу 2024 года в системе было больше сотни внутренних продуктов банка, включая команды за пределами бизнес-контура. Активная аудитория в месяц выросла примерно в десять раз — с порядка 2 000 до порядка 20 000 человек. CSI за два года вырос на 48 пунктов: с «ниже 40» до «выше 80».

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

Где граница моего вклада. Рост аудитории дала плановая раскатка; часть команд разработки попросила доступ сама, узнав об анонсе ИИ-функций базы. CSI отражает и качество контента, который размещают подразделения: на продукт мы влияли напрямую, на контент — только через удобство инструментов. Первая массовая волна миграции просадила показатель: пересевшие с Confluence сравнивали новую систему со старой. После неё выборку сузили до пользователей со стажем от трёх месяцев, чтобы отделить регулярную работу от первого впечатления. Большая часть роста при этом пришлась на период до смены выборки. Бизнес-метрики линии — время ответа, стоимость, удовлетворённость клиентов — считались на стороне заказчика и до команды не доходили. Поэтому +48 — динамика метрики всего продукта, и мои решения — часть этой работы.

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

Что я сделал бы иначе

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

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

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

Что я вынес

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

В этом проекте я укрепился в трёх принципах. Они помогали договариваться с людьми, находить решения и расставлять приоритеты.

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

Ограничения — часть условий задачи. Чтобы решить проблему, снимать ограничение не обязательно. Разлогин по-прежнему защищает данные от утечки — а работа при нём больше не теряется. Структура базы сохранилась — а дерево стало удобнее.

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

Что дальше

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

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