Вопросы на собеседовании: Продуктовый дизайнер

Я построю граф из четырёх слоёв: примитивы, семантика, компоненты и платформенные выходы, а бренды и темы оформлю режимами, а не копиями.

• DTCG JSON будет хранить нейтральные примитивы вроде color.blue.600 и шкалу отступов с шагом 8; продуктовый код не сможет обращаться к ним напрямую, что добавит один переход по ссылке, но не даст брендовым значениям просочиться в компоненты.
• Семантические токены вроде surface.default и text.danger будут разрешаться через 4 набора режимов бренд-тема, поэтому 2 бренда и 2 темы останутся одним контрактом вместо 4 скопированных библиотек.
• Компонентные токены появятся только для реальных исключений, например button.primary.background; я ограничу их квартальным ревью Token Taxonomy Matrix, потому что 300 компонентных ссылок сложнее поддерживать, чем 40 семантических.
• Style Dictionary соберёт CSS custom properties, значения Swift assets и Jetpack Compose, а CI проверит потерянные ссылки и снимки всех 12 комбинаций платформы, бренда и темы перед релизом.

Я разделю общий headless-календарь с моделью выбора и подключаемые правила предметной области, а не буду растягивать компонент продуктовыми флагами.

• DateRange Contract будет использовать календарные значения LocalDate и отдельно заданный часовой пояс продукта, а также указывать, включается ли конец диапазона; в бронировании 10-12 мая это 2 ночи, а в аналитике 3 отчётных дня.
• Интерфейс правил предоставит isDateSelectable, validateRange и normalizeRange; бронирование отклонит закрытую ночь, а аналитика день 91, без флага isBooking, связывающего пакет с продуктом.
• Слоты представления разделят клавиатурную навигацию, фокус и отрисовку месяцев, но бронирование добавит цены за ночь, а аналитика пресеты на 7 и 30 дней; цена решения, 2 тонкие обёртки вместо двух реализаций доступности.
• В Storybook будет 8 контрактных сценариев, включая переход на летнее время, закрытую ночь в середине и границу 90 дней, и те же сценарии запустятся в unit-тестах React перед minor-релизом.

Я сделаю прошедший ревью DTCG JSON источником релиза, а Figma Variables, платформенные пакеты и Storybook, генерируемыми потребителями.

• Проверка схемы будет валидировать имена, типы, ссылки и 4 режима бренд-тема при каждом изменении; прямые правки опубликованных коллекций Figma будут перезаписываться, что ограничивает спонтанность, но убирает неоднозначность двустороннего слияния.
• Style Dictionary соберёт CSS, Swift и Android из одного изменения, затем Figma Variables API обновит сопоставленные ID переменных, а не создаст новые при каждом запуске.
• Token Provenance Manifest зафиксирует путь DTCG, ID переменной Figma, версию пакета, checksum источника и URL сборки Storybook, поэтому расхождение можно будет проследить менее чем за 5 минут.
• CI остановит релиз при расхождении checksum или визуальных изменениях Chromatic без одобрения и сохранит SLA 30 минут; цена решения, поддержка одного сервиса синхронизации вместо 4 ручных передач.

Я введу несколько путей для вкладов и распределю сбор данных и реализацию, сохранив одобрение общего контракта за основной командой.

• Contribution RFC потребует 2 продуктовых примера, нерешённую потребность пользователя, состояния, данные о доступности, владельца разработки и ожидаемое повторное использование; исправление опечатки обойдёт этот путь, новый компонент нет.
• Один мейнтейнер будет еженедельно дежурить на триаже с SLA ответа 2 дня, а запросы попадут в категории быстрого исправления, расширения, экспериментального паттерна или отказа, чтобы 60-минутные ревью оставались для публичных API.
• Стабильному компоненту понадобятся голоса 2 из 3 мейнтейнеров и 1 внедряющего сквада; эксперимент можно выпустить после ревью 1 мейнтейнера, но он должен подтвердить использование в 2 сквадах за 2 релиза.
• Сквад-автор оплатит реализацию и документацию, а основная команда финальное ревью; это экономит дефицитное время мейнтейнеров, но добавляет автору около 20 процентов к сроку по сравнению с локальным компонентом.

Я выпущу новую major-версию с временным слоем совместимости и переведу 9 приложений контролируемыми волнами, а не одновременно.

• Версия 2.8 добавит предупреждения об устаревании, а 3.0 новый контракт FormField и временный адаптер старых props; поддержка двух путей 6 недель увеличит bundle, но позволит приложениям выкатываться независимо.
• Кодмод на jscodeshift и руководство по миграции покроют механические 80 процентов, оставив каждому приложению 2 инженерных дня на правила валидации и визуальное ревью, а не переименование props.
• Six-Week Migration Ledger укажет владельца, текущую версию, результат кодмода, статус контрактных тестов и дату релиза для всех 9 приложений, разбитых на волны из 2, 3 и 4 потребителей.
• Бейзлайны Chromatic и consumer-тесты будут блокировать каждую волну; я удалю адаптер только после прохождения 9 из 9 приложений и заранее объявлю фиксированную дату окончания поддержки версии 2.

Я вынесу в общее стабильные примитивы взаимодействия, а машину состояний из 5 шагов оставлю в продуктах, пока контракт предметной области действительно не станет общим.

• Дизайн-система будет владеть Stepper, FormSection, ValidationSummary, оболочкой сохранения и продолжения и поведением доступности, задокументированными в Storybook через состояния, а не правила магазина.
• Каждый продукт будет владеть своей машиной XState, вызовами API, ветками допуска, текстами и событиями аналитики; централизация этих 5 шагов сейчас свяжет один релиз с 3 владельцами предметных областей.
• Boundary Decision Record покажет владельцев и зависимости каждого слоя, включая правило, что продукт может собирать общие компоненты, но пакет дизайн-системы не может импортировать продуктовые схемы.
• Я вернусь к общему headless-процессу, только если 3 потребителя разделяют не менее 80 процентов переходов 2 квартала; временное дублирование оркестрации стоит кода, но дешевле ложной абстракции, замедляющей все 3 продукта.

Я оформлю каждое одобренное отклонение как прослеживаемый контракт со сроком пересмотра, связанный с точными поверхностями дизайна и кода.

• Каждая запись Deviation Register получит ID, ссылку на норму, юрисдикцию, затронутый токен или компонент, обоснование, риск, владельца, согласующих, дату введения, дату ревью и ссылку на доказательства со сроком хранения 7 лет.
• Статус будет меняться между предложено, одобрено, истекает, устранено и отклонено; для одобрения понадобятся Legal и владелец дизайн-системы, а напоминание придёт за 30 дней до ревью.
• Тот же ID отклонения появится в аннотации Figma и отдельной истории Storybook, поэтому аудитор перейдёт от правила FIN-DE-014 к выпущенному немецкому паттерну раскрытия без поиска в 4 инструментах.
• Локальное исключение станет общим вариантом, только если одинаковое поведение нужно минимум 2 юрисдикциям; реестр добавляет стоимость ревью, но не даёт правилу одного рынка навсегда усложнить всех потребителей.

Я покажу 3 измерения отдельно и только на подходящих продуктовых поверхностях, чтобы сильная метрика не скрывала слабую.

• Поддерживаемое покрытие будет равно числу правильно внедрённых системных паттернов, делённому на число подходящих паттернов, без документированных неподдерживаемых случаев; целевой уровень 85 процентов, а соответствие Figma и кода проверяется отдельно.
• Срок поставки сравнит медиану дней от одобренного дизайна до production для сопоставимой работы, например 12 дней до внедрения и 9 после, чтобы система не получила заслугу за более мелкие задачи.
• Дефекты будут считать визуальные, интерактивные ошибки и проблемы доступности по вине дизайн-системы на 100 релизов, с целью ниже 2 и отдельным показом каждого P1 вместо усреднения.
• Adoption Scorecard даст красный, жёлтый или зелёный статус каждому измерению без взвешенной суммы; классификация стоит каждому скваду около 2 часов в месяц, но не создаёт тщеславный балл из шумной телеметрии.

Я превращу входящие запросы в явное распределение мощности, а не в очередь, где каждый запрос незаметно становится проектом.

• Единая форма потребует нужное решение, затронутых пользователей, данные, причину срока, спонсора и формат помощи; неполные запросы пойдут в office hours, а не займут один из 4 WIP-слотов.
• Триаж 2 раза в неделю оценит вред пользователю, стратегическое повторное использование, жёсткость срока и объём, затем направит работу в срочную, плановую, консультацию, self-service или отказ с решением за 5 рабочих дней.
• Intake Capacity Board зарезервирует 20 процентов из 26 человеко-недель под неожиданные требования регулятора и ограничит работу 2 активными задачами на дизайнера, потому что 5 параллельных запросов только удлинят каждый цикл.
• Для 60 квартальных запросов я запланирую около 15 полных задач, 25 консультаций и 20 отложенных или отклонённых запросов, затем опубликую спрос, время ожидания и причины, чтобы дефицит финансировали, а не прятали в переработках.

Я сделаю единый неизменяемый Release Manifest контрактом, который связывает дизайн-ресурсы, код, документацию и обязанности по миграции одной версией.

• Манифест зафиксирует версию 4.6.0, ключ библиотеки Figma и ID публикации, версии npm, Swift и Android, checksum токенов, URL Storybook, статус релиза и время для прослеживаемости.
• Changelog разделит добавленное, изменённое, устаревшее, удалённое и исправленное, приложив визуальные различия Chromatic и ссылки на компоненты, чтобы 9 приложений оценили влияние без открытия Figma.
• Для каждого ломающего или устаревшего элемента будут указаны новый API, кодмод или ручные шаги, окно совместимости, версия удаления и владелец миграции; major-релиз не выйдет без этого контракта.
• Release candidate заморозит Figma и код, пройдёт визуальные и контрактные тесты, затем опубликует все артефакты в пределах 24 часов; заморозка замедляет правки в последний момент, но при сбое можно откатиться к предыдущему манифесту как к единому набору.

Я опубликую единый контракт семантических токенов, который одновременно определяет визуальный замысел, значения в реализации, поведение в локалях и режим уменьшенного движения.

• Роли типографики вроде body-sm и heading-lg задают семейство, начертание, размер, межстрочный интервал и стек запасных шрифтов, а роли отступов используют единую шкалу с шагом 4 px вместо значений для отдельных экранов.
• Набор фикстур для 6 локалей покрывает каждый компонент реальными строками, расширением текста на 30%, переносами, обрезкой и проверками запасных шрифтов на ширине 320 px и 1440 px.
• Каждый токен движения задает длительность, easing, свойство и назначение, а также соответствие для prefers-reduced-motion, которое убирает перемещение и сохраняет нужную обратную связь мгновенной сменой состояния или opacity-переходом на 100 мс.
• Переменные Figma и Style Dictionary используют одинаковые имена токенов, CI блокирует отсутствующие соответствия, а релизный артефакт фиксирует версию, владельца, исключения и инструкции по миграции.

Я разделю покрытие компонентов и сквозное качество сценариев, чтобы высокий средний балл не скрывал поломку критического пути.

• Для каждого из 140 выпущенных компонентов будет строка с обязательными состояниями, соответствием токенам, управлением с клавиатуры, семантикой для скринридера, отображением в 6 локалях, адаптивностью, владельцем, версией и открытым исключением.
• По каждому критерию я показываю число прошедших компонентов из 140, а любой дефект доступности или отсутствие состояния разрушительного действия считаю блокером, который нельзя скрыть усреднением.
• 10 критических сценариев запускаются как версионируемые проверки на ширине 320 px и 1440 px, во всех 6 локалях и с уменьшенным движением, с учетом завершения, визуальных регрессий, дефектов доступности и обходов системы.
• Ежемесячная оценочная карта содержит ссылки на доказательства в Storybook и тестовые прогоны, требует отсутствия блокеров во всех 10 из 10 сценариев и назначает каждому проваленному критерию владельца и срок.

Я привяжу дерево к точно определенному событию получения ценности и отделю диагностические шаги от самой активации.

• Доля активации равна числу подходящих новых пользователей, которые завершили настройку и первую ключевую задачу в течение 7 календарных дней после создания аккаунта, деленному на всех подходящих новых пользователей той же когорты регистрации.
• Дерево связывает соответствие условиям регистрации, начало настройки, завершение настройки, попытку первой задачи, успех первой задачи и активацию за 7 дней, с разрезами по каналу привлечения, локали, устройству и заявленной цели.
• До редизайна я фиксирую базовые значения каждого узла за 4 полные недели и провожу одну и ту же ключевую задачу со 100 репрезентативными новыми пользователями, определяя успех как завершение без помощи модератора за 5 минут.
• Документ измерения хранит определения событий, исключения, правило созревания 7-дневной когорты, сценарий юзабилити-теста, квоты сегментов, а также числитель и знаменатель базового значения, чтобы после запуска нельзя было переопределить успех.

Я определю каждую метрику checkout вокруг стабильного checkout_id и дам отложенным результатам достаточно времени для созревания.

• Недельные старты равны 100 000 уникальных checkout_id, дошедших до первого шага оплаты за неделю ISO, после исключения тестового, внутреннего и подтвержденного бот-трафика; повторные попытки сохраняют исходный checkout_id.
• Конверсия равна числу checkout_id с первым успешным списанием в течение 24 часов, деленному на все подходящие старты checkout, поэтому повторные списания не увеличивают конверсию.
• Доля двойных списаний равна числу завершенных checkout_id с более чем одним успешным списанием по одному заказу за 24 часа, деленному на checkout_id хотя бы с одним успешным списанием, а доля возвратов за 30 дней равна возвращенным завершенным заказам, деленным на завершенные заказы с полным 30-дневным окном наблюдения.
• Время завершения считается от первого показа шага оплаты до первого успешного списания и публикуется как медиана и 90-й перцентиль для сконвертированных checkout, рядом с долей незавершенных за 24 часа, чтобы показать смещение выживших.

Я сохраню единый протокол и переведу проценты в наблюдаемые результаты участников.

• Успех означает завершение фиксированной критической задачи без помощи модератора и без критической ошибки за 5 минут, поэтому база равна 70 из 120 участников, или 58,3%, а цель равна 90 из 120, или 75%.
• Базовый и повторный замеры используют одинаковые квоты сегментов, набор устройств, начальное состояние, инструкции, точность прототипа и правила модератора, а результаты каждого участника хранятся в таблице бенчмарка.
• Я показываю медиану и 90-й перцентиль времени успешных попыток, время до остановки для всех 120 попыток с ограничением неудач на 5 минутах и число критических ошибок на попытку по заранее написанной шкале серьезности.
• Я принимаю цель, только если успеха достигли не менее 90 из 120 участников, а медианное время и число критических ошибок на 120 попыток не ухудшились сверх заранее зарегистрированного допуска.

Я рассчитаю чистую пропускную способность по наблюдаемой обработке кейсов и назову ее экономией только тогда, когда организация действительно может использовать или сократить эту мощность.

• Сокращение на 2 минуты для 20 000 подходящих кейсов дает 40 000 минут, или 666,7 часа валовой рабочей мощности в месяц, до вычета времени на новые проверки, обучение и обработку исключений.
• Мощность от снижения доработок считается как 20 000, умноженные на разницу между базовой и новой долей доработок, а затем на проверенное время одной доработки; снижение с 8% до 5% при 12 минутах добавляет 7 200 минут, или 120 часов.
• В этом примере месячная мощность равна 786,7 часа, которые переводятся в кейсы по новому медианному времени обработки и в стоимость по полной часовой стоимости труда.
• Реестр эффекта разделяет денежную экономию и перераспределенную мощность, фиксирует состав кейсов и защитные метрики качества и требует 8 полных недель после запуска до пересчета результата на год.

Я сделаю взаимный вклад метрикой ценности, а приглашения оставлю диагностикой верхней части воронки.

• Подходящая пара появляется, когда один участник приглашает другого к общему объекту, причем каждая неупорядоченная пара участников считается один раз даже при нескольких приглашениях.
• Доля взаимного вклада за 7 дней равна числу принявших приглашение пар, где оба разных участника внесли хотя бы один значимый вклад в течение 7 календарных дней после принятия, деленному на все принявшие приглашение подходящие пары.
• Значимым вкладом считается редактирование, содержательный комментарий, назначение задачи или закрытие вопроса в общем объекте; просмотры, реакции, автоматические изменения и дублирующие комментарии не учитываются.
• Я сегментирую результат по размеру команды и новым либо существующим связям, а затем отслеживаю вклад с 8-го по 30-й день, отклонения приглашений, блокировки и жалобы на злоупотребления, чтобы выявить поверхностную или навязанную совместную работу.

Я оставлю кликабельность диагностикой, а качество рекомендации буду оценивать по устойчивому результату после принятия.

• Кликабельность равна числу показов рекомендации с кликом, деленному на все подходящие показы, с дедупликацией до одного показа на рекомендацию, пользователя и сессию.
• Доля принятого результата за 14 дней равна числу показов, после которых пользователь принял рекомендацию, выполнил целевое действие и сохранил результат на 14 дней, деленному на все подходящие показы.
• Доля отмен равна числу принятых рекомендаций, которые отменили, откатили или вручную заменили в течение 14 дней, деленному на все принятые рекомендации с созревшим 14-дневным окном.
• Доля сожаления равна числу созревших принятых рекомендаций с явной отметкой о бесполезности или оценкой сожаления 1 либо 2 из 5 за 14 дней, деленному на принятые рекомендации, для которых была соответствующая возможность оставить отзыв.

Я буду считать активацию опережающей метрикой, а 30-дневное удержание контрметрикой устойчивой ценности, после чего проверю, изменил ли онбординг состав активированных пользователей или смысл активации.

• Активация остается числом активированных подходящих регистраций, деленным на все подходящие регистрации за 7 дней, а 30-дневное удержание равно активированным пользователям, выполнившим ключевую задачу с 30-го по 36-й день, деленным на активированных пользователей с полностью созревшим окном удержания.
• Я сравниваю когорты до изменения, после изменения и из рандомизированной контрольной группы, если она есть, внутри одинаковых каналов привлечения, локалей, устройств, заявленных целей, недель регистрации и правил соответствия вместо общих трендов.
• Я проверяю определения событий и сбор данных, затем раскладываю путь на завершение настройки, первую ключевую задачу, повторную ключевую задачу, время до второго использования и удержание, чтобы найти место разрыва связи.
• Я использую контрольную группу или поэтапный когортный тест для оценки причинности и меняю критерий активации, если он предсказывает поверхностное завершение, сохраняя привязку решения о раскатке к заранее согласованному порогу удержания, а не к реакции на инцидент.

Я зарегистрирую одну гипотезу конверсии и три порога вреда до начала эксперимента, чтобы команда не могла оправдать вредный выигрыш после получения результатов.

• Основная метрика равна завершенным заказам за 24 часа, деленным на подходящие уникальные старты checkout, с целью не менее 3% относительного роста за 14 полных дней и анализом по назначенному варианту.
• Доля жалоб на checkout равна числу уникальных подтвержденных жалоб в течение 7 дней, деленному на завершенные заказы, с порогом остановки при абсолютном росте на 0,20 процентного пункта, когда 95% доверительный интервал исключает ноль.
• Доля обращений в поддержку равна пользователям хотя бы с одним обращением с тегом checkout за 7 дней, деленным на завершенные заказы, с порогом остановки при относительном росте на 5%, а доля возвратов за 30 дней равна возвращенным заказам, деленным на завершенные заказы с созревшим 30-дневным окном, при абсолютном лимите 0,30 процентного пункта.
• Предварительная регистрация фиксирует исключения, правило размера выборки, запросы событий, разрезы сегментов, пороги и логику решения, а выпуск требует достижения цели конверсии и прохождения всех 3 ограничителей после созревания их окон.