Штучний інтелект зруйнував не інструменти дизайнера, а спільну систему координат. Однакові дослідження, метрики та кейси про ШІ різні команди читають протилежно: для одних це доказ, що професія зникає, для інших — що вона нарешті звільнилася від рутини. Спільнота UX-дизайнерів залишилася без консенсусу, на який можна спертися, ухвалюючи рішення про інструменти, процеси й навички.
Проблема не в браку даних. Їх якраз достатньо: звіти про продуктивність, кейси впровадження, статистика вакансій і зарплат. Проблема в тому, що ці дані не складаються в єдину картину. Той самий графік зростання генеративних інструментів один дизайн-лід прочитає як «треба терміново вчити промпти», а інший — як «це тимчасовий хайп, який не змінює суть роботи». Обидва мають аргументи. Обидва ризикують.
Для українських продуктових команд це не абстрактна дискусія. Дизайнер в агенції чи продуктовій команді щодня ухвалює рішення: чи вбудовувати ШІ в дизайн-систему, чи переписувати бриф, чи міняти процес досліджень, чи наймати людину з новими навичками. Коли немає спільної опори, кожен керівник вирішує на свій страх і ризик — і саме тут виникають дорогі помилки.
Найпомітніше це в трьох площинах. Перша — інструменти. Figma, Adobe та десятки стартапів додають генеративні функції, але команди не мають спільного розуміння, чи це прискорює роботу, чи додає технічного боргу. Друга — процеси. Частина студій уже віддає ШІ чорнові макети й тексти, інші принципово тримають його подалі від клієнтських проєктів. Третя — люди. Junior-дизайнер, який учора робив іконки, сьогодні конкурує з моделлю, і ніхто не скаже йому, яку навичку вчити наступною.
Відсутність консенсусу має й практичний бік. Коли немає єдиної думки, рішення ухвалюють ті, хто голосніше говорить або швидше продає — часто це не дизайнери, а постачальники інструментів. Їхній інтерес — продати підписку, а не зробити команду ефективнішою. Українським командам варто це враховувати: не купувати інструмент, бо про нього всі пишуть, а перевіряти його на власному процесі.
Що робити без спільної опори? По-перше, фіксувати власні метрики, а не покладатися на чужі звіти: скільки часу йде на макет, скільки ітерацій до затвердження, скільки правок після передачі в розробку. По-друге, домовлятися всередині команди, де ШІ можна, а де не можна — і записувати це в регламент. По-третє, вчити не інструмент, а мислення: формулювати задачу, оцінювати результат, ставити правильні питання.
Консенсус у дизайні, схоже, не повернеться. Але це не привід чекати, поки хтось інший вирішить. Українські команди, які сьогодні самі визначать правила роботи з ШІ, отримають перевагу над тими, хто досі шукає єдину правильну відповідь.
4
