30 питань на співбесіді UX/UI Senior 2026: різниця між Junior і Senior відповіддю

Я проектував B2B-платформу для логістики. Почав з трьох сценаріїв: диспетчер, водій, клієнт. Виявив що 80% часу диспетчер проводить між двома екранами — побудував архітектуру навколо цього патерну. Систему рознесли на 3 ролі з різними дашбордами, але спільною дизайн-системою. За пів року продукт виріс з 1 до 4 ролей — архітектура витримала без переробки.

Починаю з jobs to be done і трьох-чотирьох ключових сценаріїв. Кожен сценарій — це окремий флоу зі своїми точками входу і виходу. Спільні елементи виношу в дизайн-систему до того як починаю екрани. Якщо в одному флоу більше 7 кроків — це сигнал що треба декомпозувати на під-сценарії, інакше команда розробки не витримає термінів.

Це модель того як користувач шукає інформацію — і модель того як бізнес хоче щоб її знаходили. Часто це два різні дерева. Моя робота — знайти перетин і зробити так щоб користувач знайшов те що шукає, а бізнес — продав те що хоче продати. На останньому проекті я переробив IA фінтех-додатку: ми мали 12 розділів, я звів до 5, конверсія в onboarding виросла на 23%.

Спочатку звожу до критеріїв вибору: швидкість виходу, технічна складність, відповідність бренду, ризик для метрики. Якщо критерії не дають однозначної відповіді — провожу A/B або 5-секундний тест на 10 користувачів. Найчастіше виявляється що один з варіантів вирішує проблему ширшу за ту що я брав — і саме його обираю.

Цікавий приклад — пошук квитків в Booking. Вони навмисно ускладнюють фільтрацію щоб користувач переглянув більше пропозицій. Це поганий UX з точки зору ефективності, але хороший з точки зору конверсії. Мій висновок з цього кейсу: моя задача — зробити так щоб бізнес виграв через зручність користувача. Зручність сама по собі — не самоціль.

У нас в команду прийшов Middle який робив всі екрани окремо і не використовував компоненти. Я сів з ним на 2 години, показав як це працює на одному з його кейсів — час на новий екран зменшився з 4 годин до 40 хвилин. За місяць він став сам інтегрувати нові компоненти в систему. Спрацювала демонстрація на його ж задачі. Теоретичне пояснення без прив’язки до його роботи я пробував раніше з іншим дизайнером — це не дало результату за 3 місяці.

Перше — фідбек завжди на роботу, не на людину. Друге — формула SBI: ситуація, поведінка, вплив. «У понеділок на ревʼю (S) ти показав 3 версії редизайну (B) — це забрало 40 хвилин обговорення замість 15 (I). Давай наступного разу прийдемо з однією рекомендованою версією і двома альтернативами». Третє — ніколи не даю складний фідбек публічно. Тільки 1-на-1.

Три сигнали. Перший — він приходить з рішеннями, а не з проблемами. Другий — інші члени команди звертаються до нього за порадою без мого втручання. Третій — він починає робити фідбек на мою роботу аргументовано і це робить роботу кращою. Якщо всі три сигнали стабільно протягом 2-3 місяців — час говорити з його менеджером про grade.

Спочатку розбираюсь чи це конфлікт особистостей чи конфлікт підходів. Якщо підходів — це нормальна частина роботи, треба тільки звести до спільних критеріїв і прийняти рішення. Якщо особистостей — це проблема яка не вирішується дизайн-аргументами, треба ескалувати менеджеру і структурувати роботу так щоб вони перетиналися мінімально. Колись я витратив 3 тижні намагаючись помирити двох людей які просто не любили одне одного. Це була моя помилка як Lead.

Реалістично — від 4 до 6 дизайнерів якщо я фокусуюся тільки на менторстві. Якщо я ще працюю над власними проектами — максимум 3. Більше 6 — це менеджмент, а не дизайн-лідерство. Я волію меншу команду де можу глибоко впливати на ріст кожного, ніж велику де я бачу всіх раз на 2 тижні.

Я редизайнив онбординг B2B SaaS. Час до першого корисного дії впав з 14 хвилин до 4. Конверсія з реєстрації в активного користувача на 7-й день виросла з 31% до 47%. Це принесло компанії додатково ~$180K MRR за квартал.

Через мову яку розуміє менеджмент: гроші, час, ризик. Якщо я роблю редизайн форми — рахую скільки коштує компанії кожен 1% падіння конверсії. Якщо я роблю дизайн-систему — рахую скільки годин розробки вона економить за квартал. Дослідження користувачів — це інструмент, але я ніколи не показую його як аргумент. Аргумент — це бізнес-результат до якого дослідження веде.

Я завжди передбачаю сценарій провалу до релізу. Перед запуском чекауту в нас був план Б: якщо конверсія падає більше ніж на 3% за 5 днів — відкат. У контракті з продуктом це було прописано. Це знімає половину тиску з релізу — бо ти не йдеш ва-банк, ти проводиш контрольований експеримент.

3 рівні валідації. Перший — quantitative: конверсія, retention, час до дії, error rate. Другий — qualitative: 5 інтервʼю з тими хто прошёл флоу і 5 з тими хто не пройшов. Третій — proxy-метрики: кількість тікетів в саппорт по цьому флоу, час менеджера на пояснення продукту клієнту. Тільки коли всі три рівні узгоджені — я кажу що дизайн працює. Один рівень — це гіпотеза, не доказ.

Залежить від типу продукту. Для SaaS — час до Aha-moment, тижневий active retention і expansion revenue. Для e-commerce — conversion rate, average order value і повторні покупки за 90 днів. Для marketplace — match rate і time to first transaction. Універсального списку немає — Senior дизайнер обирає метрики під продукт, а не навпаки.

CEO хотів додати на головну сторінку банер про новий продукт. Я аргументував що банер впаде по конверсії на 5-7% бо забирає увагу від CTA. CEO наполягав. Я запропонував A/B-тест на 20% трафіку на 2 тижні. Тест показав падіння 6%. Банер прибрали. Мій висновок з кейсу — пропонувати CEO експеримент з обмеженим ризиком замість словесних аргументів. CEO потім сам сказав що моя пропозиція тесту була правильним рішенням.

Не кажу «ні». Кажу «так, але». Розкладаю задачу на критичні і некритичні частини. «Так, ми можемо зробити це за 2 тижні, але без юзер-тестів. Або 4 тижні з тестами. Якщо ми викочуємо без тестів — ризик падіння конверсії 10-15%, я брав схожі проекти і там було так». Перекладаю свій компроміс у термін ризику бізнесу. PM сам обирає.

Питаю який бізнес-результат має дати «веселіше». Якщо це збільшити CTR — ми міряємо CTR і тестуємо 2 версії. Якщо це «нам так здається» — пояснюю що ми не можемо оптимізувати під відчуття людини яка не є нашим користувачем. Часто після цього питання маркетинг або формулює конкретну ціль (і тоді я працюю), або відкочується (і це теж результат).

Перше — починаю з проблеми і метрики яку ми вирішуємо, макети показую тільки після узгодження проблеми. Якщо стейкхолдер не погоджується з проблемою — макети дивитись немає сенсу. Друге — показую 1 рекомендовану версію і 1 альтернативу, не 5. Третє — закінчую конкретним рішенням: «Ми йдемо в А, наступний крок — підготовка до A/B-тесту, дата старту 12 числа». Менеджмент любить ясність, а не дискусії.

Зупиняюсь і питаю прямо: «У нас є системна різниця в оцінці критеріїв. Давай зустрінемось окремо і запишемо що для тебе є мірилом успіху цього проекту. Я хочу зрозуміти що я пропускаю». 9 з 10 разів виявляється що стейкхолдер бачить ризик якого я не бачу — або політичний, або з минулого досвіду. Це не дизайн-проблема, це проблема контексту. Senior розуміє це, Middle сприймає як особисте відхилення.

Я будував дизайн-систему для фінтех-продукту з 12 командами розробки. Архітектура — 3 рівні: primitives (токени), components (UI-блоки) і patterns (готові флоу типу платіжної форми). Кожен рівень має свого owner-дизайнера, governance процес для додавання нового компоненту: пропозиція → 2 use-cases від різних команд → ревʼю → реліз. За рік скоротили час на новий екран з 3 днів до 4 годин.

Залежить від зрілості. На ранній стадії — один дизайнер. Коли система переходить за 30+ компонентів — треба окрема людина або dedicated team на 0.5-1 FTE. Якщо ні — система деградує: розробники додають компоненти без узгодження, дизайнери обходять обмеження, через рік ти маєш 4 версії однієї кнопки. У мене був досвід коли я був єдиним owner на 60 компонентів — це не масштабувалось.

Не переконую — рахую їм їхній час. Показую: цей екран в системі — 4 години, без системи — 16 годин. За рік це 200+ годин економії. Друге — будую систему разом з ними, не для них. Tech Lead розробки має бути партнером з першого дня. Третє — компоненти в Storybook повинні бути копі-пейст ready з коду, інакше розробники будуть мати свою версію. Дизайн-система яку розробка обходить — це не дизайн-система.

Не зразу зупиняю — питаю чому він робить свій компонент. У 30% випадків виявляється що в системі справді бракує цього компонента або існуючий не вирішує його кейс. Тоді або додаю в систему, або документую виняток. У 70% випадків — він просто не знав що такий компонент є. Це сигнал що моя документація і онбординг працюють погано. Я не сварю дизайнера — я виправляю процес.

Процес з 3 кроків. Перше — позначаю «deprecated» в Figma і Storybook з посиланням на заміну, лишаю на 2 спринти. Друге — комунікую командам через release notes і ping в Slack. Третє — після 2 спринтів видаляю з системи. Ніколи не видаляю різко — це ламає продакшен у тих хто ще використовує. Якщо компонент використовується більше ніж у 10 продуктових екранах — deprecation займає 1-2 квартали.

Справедливе питання. Я почав цей кейс на Middle-позиції 2 роки тому. За цей час моя роль розширилась — я взяв менторство 3 дизайнерів, написав governance процес для дизайн-системи і провів 4 ребрендингові ініціативи поза основним кейсом. У портфоліо я не оновлював core-проект, але можу окремо показати ці Senior-активності.

Минулого вівторка я погодився на дедлайн який ми не могли витримати. PM натиснув, я погодився щоб не псувати відносини. У середу зрозумів що 4 дизайн-задачі не встигнемо. Прийшов до PM, чесно сказав що погодився під тиском, попросив переглянути scope. Урок — я мав сказати «ні» в понеділок, а не в середу. Тиждень тому я почав використовувати чек-лист перед погодженням термінів.

Я свідомо лишився Senior IC замість Lead. Lead — це 70% менеджменту, я люблю проектувати продукти і це моя сильна сторона. Я веду менторство і governance — це Lead-активності — але без формального менеджменту команди. Якщо у вас цей track існує — обговоримо. Якщо ні — я готовий перейти в Lead-роль, але хочу чесно сказати що мене мотивує.

Три зміни. Перша — використовую Figma AI для генерації варіантів — заощаджую 30-40% часу на початкових ітераціях. Друга — генерую тестові гіпотези через Claude: даю йому контекст продукту, прошу 10 варіантів причин чому користувач кидає корзину, далі тестую гіпотези по якій з них найбільший impact. Третя — переписав код-ревʼю процес з розробкою через AI-асистента який автоматично перевіряє чи дизайн відповідає системі. Не вірю в AI який замінює дизайнера. Вірю в дизайнера який не використовує AI — він буде в 2 рази повільніший за того хто використовує.

Перший тиждень — 1-на-1 з кожним членом дизайн-команди і ключовими PM. Без презентацій, тільки слухати. Другий тиждень — аудит дизайн-системи і існуючих процесів, виявлення 3-х найбільших болів. Третій тиждень — формулюю 2-3 ініціативи на квартал, узгоджую з менеджером. Четвертий — починаю з найболючішої але найшвидшої. Не намагаюсь міняти все одразу — Senior розуміє що довіра команди формується через ранні маленькі перемоги.