Ускорил публикацию правок на витрине кредитных карт в 6 раз
Панель администратора: разработка модуля для управления витриной кредитных карт в интернет-банке
Контекст
Админка — внутренняя CMS банка: через неё правят JSON-файлы, из которых собраны экраны интернет-банка. Продуктовые команды заказывают в ней модули под свои сценарии, чтобы заполнять поля вместо ручной правки файлов. Команда кредитных карт решила заказать такой модуль для витрины — экранов, с которых клиент начинает оформление карты. Цель — быстрее публиковать изменения и разгрузить разработчиков
Витрина в приложении: карточка, промоэкран и подборщик
Моя задача
Спроектировать модуль в существующих паттернах админки: разобрать с разработчиками компоненты JSON, перевести их параметры в поля формы, спроектировать сценарии и экраны. Связать команду кредитных карт с командой админки
Решение
- Разобраться, как сейчас правят витрину и где можно встроиться в процесс
- Изучить редакторы контента в других админках и CMS
- Соотнести компоненты дизайн-системы и их описание в JSON
- Собрать CJM основных сценариев
- Собрать макеты и передать разработке админки
Определение проблемы
Поговорил с продакт-оунерами и разработчиками, которые работают с витриной, и несколько раз посмотрел, как вносят правку. Нашёл три проблемы:
- Три файла на одну карту. У каждой карты отдельный JSON для iOS, Android и Web, поэтому одну правку вносили трижды, и это занимало до часа
- Запутанная схема JSON. Разобраться в ней мог только разработчик, а продакт ставил задачу и ждал
- Нет предпросмотра. Результат правки видели только после публикации, и опечатки замечали уже у клиентов
Анализ конкурентов
Изучил редакторы контента в CMS и продуктовых админках. Что взял в модуль:
Макеты модуля
По итогам исследования спроектировал три части модуля: редактор витрины, список с активацией и журнал изменений
Связка параметров JSON и полей формы
Задача экрана. Продакт-оунер меняет тексты и условия на карточке и промоэкране карты, не зная, как устроен JSON
Что сделал. Вместе с разработчиками прошёл схему JSON и сопоставил каждый параметр с элементом на экране. Назвал поля формы как элементы экрана: «Заголовок», «Подзаголовок», «Тег», а тип, обязательность и ограничения взял из параметров. Добавил на промоэкран дополнительные блоки, которые включаются переключателем: админка сама добавляет в JSON заготовку компонента, остаётся заполнить поля
Редактор витрины: поля названы так, как их видит клиент, а дополнительные блоки включаются переключателем
Статусная модель и процесс активации
Задача экрана. Найти нужную витрину, проверить правку и вывести её на клиентов
Что сделал. Сгруппировал витрины в списке по типу продукта. Спроектировал статусы: новая витрина создаётся черновиком и до активации не видна клиентам. Перед активацией добавил полный предпросмотр, где экраны выглядят так, как их увидит клиент, и опечатки стало видно до публикации
Список витрин, полный предпросмотр и активация черновика
Журнал истории и просмотр JSON
Задача экрана. Понять, кто и что поменял в витрине, и при необходимости разобрать конкретную правку
Что сделал. Собрал правки в журнал по ревизиям. Сделал просмотр любой ревизии в JSON с подсветкой отличий от предыдущей, чтобы не сравнивать файлы вручную
Журнал изменений и JSON ревизии с отличиями от предыдущей
Результат
- 1 час → 10 мин
- правка витрины до выхода в прод
До модуля опрашивали разработчиков, сколько уходит на замену JSON, и несколько раз я смотрел правку вживую: выходило около часа. После запуска засекали время у продакт-оунеров: сама правка занимала около пяти минут, ещё пять уходило на ожидание раскатки на прод, когда работа уже сделана
- Текст пишет тот, кто знает контекст, без пересказа через разработчика
- Разработчик больше не отвлекается от спринта ради строки в FAQ
- Опечатки заметны до публикации: предпросмотр показывает экран так, как его увидит клиент
- Журнал хранит, кто и что поменял в каждой ревизии
Витрина в админке: слева то, что заполнил продакт, справа экран, каким его увидит клиент