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

Сначала я соберу инвентарь на основе данных, а затем решу, что объединять, вместо оценки 180 компонентов только по визуальному сходству.

• Выгружу аналитику библиотеки Figma и проверю Storybook и кодовую базу, зафиксировав в одной таблице ключ компонента, пакет, владельца, использование за 90 дней и продукты-потребители.
• Сравню три выбора даты как контракты взаимодействия: клавиатуру, форматы локалей, выбор диапазона, валидацию, мобильное поведение и все 12 ожидаемых состояний, а не только скриншоты.
• Глубоко проверю 30 самых используемых компонентов и все компоненты в 15 критических сценариях; равная проверка всех 180 потратит 10 дней на низкорисковый инвентарь вместо пользовательских рисков.
• Для каждого элемента вынесу решение сохранить, объединить, вывести или исследовать, указав долю дублей, число бесхозных компонентов, владельца и срок в отчёте.

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

• Один раз задам примитивы вроде blue.600, gray.950 и space.200; они образуют палитру значений, но никогда не используются напрямую в стилях компонентов.
• Сопоставлю семантику вроде surface.default, text.muted и border.danger с каждой из шести комбинаций бренда и режима, чтобы кнопка использовала одно имя вместо шести цветовых веток.
• Добавлю алиасы компонентов вроде button.primary.background, только если общий семантический токен не выражает реальный контракт; дополнительный слой стоит поддержки, поэтому алиасы не нужны для каждого свойства.
• Буду версионировать сопоставления в DTCG JSON и проверять контраст всех шести тем в CI, останавливая релиз, если текстовые пары не проходят согласованный порог WCAG AA.

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

• Перенесу решение в компонент, если у него одна ограниченная задача, переиспользуемые состояния, нейтральный к домену контент и минимум три подтверждённых применения, например общий контрол загрузки документов.
• Оставлю оркестрацию локальной, если она содержит политику проверки, последовательность API, права или восстановление на семи шагах; эти правила принадлежат продуктовому домену, а не общему API компонента.
• Проверю предлагаемый API в прототипе Storybook: больше нескольких условных флагов или взаимоисключающих свойств указывает, что система кодирует несколько продуктовых сценариев.
• Зафиксирую решение в одностраничном документе о границах с контрактами компонентов, локальным рецептом паттерна, исключёнными задачами и данными для будущего пересмотра.

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

• Дам каждому токену стабильный ID и свяжу его с коллекцией, переменной и режимом Figma через Variables API или одобренный плагин, чтобы переименование подписи не ломало связь с кодом.
• Style Dictionary будет выпускать CSS custom properties, TypeScript, iOS и Android артефакты из одной схемы, а преобразования единиц и размеров останутся в репозитории токенов.
• В CI буду отклонять отсутствующие ссылки, циклические алиасы, неверные единицы, проблемы контраста и удаления значений без ревью; затем Chromatic проверит показательные компоненты во всех режимах тем.
• Опубликую semver-пакет токенов и соответствующее обновление Figma-библиотеки с одним ID релиза и changelog, приняв короткую блокировку релиза ради синхронности версий у дизайна и разработки.

Я выпущу новый контракт как major-версию и оставлю измеряемое окно совместимости для 12 потребителей.

• Через поиск по коду и отчёты зависимостей перечислю все места вызова модального окна по командам, критическим сценариям и неподдерживаемым свойствам, затем назначу каждой строке владельца и неделю миграции.
• Выпущу codemod, примеры до и после и временный адаптер для распространённого старого API; адаптер добавляет второй путь тестирования, поэтому его срок закончится через восемь недель.
• Во вторую неделю проведу canary с двумя командами, проверю клавиатуру, фокус, визуал и потребительские контракты, затем переведу остальные команды тремя недельными волнами.
• Удалю старый контракт, только когда доска покажет ноль старых импортов у всех 12 команд, откат будет проверен, а дата отключения появится в двух выпусках release notes.

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

• Включу пять реальных сценариев, текущие обходные пути, влияние на пользователей, исключённые задачи и решение о том, какие правила сортировки, выбора, пагинации и массовых действий действительно общие.
• Приложу анатомию, матрицы состояний и прав, адаптивное поведение, правила контента и доступность клавиатуры, фокуса, заголовков и объявлений скринридера.
• Подготовлю Figma-прототип и кодовый прототип в Storybook с реалистичными строками, пустыми состояниями, пагинацией 10 000 элементов и одним сбоем массового действия вместо отполированного успешного пути.
• Завершу RFC предлагаемым API, владельцами, ценой пакета, метриками внедрения, открытыми рисками и пятидневным окном ревью в журнале решений.

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

• Опишу в руководстве три пути: исправление документации или токенов, совместимое расширение компонента и новый компонент, для каждого будут свои требования к данным и ревьюерам.
• Направлю предложения через GitHub-шаблон и задам срок триажа в два рабочих дня; каждое расширение проверят один участник основной команды и один эксперт продуктового домена вместо всего совета.
• Сделаю CODEOWNERS, Storybook, тесты доступности, визуальную регрессию и релизный чеклист условиями мержа, чтобы качество обеспечивали артефакты, а не повторяющиеся встречи согласования.
• Соберу ротацию контрибьюторов из 20 команд и обяжу команду-автора поддерживать добавление 90 дней; это создаёт локальную нагрузку, но не оставляет основной четвёрке все крайние случаи.

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

• Сохраню каждое исключение в версионируемом YAML-реестре с компонентом, продуктом, незакрытой потребностью, пользовательскими данными, владельцем, затронутыми маршрутами, расположением форка, датой одобрения и сроком действия.
• Предпочту локальную обёртку над поддерживаемым пакетом копированию исходников, потому что обёртка получает обновления безопасности и доступности, а форк создаёт вторую линию поддержки.
• Дам временным отклонениям 90 дней и потребую тесты против исходного контракта; просроченная запись заблокирует следующий релиз до продления, миграции или удаления.
• Буду ежемесячно разбирать реестр и открою общий RFC, когда три исключения сгруппируются вокруг одной потребности, но сохраню отдельный форк для устойчивого регуляторного поведения с явным финансированием.

Я покажу внедрение как поддерживаемое использование вместе с результатами скорости и качества, а не как число установок пакета или компонентов.

• Измерю долю подходящего интерфейса из поддерживаемых пакетов и связанных Figma-ресурсов по критическим сценариям и командам; до заявления о широком внедрении буду ждать 80 процентов покрытия.
• Сравню медианное время от дизайна до production для повторяемых паттернов с базовой линией по Jira и Git, ожидая заметного сокращения, например с 12 до 8 дней.
• Буду отслеживать дефекты доступности и визуальной согласованности на релиз, пропущенные дефекты компонентов и время исправления, потому что ускорение с ростом ошибок не является победой системы.
• Добавлю в дашборд задержку обновлений, активные форки, просроченные исключения, срок обработки контрибьюций и месячных активных потребителей, чтобы покрытие не скрывало устаревшее или неподдерживаемое использование.

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

• В первые две недели распределю все 420 использований по командам, критическим сценариям, готовности замены и сложности, затем опубликую таблицу прогресса с одним ответственным за каждую группу миграции.
• В первом квартале запрещу новые старые импорты через ESLint, предоставлю codemod и обёртки совместимости, проверю процесс на двух командах и переведу остальных четырьмя волнами по уровню риска.
• Буду поддерживать обе библиотеки только в окне миграции; параллельная поддержка удваивает визуальный контроль и релизную работу, поэтому обёртки и старые исправления получат явные даты отключения.
• Во втором квартале уберу старые Figma-ресурсы из публикации, подтвержу ноль импортов в runtime и паритет критических сценариев, отрепетирую откат и архивирую пакет после подписания отчёта всеми 16 владельцами.

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

• В Storybook каждое состояние должно проходить axe без серьёзных и критических нарушений, включая ошибку, недоступность, выбранную дату и режим высокой контрастности.
• Ревьюер проверяет полный выбор даты с клавиатуры и в NVDA с Chrome: порядок и видимость фокуса, подписи, объявления и выход по Escape согласно WCAG 2.2 AA.
• Контракт компонента требует цели размером не менее 24 на 24 CSS-пикселя или достаточных отступов, контраст текста 4,5:1, контраст контролов 3:1 и отсутствие перекрытого фокуса.
• Владелец доступности дизайн-системы подписывает релиз; исключение содержит критерии, продуктовый риск, компенсацию, владельца и срок не более 30 дней.

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

• Спецификация в Figma задаёт перестроение на ширине контейнера 320, 768 и 1440 пикселей, гибкие области подписи и ошибки и запрещает фиксированную высоту, обрезающую переносы.
• Storybook показывает каждое состояние на en, ru, fr, de, pt и es, а также фикстуру с увеличением текста на 50 процентов и длинными датами, именами и десятичными форматами.
• Контракт фиксирует правила сокращения, минимальные размеры касания, перенос подписи и ошибки, порядок контролов и контент, который можно свернуть ниже 320 пикселей.
• CI снимает матрицу локалей и размеров, а владелец компонента блокирует публикацию при наложении текста, потере смысла или изменении порядка фокуса после перестроения.

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

• В запросе обязательны пользовательская проблема, затронутые продукты, доказательства, текущий обходной путь, срок релиза, риск доступности или регулирования и партнёр со стороны разработки.
• На еженедельном 30-минутном триаже охват, тяжесть, переиспользование между продуктами и цена задержки получают оценку от 1 до 5, после чего вычитаются трудозатраты на дизайн и миграцию.
• На квартал я оставляю 60 процентов ресурса для общей работы с наивысшим баллом, 25 процентов для проверенных вкладов продуктовых команд и 15 процентов для срочных дефектов доступности или production.
• Открытый журнал показывает принятые, делегированные, требующие данных и отклонённые запросы с владельцем и датой пересмотра; должность автора запроса не меняет балл.

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

• Только четыре мейнтейнера дизайн-системы получают права редактирования и публикации основной библиотеки; продуктовые дизайнеры предлагают изменения в ветках, связанных с intake-тикетом.
• Ветку должны проверить один мейнтейнер дизайн-системы и владелец инженерного компонента, а в ревью перечисляются изменённые варианты, токены, поведение доступности и влияние миграции.
• Один мейнтейнер становится владельцем релиза, объединяет одобренные ветки в плановое еженедельное окно, публикует именованную версию и пишет описание релиза Figma и заметку о миграции.
• Экстренная публикация требует второго мейнтейнера, ссылки на инцидент и разбора на следующий рабочий день; квартальный аудит прав удаляет устаревшие доступы редакторов и публикаторов.

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

• Критические компоненты покрывают обычное состояние, наведение, фокус, ошибку, недоступность, загрузку и высокую контрастность на ширине 320, 768 и 1440 пикселей.
• Для обычных историй я сохраняю порог Chromatic 0,063 и допускаю максимум 0,1 только для документированного сглаживания, но никогда для сокрытия сдвига вёрстки.
• Любое найденное изменение критического состояния блокирует pull request, пока мейнтейнер дизайн-системы и инженер компонента не примут новую базовую линию; неизменённые истории ручного ревью не требуют.
• Шрифты, даты, анимация и тестовые данные фиксируются в CI, а ежемесячный отчёт о шуме устраняет нестабильные истории вместо постоянного расширения порогов.

Я введу единый intake по уровню риска с SLA на три рабочих дня для триажа до обещания сроков исследования.

• Форма фиксирует предстоящее решение, дедлайн, цену ошибки, существующие данные, целевых участников, предположение о методе и человека, который применит результат.
• На еженедельном триаже исследователи оценивают риск решения, обратимость, пробел в данных и сложность рекрутинга, а затем объединяют повторяющиеся вопросы сквадов.
• Я выделяю 70 процентов ресурса плановым решениям высокого риска, 20 процентов межкомандным стратегическим исследованиям и 10 процентов срочным проблемам; низкорисковые вопросы юзабилити получают шаблоны и еженедельные консультации.
• Доска intake показывает принятую работу, исследователя, дату готовности данных, переведённые в self-service и отклонённые запросы, а срочные конфликты эскалируются лиду исследований.

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

• В оценке безопасность и конфиденциальность весят 35 процентов, находимость и происхождение данных 25, управление и права 20, миграция и экспорт 10, стоимость за три года 10.
• Поставщики вроде Dovetail и Condens должны показать SSO, ролевой доступ, экспорт аудита, процессы хранения, ограничения согласия, варианты регионального размещения и полный массовый экспорт без привязки к закрытому формату.
• Мы пилотируем 50 исследований за пять лет с тремя типами согласия, затем просим 10 исследователей и продуктовых партнёров найти данные для реальных решений и определить недоступные им материалы.
• Владелец Research Ops выбирает инструмент, только если закрытые исследования остаются закрытыми, просроченные материалы удаляются с подтверждением, а 80 процентов пилотных поисков находят полезные данные за три минуты.

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

• Каждое приглашение и участие записывается в одну карточку панели; пользователь не получает новое приглашение 90 дней и участвует не более чем в двух исследованиях за любые шесть месяцев.
• Выборка начинается с квот сегментов конкретного решения, затем случайно выбирает доступных пользователей вместо самых быстрых респондентов или одних и тех же опытных клиентов.
• Intake проверяет прошлые исследования до рекрутинга, поэтому сквад должен показать незакрытый пробел в данных, а не повторять уже отвеченный в хранилище вопрос.
• Research Ops ежемесячно отслеживает отписки, неответы, отмены и объём приглашений по сегментам, исключая когорты, где доля отписок превышает базовую линию панели на 50 процентов.

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

• Research Ops подтверждает реализуемость и согласует скринер за два рабочих дня, включая размер компании, права администратора, недавний опыт задачи, конфликты и квоты.
• Параллельно рекрутируем через согласованные клиентские списки customer success, сообщества поддержки и администраторов и одного проверенного поставщика B2B-панели с вознаграждением от 150 до 250 долларов по уровню роли и рынку.
• Первые два подходящих профиля должны быть готовы к 7-му рабочему дню, а все шесть сессий к 15-му; если к 5-му дню найдено меньше двух, исследователь и владелец сквада пересматривают охват и каналы.
• Эскалация предлагает продление до 20 рабочих дней, расширение документированного некритичного критерия или уменьшение выборки с более узкими выводами, но не давление продаж на клиентов.

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

• При создании исследования обязательные поля Dovetail фиксируют границы согласия, разрешённые аудитории, наличие записи, способ отзыва, класс хранения и дату удаления до загрузки данных.
• Прямые идентификаторы и формы согласия остаются в закрытом проекте; в заметках имена заменяются ID участников, а исходные записи удаляются через 30 дней после анализа, если согласие и политика не разрешают больший срок.
• Ежемесячная очередь сроков назначает задачи удаления, фиксирует удалившего каждую запись, транскрипт, экспорт и ссылку на резервную копию и закрывает запросы на отзыв в течение 30 календарных дней.
• Data steward ежеквартально проверяет выборку из 10 процентов исследований по доступу, согласию, хранению и доказательствам удаления, сообщает нарушения Privacy и хранит неизменяемый экспорт аудита два года.