Обзор
Компания: Piano — глобальная платформа для монетизации контента крупнейших мировых издательств.
Продукт: Cubit — B2B-платформа для управления доступом сотрудников к премиальным новостным ресурсам.
Роль: Единственный продуктовый дизайнер — UX-архитектура, UI, дизайн-система, визуальный QA.
Команда: 6 человек · Сроки: 11 месяцев, ~3 месяца на админ-интерфейс.
Задача
Полностью новый продукт с нуля. Без legacy-системы, без пользователей, без данных.
Основная сложность:
- Внутренняя валюта (Cubits) с двумя типами расходов — за прочтение статьи и обязательный месячный минимум за пользователя. Каждое действие админа влияет на бюджет
- Движок политик с 6 состояниями жизненного цикла, привязанными к биллинговым периодам
- Брендинг менялся дважды в процессе разработки — название, цвета, всё
- Все дизайн-решения основаны на доменном исследовании и работе с командой
Ключевые дизайн-решения
Всегда показывать стоимость. Главный вопрос админа: «Сколько это будет стоить?» Каждый экран отвечает на него.
При создании политики сайдбар показывает доступные Cubits, прогнозируемую стоимость и остаток — всё обновляется в реальном времени по мере изменений.
Создание политики — сайдбар с балансом Cubits и прогнозом стоимости
Pending Users — защита от неожиданных расходов
Автоматически синхронизированные сотрудники (через SCIM) могут незаметно увеличить расходы. Моё решение: новые пользователи попадают в статус Pending. Админ видит каждого и точное влияние на баланс Cubits перед подтверждением.
Pending users — подтверждение, пропуск или отклонение с разбивкой по Cubits
Конструктор аудиторий
Админ фильтрует пользователей по департаменту, должности или локации. Счётчик показывает сколько пользователей подходят под правила — вместе с превью стоимости это даёт полную картину до сохранения.
Конструктор правил — фильтрация по департаменту, должности, локации с количеством пользователей
Список политик
Политики могут быть в 6 состояниях, некоторые совмещённые (например Active + Scheduled Changes). Три таба — Active, Drafts, Archived — с дополнительными бейджами на каждой политике. 50 политик сканируются без открытия каждой.
Список политик — таб Active с бейджами “Scheduled changes” и “Grace period”
Детали политики — текущее vs. будущее
Когда у политики есть запланированные изменения, переключатель позволяет сравнить «Active state» и «Scheduled changes». Никаких догадок, что изменится и когда.
Детали политики — переключатель между текущим и будущим состоянием
Дизайн-система — когда всё меняется на ходу
30+ компонентов с нуля, плюс иконки и типографика — всё в характерном квадратном пиксельном стиле Cubit. Брендинг менялся дважды. Система выдержала, но без дизайн-токенов это стоило лишнего времени.
Библиотека компонентов — кнопки, таблицы, фильтры, иконки
Решения и компромиссы
- Pending-статус для SCIM-пользователей: безопасность бюджета важнее бесшовного онбординга.
- Изменения привязаны к биллинговым циклам: предсказуемость для enterprise важнее мгновенных изменений.
- 48-часовой grace period: баланс между исправлением ошибок и стабильностью системы.
- Превью стоимости на каждом действии: лучше показать лишнее, чем допустить сюрприз.
- Составные статус-бейджи: чистый список с информацией о сложном жизненном цикле.
Рефлексия
Первый опыт проектирования без пользовательских данных. Каждое решение строилось на доменной логике и работе с командой.
Что бы сделал иначе: поговорил бы с потенциальными пользователями до начала дизайна (хватило бы 3–5 звонков), внедрил бы дизайн-токены с первого дня и жёстче определил scope MVP, чтобы сократить развороты на ходу.