Дизайнер, що кодить, - це дизайнер, який сам доводить свої рішення до робочого інтерфейсу: правки UI, стани, токени, лендинги і прототипи він робить у коді через Claude Code і віддає розробникам не макет, а готовий pull request на рев'ю. Щоб перестати чекати девелоперів, забери собі «фронтовий хвіст» (тексти, відступи, кольори, стани, адаптив), а логіку, дані й безпеку залиш інженерам. Старт займає 2-4 тижні: доступ до репозиторію, базовий Git, Claude Code і домовленість з командою про правила PR.
Я, Dmytro Nikolaienko, працюю так щодня: сайт, платформа курсів і внутрішня CRM UX Hero зібрані без окремого фронтенд-розробника. Нижче - де проходить межа «моє / не моє», як виглядає правка без черги, як домовитись з розробниками і з яких трьох pull request почати.
Хто такий дизайнер, що кодить, і чим він не є?
Визначення: дизайнер, що кодить, - продуктовий дизайнер, який вміє внести зміну в реальний код продукту (зазвичай разом з AI-агентом) і провести її через рев'ю до продакшну.
Це не розробник і не обов'язково окрема посада. Це навик поверх дизайну, який змінює точку, де закінчується твоя робота.
| Роль | Що віддає | Де закінчується робота |
|---|---|---|
| Класичний дизайнер | макет у Figma і специфікацію | на handoff |
| Дизайнер, що кодить | pull request з готовою зміною UI | після рев'ю і мерджу |
| Design Engineer | компоненти, дизайн-систему в коді, прототипи | у продакшні і Storybook |
| Фронтенд-розробник | фічі з логікою, даними і API | у продакшні |
Design Engineer - вже окрема роль зі своїми зарплатами, про неї детально в статті Design Engineer у 2026. Дизайнер, що кодить, - перший крок до неї, і він корисний, навіть якщо ти не плануєш міняти посаду.
І одразу про головне: це не про генерацію картинок у нейромережах. Картинки зараз генерує кожен. Цінність - довести дизайн до коду, який реально бачить користувач.
Чому дизайнер взагалі чекає девелоперів?
Бо маленька правка конкурує в беклозі з фічами і завжди програє. Правка відступу - це 10 хвилин роботи, але заради 10 хвилин ніхто не перемикає контекст, тож вона чекає тиждень-два.
- Пріоритет. Фічі й баги завжди важливіші за «зелений не той».
- Втрати при передачі. Макет → тікет → інтерпретація → «майже як у макеті».
- Зайві кола перевірки. Розробник зробив, дизайнер знайшов розбіжність, ще одне коло.
- Дизайн-борг. За квартал набігають десятки дрібниць, які ніхто не візьме.
Типовий шлях у команді зі спринтами по два тижні: тікет, планування спринту, реалізація, дизайн-рев'ю, друге коло. Від ідеї до продакшну виходить 1-3 тижні. Коли ту саму правку робить дизайнер, це година-дві роботи плюс час на рев'ю коду.
Що дизайнер може забрати собі, а що лишити розробникам?
Правило одне: бери те, що можеш перевірити очима. Якщо результат видно в браузері - це твоя зона. Якщо помилку видно тільки в логах чи в базі даних - не твоя.
| Зона | Задачі | Хто робить |
|---|---|---|
| Зелена | тексти, кольори, відступи, шрифти, іконки, адаптив, hover і focus, пусті стани й стани помилок, анімації, токени, лендинги, прототипи | дизайнер сам, розробник рев'юїть |
| Жовта | нові UI-компоненти, форми з валідацією, Storybook-сторі, дрібна інтерактивність | дизайнер з підстраховкою інженера |
| Червона | авторизація, оплати, база даних, API, права доступу, безпека, інфраструктура | тільки розробник |
Навіть одна зелена зона закриває більшу частину дизайн-боргу. А червону не чіпай, навіть якщо Claude Code впевнено каже, що все працює: агент пише правдоподібний код, але ти не зможеш сам перевірити, чи він безпечний.
Як виглядає правка без черги крок за кроком?
- Опиши проблему. Що не так і як має бути, зі скріном з Figma.
- Створи гілку.
git checkout -b fix/card-spacing. Головна гілка лишається недоторканою. Основи - у статті Git для дизайнерів. - Дай задачу Claude Code. У репозиторії має лежати CLAUDE.md з токенами і правилами, щоб агент не вигадував кольори.
- Перевір у браузері на 375, 768 і 1440px, у темній темі і з клавіатурним фокусом.
- Відкрий pull request з коротким описом і скрінами до/після.
- Дай preview-посилання. Vercel і Cloudflare Pages автоматично збирають живу версію кожного PR, тож розробник і PM бачать результат, а не опис. Як це налаштувати - у статті про деплой на Vercel.
- Рев'ю інженера і мердж. Без апруву нічого не потрапляє в продакшн.
«У компоненті ProductCard відступ між фото і назвою 12px, а в макеті 16px. Заміни на токен --space-4, більше нічого не змінюй. Покажи diff перед комітом.»
Ключова фраза тут - «більше нічого не змінюй». Маленький передбачуваний diff розробник прорев'юїть за дві хвилини, а великий відкладе «на потім», і ти знову чекаєш.
| Етап | Через тікет | Через свій PR |
|---|---|---|
| Старт роботи | коли дійде черга у спринті | одразу |
| Точність | «майже як у макеті» | піксель у піксель, бо робить автор макета |
| Перевірка | 2-3 кола дизайн-рев'ю | одне рев'ю коду |
| Час розробника | реалізація + правки | тільки рев'ю |
Як домовитись з розробниками, щоб вони були за?
Розробники проти не дизайнера в репозиторії, а хаосу в ньому. Тому приходь з правилами, а не з проханням «дайте доступ»:
- Перший місяць - тільки зелена зона.
- Маленькі PR: одна зміна, орієнтовно до 100-200 рядків diff.
- Кожен PR зі скрінами до/після і preview-посиланням.
- Не чіпаю залежності, конфіги і
package.jsonбез питання. - Жодного мерджу без апруву інженера, головна гілка захищена.
- CLAUDE.md у репозиторії погоджений з командою: стек, токени, папки, куди агенту заходити не можна.
Аргумент для тімліда простий: ти знімаєш з розробників найнудніші тікети, а вони отримують час на фічі. Перші 2-3 PR рев'юїтимуть довго і прискіпливо, це нормально. Далі довіра росте, і рев'ю стає формальністю.
З чого почати: три перші pull request
Не вчи «програмування взагалі». Вчи рівно те, що потрібно для наступного PR:
| PR | Що робиш | Чого вчишся |
|---|---|---|
| №1 | виправляєш текст або колір | гілка, commit, PR, рев'ю |
| №2 | додаєш пустий стан або стан помилки | структура компонента, умови, адаптив |
| №3 | робиш новий компонент зі Storybook-сторі | props, варіанти, токени, документація |
Мінімальний набір знань: Git на рівні гілок і PR, вміння читати HTML і CSS, CSS-змінні і токени, базова будова React-компонента і сам Claude Code. Як встановити його з нуля і написати перший CLAUDE.md - у гайді Claude Code для дизайнерів.
Реалістично: перший простий PR можна зробити за вечір, якщо проєкт уже запускається локально. До рівня, коли твої PR проходять рев'ю без переписувань, - 2-4 тижні практики по кілька вечорів.
Як це працює в UX Hero без окремого фронтенд-розробника?
У UX Hero немає штатного фронтенд-розробника. Сайт uxhero.design, платформу курсів із входом по коду з пошти і доступом після оплати, внутрішню CRM з продажами я зібрав у Claude Code сам. Процес той самий, що вище: кожна зміна - окрема гілка, PR і preview-посилання, і тільки після перевірки мердж у головну гілку, яка сама деплоїться на Cloudflare.
Але червону зону я не спрощую. Усе, що стосується оплат і доступів студентів, тестую на копіях і перевіряю окремо, а не вірю на слово «агент сказав, що працює». Дизайнер, що кодить, - це не «роблю все сам». Це «знаю, де моя межа, і переходжу її тільки з перевіркою».
Живі робочі сесії в Claude Code на реальних проєктах я викладаю на YouTube-каналі UX Hero.
Які помилки роблять дизайнери, що починають кодити?
- Великі PR «заодно поправив ще 12 речей». Такий PR ніхто не прорев'юїть, і він зависне.
- Хардкод замість токенів. Через місяць у коді 40 відтінків сірого, і ти сам створив дизайн-борг.
- Перевірка тільки на своєму ноутбуці. Мобільна версія, темна тема і фокус з клавіатури обов'язкові.
- Вихід у червону зону, бо «агент впорався». Впорався - не означає безпечно.
- Мердж без рев'ю, навіть якщо права дозволяють. Одна така помилка коштує всієї довіри команди.
- Бажання переписати все «на нормальний стек». Працюй у тому, що вже є в проєкті.
Часті питання
Чи треба дизайнеру вчити програмування, щоб кодити з AI?
Не в класичному сенсі. Код пише Claude Code, а дизайнеру треба розуміти Git, читати HTML і CSS, знати токени і будову компонента, щоб поставити точну задачу і перевірити результат.
Чи дадуть дизайнеру доступ до репозиторію?
Зазвичай так, якщо прийти з правилами: тільки UI-зміни, маленькі PR зі скрінами і preview, жодного мерджу без апруву інженера. Коли головна гілка захищена, зміна не потрапить у продакшн без рев'ю.
Скільки часу потрібно, щоб зробити перший pull request?
Перший простий PR, наприклад заміну тексту чи кольору, реально зробити за вечір, якщо проєкт уже запускається локально. До PR, які проходять рев'ю без переписувань, зазвичай 2-4 тижні практики.
Чим дизайнер, що кодить, відрізняється від Design Engineer?
Дизайнер, що кодить, - це навик: він сам вносить UI-зміни в код продукту через pull request. Design Engineer - окрема роль, яка відповідає за компоненти, дизайн-систему в коді і прототипи. Перше - природний крок до другого.
Де дизайнеру навчитися кодити українською?
У UX Hero є курс «Design Engineer» від Dmytro Nikolaienko: 10 лекцій про Git, HTML/CSS і Tailwind, Claude Code, React, токени, Storybook і деплой. Перший власний pull request на GitHub ти робиш уже в лекції про Git. Курс не про генерацію картинок, а про те, як доводити дизайн до коду.
Чекати девелоперів - це не доля дизайнера, а наслідок того, що твоя робота закінчується на макеті. Перенеси цю точку на один крок далі, до власного pull request, і дрібні правки перестануть жити в беклозі місяцями.