Робота з AI як дизайн-інженер: від ідейшну до реального продукту

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

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

Зараз я майже не використовую фігму, а одразу створюю працюючі прототипи та, на деяких продуктах, одразу пушу у прод. В цілому робота з кодом для мене не нова. На початку карʼєри багато працював з версткою сайтів — HTML, CSS, трохи JS — і тільки потім повноцінно свічнувся у дизайн.

У мене прототипи в коді, дизайн-система у Storybook, і команда агентів, якій я віддаю рутину. Про це пишу в Telegram-каналі і на своєму сайті, де лежать кейси та інші статті.

Тож розповідаю, як змінилася моя роль продакт-дизайнера, коли я почав працювати з кодом і AI-агентами — без магії, з помилками і з воркфлоу, який реально працює на комерційних проєктах.

Замість вступу

Минулого тижня я вперше закрив роботу над комерційним продуктом повністю без фронтенд-розробників. Не пет-проєкт — реальний клієнтський продукт. Дизайн, прототип, компоненти, фронтенд, підключення до готового бекенду. Все.

Півтора року тому я тільки починав працювати з AI: пет-проєкти, розбирався, як підключити бекенд, оплати, авторизацію. Потім почав тягнути AI в комерційну роботу — але ще всередині Figma: оптимізував дизайн-системи, флоу компонентів, генерував варіанти. А останні пів року я повністю перейшов на AI-воркфлоу: клікабельні прототипи на готових компонентах, які мої розробники потім просто перевикористовують. І це працює і для вебу, і для мобайлу.

Так, я все ще відкриваю Figma. Але вже рідше, ніж менеджери.

Цю статтю я пишу не сам. Зі мною — Даяна, моя дружина, колега і джерело натхнення. У неї свій великий продукт, свої граблі і свої правила, які іноді не збігаються з моїми. Тому там, де наш досвід сходиться, ми пишемо «ми». А там, де він розходиться або хтось із нас хоче підсвітити щось важливе, — будуть окремі поради від Даяни або від мене.

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

І ще одне. Я надиктовую свої статті голосом, а AI розшифровує і допомагає структурувати. Тому те, що ви читаєте, теж спочатку було голосовим повідомленням. Чому це важливо — розкажу трохи нижче.

Хто такий АІ дизайн-інженер і навіщо він

Коротко: це той самий продакт-дизайнер, але з іншим стеком інструментів.

Ціль не змінилася. Я так само роблю продукт, який вирішує задачу бізнесу і задачу користувача. Змінилося те, чим я це роблю: замість тисяч екранів у Figma — прототип у коді, дизайн-система у Storybook і команда AI-агентів, яким я віддаю рутину.

Чому це стало трендом і чому продуктові компанії зараз цього хочуть? Швидкість. Особливо на американському ринку. Від дизайн-інженера очікують не тільки макет і не тільки прототип — очікують готові компоненти в коді і базове розуміння фронтенду, щоб правильно віддати їх розробникам. Компанія отримує дизайнера, який закриває шматок роботи, на який раніше треба було двох-трьох людей.

Чому саме цей напрямок

У мене був досвід управління командою — я працював тімлідом. У Даяни теж. І виявилося, що це найкорисніша навичка для роботи з AI.

Бо агенти — це, по суті, мідли. Раніше я називав їх джунами, зараз вони підросли. Ти віддаєш їм частину задач, вони приносять результат через пів години, а не через тиждень. Але їх усе одно треба менеджерити: ставити контекст, перевіряти, повертати на доопрацювання, нагадувати про правила. Тімлідство нікуди не поділося — просто команда тепер інша.

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

Якщо ви ніколи не керували людьми — нічого страшного, навчитеся на агентах. Вони терплячі.

Дисклеймер, який важливо прочитати

Дизайн-інженерія — не єдиний шлях розвитку професії.

Дизайнери так само можуть іти в глибокий, унікальний UI — і це не менш цінна гілка. Ця стаття не закликає всіх писати код. Вона про те, як це виглядає, якщо ви обрали саме цей шлях.

Це важливо і для тих, хто наймає. Не можна найняти одну людину, яка робитиме взагалі все, ідеально, і бажано безкоштовно горітиме вашим проєктом. Професія ще формується і, скоріш за все, далі поділиться на менші спеціалізації. Ми описуємо момент, а не фінальну форму.

Спочатку — ціль, потім воркфлоу

Найперше питання перед будь-яким проєктом: що саме ви робите?

Воркфлоу для сайту — не той, що для прототипу мобільного застосунку. Прототип iOS-апки — не те саме, що веб-платформа, де ви ще й пишете фронтенд. Базові принципи однакові всюди. Але чим глибше розумієте інструменти, тим складніші продукти можете тягнути. І з часом це вже не один продукт, а зв’язка продуктів в одній системі з різним стеком, з якою треба працювати консистентно.

Налаштування агента: те, з чого варто починати будь-що

Цей розділ я спочатку писав у частині про сайти. Потім зрозумів, що він стосується всього — і виніс нагору. Бо позиціонування свого агента важливе всім, з будь-яким інструментом.

Розкажіть йому, хто ви

За півтора року роботи AI-інструменти встигли зрозуміти мене: мої патерни, звички, як я думаю, як робити не варто. І тому мої запити виконуються без сюрпризів.

Перед першим промтом розкажіть агенту, хто ви, які ваші цілі, що ви з ним будете робити. Якщо робите сайт — скажіть, що ви дизайнер з таким-то досвідом, ось портфоліо, ось CV, ось досягнення. Чим краще він вас розуміє, тим краще підлаштовується.

І тут важливий момент. Будь-який AI, як і ми, доволі ледачий і хоче працювати менше. Він вчиться робити так, як ви його вчите. Якщо не даєте йому лінитися — він не лінитиметься. Якщо даєте — буде.

Ми про це ще скажемо разів п’ять протягом статті. Бо це реально важливо.

Референси важливіші за деталі

Щоб агент робив дійсно гарний UI, йому все одно потрібні референси. І з мого досвіду — і на сайтах, і на мобільних застосунках — працює не «чим детальніше», а чим якісніше. Якісні референси плюс зрозуміле пояснення, що ви хочете, дають кращий результат, ніж три сторінки промта.

Ніхто не гарантує, що вийде з першого разу. Але ви витратите значно менше часу на переробки.

Несподіванка: супердетальний промт працює не найкраще

Раніше треба було використовувати кілька AI-інструментів, щоб один редагував промт для іншого. Зараз це працює гірше.

Що працює найкраще на момент написання статті — ваші голосові повідомлення. З усіма «а», «е», «ну типу» посеред речення. Для нас із Даяною це було справжнім відкриттям. Агент, як виявилося, теж має можливість подумати, коли ви даєте йому цю можливість, а не зашиваєте все в жорстку інструкцію.

Це може змінитися. Не завтра, але післязавтра Anthropic або OpenAI випустять нові правила промтингу — і буде інакше. Тому це не закон, а спостереження.

Описуйте як ідею, так і «вайб» продукту, який хочете отримати

Описати кінцевий продукт треба обов’язково. Агент має розуміти, що в результаті має вийти: які екрани, які функції, для кого. Без цього ви отримаєте щось гарне, але не те.

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

Умовно: якщо ви пропишете продукт, додасте Figma і референси — він вийде таким, як ви описали. Але якщо ви ще й скажете, що ваша аудиторія — люди похилого віку або діти, що у вас є конкретні консьорни щодо доступності — то й кожне наступне рішення агента буде узгоджене з цим. І правки він розумітиме краще, бо в нього є контекст, навіщо це все.

Говоріть з AI однією мовою

Якщо ви говорите з агентом мовою інтерфейсу — він розуміє вас набагато краще.

Вивчіть, як називаються речі: ease-in, ease-out, hover state, scroll state, padding, border radius, spring, stagger. Це ключові слова, тільки у світі промтингу. Одним точним словом ви показуєте, що саме хочете, там, де інакше довелося б писати абзац — і все одно вийшло б гірше.

Гарний старт для словника — daiana.art/blog/the-words-that-make-ai-build-what-you-meant, практичний словник термінів інтерфейсу для промптингу AI. «Bounce», «Pulse», «Breathing» і «анімуй мені цей значок» дають дуже різні результати.

Технічна примітка. Це працює і в інший бік: чим більше ви розумієте, як влаштований фронтенд, тим точніше пояснюєте і тим легше потім віддаєте компоненти розробникам. Фронтенд-скіли не обов’язкові, але дуже бажані.

Сайт: з чого починають усі

Найпростіший рівень, і з нього починають усі вайбкодери. Я теж починав звідси.

Як ви могли помітити з попередніх статей — цей сайт повністю зроблено AI-інструментами. Кейси розписані AI. Статті, включно з цією, надиктовані голосом і оформлені AI. Мені просто ліньки писати руками. Це чесно.

Коли я робив свій сайт уперше, я використовував кілька інструментів: один для плану, інший для структури, третій для коду. Зараз усе простіше. Достатньо одного — Claude Code або Codex. Ви начитуєте йому, що хочете, даєте фотографії та картинки кейсів — і він сам збирає все необхідне.

Промти працюють, навіть якщо написати «зроби мені, будь ласка, красиво». Єдине що — перші результати будуть дуже банальними. Слоп, як це зараз називають. Саме тому весь попередній розділ про налаштування агента стоїть перед цим.

Сайтом може займатися будь-яка людина. Тут дійсно немає секретів, окрім контексту і референсів.

Технічна примітка. Сайти будуються на різному: іноді це просто HTML/CSS/JavaScript, іноді Next.js із TypeScript. Для простого портфоліо різниці майже не відчуєте. Різниця з’явиться, коли захочете щось складніше — про це нижче в частині про прототипи.

Веб-платформи: комерційна робота

Тут починається те, заради чого я пишу цю статтю. Пет-проєкти і full-stack дизайн-інженерія (коли ви робите ще й бекенд) — окрема історія, і вона в моєму житті йде після комерційної роботи. Тут я хочу сконцентруватися на реальних клієнтських проєктах.

Що було раніше

Figma. Дизайн-системи. Багато сторінок з документацією. Промальовані стрілочками user flow. Сотні екранів, правил, компонентів, токенів.

Це перевантажувало будь-якого дизайнера і розробника, робило нашу роботу довгою, нудною і максимально складною. За майже сім років мене це чесно замахало — наче я не дизайнер, а будівельник, який має кожну цеглинку власноруч проробити.

Що дає дизайн-інженерія? Можливість покласти цю рутину на агентів. А самому в цей час займатися бізнес-процесами, продуктовою логікою, тестуванням, архітектурою — тим, що реально складне і де потрібна голова.

Перша задача: не втратити source of truth

Коли ми переходили на AI-воркфлоу, перша задача була — максимально скопіювати те, що добре працювало у Figma:

Зараз розкажу, як ми хендлимо це на вебі. Мобілка — трохи пізніше, бо там усе цікавіше.

Крок нуль: скажіть агенту, навіщо цей прототип

Ви буквально пишете: «Я працюю над AI-прототипом, який пізніше буде передано розробникам як джерело правди». Це змінює те, як агент працює. Він розуміє, що:

• дані в прототипі мають бути захардкоджені — тобто замокані всередині прототипу, щоб він працював без підключення до бекенду;
• прототип має показувати edge-кейси, принаймні більшість з них;
• усе, що він створює, хтось буде перевикористовувати.

Дайте агенту доступ до реального продукту

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

Наприклад, до staging environment через вбудований браузер: вводите credentials і даєте агенту проклікати апку. Або хоча б конкретний флоу, який ви редизайните. Ви можете забути про вкладені дропдауни, додаткові поля, дані, які там реально є. Агент, проклікавши, цей контекст побачить.

Не розраховуйте, що він перенесе все ідеально. Але розуміння продукту в нього буде значно більше, ніж зі скріншотів.

Далі два різних флоу: ви робите з нуля або переносите готовий дизайн. Розкажу про обидва.

Флоу 1: з нуля

Тут насправді все просто.

1. Сетапите проєкт.
2. Кидаєте референси — Pinterest, Dribbble, що завгодно.
3. Даєте візуальне розуміння, як це має працювати. Голосом, документами, якщо вже є документація.
4. Пояснюєте, що і над чим ви будете працювати.

Для цього етапу я раджу сильні моделі — Fable або Astra (принаймні на момент написання статті вони були найсильнішими). Щоб агент зрозумів контекст, налаштував його в проєкті і, як то кажуть, зловив вайб.

Після цього для імплементації можна брати слабші моделі — Opus, наприклад. Sonnet не раджу. І дуже класно працює оркестрація: ви просите сильну модель оркеструвати слабшими, і кожна з них займається своїм флоу.

Перша ітерація прототипу, скоріш за все, буде не такою, як ви хотіли. Але ви отримаєте її за пів години-годину роботи агентів, а не за дні або тижні у Figma. Далі — мінорні правки, поки не стане так, як вам подобається.

І ніяких секретних заклинань тут немає. Ви просто пояснюєте: «тут додай кнопку», «тут врахуй ось цей кейс», «тут додай кнопку назад». Агент допускає дуже смішні помилки — нормально. Ви як дизайнер, який заходить у цю сферу, оркеструєте. З часом агенти підлаштовуються під те, як ви думаєте, і стають продовженням вас.

Figma нікуди не зникла

Один із юзкейсів, як я досі використовую Figma: беру дизайн, який зробив агент, і переношу його у Figma через Figma Chrome extension. Воно копіює цілий екран або компонент прямо з браузера (навіть з localhost) у шари Figma.

Далі правлю у Figma — і повертаю агенту або через Figma MCP, або просто скріншотом. «Ось як я це бачу, зроби так». Після кількох ітерацій ви взагалі зрозумієте, як пояснювати дизайн-рішення словами, і Figma буде потрібна ще рідше.

Це особливо виручає, коли агент видає «так собі» результат на редизайні. Пара втиків, мій ідейшн у Figma — і він починає видавати цікаві варіанти.

Chrome extension в дії: екран з localhost → шари у Figma Офіційний приклад · Figma Learn ↗

Консистентність: чому Storybook

Ви можете спитати: окей, прототип зробити можна. А як стежити за консистентністю? Постійно нагадувати агенту, які компоненти використовувати, — важко.

Повністю погоджуюся. І тому дизайн-інженерія — це більше, ніж промт-інженерія. Тут треба розуміти, які інструменти додати до агента, щоб він працював краще. Хтось тримає базу знань у Obsidian — але це саме база знань: текст, ментальні моделі, зв’язки між сторінками, графи. Для компонентів, токенів і візуальних стейтів він не підходить. Хтось робить окрему сторінку в проєкті, де зберігає всі компоненти і edge-кейси. Для маленьких проєктів або сайтів це працює — такий собі аналог UI-кіта у Figma. Але з мого досвіду на великих проєктах така сторінка швидко перевантажується.

Для компонентів мій фаворит — Storybook.

Що це. Storybook — це аналог дизайн-системи у Figma, тільки в коді. Сторінка, де зберігаються всі компоненти, їхні стейти, документація, edge-кейси. Ви заходите на сторінку компонента і бачите всі його стани — точнісінько як раніше в дизайн-системі.

Чому саме там edge-кейси. Якщо у мене є віджет із сотнею edge-кейсів, показувати їх усі в прототипі важко і не завжди потрібно. А в Storybook я додаю всі стани прямо на сторінку компонента. Розробник заходить і бачить. Усе.

Як його отримують розробники. Storybook можна опублікувати як окрему систему з публічним посиланням. Але мої розробники зазвичай просто стягують мій Storybook разом із репозиторієм — і всі оновлення в них є одразу.

Сторінка компонента в Storybook з усіма стейтами: empty, loading, error, edge cases

Я вже писав про це окремо і записав відео на YouTube. Там же безкоштовний скіл для Claude Code, який сам сетапить Storybook у ваш проєкт і слідкує за токенами: github.com/dobzha/dobzha-storybook-ds-skill. Це саме скіл, а не плагін — він ставиться в код, і далі агент його використовує.

Але. Це все одно не гарантує, що агент не помилиться. У ваших rules і промтах усе одно мають з’являтися фрази:

• «звірся зі Storybook»;
• «роби компоненти такими, як у Storybook»;
• «орієнтуйся на Storybook як на джерело правди»;
• «якщо створюєш новий компонент — додай його у Storybook».

AI, як і джуніор-мідл дизайнеру, треба постійно нагадувати, щоб він не вигадував нові компоненти і не хардкодив. Ви — тімлід серед AI-дизайнерів. Але зате розробники отримують джерело правди в компонентах, яке можуть перевикористовувати без здогадок.

Даяна Євчук,
Senior Product Designer / Design Engineer

Інтегруйте дизайн-систему одразу. Якщо у вас є документи, компоненти, стилі, кольори — заводьте їх на самому старті. Набагато простіше сказати агенту «референси існуючі компоненти», ніж потім перероблювати. У мене був неприємний досвід переведення готового прототипу на токени: знадобилося кілька ітерацій, і прототип усе одно не дійшов до тих токенів, які я надіслала з дуже чіткими інструкціями. Перевірити це у великому прототипі майже неможливо. Сетап на початку дає значно більше, ніж ви уявляєте.

Один прототип чи декілька: підхід Даяни

Тут ми з Даяною розходимося, тому цей розділ — її.

Даяна Євчук,
Senior Product Designer / Design Engineer

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

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

Що потрібно для мультипрототиповості:

• окрема дизайн-система для спільних компонентів;
• схожий воркфлоу, з яким ви починаєте кожен прототип;
• shared knowledge — не всередині прототипу, а як окрема база знань проєкту.

Про базу знань. У мене є окремий проєкт зі knowledge по всьому продукту, який за потреби шериться з тім-мемберами. Не важливо, на якій підписці ви його тримаєте, — важливо, що він окремий. І що мені здається кумедним — цей проєкт узагалі не використовується для кодінгу. Тільки як knowledge base: референс для обговорень, для кращих рішень, для ресерчів. Він знає проєкт глибоко, розуміє, як приймаються рішення, що я вважаю важливим — і тому пропонує зазвичай дуже цікаві ідеї.

Коли я сетаплю новий прототип, я викачую базовий knowledge з цього проєкту (плюс knowledge з останніх прототипів), і ці документи стають базою: shell-сторінки, базові кольори, токени, загальний підхід до продукту.

Але чесно: мультипрототиповість інтродюсить шалену кількість додаткової роботи. Тому це рішення треба приймати свідомо.

Чому я скептичний: новий прототип не має всього контексту старого. А робота в старому може почати «фонити» — інтродюсити баги навіть у функціонал, який уже працював. І якщо ви віддаєте цей прототип розробникам, це вилазить боком.

Тому я тримаю один прототип, а контекст ділю всередині нього через markdown-файли: на кожен флоу — свій .md, який описує, як цей флоу працює. Умовно, флоу авторизації має працювати згідно з docs/flows/auth.md, і агент читає його перед тим, як щось там чіпати. Так один прототип залишається читабельним і не перевантажується. Детальніше про цю архітектуру — в розділі про мобілку, бо там вона критична.

Обидва підходи робочі. Обирайте той, який відповідає вашому продукту і розміру команди.

Хочете більше почитати про цей підхід?

Даяна пояснює, як організувати кілька прототипів для одного продукту — або кількох продуктів у спільній екосистемі.

Тестинг-план і ретроспектива

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

Флоу 2: коли дизайн уже є

Ті, хто пробував, знають: перенести дизайн піксель у піксель у прототип важко. Кілька секретів, які допоможуть зробити це якісніше.

1. Не переносьте все одразу.Дехто скидає посилання на Figma-файл і просить агента «проаналізуй усе і перенеси». Це програшна стратегія. Він зробить не те.
2. Спочатку компоненти, потім екрани.Засетапте Storybook під вашу готову дизайн-систему і переносьте компонент за компонентом: модалка, кнопки, хедери, інпути. Усе покроково. Тільки після цього — екрани. Інакше агент буде створювати компоненти з нуля або хардкодити, і ви отримаєте даблворк.
3. Екрани — по флоу.Обираєте флоу, кидаєте агенту скріншоти екранів цього флоу. У промті обов’язково, навіть якщо це вже є в rules, повторюєте: використовуй саме компоненти зі Storybook. Добре, якщо у Figma вони названі так само. Але це не завжди працює.
4. Figma MCP необов’язковий.Так, можна через офіційний Figma MCP або неофіційний Figma Bridge MCP. Я особисто ними не користуюся: з’їдає багато токенів і не завжди дає гарний результат. Мені більш ніж вистачає скріншотів флоу з проханням реалізувати їх на відповідних компонентах. Візуально агент розуміє, як виглядають мої компоненти на скріншоті, і підставляє потрібні.
5. Самоперевірка.Засетапте hook або просто промтом попросіть: після кожного екрана перевір, чи використані компоненти зі Storybook, чи немає захардкоджених компонентів і кольорів.
6. Великий флоу.Якщо за раз не переноситься — розділіть на частини. Або попросіть оркестратора засетапити саб-агентів, кожен на свою частину. Якщо все налаштовано правильно, він розділить сам.

І це, чесно, всі секрети роботи з веб-прототипами. Якщо з’являться нові — допишу.

Як показати прототип клієнту

Найпростіший спосіб — Vercel. Вам потрібно лише запушити прототип на GitHub і імпортувати його у Vercel.

Коротка інструкція для тих, хто ніколи цього не робив:

1. Створіть акаунт на GitHub і новий репозиторій.
2. Скиньте посилання на репозиторій агенту або підключіть GitHub до Claude Code / Codex.
3. Попросіть агента запушити прототип у репозиторій.
4. Зайдіть на Vercel, натисніть Import, оберіть репозиторій.
5. Все. У вас є посилання, яке оновлюється після кожного пуша.

Імпорт репозиторію у Vercel. Офіційний приклад · Vercel Docs ↗

Бонус: з мобільного Claude тепер можна комітити зміни в GitHub. Тобто можна поїхати кудись без ноута, і якщо треба терміново щось пофіксити — зробити це з телефона і перевірити на стейджі у Vercel. Трохи костильно, але значно краще, ніж тягати ноут скрізь.

Design canvas: як показувати екрани менеджерам

Прототип має одну проблему, яку я довго терпів. Він показує один стан за раз. А менеджеру або тестувальнику треба бачити всі: порожній, з помилкою, для нового користувача і для того, хто в продукті вже рік. Раніше я або вбудовував у прототип перемикач станів (нудно робити, і розробники потім думають, що це частина продукту), або пояснював голосом, куди клікнути, щоб побачити потрібний екран.

Тепер у мене є канвас. Як Figma, тільки у view mode.

Design canvas. Це скіл для Claude Code від Володимира, і я хочу окремо подякувати автору, бо інструмент виявився дуже корисним і суттєво спростив мою роботу з менеджерами: github.com/volomydyr/design-canvas. Що він робить: кладе кожен екран і кожен стан прототипу на один канвас, групує їх у user flow і з’єднує стрілками. Важливий момент — на канвасі немає жодного мокапу. Кожен фрейм — це реальний роут прототипу, який запущений з певним закріпленим станом. Тобто те, що бачить менеджер, і є прототип, просто розкладений.

Далі — коментарі. На будь-який фрейм можна залишити коментар, і він летить назад у Claude разом із картинкою. Агент бачить, про який екран мова, і робить правку. Є ще exploration mode: просите Claude накидати кілька варіантів одного екрана, вони з’являються на канвасі поруч, і ви обираєте той, що працює. Це замінило мені частину ідейшну у Figma.

Design canvas: усі екрани флоу на одному полотні, згруповані і з’єднані

Я під це і сетапив свій прототип на Next.js, бо скіл працює саме з Next.js, Tailwind і Playwright. Менеджери й тестувальники тепер відкривають одне посилання на стейджі і бачать усі флоу з усіма станами, замість того щоб проклікувати прототип і питати, де знайти той чи інший екран.

Коментарі від тих, у кого немає Claude. Менеджеру або тестувальнику не треба заходити в Claude Code, щоб залишити фідбек. Для цього я додав CommentLayer: один скрипт на сторінку, і на прототипі або на канвасі з’являються коментарі в стилі Figma. Клікаєте на елемент, залишаєте пін, він зберігає скріншот того, як елемент виглядав у момент коментаря. Все це живе в моїй базі даних, тому я бачу всі коментарі в себе. Найприємніша фіча — коли агент перегенерував ділянку інтерфейсу, коментарі на цій ділянці закриваються самі, а на незмінених — переносяться на нову версію. І відкриті коментарі можна експортувати в md-файл із маршрутом, елементом і скріншотом і просто віддати агенту як список правок.

Технічна примітка. CommentLayer — це review-шар із відкритим доступом на запис, тому він живе тільки на стейджі або за прапорцем. На публічний прод його не ставте.

Що я зараз докручую. На канвасі буде окрема сторінка з компонентами. Не як джерело правди — джерело правди залишається у Storybook — а як view для менеджерів: усі стейти й edge-кейси компонентів в одному місці, щоб не відправляти їх у Storybook, де їм нічого робити.

Мобільні застосунки

Тут значно цікавіше, бо готових рішень немає. Але це можливо.

Мій сетап на реальному редизайні iOS-апки

Я зараз працюю над редизайном нативної iOS-апки. І ось як це влаштовано.

Чому саме так? Бо я спочатку спробував зробити повноцінний iOS-прототип великої апки — і відкрив для себе неприємний факт: це дуже дорого по токенах і значно складніше за веб. Тому UX-частину (флоу, юзкейси) я роблю в HTML, а UI нативних елементів — у SwiftUI. Так я не спалюю токени на повноцінний iOS-прототип, але можу показати компоненти з усіма приколами iOS (скляні ефекти тощо).

Два вікна поруч: Swift-апка з бібліотекою компонентів і HTML-прототип, над якими працює Claude Code

Єдиний мінус HTML: не можна один в один повторити дизайн iOS. Для цього і існує Swift-бібліотека. Другий нюанс — HTML іноді важко тягне великі прототипи. Знаю, що дехто будує прототипи на TypeScript саме тому, що воно працює краще. Мені вистачило HTML, хоча апка немаленька.

Технічна примітка про Xcode. Для мобільних прототипів бажано мати встановлений Xcode. Він не обов’язковий у строгому сенсі, але потрібен, щоб Claude міг запускати симулятор апки на вашому комп’ютері, проклікувати реальний застосунок і переносити логіку. Вам як дизайнеру відкривати Xcode і щось там правити не доведеться. Просто хай буде.

Архітектура .md-файлів

З точки зору архітектури дуже раджу засетапити правильну структуру markdown-файлів. Це працює і для вебу, і для мобілки — і це те, що дозволяє мені тримати один прототип замість кількох.

• Головний .md — пояснює все, що є в апці, і навігує агента.
• .md на кожен флоу — що це, навіщо, які правила в цьому флоу, які стейти.

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

Коли HTML перестає працювати

На досвіді Даяни HTML дійсно дуже швидко справляється з UI. Якщо робити той самий UI на HTML-прототипі і на Next.js-прототипі — до гарного результату дійдете за різний час, і HTML буде швидшим. Тому він класно працює, коли треба зробити невеликий флоу, але UI-перфект.

Але вона стикнулася з проблемою, коли логіка прототипу стала перевантаженою. Якщо треба просто проклікати флоу — HTML ок. Але якщо ви щось змінюєте всередині флоу і воно має залишатися в контексті, показувати варнінги, тости, з’являтися в іншому місці після збереження — ця комплексна логіка не для HTML.

І тоді їй довелося переписувати величезний прототип з HTML на Next.js (TypeScript + React). Це зайняло більше тижня. Тільки на переписування. І це дуже сильно блокує, бо поки ти переписуєш — не можна вносити зміни. Спочатку треба проестимувати, продивитися, задокументувати весь прототип — і тільки потім починати.

Даяна Євчук,
Senior Product Designer / Design Engineer

Спочатку оцініть роботу. Якщо розумієте, що прототип стане комплексним — одразу починайте з TypeScript.

Технічна примітка про версії. Не буду називати конкретну версію React, бо вона застаріє швидше за цю статтю. Але важливо: AI часто ставить стару версію за замовчуванням, а багато фреймворків старі версії вже не підтримують. Тому в rules пропишіть: використовуй якщо не найновішу, то одну з найновіших стабільних версій. І ще одне — перед встановленням нової версії будь-якого пакета попросіть агента перевірити в новинах, чи не була ця версія скомпрометована. Історії з зараженими npm-пакетами трапляються регулярно, і краще витратити хвилину на перевірку, ніж потім розбиратися.

Rules для агента: не давайте йому лінитися

Ми про це говоримо вже пів статті, але тут воно критичне.

У rules для агента варто нагадати базу: перевикористання, наслідування, базове ООП (коли код ділять на невеликі об’єкти з чіткими ролями, які можна перевикористовувати й розширювати) — усе те, що для розробників очевидно, а агенту треба нагадати, щоб не лінився. Скажіть, що ви це розумієте — і він теж не буде халтурити.

І обов’язково — обмеження на кількість рядків у файлі. Агент дуже любить писати все одним монолітом. А моноліт — це один великий камінь: не скейлиться, а якщо щось ламається — ламається все. Ваш агент має писати в різних файлах, мати ліміти і структурований формат коду.

Технічна примітка. Готовий набір rules для агента — структура файлів, ліміти рядків, правила перевикористання, версії — буде у файлі контексту, який можна завантажити на початку статті.

Що ще потрібно для мобілки

Дизайнерські знання. Звучить банально, але саме вони потрібні, щоб пояснити агенту, що і як має працювати нативно. Флоу роботи з мобільними прототипами дуже схожий на веб — головна відмінність у тому, де живе дизайн-система. Мені зручно зберігати її в окремій Swift-апці. Можливо, ви знайдете інше рішення, яке для вас буде ефективнішим. Наразі універсального не існує — і це особливість цього підходу.

Реальний продукт: коли прототип стає продом

Про це я мало не забув розповісти, а це, можливо, найважливіша частина статті. Той самий комерційний продукт із вступу — який я закрив без фронтенд-розробників.

Що це було

Платформа для однієї людини. Клієнт вів усю свою роботу в Excel-таблиці, і задача була цю таблицю діджиталізувати. Його атлети користуються iOS-застосунком, вводять там свої змінні, а ці дані через бекенд прилітають на платформу, де клієнт може все це менеджерити і розуміти, що відбувається.

Я зробив дизайн, зібрав прототип, підключив бекенд-ендпоінти, і дані пішли. Більше деталей не можу — NDA. Але цього досить, щоб розповісти про нюанси, бо вони не про продукт, а про те, як працювати, коли твій прототип більше не прототип.

Спочатку про чесність із собою

Я дизайнер, а не розробник. Хоча і досвід в розробці певний маю. Але я прекрасно розумію, що десь чогось можу не розуміти — особливо там, де це стосується безпеки. Тому перед тим, як віддавати продукт клієнту, я підключив фронтенд-розробника, щоб він проаналізував увесь скоуп: сек’юрність, підключення, як усе відображається. Він апрувнув усе повністю.

Раджу робити так само. Не тому, що AI зробить погано, а тому, що ви як дизайнер не побачите деякі речі просто тому, що не знаєте, куди дивитися. Одна рев’ю-сесія з розробником коштує значно дешевше, ніж дірка в проді.

Ролі: хто за що відповідає

На прототипі ви з агентом працюєте вдвох. На реальному продукті сторін три: ви, агент і бекенд-команда, яка володіє API, авторизацією і даними. Мій розподіл був простим:

• Я — продуктові рішення, пріоритети, стосунки з бекенд-командою і тестувальниками, і go/no-go на кожен деплой.
• Агент — імплементація, перевірка, документація, пам’ять, механіка релізу після мого підтвердження.
• Бекенд-команда — контракт API, авторизація, дані, інфраструктура.

І одне правило, яке важливіше за всі інші: агент може підготувати що завгодно, але ніколи не пушить у гілку, яка деплоїться, без мого явного «так» у тій самій розмові. Не на сесію — на кожну дію окремо. «Пушни на стейдж» не означає прод. Бо коли пуш у гілку — це реліз, ця гілка більше не місце для експериментів.

Handoff-документ: те, що агент читає першим

У проєкті є файл, який агент завантажує на старті кожної сесії. У Claude Code це CLAUDE.md. Він має читатися людиною зверху донизу, і в мене він містить:

• що це за продукт і що він замінює;
• як запустити, які скрипти, які змінні середовища;
• які гілки деплояться при пуші — прямим текстом: «merge в ці гілки — це деплой»;
• контракт із бекендом: таблиця ендпоінтів і окремо — поля, які бекенд пообіцяв, але ще не відправляє, з датою, коли ми їх запропонували;
• рішення і граблі, які не можна відкочувати без причини — кожен запис: що вирішили, чому, і що зламається, якщо повернути назад.

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

І ще: застаріле речення в цьому файлі коштує дорожче, ніж відсутнє. Бо агент йому повірить. Тому кожен розділ, який описує стан, датований, і коли агент бачить, що щось змінилося (гілка з’явилася, remote переїхав), він виправляє це в тому ж коміті і каже про це у звіті.

Технічна примітка. Поки бекенд не готовий, платформа працює на мок-даних, які вмикаються одним налаштуванням. Ці дані ніколи не потрапляють у прод і не містять справжніх імен, ID чи посилань. Реальні експорти клієнта ми не додаємо в git.

Робота з бекенд-командою

• Контракт API лежить у репозиторії і вважається головним документом. Коли документи розходяться, у CLAUDE.md написано, який виграє.
• Нові поля я пропоную письмово, з назвами ключів і форматом. Поки бекенд їх не відправив — інтерфейс показує чесний empty state, а не вигадані дані. Плюс dev-перемикач, щоб показати клієнту, як буде виглядати заповнений стан.
• Помилка в інтерфейсі називає причину. «API відповіло HTML замість JSON» — краще, ніж «unexpected token», бо фікс на іншому боці, і та команда має знати, куди дивитися.

Перевірка перед кожним пушем

Мене не треба просити перевірити руками. Агент перевіряє і показує докази.

Перед будь-яким пушем — локальний gate, завжди в такому порядку:

npm run typecheck && npm run test && npm run build

Далі — перевірка в браузері: запустити, перезавантажити, прочитати консоль і мережу, проклікати, скріншот. Якщо тест впав — процитувати. Якщо крок пропущено — сказати який і чому. Якщо пайплайн пройшов — дати id запуску. «Запушено» не дорівнює «задеплоєно»: агент дивиться пайплайн до кінця і звітує.

Коли тестувальники повідомляють про баг, агент спочатку намагається його повторити й лише потім щось змінює: локально, на задеплоєній версії та в іншому браузері. Якщо проблема була на планшеті — перевіряє і тач. Якщо баг не повторюється, агент записує, що вже перевірив і що ще треба уточнити в тестувальника.

Стейдж і прод

Стейдж — для мене і клієнта. Прод — тільки після того, як стейдж перевірили обидва. Після кожного релізу агент записує в пам’ять, який коміт де стоїть і чи відстає main. Це звучить як бюрократія, поки ви один раз не втратите пів дня, з’ясовуючи, яка версія зараз у клієнта.

А Storybook?

Тут він опціональний. Платформа для однієї людини з відносно невеликою кількістю екранів — і я міг би обійтися без нього. Але якщо ваш продукт буде рости або його підхопить інша команда, Storybook варто заводити з самого початку, як я писав вище. Легше, ніж додавати потім.

Що з цього взяти

Реальний продукт відрізняється від прототипу не складністю коду, а кількістю правил навколо коду. Хто може деплоїти. Що є джерелом правди. Як не втратити дані клієнта. Як розмовляти з бекенд-командою. Усе це не робить агент — це робите ви як продакт-оунер, а агент виконує в тих межах, які ви поставили.

Повний набір цих правил, так, щоб можна було скинути в новий проєкт і почати, буде у файлі контексту на початку статті.

Що змінилося насправді

Я залишився продакт-дизайнером. Ціль моєї роботи та сама. Змінився стек — і змінилося те, на що йде мій час: не на промальовку сотні стейтів, а на логіку продукту, тестування, архітектуру і розмови з бізнесом.

Дизайн-інженерія — це менеджмент, а не «один промт і все готово». Ви ставите контекст, ви перевіряєте, ви повертаєте на доопрацювання, ви не даєте агенту лінитися. Якщо ви це вмієте з людьми — зможете і з агентами. Якщо не вмієте — навчитеся.

Але буду чесним і про мінуси, бо їх є.

Когнітивне навантаження зросло. Коли ти за день збираєш цілий флоу, у голові одночасно живе дизайн, логіка, компоненти, правила для агента, стан прототипу і те, що клієнт сказав на дзвінку. І в цьому потоці легше пропустити мінорну деталь або юзкейс, на який раніше просто був час. Те, що я колись продумував детально, бо іншого варіанта не було, тепер іноді опускається. І потім спливає як недопрацювання — на тестуванні або, гірше, у розробників.

Тому коли ми кажемо «за день можна віддати весь флоу», це не означає, що він буде такої самої якості, як за тиждень чи два у Figma. Швидкість тут купується за рахунок глибини, якщо спеціально за цим не стежити. Треба все одно виділяти окремий час на те, щоб сісти і продумати всі юзкейси, пройтися по edge-кейсах і зафіксувати їх у прототипі. Агент цього за вас не зробить, бо він не знає, чого ви не врахували.

І ні, не всім треба сюди йти. Але якщо ви вирішили — тепер ви знаєте, з чого починати і на що ми з Даяною вже наступили.

Завантажити контекст цієї статті для AI — технічний md-файл з правилами, структурою і воркфлоу, без моїх коментарів — можете тут.