Після хендофу: як AI поєднує дизайн і розробку

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

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

Модель була зрозумілою: дизайн робив план, розробка будувала продукт. Але вона трималася на крихкому припущенні: що дизайн треба перекласти з одного файлу в інший в один визначений момент. Майже ніхто її не захищає. В опитуванні Figma 2025 року 91% розробників і 92% дизайнерів сказали, що хендоф можна покращити.

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

І проблема рідко в людях. Дизайнери, розробники й продакт-менеджери здебільшого добре знають свою справу. Гальмує інше: те, де живе робота: дизайнери у файлах Figma, продакти на бордах і в прототипах на власних ноутбуках, розробники в коді. Кожне місце окремо має сенс. Разом вони створюють кілька версій одного продукту.

“

Хендоф замінює не менша дисципліна. Його замінює безперервна робота в одній спільній системі.

Прихована ціна хендофу

Здалеку хендоф може виглядати ефективно. Одна команда закінчує, інша починає, і кожен етап має зрозумілого власника. Зблизька ця модель створює чотири види витрат. Перший: очікування. Розробник натрапляє на питання, а дизайнер уже працює над іншою фічею. Відсутній стан перетворюється на тікет. Маленька правка тексту чекає, поки оновлять макет. Сама зміна займає хвилини, а черга навколо неї займає дні.

І це накопичується. За даними Design Systems Collective, розробники витрачають близько 4,5 години на тиждень лише на те, щоб зʼясувати питання щодо дизайну. Другий: переклад. Екран показує результат, але рідко міркування за ним. На ньому не видно відкинутих варіантів, бізнес-правила, що визначило композицію, чи крайнього випадку, який змінив взаємодію. Поки робота дійде до розробки, більшість цього контексту стиснеться до коментарів і описів у тікетах.

Третій: наздоганяння. Справжній продукт приносить те, чого не було в макеті: реальні дані, довгі назви, повільне завантаження, помилки, різні розміри екранів, технічні обмеження. Дизайн і продукт починають розходитися, і команда витрачає час, щоб зʼясувати, яка версія актуальна. За оцінкою Nielsen Norman Group, переробки після хендофу забирають 15–30% часу розробки.

Четвертий вид витрат новіший, і AI його посилив: фрагментація. Тепер будь-хто може зібрати робочий прототип за пів дня. Продакт-менеджер збирає ідею з AI-інструментом на своєму ноутбуці, кілька днів її доробляє й надсилає дизайнеру файл із «кількома правками». Дизайнер коригує власну копію. Розробник перебудовує вдалі частини з запису екрана. За тиждень у команди пʼять версій того самого прототипу, і жодна з них не є продуктом.

“

Проблема не в тому, що людям бракує навичок. А в тому, що кожен вправний у своїй окремій копії.

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

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

Команди й раніше намагалися це виправити: спільні чати, ранні ревʼю, бібліотеки компонентів.

“

«Код не є протилежністю дизайну. Код є матеріалом для дизайну».

Різниця в тому, що тепер дизайн і код починають бути справді повʼязаними, а не лише розмовляти одне з одним.

Дизайн-рішення можуть рухатися як дані

Візьмімо колір. Його більше не треба вручну переносити з Figma в код. Його можна визначити один раз, дати йому назву й використовувати всюди: на сайті, в iOS-застосунку, в Android. Дизайнерам не треба знати, як це влаштовано всередині, бо про це дбають інструменти й розробники. Важлива сама ідея: одне рішення, ухвалене один раз, потрапляє в кожне місце, де воно використовується. Коли так стається, дизайн-система перестає бути бібліотекою, яка описує продукт. Вона стає частиною того, як продукт будується.

Агенти можуть працювати всередині дизайн-середовища

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

Цикл тепер працює в обидва боки

Працює це й у зворотний бік. Робочий інтерфейс можна повернути у Figma як фрейми, які можна редагувати. Команда може порівнювати, коментувати, пробувати альтернативи й повертати обраний напрям у розробку. Це вже не прогноз. У лютому 2026 року Figma та Anthropic оголосили партнерство, збудоване саме навколо цього двостороннього шляху між кодом і полотном.

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

Інструменти змінюватимуться швидко. Незмінним лишиться інше: код і Figma стають двома поглядами на той самий продукт.

Дизайнери можуть змінювати джерело продукту напряму

Саме це найбільше змінило мою власну роботу. Коли Claude підключений до GitHub (там, де живе код продукту), я можу попросити зміну в дизайн-системі чи інтерфейсі й отримати її прямо в продукті: колір, новий стан кнопки, виправлений відступ. Я не перемальовую це у Figma й не чекаю, поки хтось перебудує. І ні, це не потрапляє одразу до користувачів. Зміна приходить окремою версією з посиланням на прев'ю. Розробники її переглядають, а хтось вирішує, коли публікувати. Я не читаю код, і мені не треба, бо ревʼю коду лишається за розробниками. Але моя робота починається в справжньому продукті, а не у власній копії.

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

Зсув не в тому, що всі пишуть код

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

“

Усі працюють з одним джерелом правди. Ніхто не мусить працювати через той самий інтерфейс.

Дизайнер працює у Figma й через AI-агента. Розробник працює в коді. Продакт-менеджер збирає прототипи у спільному проєкті й оновлює тексти там, звідки їх бере продукт. Кожен лишається в зручному для себе інструменті, а кольори, компоненти, тексти й рішення лишаються повʼязаними. Нікому не треба опановувати нову професію. Команда просто перестає чекати, поки хтось інший перекладе кожну дрібну частину задумки.

Найсильніше заперечення проти уніфікації

Не всі погоджуються, що обʼєднання є метою. Каррі Саарінен, один з авторів дизайн-системи Airbnb, а тепер CEO Linear, погоджується, що під час хендофу інформація губиться:

“

«Хендофи втрачають інформацію».

Але він також попереджає: у повного обʼєднання є тіньовий бік. Його аргумент такий. Спільні системи піднімають підлогу. Вони спрощують узгодженість, звільняють команду від повторних рішень і допомагають і людям, і AI робити те, що пасує продукту. Але вони ж можуть непомітно опустити стелю, якщо найлегший шлях завжди найзвичайніший. Коли кожен новий екран збирають із тих самих деталей, продукт починає визначати звичка. Компонент, створений заради узгодженості, стає причиною не пробувати кращу взаємодію. Правило, написане, щоб AI був передбачуваним, підміняє судження.

Він має рацію, і це не послаблює аргумент за одне джерело правди, а загострює його. Стає зрозуміло, що саме варто обʼєднувати.

Обʼєднуйте те, що має лишатися узгодженим: кольори й типографіку, компоненти, тексти, правила доступності. Не обʼєднуйте те, як люди думають, шукають і ставлять систему під сумнів. Тож здоровій дизайн-системі потрібен простір, щоб із неї виходити. Команди мають змогу тестувати новий патерн, перш ніж робити з нього компонент. Дизайнери можуть шукати поза бібліотекою. Розробники можуть питати, чи спільний компонент досі відповідає продукту. Спільна система є інфраструктурою для добрих рішень. Щойно вона починає вирішувати, що варто пробувати, вона стає обмеженням для самого продукту.

Як виглядає одна маленька зміна

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

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

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

Рішення не зникли. Відповідальність теж. Зникли кілька очікувань між людьми, які вже розуміли ту саму проблему.

Хто за що відповідає

Спільний доступ працює лише тоді, коли всі досі знають, хто за що відповідає.

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

“

«Агент бере на себе виробництво, ви берете на себе продуктове мислення».

Що ламається, коли команди впроваджують це погано

Ревʼю стає театром

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

Доступність тихо погіршується

Згенерований екран може виглядати правильно й водночас підводити людей, які користуються клавіатурою чи скрінрідером: неправильний порядок фокуса, відсутні підписи, слабкий контраст у деяких станах, забагато анімації. До того ж про доступність часто згадують запізно: за даними Level Access, лише 27% організацій займаються нею ще на етапі дизайну. AI не вигадує нових проблем. Він масштабує той стандарт якості, який у команди вже є. Якщо доступність вбудована в компоненти й ревʼю, AI допомагає застосувати її всюди. Якщо це чекліст, який відкривають перед релізом, команда просто швидше робитиме недоступні екрани.

Figma і код розходяться

Багато команд кажуть, що мають одне джерело правди, але тримають один набір кольорів у Figma, а інший у коді. Назви збігаються, та кожна зміна залежить від того, чи хтось не забуде оновити обидва. Це поширена історія. В огляді дизайн-систем 2026 року 84% команд сказали, що використовують спільні дизайн-значення, але багато хто досі тримає два окремі набори.

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

Швидкість підміняє мислення

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

Локальні копії повертаються

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

З чого почати

Не починайте з агентів. Почніть із рішення, де живе продукт.

1. Назвіть одне джерело

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

2. Заберіть прототипи з ноутбуків

Кожен прототип, який варто показати, живе у спільному проєкті й має посилання. Жодних zip-файлів, «у мене на ноутбуці працює» чи «зараз скину свою версію». Якщо команда не може його відкрити, він ще не готовий до обговорення.

3. Підключіть інструмент кожної ролі до цього джерела

Дизайнери працюють у Figma й через AI-агента, підключеного до продукту. Продакт-менеджери працюють у спільних прототипах і там, де живуть тексти. Розробники працюють у коді. Різні двері, одна кімната.

4. Тримайте версії й релізи явними

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

Одне джерело, і всі в ньому

Хендоф ніколи насправді не був про повільних дизайнерів чи нетерплячих розробників. Це був обхідний шлях для часу, коли дизайн, продукт і код не могли жити в одному місці. Цей час минає. Figma, борд, прототип і код тепер можуть підʼєднуватися до одного місця. Лишається складніша частина: домовитися перестати тримати приватні копії. Пʼять версій одного прототипу не є ознакою продуктивної команди. Це ознака команди, в якої немає спільного місця для роботи.

“

Годі передавати продукт по колу. Працюйте над ним разом, в одному місці.

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