Claude Design: межа між генерацією і продуктом. Ілюзія готового інтерфейсу

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

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

Мене звати Олена Івлєва, маю 15 років досвіду в дизайні, фронтенді та інженерінгу і працюю у Kavita Systems. Для мене дизайн давно не про «зробити красиво», а про систему рішень, яка або працює в реальному продукті, або дуже швидко показує, де саме вона розсипається.

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

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

Експеримент: коли AI пише промпт сам для себе

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

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

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

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

Наступним кроком я взяла цей згенерований бриф і використала його як вхідні дані в Claude Design без додаткових пояснень або ручних правок. І на виході отримала лендинг.

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

Але що бачу я. Рішення максимально шаблонне: просте, передбачуване і без ідеї. Усе ніби правильно, але немає відчуття, що це дизайн як відповідь на задачу, а також немає зв’язку з реальними потребами користувача.

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

Claude не замінює систему. Він показує, де її немає

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

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

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

І ще один момент, який варто відзначити — Claude Design добре комбінує знайомі шаблони та перевірені рішення, але не створює нові. Він робить те, що ти просиш, але не додає унікальності. У результаті виходить щось правильне на вигляд, але без ідеї. У свою чергу унікальність виникає тільки там, де є робота з ідеєю, контекстом і самим продуктом.

Під капотом: коли «схоже на фронтенд» — ще не фронтенд

Після візуалу я така: окей, а що там по коду? Бо зовні все виглядає більш ніж нормально — HTML, CSS, JSX, навіть щось схоже на component library. І в якийсь момент реально ловиш себе на думці: ну все, майже готовий фронтенд. А потім відкриваєш архів із Claude Design... і починається магія. Тобто виглядає як фронтенд, прям дуже схоже. Але працює... ну, скажімо так, не як фронтенд. Я для себе це назвала frontend-shaped code — коли ніби качка, ходить як качка, але в прод ти її не пустиш.

Ніякого нормального build process, routing та середовища просто немає. React крутиться через @babel/standalone, JSX прямо в браузері. Для демки виглядає ефектно, але в прод ти це, чесно, не понесеш. Із інтерактивністю така ж історія: UI ніби живий, щось клікається та рухається, втім, логіка або обірвана, або її просто немає.

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

Я додала одну кнопку, і це змінило всю розмову

Я пішла далі та вирішила перевірити Claude Design не на стартовій генерації, а на редагуванні вже створеного прототипу. Адже саме тут і починається реальна робота дизайнера: не коли ти створюєш щось з нуля, а коли щось потрібно змінити. Взяла максимально простий кейс: додати кнопку, яка відкриває modal. Така собі задача «на 10 хвилин». Claude щось згенерував. На вигляд усе ок. Але клікаю та розумію, що логіка працює десь наполовину.

Уточнюю промпт, Claude відповідає, але замість того, щоб допрацювати попереднє рішення, просто генерує нове. Тепер хоча кнопка і модалка виглядають так, як я просила, але як система це вже не працює. Так, кнопка не відкриває модалку, а модалка просто десь поруч існує. І так кожного разу. Логіка не накопичується, а щоразу будується заново. Особливо це видно на адаптиві: підправляєш mobile — ламається desktop.

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

Частина, про яку мало говорять: економіка ітерацій

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

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

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

Бо дизайн — це не тільки результат. Це ще й шлях, яким ти до нього приходиш.

Де саме Claude Design корисний

Якщо прибрати хайп, усе зводиться до простого: де він реально працює?

Найкраще — там, де потрібен швидкий старт. Лендинги, прості сторінки, MVP, базові onboarding-флоу. Коли важливо не ідеально, а швидко зробити щось видимим. Тут він дійсно економить час.

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

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

Іноді він може допомогти з дрібними змінами там, де немає дизайнера, бути базовою точкою старту.

Але важливо не плутати старт із результатом. Claude Design — це не фінальний дизайн і не продукт. Фактично це чернетка, інструмент мислення та швидкий спосіб винести ідею назовні.

Хто ж насправді у зоні ризику?

Не дизайнери.

Найбільший ризик — у сервісів і платформ, які роками продавали швидкість як продукт. Тобто пропонували шаблони, конструктори, «сайт за день», готові лендинги тощо. Зараз це стає дефолтною фічею. Те, що раніше було окремим продуктом, перетворюється на кнопку Generate: шаблонні сайти, стандартні UI-патерни, базовий фронтенд — усе швидко автоматизується. Тому під найбільшим тиском не дизайнери, а продукти, побудовані навколо ідеї fast enough design. Бо fast enough дуже швидко стає інфраструктурою.

Де закінчується автопілот і починається відповідальність

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

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

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

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

Claude Design може бути першим кроком, та далі починається справжня робота — там, де є повний контроль: над логікою, станами і системою в цілому.