UXPUB 🇺🇦 Дизайн-спільнота: Nick Chukreiev

Ти вчиш більше і розумієш менше. Стів Джобс мав відповідь на когнітивне перевантаження.

Nick Chukreiev — Tue, 09 Jun 2026 12:54:48 +0000

Ти не зламаний через ШІ. Просто твій мозок не був створений для цього

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

Ця стаття виросла з тієї розмови.

Якщо ти зараз відчуваєш, що всі навколо рухаються, вчаться, «ростуть разом із ШІ», а ти стоїш на місці і не розумієш, що саме маєш робити, ти не один. І з тобою все гаразд. Дочитай до кінця, і ти зрозумієш чому.

Як це працювало раніше

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

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

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

Що сталося потім

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

Потім у листопаді 2022 року з'явився ChatGPT.

За кілька тижнів інструмент, який до того існував лише в дослідницьких лабораторіях, опинився в руках ста мільйонів людей. За ним пішли Midjourney, Claude, Gemini, Sora і десятки інших — буквально щотижня.

І разом із ними прийшла повінь порад.

Вивчай промпт-інжиніринг. Ні, справжній пріоритет управління ШІ-агентами. Ні, найважливіше грамотність у роботі з даними. Ні, виживуть лише ті, хто має сильні soft skills, бо ШІ забере все інше. Ні, вивчай Python. Ні, вивчай аналіз даних. Ні, стеж за цими двадцятьма авторами щодня…

Результат від усього цього навчання? Незрозумілий. Терміни? Невідомі. Фінішна лінія? Її не існує, бо ринок змінюється швидше, ніж хтось встигає закінчити курс.

Саме тут мозок починає ламатись. Не як фігура мови. Буквально.

Чому мозок реагує саме так

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

Я детально писав про ці закони раніше у своїй статті «Гештальт-принципи: шість законів, які пояснюють, чому деякі UX-інтерфейси відчуваються неправильними», якщо хочеш глибше зрозуміти механіку, це гарне місце для старту.

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

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

Закон простоти (Prägnanz). Мозок завжди намагається звести складність до чіткої, завершеної форми. Коли це неможливо, вмикається захисна реакція. У різних людей вона виглядає по-різному: одні впадають у заперечення («це все хайп, про нього забудуть за рік»), інші у параліч («я не знаю, з чого почати, тому не почну»), треті просто живуть із постійною фоновою тривогою, не розуміючи, звідки вона.

Це не слабкість характеру. Це архітектура. Мозок робить рівно те, для чого був створений: намагається знайти форму. Просто ніхто йому її не дає.

Що сказав Джобс і де я це почув

Кілька тижнів тому я слухав епізод подкасту The Diary of a CEO зі Стівеном Бартлеттом. Гостем був Кевін О'Лірі, інвестор і підприємець. У якийсь момент він розповів історію, яка міцно засіла в мене в голові.

На початку 1990-х О'Лірі співпрацював зі Стівом Джобсом над освітнім програмним забезпеченням для Apple. З цієї співпраці він виніс один принцип, який застосовує досі.

Джобс назвав його Сигнал проти шуму.

Сигнал — це 3–5 речей, які ти маєш зробити сьогодні. Конкретно. У наступні 18 годин. Ті, що насправді рухають результат уперед.

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

За словами О'Лірі, Джобс працював у режимі «80% сигнал, 20% шум» — більшість часу він присвячував критично важливим кільком задачам, а все інше вважав відволіканням. Це був не геній у звичному розумінні. Це була здатність у будь-який момент сказати: ось сигнал, ось шум — і захищати сигнал з абсолютною послідовністю. (The Diary of a CEO, Storyboard18)

Джобс сформулював це так:

«Люди думають, що фокус означає говорити "так" тому, на чому треба зосередитись. Але це зовсім не так. Це означає говорити "ні" сотням інших гарних ідей».

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

Що з цим робити

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

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

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

Фільтруй джерела, а не інформацію. Обробити весь потік неможливо. Набагато продуктивніше обрати 3–5 людей, яким ти довіряєш у конкретній темі, і стежити тільки за ними. Це і є принцип сигналу на практиці.

Прийми незнання як нормальний стан. Зараз ніхто не знає, як все виглядатиме через рік. Буквально ніхто. Ні великі компанії, ні відомі експерти, ні дослідницькі інститути. Тривога від невизначеності нормальна реакція на об'єктивно невизначену ситуацію. Це не симптом твоєї непідготовленості.

Підсумок

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

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

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

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

AI пише код. Дизайнерам час розібратися з Git

Nick Chukreiev — Tue, 05 May 2026 07:44:10 +0000

Останні кілька місяців я все частіше ловлю себе на тому, що працюю з речами, які раніше впевнено жили “на боці розробки”.

Не тому, що я раптом вирішив стати frontend-розробником. Ні. Я все ще дизайнер. Але дизайн дедалі рідше закінчується у Figma.

Коли ти працюєш із дизайн-системами в коді, Storybook, Claude Code, реальними компонентами, AI-прототипами та design-to-code процесами, дуже швидко стає очевидною одна незручна річ:

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

І ось тут з’являється Git.

Для багатьох дизайнерів Git довгий час здавався чимось з інженерного підвалу. Гілки, коміти, pull request, merge conflict, термінал, білий текст на чорному фоні. Не зовсім те місце, де дизайнер хоче провести свій день.

Максимум: відкрити посилання на GitHub, подивитися README, ввічливо кивнути й закрити вкладку.

Але ситуація змінилася.

AI-інструменти тепер дозволяють дизайнерам робити значно більше, ніж просто описувати інтерфейс. Можна попросити Claude поправити layout, додати empty state, зібрати екран із компонентів дизайн-системи, адаптувати мобільну версію або підготувати інтерактивний прототип, який набагато ближчий до реального продукту.

Звучить чудово.

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

І якщо раніше дизайнер міг сказати: “Git — це не моя зона”, то зараз така позиція починає заважати.

Не тому, що кожен дизайнер має стати інженером.

А тому, що дизайнер, який працює з AI та кодовими прототипами, має розуміти базову механіку змін.

Git — це не про те, щоб писати складну backend-логіку або сперечатися про ідеальну архітектуру React-застосунку.

Для дизайнерів Git — це про значно простіше:

Як безпечно спробувати ідею, зберегти результат, показати його команді й не зруйнувати основний продукт?

Саме про це ця стаття.

Це не повний курс Git для розробників.
Не “50 команд, які ви забудете через 20 хвилин”.
Це практичне пояснення Git для дизайнерів: що таке репозиторій, гілка, коміт, pull request і чому все це важливо, коли AI уже пише код поруч із вами.

Git — це історія змін

Якщо дуже просто, Git — це система контролю версій.

Для дизайнерів найближча аналогія — Version History у Figma.

Ви вносите зміни у файл. Зберігаєте версії. Можете подивитися назад і відновити попередній стан, якщо потрібно. Git робить схожу річ, але для коду й файлів проєкту.

Тільки Git значно потужніший.

Він допомагає:

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

Тобто Git — це не просто “інструмент для розробників”.

Він відповідає на дуже продуктові питання: Що змінилося, хто це змінив, навіщо це було змінено і чи можемо ми безпечно додати це в продукт?

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

Без Git AI-експерименти дуже швидко стають хаотичними.

Учора Claude щось змінив. Сьогодні прототип наче працює. Потім ви просите його “трохи покращити layout”, і раптом половина інтерфейсу виглядає інакше. Через годину вже ніхто не розуміє, яка версія була хорошою, яка зламана, що саме змінилося і як повернутися назад.

Git вирішує саме цю проблему. Він не робить AI розумнішим. Він робить роботу з AI контрольованішою.

Чому це важливо саме зараз

Традиційний дизайн-процес часто виглядав приблизно так:

Figma → handoff → developer → implementation → review → changes

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

Зараз дедалі частіше з’являється інший сценарій:

Figma / Design System → AI prototype → branch → review → implementation

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

Це не означає, що дизайнер замінює frontend-розробника.

Це означає, що межа між дизайном і реалізацією стає тоншою.

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

Git — одна з найважливіших частин цієї інфраструктури.

Основні поняття Git людською мовою

Давайте без академічних визначень і інженерного героїзму.

Дизайнерам не потрібно вивчати весь Git на старті. Не потрібно запам’ятовувати десятки команд. Не потрібно розуміти всі внутрішні механізми Git.

Спочатку достатньо розібратися з кількома поняттями:

repository;
commit;
branch;
status;
add;
push;
pull;
pull request;
merge conflict;
.gitignore.

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

Repository: проєкт із пам’яттю

Репозиторій — це папка проєкту, у якій Git відстежує зміни. Але простіше думати про це так: Репозиторій — це проєкт із пам’яттю.

У звичайній папці лежать файли. У Git-репозиторії лежать файли плюс історія: що змінилося, коли, ким і навіщо.

Репозиторієм може бути:

frontend-застосунок;
дизайн-система в коді;
Storybook-проєкт;
сайт;
документація;
AI-прототип;
дизайнерський sandbox;
бібліотека компонентів;
сайт-портфоліо.

Коли ви завантажуєте проєкт із GitHub, GitLab або Bitbucket, ви зазвичай завантажуєте не тільки поточні файли, а й історію проєкту.

Для цього використовується команда:

git clone https://github.com/example/project.git

clone означає: скопіювати віддалений репозиторій на свій комп’ютер.

Дизайнерською мовою: “Завантаж цей проєкт локально, щоб я міг з ним працювати.”

Commit: осмислена точка збереження

Коміт — це збережений стан проєкту.

Але це не просто Cmd + S.

Коміт — це радше осмислена точка в історії проєкту. Ви маєте вміти пояснити, що саме змінилося.

Наприклад, ви оновили empty state у таблиці документів. Додали зрозуміліший текст, primary action і поправили spacing.

Це можна зберегти як коміт:

git commit -m "Update empty state for documents table"

Текст після -m — це commit message. Він коротко пояснює, що змінилося.

Поганий commit message:

git commit -m "fix"

Трохи краще:

git commit -m "Fix layout"

Ще краще:

git commit -m "Fix mobile layout for onboarding stepper"

Добре:

git commit -m "Improve mobile onboarding stepper spacing"

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

Наприклад:

git commit -m "Add loading state for client list"
git commit -m "Update billing card hierarchy"
git commit -m "Replace deprecated button component"
git commit -m "Add empty state copy for documents table"
git commit -m "Refine sidebar navigation spacing"

Це вже не тільки технічна історія. Це також історія інтерфейсних рішень.

Status: перевірити, що відбувається

Одна з найкорисніших Git-команд:

git status

Вона показує поточний стан проєкту.

Наприклад:

які файли змінилися;
які файли нові;
які зміни готові до коміту;
які зміни ще не підготовлені;
у якій гілці ви зараз перебуваєте.

Для дизайнерів ця команда означає: “Покажи, що я змінив.”

Хороша новина: git status нічого не ламає. Її можна запускати скільки завгодно разів.

Перед будь-якою важливою дією можна написати:

git status

Це як перевірити шари у Figma перед тим, як рухати щось важливе.

Add: підготувати зміни до коміту

Перед тим як створити коміт, потрібно сказати Git, які зміни ви хочете включити.

Для цього використовується команда:

git add .

Крапка означає “додати всі поточні зміни в цьому проєкті”.

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

Акуратніший варіант — додати конкретний файл:

git add src/components/EmptyState.tsx

Людською мовою: “Підготуй цей файл до наступного коміту.”

Важлива різниця:

git add не зберігає зміни в історію;
git add тільки готує їх;
реальна точка збереження створюється через git commit.

Типовий міні-процес виглядає так:

git status
git add .
git commit -m "Update empty state layout"

Спочатку ви перевіряєте, що змінилося. Потім готуєте зміни. Потім зберігаєте їх в історію.

Branch: безпечний простір для експериментів

Гілка — одне з найважливіших понять Git для дизайнерів.

Branch — це окрема лінія роботи.

У більшості проєктів є головна гілка. Сьогодні її зазвичай називають main. У старіших проєктах вона може називатися master.

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

Але якщо ви хочете спробувати нову ідею, не варто робити це прямо в main.

Краще створити окрему гілку:

git checkout -b redesign-empty-state

Або через новіший синтаксис:

git switch -c redesign-empty-state

Це означає: “Створи нову гілку й перемкни мене в неї.”

Для дизайнерів гілка — це як окремий exploration file у Figma.

Ви можете спробувати нову навігацію, зібрати AI-прототип, змінити layout, протестувати компонент, і все це не зламає основну версію проєкту.

Приклади назв гілок:

git checkout -b ai-dashboard-prototype
git checkout -b improve-billing-flow
git checkout -b update-mobile-navigation
git checkout -b test-new-empty-state-pattern

Хороша назва гілки допомагає команді зрозуміти, що відбувається.

Погані назви:

test
new
fix
nick-branch

Кращі назви:

improve-client-list-empty-state
update-settings-layout
prototype-ai-generated-dashboard
fix-mobile-table-toolbar

Pull: забрати останні зміни команди

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

Перед початком роботи корисно оновити локальний проєкт:

git pull

Це означає: “Забери останні зміни з віддаленого репозиторію.”

Чому це важливо? Бо якщо ви працюєте зі старою версією проєкту, AI теж працюватиме зі старим контекстом. Він може використати застарілий компонент, стару структуру файлів, видалений API або deprecated pattern.

Хороша звичка:

git pull
git status

Спочатку оновити проєкт. Потім перевірити поточний стан.

Push: відправити свої зміни команді

Коли ви створили коміт, він усе ще живе тільки на вашому комп’ютері.

Щоб команда побачила вашу гілку й ваші зміни, потрібно відправити їх у віддалений репозиторій:

git push

Іноді потрібно явно вказати гілку:

git push origin improve-client-list-empty-state

Людською мовою: “Відправ мою гілку в хмару, щоб команда могла її переглянути.”

Після цього зазвичай можна створити pull request.

Pull Request: місце, де зміни стають розмовою

Pull request, або PR, — це запит на додавання ваших змін у головну гілку.

Для розробників PR — звичайна частина робочого процесу.
Для дизайнерів це може звучати занадто технічно.

Але насправді PR — це дуже дизайнерський артефакт.

Хороший PR відповідає на такі питання:

що змінилося;
чому це змінилося;
яку проблему це вирішує;
які компоненти були використані;
які стани потрібно перевірити;
що ще відкрите;
де є ризики.

Наприклад, опис PR від дизайнера може виглядати так:

## What changed
Updated the empty state for the Documents table.

## Why
The previous state did not explain what users should do next when no documents were available.

## Design notes
- Added clearer title and helper text
- Added primary CTA
- Used existing EmptyState component
- Kept layout aligned with the current table pattern

## Needs review
- Copy
- Spacing
- Mobile behavior
- Component usage

Це вже не просто “я змінив якийсь код”.

Це зрозуміле пояснення дизайн-рішення.

PR — це місце, де дизайнер може пояснити свою логіку розробникам, продактам, QA та іншим дизайнерам.

Це не тільки технічний gate. Це точка командного review.

Merge: додати зміни в головну гілку

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

Людською мовою: “Додати зміни з моєї гілки в основну версію проєкту.”

У реальних продуктових командах дизайнерам часто не потрібно робити merge самостійно. Зазвичай це роблять розробники або власники репозиторію.

Але дизайнерам важливо розуміти сам процес:

branch → pull request → review → merge

Спочатку ви працюєте окремо.
Потім показуєте зміни.
Потім команда їх перевіряє.
Потім зміни стають частиною головної гілки.

Це безпечний шлях.

Merge Conflict: коли Git не знає, яку версію вибрати

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

Git намагається об’єднати зміни автоматично. Але іноді не може.

Тоді виникає merge conflict.

Для дизайнерів просте пояснення таке: Git бачить дві різні версії одного й того самого місця й питає: “Яку залишити?”

Наприклад, одна людина змінила текст кнопки на:

Create document

Інша людина змінила той самий текст на:

Add new document

Git не завжди може вирішити, який варіант правильний. Бо це не тільки технічне рішення. Це продуктове й UX-рішення.

У коді conflict може виглядати страшно:

<<<<<<< HEAD
Create document
=======
Add new document
>>>>>>> update-empty-state-copy

Але сенс простий:

одна версія зверху;
інша версія знизу;
потрібно вибрати правильний фінальний варіант;
службові маркери потрібно видалити;
фінальний файл потрібно зберегти.

У великих проєктах conflicts можуть бути складними. Дизайнерам не потрібно вирішувати їх наодинці.

Але корисно розуміти, що саме відбувається.

Merge conflict — це не катастрофа. Це просто Git чесно каже: “Я не впевнений, яка версія правильна.”

.gitignore: список того, що Git має ігнорувати

Не кожен файл потрібно зберігати в Git.

Наприклад:

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

Для цього існує .gitignore.

Він каже Git: “Не відстежуй ці файли й папки.”

Приклад:

node_modules/
dist/
.DS_Store
.env
my-notes.txt

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

Особливо обережно треба ставитися до .env файлів. У них можуть бути ключі, токени, паролі та локальні налаштування середовища. Їх майже ніколи не потрібно відправляти в публічний або спільний репозиторій.

Мінімальний набір Git-команд для дизайнерів

Дизайнерам на старті не потрібен весь Git.

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

Завантажити проєкт

git clone https://github.com/example/project.git

Перевірити поточний стан

git status

Забрати останні зміни

git pull

Створити нову гілку

git checkout -b my-design-change

або:

git switch -c my-design-change
Підготувати зміни
git add .

або акуратніше:

git add path/to/file

Створити коміт

git commit -m "Describe design change"

Відправити зміни

git push

Подивитися історію комітів

git log

Побачити різницю

git diff

Якщо зробити ще коротше, базовий workflow виглядає так:

git pull
git checkout -b improve-empty-state
git status
git add .
git commit -m "Improve empty state for documents table"
git push

Людською мовою:

Оновити проєкт.
Створити окрему гілку.
Перевірити, що змінилося.
Підготувати зміни.
Зберегти їх із зрозумілим описом.
Відправити гілку команді.

Реалістичний сценарій для дизайнера

Уявімо ситуацію.

У вас є таблиця документів. Коли документів немає, інтерфейс показує сухе повідомлення:

No data

Як дизайнер, ви розумієте, що це слабкий empty state. Користувач не розуміє, що сталося і що робити далі.

Ви хочете його покращити:

зрозуміліший заголовок;
корисний допоміжний текст;
primary action;
краща ієрархія;
відповідність патерну дизайн-системи.

У старому workflow ви, ймовірно, створили б макет у Figma і передали його розробнику.

Тепер можливий інший workflow.

Ви відкриваєте проєкт і створюєте гілку:

git checkout -b improve-documents-empty-state

Просите Claude Code:

Update the Documents table empty state using the existing EmptyState component.
Add a clear title, helper text, and primary CTA.
Keep spacing consistent with the table pattern.

AI змінює файли. Ви перевіряєте, що змінилося:

git status
git diff

Якщо все виглядає розумно, готуєте зміни:

git add .

Створюєте коміт:

git commit -m "Improve documents empty state"

Відправляєте гілку:

git push

Потім створюєте pull request і пояснюєте дизайн-логіку:

## What changed
Updated the empty state for the Documents table.

## Why
The previous state did not guide users toward the next action.

## Design notes
- Used existing EmptyState component
- Added primary CTA
- Updated hierarchy and spacing
- Kept behavior aligned with the table empty state pattern

## Needs review
- Copy
- Component usage
- Mobile behavior

Це і є design-to-code workflow. Ви не стали розробником. Ви не забрали на себе production engineering. Ви просто наблизили дизайн-рішення до реальності й зробили його видимим для команди.

Типові Git-помилки дизайнерів

Працювати прямо в main

Якщо ви новачок у Git, не експериментуйте в головній гілці.

Погана ідея:

main → AI changes → commit → push

Краща ідея:

main → new branch → AI changes → PR → review

Гілка — це ваш безпечний playground.

Комітити все наосліп

AI може створити або змінити багато файлів. Не всі вони потрібні.

Перед комітом перевірте:

git status
git diff

Запитайте себе: Я розумію, що саме зараз збираюся відправити?

Якщо відповідь “не зовсім”, краще зупинитися й попросити розробника переглянути зміни.

Писати беззмістовні commit messages

Погані commit messages:

fix
update
changes
new version
final
final final

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

Кращі commit messages:

Update onboarding stepper spacing
Add empty state for documents table
Refine billing summary card layout
Fix mobile navigation overflow
Replace deprecated icon component

Commit message має бути коротким, але зрозумілим.

Не робити pull перед початком роботи

Якщо ви давно не оновлювали проєкт, ви можете працювати зі старою версією.

Перед стартом:

git pull

Ця проста звичка може зекономити багато нервів.

Сліпо довіряти AI

AI може написати код, який виглядає впевнено, але він може:

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

Git не оцінить якість дизайну за вас. Але він допоможе побачити, що саме AI змінив.

Саме тому важливо перевіряти diff:

git diff

Це одна з найкорисніших звичок в AI-assisted design роботі.

Git Diff: суперсила для дизайнерів

git diff показує різницю між тим, що було, і тим, що є зараз.

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

Коли Claude або Cursor змінює файли, ви можете не розуміти кожен рядок коду. Але часто можете помітити важливі речі:

чи змінено правильний компонент;
чи не зачеплено забагато файлів;
чи не видалено важливий текст;
чи не додано дивні кастомні стилі;
чи не змінилася структура занадто широко;
чи не замінив AI системний компонент на кастомний.

Приклад:

git diff

Якщо ви попросили AI поправити empty state, а він змінив 18 файлів, routing, package-lock і половину layout-системи, це сигнал зупинитися.

AI любить допомагати. Іноді занадто сильно. git diff допомагає тримати його під контролем.

GitHub, GitLab і Bitbucket — це не Git

Ще одне важливе уточнення.

Git — це сама система контролю версій.
GitHub, GitLab і Bitbucket — це платформи, де Git-репозиторії зберігаються онлайн.

Дуже грубо:

Git = технологія
GitHub / GitLab / Bitbucket = платформи навколо Git

Для дизайнерів це схоже на різницю між:

дизайн-файл → Figma як платформа

Git може працювати локально на вашому комп’ютері. Але в команді репозиторій майже завжди живе на віддаленій платформі, наприклад GitHub, GitLab або Bitbucket.

Саме там створюються pull requests, відбувається review, запускаються автоматичні перевірки й зберігаються обговорення.

Чи можуть дизайнери використовувати Git без терміналу?

Так.

Не обов’язково з першого дня жити в терміналі.

Є візуальні Git-інструменти:

GitHub Desktop;
Sourcetree;
Fork;
GitKraken;
вбудовані Git-інструменти у VS Code;
вебінтерфейси GitHub і GitLab.

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

які файли змінилися;
що було додано;
що було видалено;
які існують гілки;
які коміти створені.

Але базові команди все одно корисно розуміти.

Не тому, що термінал робить вас “справжнім інженером”.

А тому, що AI-інструменти, документація й розробники часто говорять мовою Git-команд.

Якщо ви розумієте git status, git pull, git checkout -b, git commit і git push, ви вже не губитеся повністю.

Git і дизайн-системи

Git особливо важливий для дизайн-систем.

Сучасна дизайн-система не живе тільки у Figma.

Вона може включати:

Figma components;
design tokens;
React components;
Storybook;
документацію;
usage guidelines;
accessibility rules;
visual regression tests;
component APIs;
changelog;
Code Connect mappings;
AI-readable documentation.

Усе це потрібно якось координувати.

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

Git допомагає зрозуміти, що відбувається на кодовому боці системи.

Наприклад:

коли змінився компонент;
які props були додані;
який variant було видалено;
чому змінилася поведінка;
хто зробив зміну;
у якому pull request це обговорювали.

Для дизайнера дизайн-систем це особливо важливо.

Дизайн-система — це не просто бібліотека красивих компонентів.
Це домовленість між дизайном і реалізацією.

Git зберігає історію цієї домовленості на боці коду.

Git і AI: чому контроль має значення

AI створює ілюзію простоти.

Ви пишете:

Build a dashboard using our design system components.

AI повертає код. Інтерфейс з’являється. Це майже магія.

Але проблема в тому, що AI не завжди розуміє системні обмеження.

Він може:

створити новий Button замість використання системного Button;
написати локальні стилі замість токенів;
проігнорувати існуючий layout pattern;
вигадати новий empty state;
змішати старі й нові компоненти;
додати непотрібну залежність;
змінити поведінку, яку ви не просили чіпати.

Якщо ви не використовуєте Git, дуже швидко стає незрозуміло, що насправді сталося.

Git перетворює AI-експеримент на контрольований workflow:

idea → branch → AI changes → diff → commit → PR → review

Це ключова зв’язка.

AI генерує.
Дизайнер спрямовує.
Git фіксує.
Команда перевіряє.

Хороший AI + Git workflow для дизайнерів

Безпечніший процес може виглядати так.

Оновити проєкт git pull
Створити гілку git checkout -b prototype-new-client-dashboard
Попросити AI внести зміну

Наприклад:

Create a prototype of the new client dashboard using existing design system components.
Do not create new components unless necessary.
Use existing spacing tokens and table patterns.

Перевірити, що змінилося git status git diff
Протестувати локально

Наприклад, запустити проєкт або Storybook. Конкретна команда залежить від проєкту:

npm run dev

або:

npm run storybook

Створити коміт

git add .
git commit -m "Prototype new client dashboard layout"

Відправити гілку

git push

Створити PR і пояснити дизайн-логіку

Не просто “updated dashboard”, а щось на кшталт:

## What changed
Created a prototype for the new client dashboard layout.

## Why
We need to test whether the new structure improves visibility of key client metrics.

## Design notes
- Used existing Card, Table, Badge, and EmptyState components
- Followed the current dashboard layout pattern
- Avoided new custom components
- Mobile behavior needs additional review

## Open questions
- Should the activity feed be visible by default?
- Do we need a compact state for smaller accounts?

Це зріла дизайнерська робота з AI та кодом.

Чи потрібно дизайнерам знати термінал?

В ідеалі — так, хоча б на базовому рівні.

Вам не потрібно ставати terminal ninja.
Але корисно не боятися відкрити термінал і виконати кілька команд.

Мінімум:


git status
git pull
git checkout -b branch-name
git add .
git commit -m "Message"
git push

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

Чи потрібно дизайнерам вирішувати conflicts?

Не завжди.

Якщо ви працюєте в реальному продуктовому репозиторії, особливо у великій frontend-кодовій базі, складні conflicts зазвичай краще вирішувати разом із розробником.

Але дизайнерам корисно розуміти:

чому виник conflict;
які файли були зачеплені;
яка частина зміни стосується дизайну;
яку версію інтерфейсу потрібно залишити;
де потрібне продуктове рішення, а не тільки технічне.

Іноді conflict насправді не про код. Іноді він про дизайн-рішення. Наприклад, дві людини змінили один і той самий текст, layout, компонент або pattern. У такій ситуації дизайнер може бути саме тією людиною, яка пояснить, яка версія правильна з точки зору UX.

Що дизайнерам не потрібно робити

Важливо також не перегнути.

Дизайнерам не потрібно:

глибоко розуміти внутрішню будову Git;
лагодити складну історію комітів;
переписувати shared branches;
використовувати force push;
самостійно вирішувати складні production conflicts;
розуміти всю frontend-архітектуру;
брати на себе відповідальність за production-код без review.

Базовий Git для дизайнерів — це не про героїзм.

Це про грамотність.

Так само як дизайнерам довелося розібратися з accessibility, responsive behavior, design tokens і component states, зараз стає корисно розуміти branches, commits і pull requests.

Найкоротша шпаргалка

Якщо хочеться запам’ятати тільки найважливіше:

git status

Показує, що відбувається.

git pull

Забирає останні зміни.

git checkout -b my-branch

Створює нову гілку.

git add .

Готує зміни до коміту.

git commit -m "My message"

Зберігає зміни в історію.

git push

Відправляє зміни у віддалений репозиторій.

git diff

Показує, що саме змінилося.

Якщо ви розумієте ці сім команд, ви вже не “дизайнер, який випадково загубився в Git”. Ви дизайнер, який розуміє базову механіку сучасної продуктової роботи.

Git не замінює дизайн-мислення. Git не зробить поганий інтерфейс хорошим.

Він не напише за вас логіку empty state.
Не вирішить, який CTA правильний.
Не зрозуміє, коли потрібен progressive disclosure.
Не пояснить, чому користувачі бояться натискати destructive action.
Не побудує за вас інформаційну архітектуру.

Але Git допоможе безпечно зберегти, перевірити, показати й обговорити результат.

У цьому його цінність для дизайнерів.

Особливо зараз, коли AI може генерувати код швидше, ніж команди встигають домовитися про правила.

Фінальна думка

Дизайнерська професія знову розширюється.

Колись дизайнери могли зосереджуватися переважно на візуальній частині. Потім роль виросла й почала включати UX, research, продуктове мислення, метрики, accessibility, дизайн-системи, контент, аналітику та ближчу співпрацю з розробкою.

Тепер додається ще один шар: AI-assisted production thinking.

Це не означає, що дизайнери мають стати full-stack розробниками.

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

Git — одна з базових частин цього шляху.

Бо у світі, де AI пише код, питання вже не тільки в тому, хто може згенерувати інтерфейс.

Важливіше питання інше:

Хто розуміє, що змінилося, чому це змінилося, де це збережено, як це перевірити і чи можна це безпечно зробити частиною продукту?

Ось чому дизайнерам час розібратися з Git.

Усі спалюють токени. Але хто рахує результат?

Nick Chukreiev — Fri, 01 May 2026 08:47:52 +0000

Останні кілька місяців я дедалі більше занурююся у зсув, який зараз обговорюють багато продуктових команд: перехід від класичного 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.

Ми вимірюємо магію.

А магія чудово виглядає в демо.

Але рахунок усе одно приходить.

Від SaaS до персоналізованих AI-агентів: наступний крок у бізнес-софті

Nick Chukreiev — Fri, 24 Apr 2026 10:22:49 +0000

Або чому “давайте впровадимо Claude” — це не стратегія

Я почав думати про це не під час стратегічної сесії, не після чергового звіту McKinsey і навіть не після надихаючого поста в LinkedIn, де хтось знову “переосмислив майбутнє роботи” втретє за цей місяць.

Я почав думати про це, коли вкотре оптимізував дизайн-систему та внутрішні процеси компанії під AI First підхід.

Ми обговорювали Claude Code, Claude Design, design-to-code pipeline, інтеграцію дизайн-системи з кодом, Storybook, Figma, Code Connect, агентні workflows, прототипи, які можна збирати швидше, і все в такому дусі.

Іншими словами, стандартний набір сучасного продуктового шаманізму.

І в якийсь момент у мене з’явилося дивне відчуття.

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

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

Цінність була відчутною.

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

Сьогодні ми оптимізуємо передачу дизайну в розробку. Завтра дизайнер уже може зібрати майже production-like prototype за допомогою AI. Сьогодні ми документуємо правила для компонентів. Завтра агент читає документацію, кодову базу і сам пропонує реалізацію. Сьогодні ми обговорюємо, як пришвидшити design-to-code. Завтра питання вже не в тому, як передати дизайн у код, а в тому, чи потрібен увесь звичний процес у тому вигляді, в якому він існував раніше.

І ось тут з’являється важливіша думка.

Можливо, проблема не в тому, що ми недостатньо швидко впроваджуємо нові інструменти.

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

SaaS не помер. Спокійно, акаунт можна не видаляти

Почнімо без звичної LinkedIn-драми.

SaaS не помер. Насправді ринок програмного забезпечення все ще зростає. Gartner прогнозує, що світові витрати на IT досягнуть $6.15 трлн у 2026 році, а software залишатиметься однією з категорій витрат, що зростають найшвидше.

Тож якщо хтось каже “SaaS помер”, є велика ймовірність, що він продає вам курс “Як побудувати AI-агента за 7 днів і звільнитися з роботи”.

SaaS усе ще дуже живий. Компанії досі купують CRM, ERP, accounting tools, HR platforms, design tools, compliance systems, dashboards, analytics products, helpdesks і все інше. Бізнес не може просто прокинутися в понеділок і сказати: “Видаляємо весь enterprise stack, тепер у нас один агент на ім’я Борис Бритва. Передаємо привіт Гаю Річі.”

Так це не працює.

Але важливіше інше: SaaS може не померти як ринок, але може перестати бути основною моделлю, через яку люди взаємодіють із роботою.

І ось це вже набагато цікавіше.

Що таке класичний SaaS насправді

Класичний SaaS продає доступ до інструмента.

У тебе є задача: підготувати податкову декларацію, обробити інвойс, перевірити документи, зібрати звіт, провести клієнта через onboarding, оновити CRM, створити дизайн, написати код.

SaaS каже:

“Ось тобі інтерфейс. Ось меню. Ось фільтри. Ось таблиці. Ось налаштування. Ось документація. Ось 14 вкладок. Успіхів.”

Користувач виконує роботу всередині продукту.

Саме тому SaaS так довго будувався навколо інтерфейсів. Логіка була проста: людина заходить у систему, дивиться на екран, розуміє структуру, натискає кнопки, вводить дані, перевіряє результат і рухається далі.

Це був світ, у якому software був інструментом, а людина була оператором.

Так, інструмент міг бути хорошим. Так, UX міг бути чудовим. Так, дизайн-система могла пришвидшити розробку. Так, продукт міг бути розумнішим за конкурентів.

Але фундаментально модель була така:

Людина працює. Програма допомагає.

AI-агенти починають перевертати цю модель.

AI First часто розуміють занадто вузько

Коли компанія каже “ми стаємо AI First”, дуже часто це означає щось цілком практичне: підключити Claude Code, дати дизайнерам доступ до Claude Design, вбудувати AI в сапорт, автоматизувати research, написати промпти, створити внутрішні гайди, провести воркшоп і, звісно, створити Slack-канал #ai-transformation, бо очевидно, що без Slack-каналу жодна трансформація не відбудеться.

Усе це може бути корисним.

Але це не обов’язково змінює бізнес.

Це може просто замінити виконавця.

Раніше код писала людина. Тепер це людина плюс Claude Code. Раніше дизайнер збирав прототипи вручну. Тепер це дизайнер плюс Claude Design. Раніше аналітик писав SQL. Тепер це аналітик плюс AI. Раніше сапорт відповідав клієнтам. Тепер це сапорт плюс AI.

Це прискорення. Але це не переосмислення.

Як компанія, ви все ще будуєте той самий SaaS-продукт, для того самого ринку, з тією самою моделлю і тим самим interface-first мисленням. Просто тепер у вас швидші внутрішні процеси.

Це як перейти з Photoshop на Figma. Важливо? Так. Чи змінює це природу бізнесу? Ні.

Це як перейти від ручної front-end реалізації до design-to-code pipeline. Корисно? Так. Але податкова платформа від цього не стає новою продуктовою категорією.

І ось тут з’являється головне питання:

Ми просто впроваджуємо нові інструменти, щоб швидше будувати старий SaaS?
Чи ми готові переосмислити, чим має стати наш продукт у світі AI-агентів?

Справжній зсув: від інструмента до виконавця

Радикальний зсув починається не тоді, коли AI допомагає користувачу натискати кнопки.

Він починається тоді, коли користувач перестає бути головним оператором системи.

Класичний SaaS каже:

“Ось платформа. Зайди і зроби роботу.”

AI-агент каже:

“Скажи, який результат тобі потрібен. Я пройду процес, перевірю дані, поставлю питання, виконаю дії, покажу винятки і попрошу approval там, де потрібне людське рішення.”

Це вже не просто інтерфейс. Це інший контракт між користувачем і продуктом.

Користувач купує не доступ.
Користувач купує виконання.

Не “у нас є модуль інвойсів”.
А “інвойси будуть оброблені”.

Не “у нас є tax dashboard”.
А “податкову декларацію буде підготовлено, перевірено і передано на review”.

Не “у нас є CRM pipeline”.
А “ліди будуть кваліфіковані, follow-ups будуть відправлені, ризики будуть підсвічені”.

Не “у нас є дизайн-інструмент”.
А “прототип буде зібраний, перевірений на consistency, підготовлений до review і частково реалізований у коді”.

Це вже не SaaS у традиційному сенсі. Це ближче до персоналізованого цифрового працівника.

І так, технічно це все ще може продаватися через хмару. Формально можна сказати: “Ну, це теж SaaS.” Але це буде приблизно так само точно, як сказати, що Tesla і віз із конем — це обидва транспортні засоби.

Формально так. По суті — ні.

Чому Anthropic є важливим прикладом

Anthropic цікавий не просто тому, що має хороший чат-бот.

Цікаво те, що продукти на кшталт Claude Code починають змінювати саму роль інструмента. Anthropic описує Claude Code як agentic coding system, яка може читати кодову базу, змінювати файли, запускати тести і доводити код ближче до commit-ready стану.

Це вже не “асистент, який підказав шматок коду”.

Це система, яка бере задачу і починає діяти всередині робочого середовища.

Тепер додамо Claude Design, який дозволяє людям створювати дизайни, прототипи, слайди, one-pagers і візуальні матеріали в колаборації з Claude. Це вже не просто “AI допомагає дизайнеру”. Це AI бере участь у створенні результату.

Спочатку AI відповідав.
Потім AI писав.
Потім AI редагував.
Потім AI почав працювати всередині інструментів.
Тепер AI стає виконавцем у конкретній професійній доменній області.

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

Але роль людини зміщується.

Людина менше клікає.
Людина дедалі більше задає напрям, перевіряє, обмежує, ухвалює рішення і відповідає за якість.

Чому Google ще цікавіший

Google, здається, дивиться ще ширше.

Gemini Enterprise Agent Platform описується як платформа для створення, масштабування, управління й оптимізації enterprise-ready агентів. Іншими словами, це не просто готовий AI-продукт. Це інфраструктура для побудови агентних систем усередині компаній.

Gemini Enterprise також включає Agent Designer: no-code / low-code середовище, де люди можуть створювати single-step і multi-step агентів, описувати задачі природною мовою, візуально редагувати workflows, підключати джерела даних і запускати агентів за розкладом.

І ось тут з’являється дуже цікавий парадокс.

Gemini Enterprise сам по собі є SaaS.

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

Іншими словами, це SaaS для створення анти-SaaS.

Звучить як жарт, але насправді це дуже серйозна стратегічна позиція.

Google не просто каже: “Ось вам ще один інструмент.”
Google каже: “Ось вам середовище, де ви можете створювати цифрових виконавців для власних процесів.”

Це вже не просто ринок окремих застосунків. Це ринок агентних робочих систем.

Вертикальний AI-агент як вбивця частини SaaS

Тепер перейдемо ближче до tax, accounting і financial products.

Уявімо класичну SaaS-платформу для податків. У ній є client profiles, documents, forms, statuses, tasks, notifications, roles, approvals, dashboards, reports, workflows та integrations.

Усе це потрібно, тому що людина має бачити процес і керувати ним.

Тепер уявімо не платформу, а tax AI-агента, налаштованого під конкретну accounting firm.

Він знає спеціалізацію фірми, типи клієнтів, локальні податкові правила, внутрішній review process, стиль комунікації, потрібні документи, типові помилки, тон пояснень, ролі в команді й ситуації, де потрібен accountant approval.

Клієнт не заходить у “платформу”.
Він пише агенту:

“Що мені потрібно підготувати для self assessment?”

І агент не просто показує статтю з help center. Він дивиться на контекст клієнта, перевіряє документи, розуміє missing information, пояснює наступний крок, готує summary для бухгалтера і може надіслати нагадування клієнту, якщо це дозволено процесом.

Для accounting firm це вже не просто SaaS.

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

Ось це і є радикальний зсув.

Не “ми додали AI-кнопку в dashboard”.
А “dashboard більше не є головним способом, у який відбувається робота”.

Це вже починається в accounting і tax

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

У tax і accounting компанії та продукти вже рухаються в бік AI-агентів і vertical AI.

Наприклад, Juno, CPA-founded AI tax startup, починала як co-pilot, а пізніше запустила tax product, який швидко виріс серед tax firms. Цікаве тут не лише зростання. Цікава сама логіка: AI не просто допомагає користувачам натискати кнопки всередині старої системи. Він починає брати на себе частини tax workflow.

Balance з Y Combinator описує себе як AI accounting firm для SMBs. Їхній AI-агент Bea займається reconciliation, categorization і reporting, а людські accountants перевіряють books і подають returns. Особливо цікаво, що інтерфейсом взаємодії можуть бути Slack, WhatsApp або email. Іншими словами, користувач не обов’язково живе всередині класичної SaaS-платформи.

Thomson Reuters у 2025 році анонсувала agentic AI solutions для tax, audit і accounting workflows, включно з automated tax preparation у форматі “Ready to Review”. Wolters Kluwer також пише про зсув від task automation до workflow orchestration в accounting.

І це ключовий момент.

Майбутнє не в тому, щоб просто “додати AI”.
Майбутнє в тому, щоб перебудувати продуктову архітектуру так, щоб агенти могли безпечно виконувати роботу.

SaaS не зникне. Він стане backend для агентів

Найімовірніший сценарій не такий:

Був SaaS, потім прийшли агенти, SaaS помер, усі поплескали.

Швидше за все, буде приблизно так:

SaaS перестане бути головним інтерфейсом, але залишиться інфраструктурою.

Агентам усе одно будуть потрібні data, permissions, audit logs, workflows, integrations, business rules, compliance, source of truth, APIs, role models, billing, approvals і action history.

Іншими словами, уся нудна доросла частина продукту нікуди не зникне.

Але користувач може все рідше заходити в інтерфейс напряму.

Сьогодні SaaS каже:

“Відкрий екран, знайди задачу, виконай дію.”

Завтра агент каже:

“Я знайшов 12 клієнтів із missing documents, підготував повідомлення, 3 випадки потребують accountant review, а 2 клієнти мають ризик, пов’язаний із expense classification. Approve?”

І в цей момент SaaS стає не місцем, де живе людина, а системою, у якій діє агент.

Це величезна різниця.

Чому гонка за інструментами небезпечна

Тепер повернімося до компаній, які “стають AI First”.

Проблема не в тому, що вони впроваджують Claude, Gemini, OpenAI, Figma AI, Cursor, Code Connect або щось інше. Це нормально. Це потрібно. Це частина адаптації.

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

Це якби компанія у 2012 році сказала:

“Ми тепер mobile-first, бо купили всім iPhone.”

Ні. Ви купили телефони.

Mobile-first означав переосмислення продукту, поведінки користувачів, контексту використання, інтерфейсу, швидкості, notifications, geolocation, payments, camera, offline scenarios і всього іншого.

AI First також не означає “у нас є підписка на Claude”.

AI First має означати, що компанія починає ставити собі більш незручні питання.

Які процеси більше не мають виконуватися людьми вручну? Які частини продукту мають стати агентними? Які інтерфейси перестануть бути основним способом, у який відбувається робота? Які дані мають стати доступними для безпечного виконання дій? Які рішення потребують approval? Які задачі можна продавати як outcomes, а не як access?

І найважливіше питання:

Де ми перестаємо будувати “ще один екран” і починаємо будувати “виконавця”?

Саме це відрізняє adoption інструментів від стратегічного переосмислення.

Prompt engineering як маленький урок

Історія з prompt engineering дуже добре показує, чому небезпечно будувати стратегію навколо поточної форми інструмента.

Ще нещодавно здавалося, що prompt engineering стане великою окремою професією. Будуть люди, які знають спеціальні формули, магічні послідовності, правильні дужки, правильний порядок слів, правильне “act as a senior world-class award-winning...” та інші заклинання.

Але що ми бачимо зараз?

Промпти стають простішими. Моделі краще розуміють звичайну людську мову. Щоб створити хороше зображення, вже не завжди потрібно писати технічне есе на кшталт:

cinematic lighting, ultra detailed, octane render, trending on artstation, 8k, masterpiece, please don’t make six fingers

Часто достатньо чітко пояснити задачу.

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

Те саме станеться з багатьма AI-інструментами.

Сьогодні ми вивчаємо конкретні інтерфейси. Завтра ці інтерфейси можуть зникнути, злитися або стати автоматичними.

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

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

Головне питання для SaaS-компаній

Якщо ви будуєте SaaS-продукт, особливо у складному домені на кшталт tax, accounting, legal, compliance, healthcare, insurance, finance або enterprise operations, головне питання більше не звучить так:

“Як нам вбудувати AI в продукт?”

Це занадто маленьке питання.

Краще питання:

“Якби клієнту не потрібно було користуватися нашою платформою напряму, яку роботу наш продукт мав би виконувати від його імені?”

Ще жорсткіша версія:

“Які частини нашого інтерфейсу існують лише тому, що раніше не було агента?”

Це болюче питання. Особливо для product designers. Бо відповідь може бути некомфортною.

Багато екранів існують не тому, що користувач хоче ними користуватися.

Вони існують тому, що системі потрібен людський оператор.

А якщо оператором стає агент, інтерфейс змінюється радикально.

Він не зникає повністю. Але стає іншим. Менше navigation заради navigation. Менше manual input. Менше tables заради tables. Більше review. Більше exceptions. Більше explainability. Більше auditability. Більше controls. Більше “approve / reject / ask why”. Більше trust і responsibility.

Це вже не просто UX.

Це governance of delegated work.

Звучить добре. Можна вставляти в leadership deck.

Що це означає для дизайн-систем

Для дизайн-систем це теж некомфортна, але цікава новина.

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

Вона має почати описувати нові типи взаємодії: approval flows, exception handling, confidence states, human-in-the-loop logic, audit trails, source citation, reversible actions, permission escalation, autonomous and assisted modes, explainability і trust boundaries.

Іншими словами, дизайн-система має рухатися від UI kit до operating model.

І саме тут стає зрозуміло, чому просто “зробити компоненти красивішими” недостатньо.

Якщо агент може сам створювати, змінювати, відправляти, класифікувати, перевіряти і запускати процеси, головне дизайнерське питання вже не “як виглядає dropdown?”

Головне дизайнерське питання стає таким:

“Як людина розуміє, що агент зробив, чому він це зробив, де ризик, що можна скасувати, де потрібна відповідальність і хто тепер володіє рішенням?”

Це зовсім інший рівень патернів.

Компанія має не лише рухатися швидше. Вона має розуміти, що продає

Є два шляхи.

Перший шлях — гонка за інструментами.

Компанія впроваджує Claude, навчає команду, через місяць виходить новий tool, проводиться новий воркшоп, створюються нові гайди, усе частково застаріває, і процес повторюється.

Це не погано. Це неминуча операційна гігієна.

Але це не стратегія.

Другий шлях — переосмислення продукту як агентної системи.

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

Наприклад, для tax/accounting SaaS це може бути не “AI assistant inside the dashboard”, а окремий продуктовий шар:

personal tax preparation agent for small accounting firms

або: client document collection agent trained on your firm’s workflow

або: expense classification review agent with accountant approval

або: MTD readiness agent for UK accountants

Це вже не просто feature. Це новий продуктовий шар.

Моя гіпотеза

Моя гіпотеза проста:

SaaS не помре. Але SaaS-інтерфейс перестане бути центром бізнес-софту.

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

Старий SaaS продавав доступ до системи.
Новий агентний продукт продаватиме делеговану роботу.

Старий SaaS казав: “Зайди і зроби.”
Новий продукт казатиме: “Я зробив. Перевір винятки.”

Старий SaaS конкурував кількістю функцій.
Новий продукт конкуруватиме якістю виконання, довірою, доменною експертизою, інтеграціями і безпекою.

Старий SaaS вимірював seats.
Новий продукт дедалі частіше вимірюватиме outcomes.

І це, можливо, головний зсув.

Не “AI допоможе нам швидше будувати SaaS”.
А “AI змусить нас перебудувати саму ідею SaaS”.

Фінальна думка

Компанії, які сьогодні просто впроваджують AI-інструменти, звісно, рухатимуться швидше.

Вони швидше писатимуть код. Швидше робитимуть дизайн. Швидше збиратимуть прототипи. Швидше відповідатимуть клієнтам. Швидше генеруватимуть документи.

Це добре.

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

Бо справжнє питання не в тому, який інструмент ми використовуємо сьогодні.

Справжнє питання:

“Що станеться, коли клієнту більше не потрібно буде користуватися нашим SaaS так, як він користується ним зараз?”

Ось тут починається цікава частина.

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

Він може забрати саму категорію.

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

Зате Slack-канал #ai-first-transformation виглядатиме красиво.

ШІ не замінює дизайнерів. Він їх викриває.

Nick Chukreiev — Thu, 19 Mar 2026 15:11:24 +0000

Ця думка прийшла до мене під час дуже звичайного моменту — мого ранкового скролу. Так, того самого ☕🚽

Я натрапив на новину про те, що Google випустив новий інструмент (Stitch beta), який здатен перетворювати текст у дизайн, код та інші «магічні» результати. Ще один вражаючий реліз. Ще один сигнал того, як швидко все рухається. Але чим більше я про це думав, тим ясніше ставало: насправді це не історія про Google.

Гонка, яку ніхто не може ігнорувати

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

Саме це ми зараз і спостерігаємо. І не тільки від Google, а від усієї індустрії.

Ілюзія “text-to-product”

З’являється цілий шар інструментів: Pencil, Galileo AI, Uizard, Locofy, Framer AI, Builder.io, v0. Усі вони побудовані навколо однієї обіцянки: вам більше не потрібно проектувати чи розробляти в класичному розумінні. Достатньо просто описати, що ви хочете, і отримати готовий результат.

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

Бульбашка уваги

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

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

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

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

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

Коли навички замінюють інструменти

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

Той самий дизайнер дуже точно це сформулював: ринок починає продавати «навички роботи з інструментами» замість справжньої експертизи.

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

І це дуже крихка основа. Бо інструменти швидко змінюються. А навички — ні.

Якщо твоя сила прив’язана лише до інструмента, ти втрачаєш її в той момент, коли цей інструмент застаріває.

ШІ як інфляція

Мій друг Олег Горлачов описав цю динаміку способом, який мені відгукнувся. Він пояснив це через призму економіки: те, що ми спостерігаємо, це форма інфляції.

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

Зрештою компанії, які зробили ставку на швидкість через ШІ, дивляться на свої метрики і ставлять просте запитання: чому нічого не працює?

Коли швидкість замінює мислення

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

Сам ШІ — не проблема. Це надзвичайно потужний мультиплікатор. Але він не замінює мислення.

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

Тому що в кінцевому підсумку справа не в тому, як швидко щось можна згенерувати.

А в тому, наскільки добре це спроєктовано. 🦫

Парадокс ефективності: чому ШІ не звільнив нас від роботи, а зробив її інтенсивнішою

Nick Chukreiev — Sun, 01 Mar 2026 19:39:41 +0000

Ну що, награлися з ШІ? Нещодавнє дослідження, опубліковане в Harvard Business Review: «AI Doesn’t Reduce Work. It Intensifies It» (https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies-it), показало неочікуваний ефект: у компанії, де співробітники активно використовували генеративний ШІ, обсяг роботи не зменшився. Він став щільнішим, ширшим і швидшим. І найцікавіше, ніхто їх до цього не змушував.

Ще вчора здавалося, що коли компанії впроваджують ШІ, майже напевно стане легше. Менше рутини, менше часу на чернетки, менше механічної роботи. Більше простору для стратегічного мислення. Усі такі ділові, прогресивні. Логіка звучить бездоганно.

Але реальність виявляється складнішою. Сьогодні проллємо трохи цифрового чаю на так званий парадокс ефективності. Поїхали.

Роботи стало не менше, а більше за щільністю

Згідно з дослідженням, ШІ знімає бар’єр входу. Більше немає страху перед чистим аркушем, складною функцією чи незнайомим завданням. Можна просто запитати. Можна «спробувати». І люди починають пробувати. Продакт-менеджери лізуть у код. Дизайнери пишуть SQL. Дослідники генерують технічні гіпотези.

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

Робота починає просочуватися в паузи

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

Тепер достатньо написати кілька рядків у чат. І ось ти відправляєш «останній швидкий запит» перед тим, як піти. Запускаєш генерацію «поки обідаєш». Перевіряєш відповідь увечері з телефону. Це не відчувається як повноцінна робота. Це відчувається як діалог. Але паузи зникають.

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

Ілюзія продуктивності

З ШІ виникає відчуття партнерства. Ніби ти працюєш не сам. Є помічник, який завжди поруч. Можна паралельно генерувати кілька версій, перевіряти гіпотези, запускати альтернативні підходи. Робота рухається швидше. Видно рух. Є імпульс.

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

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

Це важливий момент. Продуктивність зросла. Зайнятість не зменшилася.

Тихе зростання навантаження

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

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

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

Чому ми втомлюємося швидше

Вигорання рідко починається з понаднормової роботи. Воно починається з відсутності відновлення. Коли день стає більш фрагментованим, коли немає чітких меж, коли завжди можна «ще трохи покращити», мозок перестає отримувати відчуття завершеності.

ШІ підсилює відчуття незавершеності. Завжди є ще одна версія. Ще одна ітерація. Ще одна ідея, яку можна швидко перевірити. Зупинитися стає складніше, ніж продовжувати. І саме це посилює втому. Вигорання стає ще ближчим.

Девальвація зусилля

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

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

Нам потрібна не просто стратегія ШІ. Нам потрібна практика ШІ

Автори дослідження в HBR пропонують важливу думку: організаціям необхідна усвідомлена «AI practice». Hабір норм і ритмів, які керують тим, як використовується ШІ.

Не лише «як прискорити». А й «де зупинитися». Це можуть бути навмисні паузи перед ухваленням рішень. Фокусні інтервали без постійних перевірок. Регулярні живі обговорення, щоб робота не перетворювалася на ізольований діалог із машиною.

ШІ змінює темп. І якщо не керувати цим темпом, він починає керувати нами.

Справжній парадокс ефективності

Ми думали, що ШІ звільнить час. Насправді він звільнив потенціал. А потенціал майже завжди заповнюється.

Ми стали швидшими. Стали ширше охоплювати завдання. Стали продуктивнішими. Але не стали працювати менше.

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

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

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

Такі справи. Усім добра 🦫 і впевненого користування ШІ.

Помилки, спостереження та висновки: що я зрозумів, написавши книгу

Nick Chukreiev — Wed, 25 Feb 2026 23:27:30 +0000

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

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

I. Про написання

1. Рік — це не так довго, як здається. І не так швидко, як хотілося б.

Книга писалася близько року. Не тому що вона така величезна. Хоча так, вона таки під 400 сторінок. А тому що я робив великі паузи.

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

2. Натхнення переоцінене

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

3. Були моменти, коли хотілося все закрити

Середина процесу — найважча. Азарт на початку. Фінал — теж драйв. А от середина — це довгий сірий коридор. У якийсь момент починаєш думати: «Кому це взагалі потрібно?» Якщо ви пишете, то робіть це насамперед для себе. Інакше не дійдете до кінця.

4. Я повторювався. Багато повторювався.

Коли живеш темою 15–20 років, думки накладаються одна на одну. Хочеться донести її з усіх боків. У підсумку в тексті з’являлося «масло масляне». Довелося кілька разів проходитися по книзі й вирізати зайве. Деякі абзаци переписував повністю. Редагування виявилося складнішим, ніж написання. Зізнаюся чесно, і зараз знайдеться, що підскорочити. Але я вже цього робити не буду.

II. Про верстку

5. Помилка з відступами коштувала мені переробки всієї книги

Верстав у Adobe InDesign. За звичкою додав до потрібного розміру стандартні 3 мм. Потім у процесі подумав про виносні елементи, а вони в мене є, і додав ще відступи під них. І лише потім зрозумів, що отримав подвійний запас по краях. Ну як потім? Прямо тримаючи в руках надруковану книгу й дивуючись, чому вона читабельна, але відступи по краях не такі, як хотілося б. Візуально ніби акуратно. Але пропорції поїхали. Переробляв майже весь файл книги. Іноді одна дрібниця тягне за собою десятки годин роботи.

6. Я переробляв верстку двічі

Перший раз — тому що хотів «не як у всіх». Не суцільний текст, але й не дизайнерський журнал. Довго шукав баланс.

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

7. Kindle виявився не для такої книги

Є такий собі індивідуальний формат у Amazon Kindle. По суті це потоковий текст. Сітка ламається. Акуратні блоки з’їжджають. Рамки та лінії живуть своїм життям. Можливо, для роману це чудово. Для дизайн-книги — це сум. У підсумку я зробив окрему PDF-версію й виклав її на Gumroad.

8. Шрифти — це не просто смак, а ліцензії

Звісно, для основного тексту взяв шрифт із безкоштовною ліцензією (Source Sans), щоб не мати проблем. Але хотів використати один акцентний шрифт, щоб підвиділити деякі фрагменти тексту. У підсумку також обрав безкоштовні, але різні варіанти для української (Caveat) та англійської (Patrick Hand - этот подобається, але тут банально немає накреслення кирилиці) версій книги. Це не найтворчіший момент у житті, але краще так, ніж потім розбиратися з юридичними сюрпризами.

9. Навіть після всіх перевірок помилки залишилися

Кілька разів вичитував. Дивився в PDF. Замовляв пробний примірник. І все одно в надрукованій версії знайшов кілька дрібниць. Нічого критичного. Але якщо ви перфекціоніст — це буде вас турбувати. Мене це турбує. Я переробив.

III. Про стратегічні помилки

10. Назва виявилася важливіше за зміст

Перша версія називалася Design System: Step by Step. Мені це здавалося логічним. Я справді розбирав систему крок за кроком: від мислення до структури. Але читачі почули інше. Вони очікували покроковий гайд по Figma: «натисніть сюди, створіть компонент, підключіть токени». А книга була зовсім не про це.

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

У підсумку довелося видалити книгу й випустити нову версію. Уже як Design System Thinking. І так, відгуки залишилися у старій картці книги на Amazon. Було неприємно. Але чесніше так, ніж продовжувати вводити людей в оману.

11. 400 сторінок — це психологічний бар’єр

Коли працюєш над книгою, обсяг не відчувається. Кожен розділ важливий. Кожен блок здається потрібним. У якийсь момент я зрозумів, що вийшло більше 400 сторінок. І всередині було відчуття гордості: «Оце масштаб. Оце можеш».

Але з боку це виглядає інакше. 439 сторінок — це: страшно починати, важко тримати в руках, дорого друкувати. І вартість друку автоматично зростає. Людям простіше купити книгу за 10–15 доларів. 30 — уже обдумують. 50 — починають сумніватися.

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

12. Ніша виявилася вужчою, ніж здається

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

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

За даними мого скромного ресерчу, якщо хочете заробити, то ваша ніша — дитячі книги, обсягом до 50–100 сторінок, із ціною продажу 5 доларів, ну максимум 10.

IV. Про Amazon і гроші

13. Print-on-demand — це реально круто

Я публікувався через Amazon KDP. І тут треба віддати належне Amazon. Ти не друкуєш тираж. Ти не зберігаєш коробки. Ти не думаєш, куди подіти 300 непроданих примірників. Купили одну книгу — надрукували одну книгу. Для автора це величезна свобода. Дякую, Amazon. Поважаю.

14. Скільки насправді заробляє автор

Коли бачиш ціну книги в магазині, легко подумати: «Ну от, майже 30 доларів. Непогано». Реальність простіша. Amazon ділиться з вами частиною виручки. Не ви з ними, а вони з вами.

Наприклад, для paperback (м’яка обкладинка) модель така: 60% від роздрібної ціни мінус вартість друку.

У моєму випадку при ціні $29.99 на м’якій обкладинці я отримую приблизно 6 доларів. І це нормально для кольорової технічної книги. Звісно, варіант чорно-білий із сірим папером буде дешевшим. Але це не варіант для книги про дизайн. Про це — наступний пункт.

15. Колір і тверда обкладинка — красиво, але дорого

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

У підсумку hardcover-версія коштує 53.99. І за такої ціни я нічого не заробляю. Це мінімальна ціна від Amazon (по суті собівартість друку і ті гроші, які Amazon бере собі). Менше поставити не дасть.

Чому не додав свій прибуток? Я не став піднімати ціну, щоб зберегти підсумковий цінник адекватним. Бо психологічно 50+ доларів — це вже важко сприймається. Іноді доводиться обирати між естетикою та економікою.

16. Назву не можна просто змінити

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

У моєму випадку це означало: видалити стару версію, завантажити нову, втратити відгуки. Це варто враховувати заздалегідь.

17. Публікація — не миттєва

Перша публікація зайняла майже 72 години. Оновлення проходять швидше. Але щоразу потрібно проходити preview і підтверджувати, що все коректно.

Один раз у мене «поїхала» обкладинка в попередньому перегляді. Перезалив той самий файл — і стало нормально. Таке трапляється. Пильнуйте.

18. Авторські примірники — зручно, але не ідеально

Можна замовити author copy за ціною друку + комісія Amazon. Без вашої роялті. Зручна штука. Я так і зробив.

Але в моєму випадку чомусь замовлення працює лише через amazon.com, а не через локальний UK-домен. І доводиться платити за доставку зі США.

19. Без просування книга просто лежить

Усередині KDP є рекламний розділ, де можна запускати Amazon Ads. Я ще не занурювався в це глибоко. Але одне зрозуміло точно: без просування органіка буде мінімальною. Книга не продається сама по собі. Особливо з такою вузькою тематикою.

V. Те, що залишається за кадром

20. Верстка — це марафон, а не творчість

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

21. Дрібниці формують відчуття якості

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

І якщо коротко

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

Добра 🦫

AI — це помічник, а не рішення: як зберегти якість та ідентичність

Nick Chukreiev — Sun, 01 Feb 2026 21:18:14 +0000

Ну що, всі вже юзають AI? Та годі, звісно всі. Сьогодні AI — один із перших інструментів у спеціалістів будь-якого профілю. А в керівників майже напевно є ця нав’язлива ідея: затягнути AI в процеси компанії будь-яким способом. Не важливо як. Не важливо навіщо. Головне — поставити галочку: «ми використовуємо AI». Ну що ж, вітаю. Чудово. Давайте працювати в тому ж дусі.

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

Ситуешн намбер 1

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

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

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

І тут стається збій системи під назвою «ми обов’язково використовуємо AI у своїй роботі».

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

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

AI впевнено диктує: «30% зліва під текст, 20% справа під зображення», перекроює таблиці, перетягує технічні характеристики в заголовки, ламає візуальну та смислову ієрархію.

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

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

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

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

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

Ситуешн намбер 2

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

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

Але не цього разу.

З’являється прогресивне рішення: «Давайте виберемо найкращий варіант за допомогою AI». У AI завантажують логотипи. Просять оцінити, порівняти, обрати найвдаліший. AI чесно старається. Він аналізує форми, симетрію, «читабельність», відповідність абстрактним трендам. Видає впевнений висновок. Іноді навіть з рейтингом.

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

У результаті обирається варіант, який виглядає «найменш спірним». Найбезпечніший. Найусереднений. Той, до якого найменше запитань — і найменше характеру. Формально рішення прийняте. Фактично — відповідальність знову перекладена. І логотип з’являється. Нормальний. Акуратний. І абсолютно ні про що.

І ось тут починається найважливіше

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

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

Експерт працює інакше. Він працює з наслідками.

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

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

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

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

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

Тому питання тут не в тому, використовувати AI чи ні. Питання в тому, хто керує процесом. Хто приймає фінальне рішення. За якими критеріями оцінюється результат. Де закінчується автоматизація й починається усвідомлений вибір.

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

Щось на кшталт підсумку

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

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

AI не винен. Він робить рівно те, чого від нього очікують.
Питання завжди в іншому: хто думає і хто приймає рішення?

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

Ех. Печаль. Але, здається, ще не пізно.

Якщо вам близький мій підхід до роботи з дизайном і процесами, я зібрав його в книзі «Design Systems. Step by Step» — практичному посібнику про те, як вибудовувати дизайн-системи в реальних командах: від структури й логіки рішень до взаємодії дизайну, розробки та продукту. Без теорії заради теорії. Лише досвід, помилки й практики, що справді працюють.

👉 Print & Kindle Amazon →
👉 PDF (Digital Edition) Gumroad →

Добра 🦫

Design System Airbnb: як «еталон» існує, якщо його ніхто не бачив

Nick Chukreiev — Mon, 05 Jan 2026 23:18:27 +0000

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

З усього, що публічно з’являлося в останні роки, найофіційніше й найпомітніше — Summer Release 2025 (Summer Release): новий застосунок Airbnb, нові напрями (Services / Experiences), нова візуальна мова і пряме твердження, що вони створили нову дизайн-систему з dimensional (об’ємним) та анімованим інтерфейсом.

Паралельно в публічному просторі з’являлися відео й пости людей, які працювали над оновленням системи. Але саму систему у вигляді відкритої бібліотеки або док-порталу Airbnb так і не виклали. LinkedIn

Тож я зробив те, що робить будь-який допитливий дизайнер у 2026 році, коли не знаходить «Airbnb DLS download»:
витратив вихідні на дослідження матеріалів і зібрав усе по крупинках: статті, доповіді, офіційні релізи, інтерв’ю, open-source сліди і розклав, як у них це влаштовано на рівні підходів. Щоб було зрозуміло навіть тим, хто слово governance вимовляє як «гавернанс» і робить вигляд, що так і треба.

Сьогодні проливаємо цифровий чай на тему внутрішньої кухні Airbnb. Заварюйте чай-каву, поїхали по 10 ключових пунктах.

1. Що саме “оновилося” у Airbnb і чому всі знову заговорили про їхню систему

У Summer Release 2025 Airbnb не просто «перефарбували кнопки». Вони заявили:

застосунок тепер покриває більше сценаріїв (житло + сервіси + враження);
під це вони створили новий технологічний стек;
і нову дизайн-систему з більш об’ємним і анімованим інтерфейсом, щоб планування подорожі відчувалося «живішим».

Важливо: це не чийсь блог «мені здається, вони оновилися», а пряме твердження в офіційному Airbnb Newsroom.

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

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

2. Чому їхню дизайн-систему досі не віддають назовні (і це логічно)

Коротко: тому що Airbnb DLS — це конкурентна перевага, а не «плюшки для спільноти».

Для великої продуктової компанії дизайн-система — це:

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

Публічний реліз означає:

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

Те, що Airbnb замість «публічного порталу» залишили публічні шматки інфраструктури та доповіді, підтверджується їхніми open-source проєктами та виступами:
вони діляться принципами й інженерними ідеями, але не «повним пакетом продукту».. GitHub

3. “Одна система для Web і Mobile”. Як це можливо, якщо патерни різні

Головна думка:
одна система ≠ однакові екрани
одна система = єдина мова + єдиний контракт.

3.1. Що в них спільне (контракт)

Зазвичай спільними є:

сенс дій (primary / secondary / destructive),
ієрархія,
стани (disabled / loading / pressed / focus),
правила візуальної виразності,
базові токени (колір, типографіка, відступи, радіуси, тіні),
accessibility як принцип.

У їхніх офіційних матеріалах Summer Release овони прямо підкреслюють: система стала більш dimensional і анімованою — це рівень мови й поведінки, а не список компонентів.

3.2. Що різне між платформами

Різне те, що диктує платформа:

навігаційні патерни (iOS vs Android vs Web),
жести й touch vs mouse/keyboard,
системні компоненти,
нюанси accessibility API.

Принцип:
система відповідає за “що і чому”, платформа — за “як саме”.

3.3 Органічна еволюція
Раніше:
єдина система → різні реалізації → суворе дотримання платформ

Тепер:
одна мова → одна естетика → платформи адаптуються під систему

Сьогодні інтерфейси Airbnb відчутно ближчі один до одного.
Платформа більше не формує обличчя продукту — його формує дизайн-система.

4. Чому всі вважають їх еталоном, навіть не бачачи “під капотом”

Тому що індустрія бачить результат:

єдину «інтонацію» продукту,
передбачуваність інтерфейсу,
швидкість еволюції без розпаду на «зоопарк» рішень.

І Airbnb першими дуже гучно показали: дизайн-система — це не набір кнопок, а Design Language: узгоджена візуальна та поведінкова мова. Це прямо лежить у тому, як вони публічно описують свої великі зміни:
“new design system”, “new interface”, “dimensional and animated”. Airbnb Newsroom

А ще є фактор «міфу»: чим менше доступно деталей, тим простіше людям домалювати в голові «там ідеальна магія».
(Не засуджуємо. Ми всі так робили.)

5. Головний публічний розбір “під капотом”: чому вони перебудовували систему, а не просто “підтримували”

Найсмачніше з точки зору інженерної логіки — доповідь “Building (And Re-Building) the Airbnb Design System” (React Conf). YouTube

Цінність доповіді не в «які у них кнопки», а в тому, які проблеми неминуче виникають у великій компанії і що вони з цим робили.

5.1. Які проблеми в них виникали (типові для будь-якого ентерпрайзу)

За переказами та матеріалами навколо доповіді (і слайдами) картина така:

фрагментація: команди починають робити «свої варіанти» компонентів,
forked code: один і той самий компонент існує у кількох несумісних версіях,
ускладнення продукту: з’являються нові сценарії та сутності (житло, враження тощо), стара структура компонентів «не тягне»,
система стає або занадто жорсткою (заважає), або занадто пухкою (не утримує консистентність).

Ця логіка прямо відображена в описах матеріалів доповіді та розборах. Slideshare

5.2. Головний висновок Airbnb (корисніший за будь-які токени)

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

І тут Airbnb зробили важливу річ: вони публічно нормалізували ідею, що систему іноді потрібно перепроєктовувати, а не «підпилювати нескінченно».

6. Що можна зрозуміти з їхнього open-source: Lona як спроба зробити “Design System as Code”

Найпоказовіший відкритий артефакт епохи Airbnb — Lona.

Офіційно Lona описується як набір інструментів для:

визначення дизайн-системи,
генерації кросплатформних артефактів: UI-коду, Sketch-файлів тощо. GitHub

6.1. Чому це важливо

Це показує їхнє мислення:
система — це не «вручну синхронізований Figma/Sketch + React».
Система — це дані й правила, з яких можна отримувати різні представлення:

«джерело істини» (структурований опис),
UI-код під платформу,
дизайн-артефакти,
документаційні матеріали.

Тобто вони намагалися піти від вічного болю:
«Дизайнер оновив компонент, у коді він інший, а в застосунку взагалі третій».

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

6.2. Як це влаштовано по шарах (з того, що можна стверджувати)

У публічному описі Lona прямо сказано про три ключові частини:

формат компонентів .component,
візуальний редактор (Studio),
компілятор (Compiler), який генерує артефакти.

Тобто «під капотом» проглядається стандартна система зрілого рівня:

model (дані / опис),
tooling (редактор / валідатор),
compiler / generator (виводи під платформи).

7. Що нам говорить Summer Release 2025 про “нову систему”: не тільки UI, а й досвід

Офіційний реліз підкреслює:

“dimensional” інтерфейс,
“beautifully animated”,
“brings the world of Airbnb to life”.

Перекладаючи з маркетингової на людську:

вони закладають у систему правила глибини / шарів (як картки нашаровуються, як контент «дихає»),
вони закладають motion-поведінку як частину мови (не «анімації за смаком команди», а спільний стиль),
вони роблять це системно, бо інакше на масштабі все перетворюється на цирк.

Сторонні медіа (Itsnicethat), описуючи редизайн, повторюють ту саму ідею: інтерфейс має залишатися “distinctly Airbnb” — живим, простим, впізнаваним. Це рівно те, чого досягає дизайн-система як «мова».

8. “Система на 200 дизайнерів”: що можна винести з публічних інтерв’ю та матеріалів

Коли в інтерв’ю фігурують масштаби типу «команда дизайнерів — сотні людей», головний сенс завжди один:

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

В інтерв’ю та матеріалах про редизайн прямо згадується, що під новий застосунок знадобилася “whole new design system”, і що це робота великої команди.

Це підтверджує простий факт: “Airbnb — еталон” не тому, що в них красивий UI, а тому, що вони вміють організувати виробництво інтерфейсу.

9. Почему “доказательства есть”, а “публичной библиотеки нет”: разделяем, что мы знаем точно, а что — домысливаем

Щоб не перетворитися на тих самих людей, які «всі говорять, але ніхто не бачив», ось чесний поділ.

9.1. Що можна стверджувати як факт (є підтвердження)

Airbnb у 2025 заявляли про нову дизайн-систему і нову візуальну мову / інтерфейс у межах Summer Release.

У Airbnb був (і публічно обговорювався) серйозний процес побудови та перебудови дизайн-системи на масштабі компанії (доповідь React Conf).

Вони ділилися інструментами та ідеями, пов’язаними з описом системи та генерацією кросплатформних артефактів (Lona).

9.2. Чого не можна чесно стверджувати (якщо не фантазувати)

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

10. Практичний підсумок: як застосувати “Airbnb-підхід” у себе (без спроб украсти їхні кнопки)

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

10.1. Будуй систему як мову + контракт

Не «UI-Kit», а:

семантика компонентів (що таке primary / secondary),
стани як стандарт (loading / disabled / focus),
ієрархія та композиція,
motion як частина мови (якщо ви доросли до цього),
accessibility як правило за замовчуванням.

(І так — у 2025 вони фактично це підтверджують через “dimensional + animated design system”: мова включає поведінку.)

10.2. Зроби платформи “діалектами”

Одна система — різні реалізації:

Web: mouse / keyboard / focus / ARIA
iOS / Android: touch / gestures / native navigation / a11y API

Система відповідає за «що і чому», платформа — за «як».

10.3. Прийми, що система буде ламатися — і заклади можливість “rebuild”

Найцінніша спадщина Airbnb — нормалізація ідеї, що:

система не вічна,
продукт змінюється,
отже архітектура системи теж має змінюватися.

Це не «провал». Це зрілість.

10.4. Інструменти: думай у бік “single source of truth”

Lona показує напрям мислення:

описуємо систему структурно,
генеруємо артефакти,
зменшуємо ручну синхронізацію «дизайн ↔ код».

Навіть якщо Lona тобі не потрібна — сама ідея «не два світи, а один» надзвичайно практична.

Замість висновку: чому тобі не потрібна “дизайн-система як у Airbnb”

Найнебезпечніша думка після всіх цих розмов: «Нам потрібна така ж дизайн-система, як у Airbnb».

Ні. Тобі не потрібна їхня система. Тобі потрібен їхній рівень мислення.

Airbnb стали еталоном не тому, що в них «ідеальні кнопки».
Вони стали еталоном, бо перестали мислити екранами і почали мислити мовою продукту. Вони зрозуміли просту, але болісну істину:

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

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

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

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

👉 Print & Kindle Amazon →
👉 PDF (Digital Edition) Gumroad →

Добра 🦫

Дизайнер, принеси мне retention. Или как рынок потерял границы ответственности

Nick Chukreiev — Mon, 08 Dec 2025 10:32:14 +0000

Сегодня о наболевшем и о наблюдении которое не покидает меня. В какой-то момент рынок коллективно решил, что дизайнер отвечает за деньги. Не за удобство, не за понятность, не за снижение ошибок, а сразу за рост, выручку, retention и LTV. Как будто дизайнер сидит где-то между маркетингом, стратегией и рынком и лично подкручивает проценты в аналитике.

Логика, конечно, красивая: интерфейс влияет на поведение, поведение влияет на метрики, метрики влияют на деньги. Только в этой цепочке дизайнер не хозяин результата, а один из элементов. Он работает с гипотезами, сценариями, решениями и человеческим поведением. Он не управляет рынком, спросом, бюджетами, стратегией и приоритетами. Но требовать с него начали так, будто он этим всем распоряжается.

Это называется не зрелостью. Это называется подмена ответственности. Сегодня пролью цифровой чай на это злободневное наблюдение.

Как так получилось, что дизайнер вдруг стал отвечать за всё

Когда-то роли в продукте были разделены вполне вменяемо. Бизнес отвечал за деньги. Продакт — за направление, гипотезы, приоритеты и метрики. Разработка — за реализацию. Дизайн — за пользовательский опыт, за то, чтобы человек не терялся, не бесился и не совершал лишних действий.

Результат всегда был общим, но ответственность различалась. И это работало.

А потом дизайн стал слишком заметным. UX стал модным. Все вдруг поняли, что интерфейс может влиять на поведение. И тут рынок сделал логический кульбит: раз влияет, значит и отвечает. Так дизайнеру начали постепенно прикручивать чужую ответственность. Без передачи власти, без инструментов управления, без финального слова.

Параллельно во многих компаниях начал вымываться продакт как носитель стратегии. Он стал координатором, фасилитатором, держателем бэклога, переводчиком хотелок между бизнесом и разработкой. Но не всегда человеком, который реально отвечает за вектор продукта и за цифры. Там, где исчезает центр управления, появляется вакуум. И этот вакуум очень удобно закрыть дизайнером. Он же “думает о пользователе”. Пусть теперь ещё подумает и о деньгах.

Кому удобно, чтобы дизайнер отвечал за провалы

Есть и более приземлённая причина. Когда показатели падают, бизнесу нужен кто-то конкретный. Маркетинг легко спрячется за фразой “рынок просел”. Продукт — за “гипотеза не взлетела”. Разработка — за “сделали как в задаче”. А дизайн — самый видимый слой. Его можно открыть, показать и ткнуть пальцем. Экран — это идеальный козёл отпущения.

Никто не тыкает в стратегию. Никто не тыкает в кривую приоритизацию. Никто не тыкает в неверную сегментацию аудитории. Зато в кнопку, пожалуйста.

Так дизайнер всё чаще становится лицом чужих ошибок.

Что дизайнер действительно обязан уметь измерять

Чтобы не было подмены смысла: дизайнер не живёт в мире вкуса и вдохновения. Он обязан опираться на факты. Но его факты — поведенческие, а не финансовые.

Он обязан понимать, где пользователь ошибается, где он теряется, где сценарий разваливается, где интерфейс провоцирует неверное действие, где растёт когнитивная нагрузка. Он обязан оперировать временем выполнения задачи, количеством ошибок, success rate сценариев, результатами usability-тестов, поведенческими паттернами.

Это про качество взаимодействия. Про ясность. Про предсказуемость. Про то, как человек чувствует себя внутри интерфейса.

Но это не про прибыль напрямую.

Где на самом деле живут деньги

Деньги живут в стратегии, в приоритетах, в выборе рынка, в позиционировании, в ценообразовании, в маркетинговых каналах, в продуктовых гипотезах. И всем этим управляет не дизайнер.

Когда с дизайнера требуют рост LTV, но он не управляет ценами, нельзя назвать это ответственностью — это просто абсурд. Когда с дизайнера требуют рост retention, но он не влияет на продуктовую стратегию и roadmap, это уже не про влияние, это про удобного виноватого.

Требовать от дизайнера выручку — это всё равно что требовать от врача финансовый отчёт по больнице. Врач отвечает за лечение. Финансовая модель — это другая система координат.

Самая токсичная ложь современного рынка — слово “ownership”

Сегодня очень любят говорить: “Возьми ownership”. Звучит солидно. Только чаще всего за этим стоит простая схема: тебе дают ответственность без власти. Ты отвечаешь за результат, но не принимаешь финальных решений. Ты отвечаешь за рост, но не влияешь на стратегию. Ты отвечаешь за метрики, но не определяешь приоритеты.

Это не ownership. Это иллюзия контроля.

Что в этой истории действительно опасно

Опасно даже не то, что с дизайнера требуют лишнее. Опасно то, что рынок системно переформатирует профессию. Из дизайнера делают универсального солдата: недопродакта, полу-аналитика, квазимаркетолога и вечного ответственного за “что-то пошло не так”.

В результате вместо сильного специалиста по пользовательскому опыту рынок всё чаще получает выгоревшего человека, который отвечает за всё, но не управляет почти ничем. Это не рост зрелости. Это рост энтропии.

Где проходит здравая граница

В нормальной системе ролей всё до смешного просто. Дизайнер отвечает за удобство, понятность, предсказуемость, доступность, снижение ошибок, качество сценариев и поведения пользователей. Продакт отвечает за направление, гипотезы, приоритеты, метрики, рост и деньги. Бизнес отвечает за стратегию, рынок, инвестиции и риски. Результат общий. Но ответственность честно разделена.

Когда же от дизайнера требуют retention, выручку и рост, не давая ему контроля над стратегией и приоритетами, это не про требования рынка. Это про организационную инфантильность. Про желание получить результат без выстраивания системы ответственности.

Что-то вроде вывода

Дизайнер обязан понимать влияние своих решений. Это факт. Но он не обязан тащить на себе всю продуктовую экономику. И пока рынок не научится различать, кто реально управляет цифрами, все разговоры про “дизайнерский impact в процентах” так и останутся красивой формой коллективного самообмана.

👉 Print & Kindle Amazon →
👉 PDF (Digital Edition) Gumroad →

Добра 🦫

Мільйони на чистці смартфонів

Nick Chukreiev — Tue, 11 Nov 2025 09:19:19 +0000

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

Що робить застосунок ідеальним

Якщо прибрати соціальні мережі та багатомільярдні платформи, формула “ідеального застосунку” стає напрочуд простою:

Він потрібен майже на кожному телефоні.
Має високу утримуваність завдяки підпискам або разовій оплаті.
Користувач платить майже миттєво.

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

Що насправді роблять клінири

Такі застосунки обіцяють:

Очистити галерею від сміття: скріншотів, дублікатів, випадкових відео, що з’їдають гігабайти.
Об’єднати дублікати контактів (“Alex Pizza”, “Alex Piza”, “Alex Delivery”).
Видалити кеш месенджерів, забитий роками переписок.
Прибрати непотрібні застосунки.
Почистити пошту від спаму.

Деякі йдуть далі та додають VPN чи “захист від вірусів”, щоб виглядати як універсальний набір утиліт. І, звісно, класика жанру “Battery Booster”, який не робить абсолютно нічого.

Аудиторія та гроші

Типовий користувач? Власники підгальмованих Android-ів чи старих iPhone-ів від таксистів до офісних працівників. Їх сотні мільйонів по всьому світу.

Самі застосунки гранично прості. Без ракетобудування, без складних AI-моделей. Один розробник середнього рівня може зробити робочий “клінер” за кілька вихідних.

Моделі монетизації варіюються від $5 на тиждень до $30 на місяць або “довічної ліцензії” за $99 (для тих, хто вірить у вічне життя свого сховища). Є й безкоштовні версії обвішані рекламою, як різдвяна ялинка.

Конкуренція скажена. Десятки застосунків заробляють понад $1 млн на рік, сотні принаймні $10 000+. Але нові продукти з’являються постійно, бо скільки б не минуло часу телефони людей завжди будуть переповнені.

Головна гра — маркетинг

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

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

На кшталт висновку

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

Не бійся насичених ринків навчись конкурувати на них. Це краще, ніж створювати те, чого нікому не потрібно.

👉 Print & Kindle Amazon →
👉 PDF (Digital Edition) Gumroad →

Добра 🦫

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

Nick Chukreiev — Thu, 16 Oct 2025 13:28:49 +0000

Це звучить як комедія про великі гроші поки не розумієш, що це радше фінансова драма. Вересень 2025 року. Три технологічні гіганти: OpenAI, Oracle і NVIDIA влаштовують ідеальний фінансовий колообіг на 300 мільярдів доларів.

Я ось за чим споглядаю. Спершу OpenAI підписує контракт з Oracle на постачання обчислювальних потужностей на всі ті ж 300 мільярдів. Акції Oracle стрімко злітають. Ларрі Еллісон на короткий час стає багатшим за Ілона Маска.

Через кілька днів Oracle оголошує нову угоду, тепер із NVIDIA. Вона купує чипи для тих самих дата-центрів, щоб обслуговувати той самий OpenAI. Сума 40 мільярдів із потенціалом зрости до трьохсот.

І фінальний штрих, NVIDIA інвестує 60 мільярдів доларів назад в OpenAI. Коло замикається. OpenAI платить Oracle, Oracle платить NVIDIA, NVIDIA знову вкладає в OpenAI. На папері всі виглядають переможцями. Акції ростуть. Але по суті ніхто нічого не створив. Просто поганяли гроші туди-сюди.

📈 Економіка хайпу

У 2025 році 80% зростання американського фондового ринку припало на компанії, пов’язані зі штучним інтелектом.
AI також забезпечив 40% зростання ВВП США.
На папері — економічне диво. На практиці мильна бульбашка, надута очікуваннями.

Дата-центри ще не добудовані, «суперінтелект» навіть не на горизонті, а капіталізація OpenAI уже сягає пів трильйона доларів. Ріст не завдяки продуктам, а завдяки вірі.

🕹 Повернення доткомів

Ми це вже бачили. Кінець 90-х. Будь-який стартап із «.com» у назві отримував мільйони. Тоді компанія Cisco продавала маршрутизатори та комутатори — інфраструктуру для Інтернету.
Іншими словами, лопати для цифрових золотошукачів.

Cisco стала найдорожчою компанією у світі. А потім бульбашка луснула.

⚙️ NVIDIA — нова Cisco

Сьогодні роль продавця лопат виконує NVIDIA. Вона контролює ринок AI-чипів і має капіталізацію $4,5 трильйона. Якби NVIDIA була країною, стояла б поряд із Німеччиною за розміром ВВП. І все це з 36 тисячами співробітників. Інвестори знову відчувають знайоме дежавю.

🔁 Коли гроші ходять по колу

Більшість доходів NVIDIA сьогодні походить від «AI дата-центрів». Але покупці цих дата-центрів — ті самі компанії, у які NVIDIA вкладає гроші.

OpenAI: –8 мільярдів доларів.
Anthropic: –2 мільярди.
xAI (Ілон Маск): –5 мільярдів.
Gemini і LLaMA тримаються на плаву лише завдяки материнським корпораціям.

Це не розвиток. Це замкнена екосистема, де гіганти обмінюються взаємними борговими зобов’язаннями.

🧮 Стартапи без прибутку

OpenAI обіцяє зрости з $6 мільярдів до $55 мільярдів до 2029 року. Звучить гарно, поки не згадати, що ринок переповнений безкоштовними альтернативами,а позови за авторські права сипляться один за одним.

AI сьогодні продає не результат, а надію.

🏛 Занадто великі, щоб впасти?

Здається, цього разу все інакше — держави теж інвестують у штучний інтелект. Від оборони до освіти. Але історія пам’ятає Lehman Brothers. Коли бульбашка лопається, корпорації не платять за рахунками. Платять громадяни.

💬 На кшталт висновку

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

Якось так.

👉 Print & Kindle Amazon →
👉 PDF (Digital Edition) Gumroad →

Добра 🦫