Останні кілька місяців я дедалі більше занурююся у зсув, який зараз обговорюють багато продуктових команд: перехід від класичного design-to-dev handoff до чогось ближчого до design-to-prod.
Дизайн-системи в коді. Storybook. Code Connect. AI-assisted prototypes. Branch-based product environments. Claude Code як один із ключових інструментів у цьому ланцюжку. І, якщо чесно, багато з цього справді вражає.
Ти описуєш задачу — і за кілька хвилин дивишся вже не на черговий статичний Figma frame з прикріпленою до нього надією. Ти дивишся на щось, що запускається. Щось, що можна поклікати. Щось, що можна показати команді.
Це відчувається як стрибок, на який дизайн-індустрія чекала роками: менше ручного складання, менше дистанції між дизайном і кодом, менше handoff-театру.
Але чим глибше я занурювався в цей процес, тим сильніше в мене з’являлося одне незручне відчуття: щось тут не сходиться.
Усі говорять про швидкість. Але хто говорить про вартість фінального результату?
Не першого AI-output. Не першого прототипу. Не першого екрана, який ефектно виглядає в демо.
А результату, який команда справді може прийняти, перевірити, використати, протестувати, передати далі або зашипити.
Тому я почав шукати цифри.
Не скриншоти. Не LinkedIn-захват. Не “ми зібрали це за 20 хвилин”. Не відео, де все чудово працює, бо ніхто не відкрив edge cases.
Реальні цифри: зекономлений час, створений rework, вартість токенів, вартість review, вартість роботи дизайнера, вартість роботи розробника і повна вартість досягнення результату, який команда справді може використати.
Бо головне питання вже не в тому, чи може AI генерувати дизайн-роботу. Може. Головне питання в тому, чи розуміють команди, скільки коштує довести цю роботу до стану, коли вона якісна, консистентна, системна і придатна до використання.
І ось тут починається найцікавіше.
Ми вже не в дискусії “чи замінить AI дизайнерів”
Багато розмов про AI у дизайні досі застрягають в одному й тому самому питанні:
Чи замінить AI дизайнерів?
Я не думаю, що це найкорисніше питання.
Практичніше питання звучить так:
Скільки насправді коштує створити надійний дизайн-результат за допомогою AI?
Бо компанії вже платять за AI. Вони платять за підписки, token usage, експерименти, внутрішні інструменти, навчання, промпти, документацію, agent workflows, engineering support і review time.
Вони також платять за помилки.
Прихована вартість не завжди видна в інвойсі. Вона з’являється в корекції, перевірці, редизайні, рефакторингу, quality control і senior time, який потрібен, щоб перетворити AI-output на щось придатне до використання.
Саме тут питання ROI стає цікавішим.
AI справді може прискорювати окремі частини роботи. Але якщо індустрія вимірює лише швидкість генерації, а не повну вартість прийнятого результату, можливо, ми вимірюємо не те.
Claude Design вражає, але він ще занадто новий для зрілих ROI-висновків
Claude Design — хороший приклад поточного моменту.
Anthropic представила Claude Design як research preview у квітні 2026 року. Його позиціонують як інструмент для створення designs, prototypes, slides, mockups, one-pagers та інших візуальних матеріалів через розмову. Він доступний для користувачів Claude Pro, Max, Team і Enterprise, а Anthropic описує його як інструмент на базі Claude Opus 4.7.
Це важливо.
Якщо продукт досі перебуває в research preview, зрілих публічних доказів його довгострокового ROI для продуктових дизайнерів просто не може існувати.
Можуть бути сильні ранні сигнали. Можуть бути вражаючі демо. Можуть бути команди, які вже отримують цінність.
Але це не те саме, що доведена економіка.
Тому коли хтось каже, що Claude Design трансформує дизайн-процеси, я б ставився до цього як до гіпотези, а не як до виміряного факту.
Інструмент може бути потужним. Напрям може бути правильним. Adoption може бути швидким.
Але облік поки що на ранній стадії.
Як завжди, keynote приходить першим. Інвойс приходить пізніше.
Навіть із Claude Code цифри неоднозначні
Claude Code дає нам кращу точку для аналізу, бо coding agents використовуються довше, а software engineering простіше вимірювати, ніж дизайн.
Там є задачі. Pull requests. Репозиторії. Тести. Review cycles. Баги. Time to completion.
І навіть там цифри не такі прості.
Anthropic опублікувала внутрішнє дослідження з дуже оптимістичною картиною. За даними дослідження, співробітники self-report використовують Claude у 60% своєї роботи й отримують 50% productivity boost. Anthropic описує це як 2–3x зростання порівняно з попереднім роком.
Це важливо.
Але це потребує контексту.
Найоптимістичніші цифри приходять із компанії, яка створює цей інструмент. Вони корисні, але це не нейтральний доказ. Внутрішні дослідження можуть бути цінними як напрямок, але вони мають очевидні обмеження: self-reporting, selection bias, культура компанії, сильна внутрішня експертиза і незвично висока мотивація зробити інструмент ефективним.
А тепер — дослідження METR.
METR провів randomized controlled trial з досвідченими open-source developers, які працювали над власними репозиторіями. Розробники очікували, що AI зробить їх швидшими. Перед початком вони прогнозували, що AI зменшить completion time на 24%. Після завершення дослідження вони все ще оцінювали, що AI скоротив completion time на 20%.
Але виміряний результат показав протилежне: коли розробники використовували AI tools, вони витрачали на 19% більше часу, ніж без AI.
Це один із найважливіших висновків для дизайнерів.
Не тому, що дизайн — це те саме, що кодинг. Ні.
А тому, що це показує: відчуття швидкості й виміряна швидкість можуть сильно розходитися.
Людина може почуватися швидшою, бо AI раніше створює видимий прогрес. Екран з’явився. Прототип запустився. Код компілюється. Сторінка виглядає майже готовою.
Але “майже готово” може бути дорогим.
Іноді “майже готово” — це просто “не готово”, але з кращою типографікою.
Потім METR оновив картину і стало ще цікавіше
У лютому 2026 року METR опублікував update. Нові дані показали певні ознаки speedup, але сигнал залишався шумним і його складно було чисто виміряти.
Для частини original developers METR оцінив можливе прискорення приблизно на 18%. Для нових учасників оцінка була ближчою до 4%. В обох випадках невизначеність залишалася широкою. METR також зазначив, що сам експеримент стало складніше проводити, бо розробники вже не хотіли працювати без AI і почали змінювати підхід до задач.
Можливо, це найреалістичніший опис того, де ми зараз:
AI, ймовірно, допомагає. Але чисто виміряти це стає складніше саме в той момент, коли adoption стає нормою.
Коли AI стає частиною щоденної роботи, ти вже не порівнюєш чисте “до” і “після”.
Ти порівнюєш один мутований workflow з іншим мутованим workflow.
Дизайнер більше не просто створює макет. Він просить AI зробити draft, виправляє його, просить реструктурувати layout, вручну чинить pattern, генерує прототип, рев’ювить код, пояснює engineering, що “це не фінальний код, але ідея там є”, а потім тихо перебудовує половину, бо system logic була неправильною.
То де саме ми вимірюємо productivity?
На першій генерації?
На першому review?
На першому usable prototype?
На accepted result?
На shipped implementation?
Відповідь має значення.
Бо ROI живе в кінці, а не в демо.
Rework tax реальний
Найкорисніша цифра, яку я знайшов для цієї теми, прийшла не з design-specific дослідження. Вона прийшла з ширшого workplace research.
У звіті Workday за 2026 рік сказано, що майже 40% AI time savings були втрачені на rework, включно з виправленням помилок, переписуванням контенту і перевіркою AI outputs. Workday також повідомляє, що лише 14% співробітників стабільно отримують clear, positive net outcomes від AI.
Це той шар, якого бракує в багатьох AI-дискусіях.
Справжня вартість — не генерація.
Справжня вартість — корекція.
Для дизайнерів цей correction layer може бути великим:
AI генерує прототип, але UX-логіка неправильна.
AI створює екран, але component structure не відповідає design system.
AI будує flow, але permissions model відсутня.
AI пише interface copy, але tone of voice неконсистентний.
AI використовує правильний visual style, але неправильний pattern.
AI створює polished happy path, але ігнорує empty, loading, error, disabled, blocked і edge states.
AI створює код, але його потрібно рефакторити, перш ніж розробники зможуть його прийняти.
Це не означає, що AI марний.
Це означає, що час, зекономлений на початку, може частково або повністю з’їдатися наприкінці.
І якщо ми не вимірюємо кінець, ми не знаємо ROI.
Перший output — це не фінальний результат
Це центральна проблема.
AI tools дуже добре роблять прогрес видимим рано.
Ти просиш прототип. Щось з’являється.
Ти просиш landing page. Щось з’являється.
Ти просиш dashboard. Щось з’являється.
Ти просиш “clean B2B SaaS interface with a modern enterprise feel, but not too enterprise, more friendly, but still professional”.
На жаль, щось з’являється знову.
І саме тут починається ілюзія.
Бо тепер у тебе є візуальний доказ роботи. Щось існує. Воно виглядає майже переконливо. Його можна відкрити. Його можна поклікати. Його можна показати.
Але продуктові команди не ship’ять перші outputs.
Вони ship’ять reviewed outputs.
Вони ship’ять роботу, яка пройшла design review, product review, engineering review, accessibility review, data constraints, system constraints і stakeholder approval. Іноді ще й випадкову людину, яка запізнилася на зустріч, але чомусь тепер має найсильнішу думку.
Тому корисне розділення таке:
Generated output — це не те саме, що acceptable result.
Generated output — це те, що AI дає спочатку.
Acceptable result — це те, що команда справді може використати.
Різниця між ними — це місце, де живе прихована вартість AI.
NN/g каже приблизно те саме, просто ввічливіше
Nielsen Norman Group писала у 2025 році, що AI design tools стали кращими, але здебільшого в narrow-scope tasks, і що більшість design-specific AI tools досі не можуть відтворити якість human designer output.
Це важливий момент.
AI може створити artifact.
Але artifact — це не judgment.
Інтерфейс може виглядати як інтерфейс. Але це не означає, що він розуміє користувача, workflow, business logic, product constraints, permissions model або edge cases.
AI може згенерувати таблицю з filters, search, empty state і кнопкою “Create”.
Але він може не зрозуміти, що саме в цьому продукті empty state не повинен пропонувати create action, бо користувач не має permission, дані надходять із зовнішньої інтеграції, і реальний стан — не “empty”, а “failed sync”.
Оце і є дистанція між “looks fine” і “can be used”.
І ця дистанція дорога.
ROI потрібно вимірювати на accepted result, а не на генерації
Якщо ми хочемо серйозно говорити про AI ROI у дизайні, нам потрібно перестати вимірювати лише “time to generate”.
Це demo metric.
Вона хороша для відео.
Вона погана для управління продуктовими командами.
Бізнес-метрика має бути ближчою до:
Cost per Acceptable Result
Проста версія моєї формули:
Cost per Acceptable Result = AI tool cost + token cost + human setup time + prompting time + review time + correction time + implementation cleanup + QA time
А швидкість треба вимірювати так:
Real Speedup = manual baseline time − total AI-assisted time to accepted result
Не так:
“Claude generated this in 10 minutes.”
Ця цифра цікава, але неповна.
Справжнє питання:
Скільки часу зайняв шлях від задачі до того, що команда може впевнено використати?
А потім:
Чи це було дешевше, ніж попередній процес?
Ось де живе ROI.
Усе інше — демо.
Вартість токенів видима. Вартість людської корекції — ні
Claude Code має вимірювану операційну вартість. Документація Anthropic каже, що Claude Code тарифікується через API token consumption, а витрати залежать від model selection, codebase size і usage patterns. Для enterprise deployments Anthropic вказує середню вартість близько $13 per developer per active day, або $150–250 per developer per month, при цьому для 90% users витрати залишаються нижчими за $30 per active day.
Це корисно, бо token cost можна виміряти.
Але token cost, ймовірно, не найбільша вартість.
Більша вартість — це людський шар навколо інструменту:
дизайнер готує контекст;
senior designer перевіряє результат;
design systems person виправляє component drift;
engineer перевіряє, чи код придатний до використання;
product manager ловить зламані assumptions;
команда переписує документацію, щоб AI наступного разу зрозумів систему.
Ось чому ROI складний.
Інвойс показує, скільки коштує AI tool.
Він не показує, скільки організаційного часу було витрачено, щоб зробити AI-output usable.
AI не прибирає структуру. Він вимагає більше структури
Саме тут, на мою думку, дизайн-індустрія недооцінює зсув.
Багато хто говорить про AI так, ніби він зменшує потребу в дизайн-системах, документації та процесі.
Я думаю навпаки.
AI робить структурований дизайн більш цінним, а не менш.
Якщо ваша design system чиста, компоненти існують у коді, patterns задокументовані, tokens стабільні, states визначені, component APIs зрозумілі, а rules machine-readable — AI має з чим працювати.
Якщо ваш продуктовий контекст живе в головах людей, AI змушений вгадувати.
А вгадування — дороге.
Справжня вартість AI у дизайні — це не лише підписка. Це вартість того, щоб зробити продуктовий контекст зрозумілим для машини.
Це означає інвестиції в:
design system architecture;
component documentation;
pattern documentation;
Storybook;
Code Connect;
tokens;
component APIs;
interaction rules;
access and permission logic;
state models;
copy rules;
examples;
agent instructions;
review checklists.
Перш ніж AI зможе надійно прискорити дизайн, дизайн-організація має стати більш explicit.
Ось парадокс:
AI обіцяє швидкість, але винагороджує підготовку.
Команди зі зрілими системами можуть побачити сильний виграш.
Команди з messy systems можуть просто генерувати хаос швидше, впевненіше і з кращими тінями.
Якість самого інструменту — це також production risk
Ще один незручний момент: AI tools — це не статична інфраструктура.
Вони змінюються.
Anthropic опублікувала postmortem у квітні 2026 року після повідомлень користувачів про проблеми якості Claude Code. Компанія визначила product-level issues, включно зі зміною default reasoning level, багом, пов’язаним із context clearing, і зміною system prompt, яка мала зменшити verbosity, але погіршила coding quality, перш ніж її відкотили.
Це важливо, бо команди починають будувати workflows навколо цих інструментів.
Якщо команда залежить від Claude Code або Claude Design для production-like prototyping, тоді зміни всередині model, prompt layer, context handling, rate limits, product settings або cost controls можуть впливати на якість output команди.
У традиційному software ми розуміємо dependency risk.
З AI tools цей dependency risk стає більш fluid.
Той самий prompt, який працював минулого місяця, може поводитися інакше наступного місяця.
Той самий agent workflow може стати дорожчим.
Та сама model може стати кращою в одному типі задач і гіршою в іншому.
Та сама команда може бути змушена оновлювати instructions, examples і review process.
Ця maintenance cost теж має бути частиною ROI.
Чому дизайнери можуть відчувати себе швидшими, навіть якщо система не стала дешевшою
Я вірю, що багато дизайнерів справді почуваються швидшими з AI.
Це відчуття не фейкове.
AI зменшує біль старту. Він дає щось, на що можна реагувати. Він створює visual momentum. Він може швидко перетворити абстрактний intent на clickable prototype. Він може допомогти дизайнерам дослідити більше варіантів і наблизитися до implementation.
Це цінно.
Але відчувати себе швидшим — не те саме, що зробити систему дешевшою.
Дизайнер може зекономити дві години на першому draft, а потім витратити дев’яносто хвилин на виправлення layout, тридцять хвилин на переписування copy, одну годину на alignment із design system, одну годину з engineer на виправлення implementation details і ще одну годину на cleaning edge cases.
У такому випадку AI не прибрав роботу.
Він перемістив роботу.
Від creation до verification.
Від drawing до correction.
Від production до orchestration.
Від execution до judgment.
Це все ще може бути кращим workflow.
Але це потрібно чесно вимірювати.
Відсутня метрика: Cost per Acceptable Result
Якби я мав запропонувати одну метрику для AI-assisted design teams, це була б:
Cost per Acceptable Result.
Не cost per prompt.
Не cost per prototype.
Не time to first screen.
Не кількість generated variants.
А саме cost per acceptable result.
Acceptable result — це результат, який відповідає визначеному quality bar:
вирішує intended user problem;
відповідає design system;
використовує правильні components;
включає key states;
поважає accessibility requirements;
може бути reviewed by engineering;
може бути tested with users or stakeholders;
не потребує disproportionate cleanup.
Коли ви визначили цей bar, можна порівнювати:
manual process vs AI-assisted process;
junior designer plus AI vs senior designer without AI;
design-only prototype vs code-based prototype;
Claude-generated prototype vs Figma prototype;
AI-assisted component usage vs manual component assembly.
Лише тоді можна говорити про ROI.
До цього ми здебільшого вимірюємо, як швидко щось з’являється на екрані.
А це не productivity.
Це screen manifestation.
Що командам варто почати вимірювати
Якщо команда хоче зрозуміти, чи AI справді допомагає, я б не починав із 70-сторінкового AI transformation framework.
Їх уже достатньо. Більшість із них уже читаються так, ніби їх написав AI, який втомився читати інші AI frameworks.
Я б почав із простої таблиці.
Для кожної AI-assisted task варто відстежувати:
Task type
Prototype, UI exploration, component implementation, flow redesign, copy generation, design system documentation, design-to-code handoff.Baseline estimate
Скільки це зазвичай займало б без AI?AI setup time
Скільки часу пішло на підготовку prompt, context, files, screenshots, rules або references?Generation cost
Tokens, subscription, tool cost, number of iterations.Review time
Скільки часу людина витратила на перевірку output?Rework time
Скільки часу пішло на виправлення output?Quality score
Чи відповідає результат design system, UX, accessibility і engineering bar?Accepted or rejected
Результат справді використали?Final time to acceptable result
Повний час від start task до accepted output.Real ROI
AI-assisted path зменшив total cost порівняно з baseline?
Це не має бути ідеальним.
Але навіть lightweight tracking буде кращим за поточну ситуацію, коли багато команд ухвалюють рішення на основі excitement, а не evidence.
Бо “it feels faster” — не найкраща одиниця вимірювання бюджету.
Ми все ще у фазі віри
Мій висновок не в тому, що AI overhyped або useless.
Це було б занадто просто і, ймовірно, неправильно.
Claude Code, Claude Design і подібні інструменти справді важливі. Вони змінюють те, як команди думають про prototypes, implementation, design systems і relationship between design and code.
Але я думаю, що ми все ще перебуваємо у фазі віри в AI adoption у дизайні.
Віра сильна.
Демо переконливі.
Інструменти швидко розвиваються.
Тиск “треба впроваджувати” реальний.
Але accounting незрілий.
Багато команд витрачають гроші ще до того, як знають, як вимірювати return. Вони спалюють токени, але не завжди рахують результат. Вони святкують швидкість, але не завжди вимірюють rework. Вони порівнюють AI generation із manual production, але не порівнюють accepted AI output з accepted manual output.
Ось у чому gap.
І це не anti-AI argument.
Навпаки.
Якщо AI має стати серйозним production layer у дизайні, ми маємо вимірювати його як production layer.
Бо AI у дизайні — це не free acceleration.
Це новий production layer.
А будь-який production layer має setup costs, operating costs, maintenance costs, quality risks, dependency risks, training costs і ROI questions.
Індустрії не бракує AI-ентузіазму.
З цим усе добре. Іноді навіть занадто добре.
Індустрії бракує AI accounting.
Ми знаємо, як швидко AI може щось згенерувати.
Але ми досі недостатньо дисципліновано знаємо, скільки коштує зробити це “щось” usable, consistent, system-aware і reliable.
Поки ми цього не вимірюємо, ми насправді не вимірюємо productivity.
Ми вимірюємо магію.
А магія чудово виглядає в демо.
Але рахунок усе одно приходить.
Топ коментарі (0)