Превращать постановку в решение
На два каталога приходились два продакт-менеджера и три аналитика. Я разбирал их постановки и готовил сценарии, макеты и правила реализации для трёх фиче-команд.
- Продуктовый каталог
- Создание и состав продуктов и услуг: мастер, вложенные продукты, бандлы.
- Контентный каталог
- Описания и медиа, которые используются на витринах.
В мастере создания и составе продукта я уточнял логику вместе с аналитиками: какие данные нужны на каждом шаге и как интерфейс реагирует на выбор. Например, в рабочих вопросах разбирал, нужно ли показывать описание вложенного продукта и где его редактировать.
Проверять поведение до спринта
Спорные переходы между экранами и сценарии выбора требовали обсуждения с командой. По отдельным макетам было трудно проверить весь путь до начала разработки.
Я собирал интерактивные прототипы в Figma Make и обсуждал их с командой до разработки. Часть гипотез отбрасывали на этом этапе.
Затем я запустил практику быстрого прототипирования в трайбе и обучал дизайнеров работе с Figma Make и AI.
Передавать решение вместе с состояниями
Разработчики получали макеты без части пустых списков, ошибок и промежуточных загрузок. Вопросы появлялись в середине спринта, когда решение уже реализовывалось. При одном дизайнере на три команды эти пробелы создавали дополнительный поток уточнений.
Я ввёл стандарт передачи: компоненты описываются с набором состояний, крайние случаи записаны в файле. Унифицировал структуру Figma-файлов, чтобы нужный макет находился по задаче.
Добавить услугу в пакет
Услуга для добавления в состав пакета
Правило передачи
Показать доступную запись. После выбора подтвердить действие и сохранить выбранное значение.
Что передаётся вместе с макетом
- Поведение
- Состояния компонента и переходы между ними.
- Крайние случаи
- Пустой результат, ошибка, загрузка и недоступное действие.
- Контекст задачи
- Задача и нужный макет в единой структуре файла.
Результат двух изменений
−15% доработок при реализации
Быстрое прототипирование и стандарт передачи вместе сократили доработки со стороны разработки на 15%. Вклад каждого изменения отдельно не измерялся.
Метод подсчёта и период сравнения ещё восстанавливаю.
Следующий шаг в измерении — разделить возвраты задач по причинам: непроверенный сценарий, пропущенное состояние, неясное требование или ограничение реализации. Так можно было бы понять вклад каждого изменения.
Описание продукта: разбор по рабочим заметкам
Проблема взята из моих рабочих вопросов. Развязка и интерфейс реконструированы для этого разбора; внедрение не подтверждено.
В продукте оставались «описание» и «краткое описание», а новый текст для витрины должен был приходить из контентного каталога. В заметках я спрашивал: скрыть старые поля или оставить для сравнения? Копировать новый текст или показывать источник?
Для разбора я выбрал предпросмотр опубликованного текста со ссылкой на источник. Описание редактируется в контентном каталоге; черновик не меняет текст на витрине. Старые значения остаются для сравнения.
Какой текст увидит клиент?
Создайте черновик, отключите связь и попробуйте опубликовать изменение.
Контентный каталог
Источник доступен
- Краткое описание
- Домашний интернет с роутером в аренду.
- Полное описание
- Подключение по адресу после проверки доступности. Аренда роутера оплачивается отдельно.
Предпросмотр в продуктовом каталоге
Веб-витрина · русский язык
- Краткое описание
- Домашний интернет с роутером в аренду.
- Полное описание
- Подключение по адресу после проверки доступности. Аренда роутера оплачивается отдельно.
Один источник текста. Изменять описание нужно в контентном каталоге.
Старое описание · для сравнения
Домашний интернет. Роутер входит в пакет.
Альтернативы и ограничения
- Копировать текст в продукт
- Подходит как переходный вариант, если API требует старые поля. Цена — правила синхронизации и разрешения конфликтов после локального редактирования.
- Убрать поля и оставить ссылку
- Достаточно, если описание проверяют редко. Нужно переходить в другую систему; старые значения можно сохранить отдельно для сравнения.
- Связать с источником и показать публикацию
- Удобно для частой сверки. Потребуются интеграция, устойчивые идентификаторы, права доступа и правила публикации для каждой витрины и языка.
Условия реализации
- Старые данные
- Сохранить для сравнения. Скрытие полей в форме не означает удаление из модели: сначала проверить обязательность в API и остальных потребителей.
- Состав и бандлы
- Просмотр вложенного продукта не должен превращаться во второе место редактирования его текста. Наследование и переопределения нужно согласовать отдельно.
- Сбой источника
- Предложенный предпросмотр сохраняет последнюю полученную публикацию с предупреждением об актуальности. Поведение реальной витрины при сбое требует отдельного соглашения с разработкой.
Для проверки предложил бы пройти путь от черновика до публикации и объяснить, какой текст сейчас видит клиент. Отдельно проверить потерю связи и продукт без контента: ему нужен явный статус «Описание ещё не опубликовано».
На чём основана реконструкция
Паттерны сверены с актуальной документацией; эти источники не описывают реализацию МТС.