Разбор собеседования
Собеседование на UX/UI-дизайнера: вопросы, ответы и разбор
Собеседование на UX/UI-дизайнера почти всегда строится вокруг портфолио: вас попросят открыть конкретные проекты и объяснить решения, а не просто показать красивые макеты. Отдельная сложность в том, что оценивают одновременно два разных навыка: насколько вы понимаете пользователя и бизнес-задачу (UX) и насколько аккуратно и системно собираете интерфейс (UI). Часто добавляют тестовое задание или блиц-редизайн экрана прямо на встрече. Дальше разберём, из каких этапов состоит собеседование, какие вопросы задают про процесс работы и как показать, что вы думаете не только про внешний вид, а про задачу целиком.
Пройдите собеседование с ИИ по этой профессии
ИИ задаст вопросы по роли «UX/UI-дизайнер», выслушает ответы голосом и покажет, где не хватило фактов. Первый персональный разбор бесплатно, без регистрации.
Пройти собеседование с ИИДолжность подставится автоматически. Резюме и описание вакансии можно не загружать.
Как обычно проходит встреча
Знакомство и рассказ о опыте10 до 15 минут
Рекрутер или дизайн-лид спрашивает, с какими продуктами вы работали, в какой роли были в команде и какой стек инструментов используете. Здесь же уточняют формат работы: были вы единственным дизайнером или частью команды с разделением на UX-исследователей и UI.
Разбор портфолио30 до 45 минут
Вас просят открыть два-три проекта на экране и рассказать про них: какая была задача, какие ограничения, почему выбрано именно это решение, что показали метрики или тесты после запуска. Интервьюер задаёт уточняющие вопросы по ходу, может попросить показать альтернативные варианты, которые вы отклонили.
Практическая часть: кейс или блиц-задача30 до 60 минут
Дают короткую задачу: спроектировать экран, поправить существующий интерфейс или провести быстрый юзабилити-разбор чужого приложения. Иногда просят порисовать вживую в Figma с шерингом экрана, иногда дают асинхронное тестовое на несколько дней.
Обсуждение процесса и инструментов15 до 20 минут
Спрашивают, как вы взаимодействуете с продакт-менеджером и разработчиками, как передаёте макеты в разработку, ведёте ли дизайн-систему, как проверяете гипотезы до того, как тратить время на финальные макеты.
Вопросы кандидата и обсуждение условий10 до 15 минут
Обсуждают формат работы, состав команды, инструменты, ожидания по загрузке и то, на каком этапе продукта находится компания сейчас.
Что на самом деле оценивают
Обоснованность решений
Работодателю важно, что за каждым элементом интерфейса стоит причина, а не личный вкус. Проверяют, умеете ли вы объяснить выбор через задачу пользователя и данные.
Владение инструментами
Figma, компонентный подход, прототипирование, работа с дизайн-токенами. Если человек путается в базовых вещах в реальном времени, это заметно сразу.
Понимание ограничений разработки
Дизайнер, который рисует нереализуемые в срок интерфейсы, создаёт проблемы всей команде. Спрашивают про опыт передачи макетов и работу с существующей дизайн-системой.
Умение работать с обратной связью
Продукт почти всегда переделывают несколько раз. Смотрят, как кандидат реагирует на критику макета прямо на собеседовании: спорит, защищается или разбирается в аргументах.
Системность мышления
Способность видеть не отдельный экран, а весь путь пользователя и последствия изменения одного элемента для остальных сценариев.
Вопросы и разбор ответов
1Расскажите про проект из портфолио, которым вы больше всего гордитесь
Что проверяют. Умение структурированно излагать процесс: задача, ограничения, решение, результат. Проверяют, ваша ли это была работа целиком или только визуальная часть.
Слабый ответ
«Вот тут я сделал приложение для доставки еды, мне очень нравится, как получилось визуально». Ответ описывает только внешний вид и не объясняет, какая была задача и почему выбрано именно такое решение.
Сильный ответ
Опишите проект по схеме: какая была бизнес-задача, какие ограничения были по срокам и техническим возможностям, какие альтернативы вы рассматривали и почему отказались, что получилось в итоге. Если есть метрики после запуска, например снижение отказов на этапе оформления заказа, назовите их. Если метрик нет, честно скажите, что не отслеживали, и объясните, как бы вы это сделали.
2Как вы понимаете, что интерфейс получился удобным, до того как его протестировали пользователи
Что проверяют. Знание эвристик юзабилити и умение применять их на практике, а не только по учебнику.
Слабый ответ
«Я стараюсь делать интуитивно понятно». Слово «интуитивно» ничего не объясняет и не показывает конкретный метод проверки.
Сильный ответ
Назовите конкретные методы: прогон по эвристикам Нильсена, проверка контраста и размеров тач-зон, коридорное тестирование на коллегах, просмотр макета в разных состояниях (пустое, ошибка, загрузка). Приведите пример, как один из этих методов реально помог найти проблему до запуска в разработку.
3Опишите ситуацию, когда ваше дизайнерское решение противоречило мнению продакт-менеджера или разработчика
Что проверяют. Способность аргументировать позицию и идти на компромисс без перехода в личный конфликт.
Слабый ответ
«Обычно я настаиваю на своём, потому что я дизайнер и лучше знаю, как должно выглядеть». Такой ответ настораживает: он показывает неготовность работать в команде и слушать ограничения других специалистов.
Сильный ответ
Опишите конкретный спор: например, разработчик говорил, что реализация анимации займёт слишком много времени. Расскажите, как вы предложили упрощённый вариант, сохранив суть UX-решения, показали данные или пример конкурента в поддержку своей позиции и в итоге нашли компромисс, который устроил обе стороны.
4Как вы работаете с дизайн-системой: создаёте её сами или используете готовую
Что проверяют. Опыт системного подхода к интерфейсу, а не сборки экранов из отдельных элементов каждый раз заново.
Слабый ответ
«Я просто копирую элементы с предыдущих экранов, чтобы было похоже». Такой подход не масштабируется и создаёт несогласованность интерфейса при росте продукта.
Сильный ответ
Расскажите, работали ли вы с готовой библиотекой компонентов или строили её с нуля: как определяли токены (цвета, отступы, типографику), как документировали компоненты для разработчиков, как поддерживали систему в актуальном состоянии при добавлении новых экранов.
5Как передаёте макеты в разработку
Что проверяют. Понимание процесса до конца, не только до момента сдачи красивого макета.
Слабый ответ
«Просто отправляю ссылку на Figma и всё». Ответ не показывает, как кандидат снимает вопросы разработчиков и следит за соответствием результата макету.
Сильный ответ
Опишите процесс: подготовка макета в режиме инспектирования, указание отступов и состояний компонентов, прикладывание спецификации по анимациям и edge-кейсам (пустые состояния, ошибки, длинный текст), участие в приёмке готового экрана перед релизом.
6Приведите пример, когда пользовательское тестирование опровергло ваше предположение
Что проверяют. Честность и готовность признавать ошибки, а не подгонять результаты под изначальную идею.
Слабый ответ
«У меня обычно всё сразу заходит хорошо, серьёзных провалов не было». Такой ответ звучит неправдоподобно и настораживает: значит либо тестов не было, либо кандидат не признаёт ошибок.
Сильный ответ
Расскажите про конкретный случай: вы были уверены, что новая навигация упростит путь пользователя, но тест показал, что люди не находят нужный раздел. Опишите, что вы поменяли по итогам теста и как проверили, что новое решение сработало лучше.
7Как вы расставляете приоритеты, если задач больше, чем времени
Что проверяют. Умение оценивать влияние задачи на продукт и договариваться о сроках, а не хвататься за всё сразу.
Слабый ответ
«Стараюсь успеть всё, работаю быстрее». Ответ не показывает метод расстановки приоритетов и обещает нереалистичную скорость.
Сильный ответ
Опишите, как вы оцениваете задачи по влиянию на ключевые метрики продукта и по срочности для бизнеса, обсуждаете приоритеты с продакт-менеджером и честно сообщаете, если что-то не успевает войти в спринт, вместо того чтобы делать всё наспех.
8Что вы будете делать в первую задачу на новом проекте
Что проверяют. Понимание, что нельзя сразу открывать Figma и рисовать, не разобравшись в контексте продукта.
Слабый ответ
«Сразу сяду делать макеты, чтобы показать результат быстрее». Быстрый результат без понимания контекста часто оказывается бесполезным и его переделывают.
Сильный ответ
Расскажите, что сначала изучите существующую дизайн-систему и продукт целиком, поговорите с продакт-менеджером и, если возможно, с пользователями или службой поддержки, посмотрите аналитику по проблемным местам, и только после этого приступите к макетам.
9Как вы относитесь к работе с готовым, уже частично сформированным продуктом, а не созданию с нуля
Что проверяют. Реалистичность ожиданий: большинство вакансий это поддержка и развитие существующего продукта, а не редизайн с чистого листа.
Слабый ответ
«Мне интереснее создавать что-то с нуля, доработка чужого не так увлекательна». Такой ответ рискует не подойти под реальные задачи вакансии.
Сильный ответ
Скажите, что вам интересна и такая работа: разбор существующих проблем часто даёт больше практической пользы, чем создание идеального интерфейса в вакууме, и приведите пример, когда вы дорабатывали чужой продукт и находили в нём точки роста.
10Как бы вы улучшили конкретный экран нашего продукта
Что проверяют. Проверяют, готовился ли кандидат к встрече и умеет ли анализировать интерфейс без предварительного брифа.
Слабый ответ
«Мне всё нравится, ничего бы не менял» или общие фразы «сделал бы более современно». Оба варианта показывают, что кандидат не изучил продукт заранее.
Сильный ответ
Заранее откройте продукт компании, найдите конкретный экран с проблемой: неочевидная кнопка, перегруженная форма, непонятная навигация. Опишите проблему и предложите конкретное решение, объяснив, на какую метрику это может повлиять.
Как построить ответ, чтобы его засчитали
Репетиция самопрезентации
Проверьте, как ваши ответы звучат вслух
Знать сильный пример недостаточно — важно быстро вспомнить его и ясно показать личный вклад. Пройдите короткую голосовую репетицию и получите разбор конкретики, результата и формулировок.
Проверить свои ответы бесплатно
Ошибки, которые чаще всего стоят оффера
- Показывать в портфолио только финальные картинки без объяснения процесса и причин решений
- Не иметь ответа на вопрос, какую метрику улучшил проект, и не признавать честно, что метрики не отслеживались
- Спорить с интервьюером во время разбора тестового задания вместо того, чтобы выслушать аргументы
- Показывать чужие или командные проекты как полностью свою личную работу
- Приходить без открытых заранее макетов и терять время на поиск файлов во время звонка
- Игнорировать вопросы про взаимодействие с разработчиками, сводя всю работу только к рисованию экранов
- Не изучить продукт компании заранее и не иметь идей по его улучшению
Свои факты, которые стоит вспомнить заранее
Большая часть провальных ответов это не незнание, а невозможность вспомнить конкретику под давлением. Выпишите это до встречи.
- Список из двух-трёх проектов, которые вы будете разбирать подробно, с открытым доступом к макетам заранее
- Конкретная ваша роль в каждом проекте: что делали лично вы, а что коллеги
- Метрики до и после изменений, если они фиксировались, например по конверсии или количеству обращений в поддержку
- Инструменты и методы, которыми пользуетесь: Figma, прототипирование, юзабилити-тестирование, аналитика
- Примеры сложных ситуаций с командой: спор с разработчиком или продактом и как он разрешился
- Идеи по улучшению продукта компании, к которой идёте на собеседование, на основе беглого разбора её интерфейса
Чек-лист перед встречей
- Откройте портфолио и подготовьте два-три проекта с доступом к макетам, а не только к скриншотам
- Продумайте для каждого проекта структуру рассказа: задача, ограничения, решение, результат
- Изучите продукт компании и найдите конкретный экран, который могли бы улучшить
- Освежите в памяти основные эвристики юзабилити и методы тестирования интерфейсов
- Подготовьте пример конфликта с командой и то, как его разрешили
- Проверьте связь и доступ к Figma заранее, если ожидается практическая часть на звонке
- Составьте свои вопросы про команду, процесс и инструменты, которые использует компания
Пройдите собеседование с ИИ по этой профессии
ИИ задаст вопросы по роли «UX/UI-дизайнер», выслушает ответы голосом и покажет, где не хватило фактов. Первый персональный разбор бесплатно, без регистрации.
Пройти собеседование с ИИДолжность подставится автоматически. Резюме и описание вакансии можно не загружать.
Частые вопросы
Нужно ли уметь рисовать вручную для собеседования на UX/UI-дизайнера
Нет, скетчинг руками требуют редко. Гораздо важнее умение работать в Figma и объяснять логику решений. Иногда просят быстро набросать структуру экрана на бумаге или в блокноте, но это не про художественные навыки, а про скорость мышления.
Что делать, если в портфолио только учебные проекты без реального запуска
Честно скажите, что проект учебный, и сделайте акцент на процессе: как вы формулировали гипотезы, что тестировали, какие ограничения придумали сами, чтобы приблизить задачу к реальной. Работодатели понимают ситуацию начинающих специалистов и оценивают ход мысли.
Стоит ли соглашаться на бесплатное тестовое задание большого объёма
Небольшое тестовое на несколько часов, соответствующее задачам вакансии, это нормальная практика. Если просят полноценный проект на несколько дней без оплаты и без чёткого объяснения, зачем он нужен именно вам, стоит уточнить, как будет использован результат, и обсудить сроки.
Что важнее на собеседовании: сильный UX или сильный UI
Зависит от вакансии, но чаще всего компании ищут баланс. Если в описании должности упор на исследования и логику продукта, готовьтесь подробно говорить про процесс и данные. Если акцент на визуал и дизайн-систему, уделите больше внимания аккуратности и последовательности стиля в портфолио.
Как реагировать, если интервьюер жёстко критикует макет из портфолио
Не защищайтесь эмоционально и не соглашайтесь со всем подряд. Выслушайте аргумент, задайте уточняющий вопрос, если критика непонятна, и честно скажите, согласны вы с ней или нет и почему. Это показывает зрелость и умение работать с обратной связью.
Собеседования на смежные должности
Как подготовлен этот материал
Редакция отделяет универсальную механику интервью от требований конкретной вакансии. Мы не обещаем «правильный» ответ и не предлагаем выдумывать опыт: каждый пример нужно сверить с задачами вакансии и заменить собственными фактами. Перед публикацией проверяются структура, повторяемость, внутренние ссылки и формулировки, которые могут ввести кандидата в заблуждение.
Материал обновлён 18.08.2026. Разбор основан на типовой практике найма и не содержит гарантий по результату конкретного собеседования.