Чем занимается наша команда
Мы развиваем единую платформу уведомлений банка
Через нашу платформу клиенты получают SMS, push и другие сообщения — о платежах, переводах и других важных событиях.
Цель — развивать единую платформу уведомлений, которая гарантирует стабильную доставку и единый стандарт сообщений.
Что за конструктор шаблонов
Это продукт, в котором собираются тексты уведомлений для разных каналов
Раньше шаблоны собирались через код, и работать с ними могли в основном люди с хорошей технической подготовкой.
Теперь появился удобный конструктор: шаблон можно настроить через простую форму или, при необходимости, открыть редактор кода. Благодаря этому с уведомлениями могут работать не только специалисты с сильным техническим бэкграундом.
В итоге банк получает единый стандарт сообщений, меньше ошибок при создании шаблонов и возможность быстрее масштабировать новые сценарии уведомлений.
Проблема
Старые легаси-интерфейсы были неудобными, создавали ошибки и замедляли внедрение
Старые легаси-интерфейсы были неудобными, создавали ошибки при создании шаблонов уведомлений и замедляли внедрение новых фич. Банк решил перевести сервисы на новую дизайн-систему Omni UI и обновить интерфейсы.
Задача
Переработать форму, через которую сотрудники создавали SMS, push и rich-push
Аудитория: около 50 сотрудников сопровождения из разных подразделений, включая линии поддержки.
Миссия: сделать процесс работы с шаблонами более понятным и быстрым, сократить ошибки и повысить удобство интерфейса.
Цель бизнеса: обеспечить бесшовный переход всех сервисов уведомлений на новую платформу и унифицировать взаимодействие через дизайн-систему.
Критерии успеха: сотрудники создают и редактируют шаблоны быстрее, все сервисы успешно мигрировали на новый интерфейс, положительная обратная связь (внутренние опросы и демо-сессии).
Дискавери
Интервью и демо с сопровождением — поля перегружены, ошибки регулярные
Начал с изучения текущей формы шаблона и сценариев работы сотрудников сопровождения.
Провёл интервью и демо-сессии с пользователями, чтобы понять, где возникают сложности. Собрал обратную связь: поля были перегружены, а ошибки при создании шаблонов встречались регулярно.
Проанализировал ограничения легаси-системы и запрос бизнеса на унификацию в рамках новой дизайн-системы Omni UI.
Как собирается уведомление
Сырые данные → шаблон преобразования → понятный текст
1) Берутся исходные сырые данные уведомления — например, сумма, баланс, номер карты.
2) Шаблон преобразования превращает данные в понятный текст.
3) Результат для клиента — понятное уведомление на телефоне: «Списание 1050.50 ₽ с карты *4977. Баланс: 251.51 ₽».
Гипотезы и черновые макеты
Две гипотезы: форма-конструктор и визуальная структура push-полей
На этом этапе разбирался, как вообще подступиться к задаче, общался с ключевыми пользователями и бизнесом. Изучил лучшие практики интерфейсов админок на Mobbin, провёл бенчмаркинг, прикинул возможную структуру новой формы.
Гипотеза 1: текущее решение слишком техническое и доступно в основном разработчикам. Если добавить форму-конструктор и вынести push-параметры в форму, сотрудники сопровождения смогут быстрее и проще создавать шаблоны без погружения в код.
Гипотеза 2: если построить интерфейс конструктора так, как выглядит реальное push-уведомление (заголовок, описание, картинка и кнопка с deeplink), и добавить визуальное превью, сотрудники быстрее ориентируются и реже задают уточняющие вопросы.
Приоритизация гипотез
Ценность ÷ сложность. В первую итерацию взяли «режимы работы»
После того как сформулировали гипотезы, мы их приоритизировали по принципу «ценность ÷ сложность».
В первую итерацию взяли гипотезу с режимами работы (форма и редактор кода) — она показала высокий коэффициент ценности при умеренной сложности.
Во второй гипотезе оставили только структурированную форму (заголовок, описание, картинка, кнопки). Визуальное превью отложили: техническая сложность оказалась слишком высокой для первого этапа.
Скоупинг
MVP: новая группировка полей, базовые подсказки и проверки, интеграция с DS
Вместе с командой определили минимальный объём первой итерации: новая логика группировки полей, базовые подсказки и проверки ошибок, интеграция с дизайн-системой. Более сложные улучшения (расширенный поиск, история изменений) оставили на следующие релизы.
Дизайн первой итерации
Прототип в Figma на основе Drawer. Демо. Аудит реализации
Изучил все гайдлайны дизайн-системы Omni UI. Подготовил кликабельные прототипы в Figma новой формы в рамках новой дизайн-системы. Провёл демо-презентацию с сопровождением и собрал обратную связь.
После передачи в разработку провёл аудит реализации на тестовой среде: корректность полей и статусов, мелкие несоответствия дизайну, соответствие логике сценариев всей админки.
Первый запуск и проблема Drawer
Длинные тексты в боковой панели — неудобно. Перешли на полностраничную форму
После первого релиза на тестовую среду пользователи жаловались, что работать с формой в формате боковой панели неудобно: при редактировании длинных текстов трудно видеть все поля и корректно настраивать шаблон.
По гайдам дизайн-системы Drawer должен был использоваться для таких сценариев, но реальный опыт показал ограничения. Я вынес проблему на обсуждение с командой дизайн-системы — согласовали изменение паттерна: вместо боковой панели сделали полностраничную форму.
Результат
Выпущено в прод. Быстрее, меньше ошибок, позитивный фидбек
Редизайн был успешно выпущен в прод. Сотрудники отметили, что форма стала заметно удобнее и быстрее, все процессы мигрировали на новый интерфейс без возврата к легаси, количество ошибок снизилось, стейкхолдеры дали положительный фидбек.
Критерии успеха достигнуты: сотрудники стали работать эффективнее, а бизнес получил стабильный и масштабируемый инструмент.
Моя роль
Единственный дизайнер, полный цикл задачи
Был единственным дизайнером, отвечал за полный цикл: от исследования и сбора фидбека до проектирования, согласования с дизайн-системой и аудита реализации. Помимо макетов взял на себя организацию встреч с пользователями и стейкхолдерами, а также аргументацию изменений в паттернах DS.
Уроки
Даже компонент по гайдлайну нужно проверять на реальном опыте
Даже если гайдлайн предписывает использовать компонент, нужно проверять его реальное удобство на практике.
Фидбек от конечных пользователей часто открывает проблемы, которые невозможно выявить только аналитикой.
Важно заранее закладывать время на итерации и быть готовым отстаивать решение, если оно улучшает юзабилити.