Вопросы на собеседовании: UI-дизайнер

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

• Я классифицирую все 60 кандидатов по назначению, состояниям, взаимодействию и поведению доступности, потому что одного визуального сходства недостаточно для эквивалентности компонентов.
• Компонент попадёт в общий слой, только если как минимум 2 из 3 продуктов требуют одинаковый контракт; сборки бизнес-сценариев, продуктовые тексты и правила данных останутся локальными.
• Общий слой будет владеть токенами, примитивами и контролами вроде Button или Select, а каждый продукт будет определять, как из этих контролов собираются пользовательские сценарии.
• Я подготовлю карту топологии, где каждому из 180 компонентов назначено решение оставить, объединить, обернуть или удалить, а также указаны каноническая замена и зависимости миграции.

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

• appearance принимает primary, secondary или tertiary, а size принимает small, medium или large, что даёт 3 на 3 поддерживаемых визуальных семейства вместо конкурирующих булевых пропсов.
• state принимает idle, loading или disabled, поэтому loading и disabled нельзя включить одновременно, а поведение клика определено для каждого состояния.
• Контент до и после текста передаётся через именованные слоты, а действие только с иконкой становится IconButton, потому что у него другой контракт доступного имени и геометрии.
• Набор компонентов Figma и матрица Storybook показывают 9 визуальных семейств в 3 рабочих состояниях, а типизированные пропсы отклоняют все неподдерживаемые сочетания.

Я заменю 30 именованных вариантов одним поведенческим ядром, явными возможностями и композициями на стороне продуктов.

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

Я переиспользую визуальные примитивы статусов, но оставлю InlineMessage, Banner и Toast отдельными публичными компонентами из-за разной длительности показа и разных контрактов взаимодействия.

• InlineMessage остаётся связанным с полем или областью контента, резервирует место в этой области и получает программную связь с элементом, когда объясняет ошибку.
• Banner участвует в компоновке страницы, остаётся до изменения условия или закрытия пользователем и может содержать действия восстановления для проблемы уровня страницы.
• Toast показывается ограниченное время и используется только для некритичного подтверждения; он не может содержать обязательное действие, а правила паузы, закрытия и озвучивания задаются явно.
• Я сопоставлю все 24 паттерна одному из 3 контрактов, перечислю общие примитивы иконок, цвета, типографики и отступов и отклоню любой вариант со смешанной семантикой.

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

• Tooltip содержит дополнительный неинтерактивный текст, открывается по наведению или фокусу после заданной задержки, закрывается по Escape и сам не получает фокус.
• Popover содержит интерактивный контент и задаёт начальный и возвратный фокус, закрытие по клику снаружи и Escape, а Menu использует модель списка действий с навигацией стрелками и поиском по первым символам.
• Я сопоставлю все 24 паттерна по триггеру, контенту, модели фокуса, клавиатурному управлению, закрытию и роли ARIA, а смешанные случаи заменю вместо добавления режимов в один плавающий компонент.
• Приёмка в Storybook покрывает мышь, клавиатуру, касание, открытое и закрытое состояния, возврат фокуса и ограничения вложенных слоёв для каждого из 3 публичных контрактов.

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

• Я использую пропс только для закрытого перечислимого выбора со стабильной анатомией и поведением, например размера или акцента.
• Я использую именованный слот, когда область и её ответственность остаются постоянными, но меняется контент, например ведущий визуальный элемент или действие в подвале.
• Я использую композицию, когда запрос объединяет существующие контролы в продуктовый сценарий, чтобы общий компонент не получал правила раскладки или бизнес-логику.
• Я создаю отдельный компонент, когда расходятся семантика, модель фокуса, владение состоянием или обязательная анатомия, а таблица классификации фиксирует один из этих 4 исходов для каждого из 14 запросов.

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

• Основа отвечает за portal, блокировку прокрутки, удержание и возврат фокуса, поведение фона, доступное название и Escape, но не владеет продуктовым контентом.
• Dialog поддерживает общий интерактивный контент, AlertDialog требует явного решения и безопасного правила начального фокуса, а Sheet добавляет привязку к краю, возможность перетаскивания и адаптивное закрытие.
• Я сопоставлю все 22 варианта этим 3 контрактам по назначению, модели фокуса, закрытию и анатомии; визуальное отличие станет свойством темы или размера, только если поведение не меняется.
• Релизный образец покрывает открытие, закрытие, длинный контент, вложенный триггер, ошибку и мобильные состояния, а одинаковые тесты основы переиспользуются всеми 3 компонентами.

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

• Оба пилота должны использовать одно семантическое ядро без импорта внутренностей и добавления продуктовых пропсов; любой обходной путь повторно открывает решение по API.
• Гейт beta требует документированных состояний, токенов, клавиатурного поведения, вывода скринридера, адаптивного поведения, а также тестов взаимодействия и визуальных тестов в Storybook.
• Статус stable требует, чтобы оба пилота прошли 1 релизный цикл без ломающего изменения контракта и с инструкциями по миграции для любого переименованного API.
• Оставшиеся 4 команды получают примеры и могут проверить применимость, но их внедрение не требуется для стабилизации контракта, уже проверенного 2 реальными потребителями.

Я задам 3 режима навигации с переходами по содержимому и проверю их во всём диапазоне от 320 до 1440 CSS px.

• Компактный режим сохраняет бренд, текущий раздел, основное действие и кнопку меню; промежуточный показывает приоритетные ссылки и overflow; расширенный показывает все основные ссылки.
• Container queries переключают режимы, когда измеренные подписи и действия перестают помещаться, вместо предположения, что одна ширина устройства подходит каждой локали.
• Матрица проверяет 320, 375, 768, 1024 и 1440 CSS px, а также масштаб 200%, длинные подписи, активное состояние, порядок клавиатурного обхода и открытое меню.
• Каждый режим сохраняет порядок разделов и доступные имена, использует цели размером не менее 44 на 44 CSS px и не допускает дублирующихся точек фокуса при переносе ссылок в overflow.

Я введу однонаправленные зависимости от паттернов к контролам и примитивам и удалю все 9 циклов до следующего релиза компонентов.

• Foundations содержит только токены, primitives низкоуровневую структуру, controls один контракт взаимодействия, а patterns собирает контролы, не импортируясь обратно в нижние слои.
• Каждый цикл я разорву выделением минимального общего примитива или переносом продуктовой композиции выше, а не маскировкой импорта ещё одним алиасом.
• Сгенерированный граф зависимостей перечисляет все 70 компонентов, их слой, прямые импорты, потребителей и путь цикла, а правила линтера запрещают импорты вверх по слоям.
• Релизный контроль требует ноль циклов, отсутствие импортов продуктовых пакетов в общую библиотеку и цель миграции для каждого публичного экспорта, перемещённого между слоями.

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

• Примитивы хранят исходные значения вроде color.brand.alpha.600, color.neutral.0 и space.200; в код компонентов они никогда не попадают.
• Семантические токены вроде color.text.primary, color.surface.canvas и color.action.primary связываются с примитивами для каждого бренда и режима и становятся публичным контрактом продуктов.
• Компонентные токены вроде button.primary.background.hover появляются только для устойчивой локальной потребности, которую нельзя выразить семантической ролью, и ссылаются на семантические токены, а не на исходные цвета.
• Сгенерированная матрица показывает каждый токен для Alpha и Beta в светлом, тёмном и высококонтрастном режимах; CI отклоняет пропущенные соответствия, циклы и неразрешённые ссылки.

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

• Манифест принимает brand из перечисления четырёх брендов и mode из light | dark | high-contrast; код во время выполнения отклоняет идентификаторы вне матрицы 4 на 3, а не незаметно подставляет запасную тему.
• Общие основы режимов задают нейтральные поверхности, текст, границы и состояния, а каждый бренд добавляет только утверждённые семантические переопределения; перед публикацией сборка вычисляет итоговые значения с учётом наследования.
• CI проверяет все семантические роли, контраст текста и нетекстовых элементов, состояния фокуса и визуальные снимки типовых контролов во всех 12 наборах.

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

• Для семантического токена color.text.brand я возьму ближайший утверждённый более светлый или тёмный оттенок, который даёт минимум 4,5:1 на каждом реальном фоне, и запишу проверенную пару в метаданные токена.
• Исходный цвет можно оставить в крупных заливках, иллюстрациях и декоративных акцентах; для значимых иконок и границ контролов всё равно нужен контраст минимум 3:1 с соседними цветами.
• Для крупного текста допустима пара 3:1 только при соответствии определению крупного текста в WCAG, а не просто потому, что в макете элемент назван заголовком.
• Автоматические проверки контраста проходят по каждому сочетанию бренда и режима, чтобы последующее изменение палитры не вернуло неудачную текстовую пару.

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

• Граф фиксирует каждый алиас, итоговое значение во всех поддерживаемых темах, число потребителей и путь разрешения, поэтому показывает неиспользуемые имена, дубли смысла и цепочки ради единичных переопределений.
• Я удалю алиасы без потребителей и объединю имена только при совпадении назначения и поведения во всех темах; одинаковые сейчас значения text.muted и border.subtle останутся разными, если у них разный смысл.
• Манифест миграции сопоставит каждому удаляемому имени замену или явное удаление, кодмод обновит потребителей в коде, а отчёт Figma перечислит затронутые переменные.

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

• Запрос должен показать независимое изменение свойства минимум в двух поддерживаемых темах и не менее чем в трёх продуктовых применениях компонента; одного макета или переопределения для одного бренда недостаточно.
• Каждый токен получает имя component.<name>.<property>.<state>, по умолчанию ссылается на существующую семантическую роль и документирует состояния, запасное значение и причину, по которой новая глобальная роль исказила бы смысл.
• CI показывает расход лимита 280 токенов и распределение по компонентам; превышение любого порога требует зафиксированного исключения с матрицей тем, отклонёнными вариантами и условием удаления.
• Лимит служит сигналом сложности, а не разрешением заполнить квоту, поэтому компоненты без доказанной независимой вариативности не получают локальных токенов.

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

• Канонические ID DTCG остаются в репозитории, а таблица соответствий связывает каждый из них с ID переменной, который создаёт Figma.
• После слияния сначала выполняются проверки схемы и алиасов, затем Style Dictionary собирает CSS-переменные и платформенные артефакты и публикует неизменяемый пакет.
• Если тариф и права разрешают запись через Variables API, авторизованный сервис синхронизации обновляет Figma и записывает хеш исходника; процесс не предполагает, что CI способен удалённо запустить настольный плагин.
• Проверка расхождений сравнивает ID DTCG, ID переменных Figma, итоговые значения и манифесты пакетов и отправляет уведомление, если пакет и Figma не синхронизированы за 30 минут.

Я буду публиковать один версионируемый релиз токенов с платформенными артефактами и манифестом совместимости для всех 40 потребителей.

• Мажорная версия удаляет или переименовывает токен либо меняет его тип или смысл, минорная добавляет обратно совместимые токены или темы, а патч исправляет значение без изменения документированного назначения.
• Сборка создаёт npm-пакет для веба, Swift Package для iOS, Maven-артефакт для Android и JSON с вычисленными значениями и CSS-совместимые значения для email; у всех один номер версии и хеш исходника.
• Каждый релиз содержит итоговые различия по темам, устаревшие токены с заменами и платформенные снимки; для несовместимого релиза также публикуются карта переименований и примеры миграции.
• Машиночитаемый реестр хранит диапазон версий, заявленный каждым из 40 потребителей, и блокирует удаление, пока любой поддерживаемый диапазон зависит от устаревшего контракта.

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

• Организация выбирает один из 2 брендов; выбор пользователя между светлым, тёмным и высококонтрастным режимами переопределяет системную цветовую настройку, а значение продукта применяется только при отсутствии обоих источников.
• Вычисленная тема задаётся атрибутами data-brand и data-mode на корневом элементе, а все компоненты используют семантические токены без условий по бренду или режиму.
• Серверный рендеринг или встроенный стартовый скрипт читает сохранённый выбор до применения CSS, поэтому перезагрузка, вход и смена организации не показывают кратко неверную тему из 6 вариантов.
• Матрица приёмки покрывает все 6 тем, пользовательское переопределение, сброс настройки, изменение системной темы, перезагрузку, вход и смену организации, а источник итогового значения виден при отладке.

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

• В исходнике будут elevation.base, elevation.raised, elevation.overlay и elevation.modal с правилами использования и наложения вместо общих значений тени.
• Веб сопоставит этим ролям последовательно усиливающиеся токены тени, границы и z-index, а Android сопоставит их с тональными ролями surface, surfaceContainerLow, surfaceContainerHigh и surfaceContainerHighest.
• Контрактные тесты проверят одинаковый порядок, перекрытие, оформление фокуса и контраст контента на обеих платформах, при этом визуальные снимки могут выглядеть по-разному.

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

• Каждый из 300 токенов обязан содержать стабильный ID, имя, тип, назначение, разрешённые и запрещённые контексты, статус и замену при устаревании; семантические и компонентные токены также описывают доступность и запасное поведение.
• Сгенерированная страница показывает цепочку алиасов, итоговое значение во всех 12 поддерживаемых темах, ссылку на переменную Figma и готовые для копирования имена токенов для веба, iOS, Android и email.
• Проверка схемы останавливает сборку при отсутствии обязательных метаданных, сломанных ссылках, дублирующихся ID или устаревшем токене без замены либо явной заметки об удалении.
• Генератор также создаёт доступный для поиска tokens-index.json и diff версий, чтобы документацию, заметки к релизу и платформенные пакеты можно было сверить по одному хешу исходника.