Контекст
Фронт-ревью, то есть сверка вёрстки с макетами, в корпорации было плохо формализовано, и продуктовые команды мало о нём знали. Задокументированного шаблона отчёта не было: дизайнеры старались делать похоже друг на друга, но получалось только примерно одинаково. Тестовые стенды доступны лишь из защищённого периметра, проверять приходится с виртуального рабочего места, а задачи на проверку вёрстки зависали в бэклоге.
Задача звучала как «ускорить фронт-ревью». Я увидел в ней процесс, который должен работать на всех уровнях: у дизайнеров, в продуктовых командах, в платформенной разработке и у руководства.
Единая нотация
Первым шагом был не инструмент, а общий язык. Я прошёлся по дизайнерам разных команд, включая свою, и спросил, чего им не хватает в нотации замечаний. Из этого выросли компоненты нотации в Figma: мы их опубликовали и отдали всем.
Это был мой первый успех в проекте. Компонентами пользуется всё подразделение, около двадцати человек, а отчёты моей команды стали заметно консистентнее.
Расширение, которое снимает рутину
Когда язык был общим, я спроектировал расширение для браузера и сам написал его с помощью ИИ. Дизайнер прямо на стенде кликает по элементу или выделяет область, расширение снимает скриншот с рамкой и заводит карточку проблемы: уровень от блокера до мелочи, описание и как должно быть. Отчёт выгружается для разработки одним файлом.
Где
- Прямо на тестовом стенде
- Без переключения в Figma или трекер
Как
- Шкала уровней из мира разработки
- Отчёт читается как баг-репорт
Как развивалось
- Сначала сырой MVP
- Потом интерфейс переехал из оверлея в панель
Отчёт собирается в двух форматах, и у каждого своя задача.
HTML
- Фильтры проблем по уровню
- Метаданные для передачи эстафеты: другой дизайнер продолжает чужой отчёт прямо там, где читает, без отдельного файла
- Удобно читать
- Каждая проблема на своей странице, между ними легко переключаться
Ещё одна вещь, которую раньше делали руками: порядок проблем. Если в отчёте уже есть красные и жёлтые, а по ходу проверки нашлась новая красная, расширение само переставит индексы и присоединит её к группе красных, чтобы отчёт не был рваным.
Пересортировка и перенумерация старых отчётов вручную отнимали массу сил и отвлекали от главного: внимательной проверки.
Нужны обезличенные скриншоты: регистрация проблемы, карточка, отчёт.
Внутренний инструмент в банке нельзя просто поставить. Я сам провёл расширение через аудит безопасной разработки и аудит поведения и добился выделенной группы виртуальных рабочих мест для команды. За три месяца от первой версии на новый формат перешла вся моя команда.
Продуктовые команды
Параллельно я рассказываю продуктовым командам, зачем приходить к нам с задачами на фронт-ревью. Сейчас задачи ставят все восемь продуктовых команд: часть приходит сама, часть по моей инициативе, и процесс ещё разворачивается.
Дизайн-система и платформенный фронт
Тем же инструментом я проверяю компоненты дизайн-системы на фронте. Отчёты уходят платформенным фронтенд-разработчикам, они правят по ним компоненты, а теперь и сами просят такие отчёты. Так формат отчёта вышел за пределы дизайна.
Руководство
Новый формат отчётов я показал руководству: интерес есть, решения о стандарте пока нет. Я регулярно приношу отчёты на встречи, чтобы формат стал привычным.
Моя роль
- Переформулировал задачу из «ускорить ревью» в процесс для всей корпорации.
- Собрал требования у дизайнеров разных команд и выпустил общие компоненты нотации.
- Спроектировал и написал расширение, сам провёл его через аудиты безопасности.
- Привёл в процесс продуктовые команды и платформенную разработку и продвигаю формат руководству.
Результат
Что дальше
Я договариваюсь о том, чтобы перевести на расширение тестировщиков. Это ещё 20–30 человек.
Что бы сделал иначе
- Дольше тестировал бы первую версию с коллегами до запуска.
- Сразу сделал бы интерфейс панелью: оверлей мешал проверять мобильную вёрстку.