Design Engineer чи frontend-розробник: у чому різниця і ким стати дизайнеру

Коротка відповідь: frontend-розробник відповідає за те, щоб застосунок працював: дані, API, логіка, продуктивність. Design engineer відповідає за те, щоб інтерфейс у коді був таким, як задумано: компоненти, токени, стани, адаптив, motion і доступність. Перетинаються вони в UI-шарі, звідси й вічне «то це ж фронтенд?». Дизайнеру з сильною Figma ближчий шлях у design engineer, ніж у фронтенд з нуля.

Я Дмитро Ніколаєнко, 15 років у продуктовому дизайні. Вів дизайн у 8 мобільних банках і весь цей час сидів поруч із фронтенд-командами: на рев'ю, на демо, у суперечках про відступи. Зараз сам щодня кодю в Claude Code і будую дизайн-системи на 800+ екранів. Питання «design engineer - це ж фронтендер, який вміє у Figma?» я чую постійно.

Чим ця роль відрізняється від продуктового дизайнера, я розібрав у статті Design Engineer у 2026: хто це і як стати. Тут тільки одне порівняння: design engineer проти frontend-розробника. З таблицею, прикладом одного pull request і тестом, щоб зрозуміти, куди тобі.

Чим design engineer відрізняється від frontend-розробника?

Найпростіше пояснити на одній кнопці. Візьмемо «Оплатити» в банківському застосунку.

Frontend-розробник думає так: запит на оплату пішов, сервер відповів, помилку обробили, подвійний тап не відправив два платежі. Гроші списались один раз, екран показав правду - його робота зроблена.

Design engineer дивиться на ту саму кнопку інакше. Чи є стан loading і чи не стрибає кнопка по ширині, коли текст змінюється на спінер. Чи disabled виглядає вимкненою, а не зламаною. Чи видно фокус, коли ходиш з клавіатури. Чи колір узятий з токена, чи вписаний хексом. Чи помилка «недостатньо коштів» читається спокійно, чи звучить як сирена.

Одна кнопка, два різні питання. Frontend питає «чи працює». Design engineer питає «чи це те, що ми задумали». У хорошій команді потрібні обидва.

Як виглядає різниця пліч-о-пліч?

Якщо звести в одну таблицю, виходить так:

Зверни увагу на останній рядок. Design engineer першим питає дизайнера «а де empty state?» і першим питає фронтенд «які пропси буде в компонента?». Він стоїть посередині, тому бачить дірки, яких не видно з жодного боку. А з продактом сперечаються обидва, це константа.

Чого design engineer не робить і чому це нормально?

Design engineer не закриває все, що закриває фронтенд. І не повинен.

• Бекенд і бази даних. Ендпоінти, схеми, міграції - не його зона.
• Інфраструктура. Сервери, CI, безпека. Задеплоїти свою сторінку на прев'ю він уміє, налаштовувати пайплайн компанії - ні.
• Складна бізнес-логіка. Розрахунок комісії, ліміти переказів, кешування, синхронізація даних між екранами.
• Глибока оптимізація. Розмір бандла, кількість запитів, рендер довгих списків. Помітити проблему він може, лагодить фронтенд.

У банку ніхто не пустить дизайнера в логіку переказів. І правильно. Якщо design engineer починає писати розрахунок комісії, команда отримує слабкого бекендера і втрачає людину, яка стежила за якістю UI. Цінність ролі якраз у вузькому фокусі: один шар, зате зроблений до кінця.

Як design engineer і frontend ділять роботу в одному pull request?

Покажу на тій самій кнопці оплати. Один PR, дві людини, ніхто нікого не чекає.

feat: кнопка оплати зі станами
├── tokens/semantic.css     DE: --color-action, --color-danger
├── PayButton.tsx           DE: вигляд, стани, фокус, motion
├── PayButton.stories.tsx   DE: кожен стан окремою історією
├── usePayment.ts           frontend: запит, відповідь, помилки
└── usePayment.test.ts      frontend: подвійний тап = один платіж

Усе тримається на контракті. Це пропси компонента, про які двоє домовляються до того, як хтось написав перший рядок:

type PayButtonProps = {
  state: 'idle' | 'loading' | 'success' | 'error';
  disabled?: boolean;
  label: string;
  onPay: () => void;
};

Далі процес виглядає так:

1. Домовляєтесь про пропси. П'ятнадцять хвилин у дзвінку або коментар у PR. Design engineer приносить список станів з макета, фронтенд каже, які дані в нього реально будуть.
2. Design engineer робить вигляд на моках. Без справжнього API. Кожен стан окремою історією в Storybook: idle, loading, success, error, disabled. Плюс перевірка на 375 і 1440px.
3. Frontend підключає дані. Хук робить запит, перетворює відповідь сервера на state і покриває тестом, що подвійний тап не шле два платежі.
4. Перехресне рев'ю. Design engineer перевіряє, що loading не стрибає по ширині, а помилка читається. Frontend перевіряє, що компонент не тягне в себе логіку.
5. Merge. Без кола «дизайнер подивився на стейджингу і завів п'ять тікетів на відступи».

Саме цей пінг-понг з тікетами на відступи я роками бачив у банківських командах. Коли UI-шар забирає людина, яка його розуміє, фронтенд нарешті займається тим, за що його найняли. Як описати всі стани від Figma до Storybook, є окрема стаття Стани компонента: з Figma у React і Storybook.

Як з вакансії зрозуміти, це design engineer чи фронтенд?

По заголовку ніяк. Роботу design engineer називають і «UI Engineer», і «Design Technologist», і «Design Systems Engineer», а іноді це просто «Frontend Developer». Буває і навпаки: у заголовку «Design Engineer», а в задачах класичний фронтенд.

Тому читай список задач. Я дивлюсь на такі сигнали:

• Схоже на design engineer: Figma, дизайн-токени, Storybook, бібліотека компонентів, доступність, motion, робота пліч-о-пліч з дизайн-командою.
• Схоже на фронтенд: API, керування станом, тести, продуктивність, «фіча від початку до кінця».

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

Повна таблиця назв, де шукати такі ролі і як самому перевірити зарплати на DOU і Djinni, є в статті Як стати Design Engineer в Україні. Цифр з голови тут не буде.

Тобі ближче design engineer чи frontend? Тест з 5 питань

Відповідай чесно, без «як правильно». На кожне питання обери А або Б.

1. Що дратує більше? А: кнопка з відступом 14px замість 16px. Б: сторінка, яка вантажиться чотири секунди.
2. Що цікавіше розкрутити? А: чому в компонента має бути шість станів. Б: чому дані з сервера приходять у трьох різних форматах.
3. Що зробиш на вихідних для себе? А: свою дизайн-систему в коді з темною темою. Б: сервіс з логіном, базою і оплатою.
4. Відкриваєш новий застосунок. Що помічаєш першим? А: типографіку, анімації, як поводяться стани. Б: як він працює без інтернету і як швидко оновлює дані.
5. Що для тебе «готово»? А: виглядає і поводиться як задумано на всіх ширинах. Б: працює без багів у всіх сценаріях.

4-5 відповідей А - тобі в design engineer. 4-5 відповідей Б - у фронтенд, і тоді вчись як розробник: глибокий JavaScript, TypeScript, API, тести. Вийшло 3 на 2 в будь-який бік - починай з UI-шару. Він спільний для обох шляхів, і за кілька місяців практики стане ясно, куди тягне.

Що вчити дизайнеру, щоб стати design engineer, а не слабким фронтендером?

Найчастіша помилка, яку я бачу: дизайнер вирішує «стати розробником» і йде на загальний курс фронтенду. Через пів року в нього половина JavaScript, нуль алгоритмів і жодної переваги над випускником будь-якого буткемпу. Свою сильну сторону, око і системне мислення, він по дорозі загубив.

Design engineer вчить вузько, зате глибоко. Ось порядок, який я б дав собі на старті:

1. HTML і CSS по-справжньому. Семантика, flex і grid, адаптив, CSS-змінні. Це мова, якою говорить твій UI-шар.
2. Токени. Як Figma Variables стають CSS-змінними або темою Tailwind і чому компонент не має знати жодного хексу. Почни зі статті про CSS-змінні і токени.
3. React на рівні читання. Компонент, пропси, стан. Писати з нуля не обов'язково, це зробить Claude Code. Твоя задача - побачити, де він помилився.
4. Git. Гілка, коміт, pull request, рев'ю. Без цього ти поруч з командою, але не в ній. Мінімум без зайвого є в статті Git для дизайнерів.
5. Claude Code. Агент, який пише код у твоєму репозиторії. Головне тут - CLAUDE.md з правилами проєкту, щоб агент брав твої токени і не вигадував сьомий відтінок сірого.

Що можна сміливо пропустити на старті: алгоритми, бекенд, бази даних, бібліотеки для керування станом, налаштування серверів. Це територія фронтенду і бекенду. Повний план на 90 днів з тижнями і задачами є в статті Як дизайнеру навчитись кодити у 2026, а про те, як перестати чекати розробників у щоденній роботі, у статті Дизайнер, що кодить.

Чи заберуть AI-агенти обидві ролі?

Моя думка, без прогнозів і графіків: агенти вже забрали більшу частину набору коду. Рішення вони не забрали.

Я щодня працюю в Claude Code. Сайт, платформа курсів і CRM UX Hero зібрані в ньому, і з командою ми випустили з ним iOS-застосунок Heroco. Компонент зі станами агент пише за хвилини. Але якщо в CLAUDE.md не записано правил, він спокійно додасть новий відтінок сірого, забуде focus і зробить помилку червоною на весь екран. Технічно все працює. Дизайну там немає.

З фронтендом так само. Агент напише хук для оплати, але хтось має вирішити, що робити, коли сервер мовчить пів хвилини, і відповідати за це перед бізнесом.

Тому обидві ролі зсуваються від «написати» до «вирішити і перевірити». Design engineer тут у вигідній позиції: коли код дешевшає, дорожчають смак, система і вміння пояснити агенту, що саме не так. Рівно те, що дизайнер приносить з собою з Figma.

Часті питання

Чим design engineer відрізняється від frontend-розробника?

Frontend-розробник відповідає за те, щоб застосунок працював: дані, API, бізнес-логіка, продуктивність, тести логіки. Design engineer відповідає за те, щоб інтерфейс у коді відповідав задуму: компоненти, токени, стани, адаптив, motion і доступність. Обидва працюють в UI-шарі, але frontend питає «чи працює», а design engineer питає «чи це те, що ми задумали».

Чи може design engineer потім перейти у frontend?

Так, це один з найприродніших переходів: HTML, CSS, React, Git і робота з компонентами в тебе вже є. Доведеться добрати те, що design engineer свідомо пропускає: глибший JavaScript, TypeScript, роботу з API і даними, тести, основи алгоритмів. Буває і зворотний шлях, коли фронтенд-розробник з сильним смаком іде в дизайн-системи.

Чи потрібна профільна освіта, щоб стати design engineer?

Зазвичай ні. У цю роль часто приходять з дизайну, і головне, що ти покажеш, це портфоліо: компоненти в коді, Storybook, задеплоєні сторінки і pull request, які можна відкрити і подивитись. Технічний диплом цього не замінить.

Чи треба design engineer знати алгоритми?

Глибоко - ні. Design engineer не пише сортування і графи, його задачі в UI-шарі: компоненти, стани, токени, адаптив. Базова логіка потрібна: умова, цикл, масив, об'єкт. Цього вистачає, щоб читати код, який пише Claude Code, і бачити, де він помилився.

З чого почати дизайнеру, який хоче стати design engineer?

З HTML і CSS, далі токени з Figma Variables у CSS-змінні, React на рівні читання, Git і Claude Code. Перший практичний крок: зібрати в коді один компонент з дизайн-системи з усіма станами і відкрити на нього pull request. Системно цей шлях проходить курс UX Hero «Design Engineer» від Дмитра Ніколаєнка.

---

Досі не впевнений, куди тобі? Приходь на безкоштовний ефір #5 «Як стати design engineer» у четвер 29 жовтня о 19:00 за Києвом. Будь-яке питання з цієї статті можна поставити наживо. Реєстрація в Telegram-боті @uxhero_bot.

Якщо вже знаєш, що тобі в design engineer, є курс Design Engineer: 10 лекцій від першого коміту до задеплоєного PR і воркбук, де записано кожен крок, промпт і перевірку. А якщо потрібні дедлайни, рев'ю коду і люди поруч, приходь у перший потік кохорти Design Engineer: кікоф у п'ятницю 30.10 о 19:00, старт 2 листопада, 4 тижні, 8 живих сесій по середах і п'ятницях о 19:00 і демо-день у середу 2 грудня. Місць 12.