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

Стати «світлим» не зробить тебе необанком

Mike Hafin — Fri, 19 Jun 2026 13:05:46 +0000

MiCA змушує кожну криптокомпанію в Європі виглядати надійно. І більшість зараз зробить ту саму помилку.

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

Це приходить від платіжних компаній, бірж, стейблкоїн-стартапів — тих, хто роками виглядав як «майбутнє», а тепер хоче виглядати як банк. Точніше, не банк. Необанк. Швидкий, чистий, регульований, такий, якому не страшно віддати гроші. Перше, що просять прибити, — градієнт.

Це не смак нарешті дозрів. Це MiCA. Без ліцензії ти більше не працюєш у європейській крипті — а ліцензована компанія, яка досі виглядає як DeFi-протокол 2021 року, має проблему, яку її юристи не вирішать.

Тож уся індустрія тихо перемальовує себе під «надійність». Звучить як прогрес. І саме тут більшість робить ту саму помилку.

Аудиторія перевернулась

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

П'ятнадцять років крипто-бренди робили для своїх — ранніх адоптерів, розробників, віруючих, які обрали крипту саме тому, що це не банк. Їх не треба було заспокоювати. Градієнт, темний дашборд, енергія «to the moon» — це були не поганий дизайн, а племінні сигнали. Вони казали: ми не вони. Для тієї аудиторії в цьому й був увесь пітч.

Та аудиторія більше не платить за рахунками.

Ліцензована компанія в Європі тепер відповідає перед тими, хто ніколи не був у племені: регулятор, що читає заявку; банк, що вирішує, чи відкривати рахунок; інституція, що вирішує, чи пускати обсяг; звичайна людина, що вирішує, чи переказати сюди зарплату. Ніхто з них не читає сяйливий градієнт як «інноваційно». Вони читають його як «нерегульовано». Той самий логотип, та сама компанія, той самий продукт — але аудиторія перевернулась, і бренд, що був активом, тихо став пасивом.

Стати «світлим» — це вибір, а не відповідь

Тож вони хапаються за очевидне: піти у світле, чисте, спокійне. Але «світле» — це не відповідь. Це одна з відповідей.

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

І градієнт, від якого всі тікають, уже замінюється новою одноманітністю — той самий офвайт, той самий стриманий шрифт, той самий спокій. Шлях для втечі перетворився на затор. Для челенджера, що заходить у ЄС, виглядати «чисто» тепер означає виглядати як усі, хто почистився. Стратегічний хід — не виглядати безпечніше. А виглядати безпомилково як ти сам, лишаючись беззаперечно надійним.

Довіра — це не колір

Це ніколи не було історією тільки про крипту. Це те, що робить будь-яка фронтир-технологія, дорослішаючи: перестає вдягатись як бунт і починає вдягатись як інституція. Подивись на AI зараз — та сама втеча від неонового «майбутнього» до стриманого, надійного, enterprise-дизайну. І рушій той самий: MiCA робить із криптою приблизно те, що EU AI Act робить з AI — тягне її з фронтиру в регульоване поле.

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

Чиста головна сторінка перед дашбордом 2021 року — це не прогрес. Це підказка. Маркетинг подорослішав, продукт — ні. Для регулятора чи інституції цей розрив читається саме тим, чим є: костюм, а не компанія.

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

У легітимності є вигляд — але вона ніколи не була тільки виглядом. Виглядати на роль можна за пів дня. Стати нею, до самого низу, — оце вся робота. Більшість зупиниться на поверхні. Ринок розбереться з ними доволі швидко.

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

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

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

Підсумок

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

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

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

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

UX Slogans by NNGroup

Євген Олексюк — Sat, 06 Jun 2026 13:44:11 +0000

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

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

Дуже часто студенти питають «А що робити якщо замовник/стейкхолдер починає пітчити свої ідеї?» тому що йому нібито видніше і взагалі його візія є єдиновірною? Зазвичай ми починаємо батлити на цю тему і все зводиться до того що замовник знає гірше аніж його юзер. Звідси витікає тейк що «Дизайнер працює на клієнта клієнта» адже монетизує ендюзер.

А ще я люблю розповідати байку про одну компанію, яка в welcome package дизайнера клала футболку з написом ТИ НЕ Є ВАЛІДНИМ! То є нагадування що думки ані дизайнера, ані стейкхолдера, ані будь-кого з проєктної тіми не мають критичної ваги. І звісно ж, цей напис не є оригінальним — це є лише варіація одного з слоганів Nielsen Norman Group.

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

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

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

UX Slogan #1: You ≠ User

Ти Не Є Користувач

Вперше цей слоган був сформульований в 1993 році в книжці Якоба Нільсена «Usability Engineering». Тут все кристально зрозуміло, але часом важко донести це до команди, адже всі вважають себе Mr.KnowItAll. Очевидно, всі члени вашої тіми матимуть свої погляди на те «ЩО і ЯК краще для користувача», але всі ці погляди засновані суто на досвіді та спотвореннях кожного конкретного члена команди, на їх бажаннях і візіях.

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

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

Дизайнери (а також Проджект Менеджер, Продукт Менеджер, Бізнес Аналітик, Делівері Менеджер і тд) це взагалі максимально спотворені ролі і їх слухати категорично заборонено.

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

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

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

Тому думка користувача найважливіша! Хорошим рішенням є тримати у вільному доступі головні артефакти проєкту (опис юзер персони, CJM, перелік проблем користувача, можливо якісь канваси проєкта) — наприклад в мітінг румі або опенспейсі розвісити роздруковані артефакти і стікери на стіні, щоб в будь-який момент обговорення чи грумінгу можна було остудити голову тіммейта словами «Давай не забувати що ми не користувачі і просто глянемо, хто ж наша цільова»😉

youtube.com

UX Slogan #2: Keep it Simple

Зберігай Простоту

Думаю всі ми знаємо абревіатуру KISS як Keep It Simple Stupid. По суті цей слоган нам говорить те саме — необхідно спрощувати все максимально. Ми вже говорили про таке поняття як «когнітивне навантаження» коли розбирались з Законами Хіка та Міллера в статті Laws of UX та на UX Break: Закони UX — теорія та практика.

В слогані #2 говориться звісно ж про перегружений інтерфейс і про те, наскільки легко або важко ним користуватись юзеру. Одразу згадуємо момент, коли ви вперше зайшли в Photoshop і нажахались всіх його фіч/функцій/можливостей. На початку своєї карєри, я працював в ФШ і це було пекло, адже весь функціонал не знав ніхто, половина функцій була взагалі не потрібна, а друга половина потрібна, але захована невідомо де. Перший макет я малював з відчуттям, ніби мене кинули в кабіну літака і сказали «нам треба летіти, натискай що завгодно, але ми МАЄМО летіти».

Але слоган нам говорить не суто про доступну реалізацію необхідного функціоналу, а й про необхідність надання юзеру певного конкретного функціоналу. Всі хто працював з дизайн-процесом (Design Thinking, Double Diamond, та інші дизайн-процеси), знає, що процес передбачає так звану сцепку «утилітарність + юзабіліті». Тобто коли ми говоримо про простоту, то охоплюємо також і момент утилітарності. Щоб продукт був потрібний юзеру, ми повинні дати йому саме те, за чим прийшов користувач і настільки зручно, наскільки це можливо.

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

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

Ну і в якості пруфів зрозумілості простого інтерфейсу — гляньте так звані one_button сайти — наприклад one-button.vercel. Або згадайте як виглядає домашня пошукова сторінка від Google. Ці сторінки прості як двері і в них важко заплутатись. 😆

UX Slogan #3: You Can’t Impose Joy

Ти Не Можеш Нав’язати Радість

Слоган #3 нам говорить про те, що не потрібно примушувати користувача кайфувати від вашого дизайну. Тут все досить просто — будь-який продукт закриває біль користувача. Тобто людина приходить на продукт з метою зробити ЩОСЬ ВАЖЛИВЕ, що її бентежить. І коли сайт (чи застосунок) починає гратись з юзером різними юайними приколясами (сплешскрінами, оверанімованим інтерфесами, тощо) то ці прікольчікі, скоріш за все, викличуть не посмішку, а роздратування користувача.

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

UX Slogan #4: Communication not Decoration

Комунікація, а Не Декорація

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

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

Мій особистий тейк полягає в тому, що важливо знайти баланс — щоб дизайн був не нудним і цікавим для юзерів продукту і самому дизайнеру в процесі роботи. Але НЕ БІЛЬШЕ! Ну бо креативність буде оплачувати ваш замовник, який зацікавлений в збільшенні прибутку.

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

Ну і в якості поганих прикладів ЯК РОБИТИ НЕ ТРЕБА ось вам:

zentry.com з їх дивними кнопками і тяжким сайтом;
spylt.com також з дивними кнопками і паралаксами;
мій фаворит mew.xyz — взагалі не зрозуміло з чим можлива взаємодія, а з чим ні (а за ховер-стейт кнопок взагалі окреме дякую).

UX Slogan #5: Brevity = Brilliance

Лаконічність = Геніальність

Уявимо собі ситуацію — ви слухаєте промову якогось дуже класного спікера. Топік вам цікавий, але спікер розповідає дуже «багато літер», використовує дивні метафори, тощо. Скоріш за все, ви загубитесь в його думках і не сприймете інформацію. В письмі є термін «графоманія» — це є антипод лаконічності і, якщо в художній літературі пишність фраз автора допустима, то в інтерфейсі це зайве. Всі ми чули, що юзер не читає, а сканує сторінку, тому якщо ви навалили на ній тексту, то його шанси бути прочитаним обернено-пропорційні величині масиву цього тексту. Тому давайте будемо скорочувати наші інтерфейси. Цей слоган працює як доповнення до слогана #2 (Зберігайте простоту).

Ось вам антиприклад — www.discountbedsbelfast.co.uk — забагато текста і, як наслідок, нічого не зрозуміло. А за менюшку взагалі їм окремий антилайк😂

Якщо ми говоримо про вміння працювати з текстом (що є одним зі скілів дизайнера), то ви можете качнути цю навичку. Наприклад раджу вам книгу «Письмо — це дизайн: Як слова створюють досвід користування (UX)» Майкла Меттса та Енді Велфл. Ну або, як варіант, можете почитати коротко про цю книгу тут.

UX Slogan #6: «Why» Beats «What» in UX

«ЧОМУ» Важливіше Ніж «ЩО» в UX

Загалом заруба між Human Centered Design (HCD), Data Driven Design (DDD) та Tech Driven Design (TDD) ведеться вже дуже давно. Якщо ми говоримо про ефективний з точки зору монетизації дизайн, то тек-дрівен можемо взагалі відкинути, адже ризик зробити НЕ ТЕ що треба енд-юзеру (який заплатить продукту) в ньому максимальний. Окремі ж суперечки точаться між любителями даних і аналітики і адептами HCD. Звісно, сила в поєднанні HCD та DDD (згадуємо нашу улюблену триангуляцію кількісними якісних), але головний тейк саме цього слогана, про який нам розповідає Якоб Нільсен, полягає в тому що «суха дата» не є така ж важлива, як розуміння ЧОМУ все відбувається як відбувається.

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

Як написав пан Якоб Нільсен в своєму пості, де пояснив, що сила якісних досліджень в їх швидкості та ітеративності (раджу почитати пост — він не великий).

Тому я рекомендую спрямовувати більшу частину бюджету дослідження користувачів (близько 90%) саме на якісні методи. Решта 10% для кількісних методів, таких як масштабні опитування чи бенчмаркінг, — це розкіш, яку можуть собі дозволити лише UX-команди з високим рівнем мачюрності.

Якщо ж ми говоримо про вже існуючий продукт, то періодично стає питання редизайну. Метрики (кількісні дослідження) будуть прекрасним маркером проблеми — вони покажуть що щось не працює, але причину (глибоке розуміння юзера, його думок і мотивацій) нам вкажуть саме якісні дослідження. Ось ЧОМУ важливіше за ЩО.

п.с. Суто моя думка з цього приводу: слоган цікавий, але трошки не вірний, адже віддавати перевагу ЧОМУ або ЩО так саме не правильно, як спитати в дитини, кого вона любить більше — маму чи тата. Для дійсно якісної та коректної роботи дизайнера (і всього продукту загалом) необхідно значи і ЧОМУ і ЩО! Обидва питання важливі і обирати або віддавати перевагу тут не є доцільним.

UX Slogan #7: UX is People

UX Це Люди

Перед тим як розповісти про сам слоган, дозвольте трошки духоти і історії 😉

Є така штука як Human-Computer Interaction (HCI) — це така мультидисциплінарна галузь, яка вивчає, як люди взаємодіють із комп’ютерними технологіями, та фокусується на проектуванні, оцінці та впровадженні інтерактивних систем, що є зручними та ефективними для користувача. Тобто якщо UX-дизайн — це практична частина створення продукту (не завжди, але в контексті UX, саме цифрового), то HCI — це саме теоретична частина, на якому базується UX. То є саме науковий фундамент.

Існує також поняття «золотого трикутника» HCI:

Людина (Human) — тут ми маємо на увазі нашого користувача, як живу людину з її когнітивними і психологічними особливостями, пам’яттю, тощо;
Комп’ютер (Computer) — це вже суто технологія, апарат взаємодії, «залізо» та «софт»;
Взаємодія (Interaction) — двосторонній процес обміну інформацією між людиною та комп’ютером. До ключових принципів HCI відносяться багато відомих вам речей: можливості, ментальні і концептуальні моделі, юзабіліті, аксесабіліті, ефективність, задоволеність, тощо.

Загалом HCI з’явився майже 100 років тому — в 1940-х роках, але то був дуже примітивний рівень, адже то була ера «Людина як оператор», де з комп’ютерами взаємодіяли спеціально-навчані люди за допомогою перфокарт. Прорив стався в 1970-х, коли XEROX розробили свій графічний інтерфейс, який вже «запозичили» спочатку Apple, а потім і всі інші виробники комп’ютерів.

Ось вам відео з рекламою того-самого першого пра-пра-компа 1972 року :

Доречі, саме тоді і з’явились поняття «робочого стола», «іконок», тощо. І аж в 1983 році Аллен Ньюелл, Стюарт Кард та Томас Моран видали в світ свою фундаментальну працю «The Psychology of Human-Computer Interaction», яка фактично і cтворила UX-дизайн. Звісно, вперше «UX» ввів в назву свого тайтла Дональд Норман аж в 1993 році, коли приєднався до Apple на посаду User Experience Architect, але це вже зовсім інша історія.

Історія про HCI тут для того, щоб нагадати, що в ланцюгу юзер-взаємодія-комп’ютер, можуть змінюватись комп’ютери (з’являтись нові девайси типу лептопа, смартфона, годинника чи планшета, VR чи AR, голосові помічники, тощо, компи можуть ставати сильніші щороку), може змінюватись взаємодія (в залежності від девайсу та існуючих паттернів), але незмінною ланкою тут є ЛЮДИНА.

Так от, якщо ми розглянемо процес розробки продукту, то в ньому задіяно 2 типи людей:

Людина-користувач — тут мається на увазі саме юзер, для якого працює команда продукту;
Людина-UX-дизайнер — а тут вже ми говоримо саме про команду дизайнерів, які є передавальною ланкою. Мені особисто подобається вираз «Дизайнер це перекладач з людської мови на технічну і навпаки». Нюанс полягає в тому, що дизайнер в продукті це людина, яка не тільки малює макети, а й приймає певні рішення щодо функціоналу (разом з ПМ, БА, стейкхолдерами і тд). Тобто роль дизайнера передбачає безпосередній вплив на продукт, а отже і на користувача. Виходячи з цього, на UX впливають саме люди: користувачі і команда розробки. А отже UX є люди!

Вже можна відкривати вікна — здається тут було трошки душно 😎

UX Slogan #8: Make it Easy

Спрощуй

Якщо в слогані #2 ми говорили що потрібно Зберігати простоту, то слоган #8 нам наголошує саме на Спрощенні. Для кращого розуміння, давайте сформулюємо ці слогани англійською: Keep It Simple VS Make It Easy. Тобто слоган 2 нам підказує, що необхідно саме зберігати простоту, не збільшуючи складність, а в слогані 8 ми говоримо саме про спрощення — тобто зменшення складності як активну дію.

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

В якості прикладу — ось вам дивний черговий one-button сайт з примітивною (хоча і непотрібною) дією clickclickclick.click (бажано зі звуком)

UX Slogan #9: Less is More

Менше — Це Більше

Коли я вперше ознайомився з цим слоганом, я подумав «Та скільки вже можна про ту простоту — це ж було вже» (тут я мав на увазі слогани #2 та #8). Але коли розібрався, то побачив різницю. Коли ми говоримо про простоту зі слоганів 2 та 8, то маємо на увазі саме певний функціонал і якесь конкретне інтерфейсне рішення. І саме їх ми хочемо спрощувати та/або не ускладнювати. В цьому випадку простота стосується саме виконання користувачем цільової дії (тобто це флоу).

Впевнений, ви багато чули про той самий «безшовний досвід», який передбачає здійснення юзером певної цільової дії без зайвого тертя об інтерфейс. Дизайнер складає CJM, JTBD Timeline, Service Blueprint та інші мапінги, шукає bottleneck-и, вирішує точкові проблеми — і все це для легкого досягнення мети і закриття болю юзера. Зазвичай в якості ключового сценарію береться саме флоу монетизації, як головної цільової дії користувача в продукті. Дизайнер зацікавлений зробити цей шлях легким — щоб нічого не відволікало юзера, щоб всі сумніви і невпевненості були мінімізовані, а різкість негативної емоції була мінімальна, або взагалі відсутня. На своєму шляху користувач використовує інтерфейс, бере необхідну інформацію, споживає контент, взаємодіє з елементами інтерфейсу сторінки.

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

Мені особисто цей слоган віддалено нагадав вираз Голдена Крішни з його книги «The Best Interface is No Interface»:

Коли ми проектуємо інтерфейси, ми проектуємо бар’єри між людьми та їхніми цілями

Проводячи паралель між цим виразом і слоганом #9, можна сказати що чим менше бар’єрів в інтерфейсі ми робимо, тим краще!

UX Slogan #10: Users Are Not Lazy

Користувачі Не Ліниві

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

Тут все просто як двері — користувачі не є лінивими — вони раціональні. Мені здається це пов’язано з когнітивним навантаженням. Адже коли в людини виникає проблема, вона починає думати, а мозок — найенерговитратніший орган (при вазі лише 2% від маси тіла людини, мозок споживає біля 20% енергії). Тож користувач не сильно любить напружуватись, а робота дизайнера не напрягати юзера зайвий раз.

В вищезгаданій книзі Голдена Крішни «The Best Interface is No Interface» є ще один цікавий вираз, який буде дуже валідно згадати тут:

Користувачі не є лінивими — вони просто хочуть отримати результат з найменшим спротивом

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

UX Slogan #11: If You’re Not Checking, You’re Guessing

Якщо Ти Не Перевіряєш — Ти Вгадуєш

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

NNG виділяють 3 причини, чому команди можуть відступати від необхідності формулювати свої продуктові гіпотези на основі досліджень:

Члени команди розробки та замовник в певній мірі є користувачами продукту і тому покладаються на власний досвід користування Тут одразу ремарка — згадуємо Слоган #1: Ти Не Є Користувач!
Команда і стейкхолдери вважають себе достатньо компетентними в домені, щоб приймати рішення суто на інтуїції, адже їх «експертна думка» завжди правильна Тут вже цікавіше — якщо продуктовий дизайнер працює в домені вже досить довгий час, він дійсно добре знає аспекти. Але мудрий працівник все-одно буде ставити під сумнів власні припущення. Вийшло занадто в дусі Сунь-Дзи, але так воно є. З іншої сторони — погано коли продукт працює суто на асампшенах дизайнерів та/або ПМ-БА, адже ці ролі напряму впливають на розвиток продукту, що зобов’язує їх мати велику надивленість. А часто оверкомпетенція та овернадивленість може завадити.
Команди вважають дослідження занадто дорогими і не сильно потрібними
Якщо проводити всі на світі активності, то в цьому випадку певна доля істини тут є, але якщо підходити до досліджень з розумом, то можна їх сильно здешевити. Завжди можна кастумізувати свій дизайн-процес, пропрацювати стратегію з мінімальними бюджетами і вставити в процес розробки ті UX-активності, які проект може собі дозволити.
Я особисто додав би ще одну причину:
Надмірне використання командою Штучного Інтелекту
Часто команда та замовник впевнені, що з однієї сторони UX-дослідження це дорого, а з другої сторони Штучний Інтелект (ШІ) може замінити дослідження. І оце масове захоплення ШІ наразі дуже шкодить, адже ШІ-шка вміє круто процесити, обробляти великі масиви даних, допомагати при деск-рісерчі, але в питаннях інсайтів, формулювання продуктових гіпотез або ідеації та валідації солюшенів, ШІ взагалі непридатний.
Існує цікава статистика основана на дослідженнях таких гігантів як Google, Microsoft та Netflix, що лише 10% продуктових гіпотез приносять якесь бізнес-велью. Це при тому, що компанії постійно проводять дослідження. Якщо ж будувати гіпотези на здогадках, то цей відсоток зменшується критично.

Ну і останній тейк: UX-дизайнер на проекті виступає мінімізатором ризиків, тому не варто дивуватись що продукт почав валитись, якщо в ньому не застосовується UX. Надмірна сервільність дизайнера не є доречною, адже може призвести до фінансових втрат.

UX Slogan #12: More Choices More Trouble

Більше Вибору — Більше Проблем

Цей слоган дуже схожий на сформульований Уільямом Хіком та Рейем Хайманом в 1952 році Закон Хіка. Тому зекономлю ваш час на читання очевидних речей. Та і вкотре пояснювати кореляцію між кількістю варіантів та когнітивним навантаженням на користувача не сильно хочеться. Краще розповім чергову цікаву байку.

В 2002 році Баррі Шварц написав свою роботу «Maximizing Versus Satisficing: Happiness Is a Matter of Choice», де досліджував Парадокс вибору та наскільки сильно зростає роздратування покупця в залежності від опцій, між якими необхідно зробити вибір.
Але це дослідження не є першоджерелом, фундаментальним був експеримент Шини Айєнгар та Марка Леппера описаний в їх роботі «When Choice is Demotivating: Can One Desire Too Much of a Good Thing?» 2000 року. Саме їх експеримент з джемом став емпіричним підґрунтям дослідження Баррі Шварца. Просто нагадаю — в експерименті було 2 столика: з 6 видами джему та з 24 видами джему. За сценарієм експерименту, людині давали купон на знижку в 1$ для покупки собі джема та направляли до одного зі столів. Результати експерименту здивували всіх:

Зупинились біля столика (умовний аквізишн): 60% біля стола з 24 сортами джему та 40% біля стола з 6 сортами джему;
Скоштували джем (тріальна версія): — по 2 сорти біля кожного зі столиків;
Купили джем (конверсія в продаж): 3% в стола з 24 сортами джему і 30% в стола з 6 сортами джему;
Задоволеність покупців (сатісфекшен): була істотно вища в покупців в стола з 6 сортами джему.

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

UX Slogan #13: Design for Them Not for You

Дизайнь Для Них, Не Для Себе

Не розумію навіщо писати дубль слогана #1 «Ти Не Є Користувач» просто в іншому формулюванні?! Загалом в відео Сара Гіббонз вкотре розповідає про важливість не забувати про те, що дизайнер не є юзером. Тому, щоб не повторюватись, краще розповім вам про «Ефект хибного консенсусу», який згадується в відео.

В 1977 році Лі Росс провів дослідження з назвою «людина-сендвіч», в результаті якого і був сформульований «Ефект хибного консенсусу». Пан Лі з колегами запропонували групі студентів Стенфордського Університету (104 особи) взяти участь в «дослідженні технік комунікацій». Студентам пропонувалось добровільно вдягнути на себе рекламний щит (так званий «сендвіч» з написом на спині та животі) з рекламним слоганом «Їжте у Джо» та 30 хвилин ходити по кампусу. Студентам не обіцяли матеріальної винагороди, проговорювалась можливості відмовитись і наголошувалось на тому, що їх участь нібито дуже допоможе в дослідженні технік комунікацій.

В результаті дослідження були цікаві інсайти:

62% з тих, хто погодився, були впевнені що переважна більшість студентів вибірки погодяться. А тих, хто відмовиться характеризували «занадто сором’язливими», «егоїстичними» або «дивними»;
Лише 33% від тих, хто відмовився брати участь в експерименті, були впевнені що більшість погодяться. Тобто 67% (100% — 33%) вважали що більшість теж відмовиться і характеризували тих, хто погодиться «вискочками», «дурнями» або «тими, хто хоче привернути увагу». Це дослідження висвітлює власну пресуппозицію правоти та асоціації себе з користувачем і це дуже погано для дизайнера.

UX Slogan #14: It Depends

Це Залежить Від…(обставин)

Коли мені джуни або студенти кажуть фразу «Ну це залежить від…», я завжди відповідаю що It Depends — це завжди правильна відповідь на будь-яке питання. То є певна універсальна відповідь незалежно від поставленого питання😉

Загалом обставини, або контекст ситуації можна розкласти на певні складові:

Утилітарність та Цінність Тут ми говоримо загалом про цінність вашого продукту саме для користувача і чи він здатний закрити біль (проблему) юзера, з якою той прийшов до вашого продукту.
Доступність та Інклюзивність Чи дозволяє продукт закрити біль всієї цільової аудиторії і чи не ігнорує людей з певними обмеженнями (щодо аксесабіліті є багато статей, тож на цьому я зупинятись не буду зараз). Але один аспект все ж виділю — не забувайте що ситуативна обмеженість трапляється з користувачами досить часто. Наприклад, людина під час стресу або в умовах обмеженого часу буває досить часто (особливо коли проживає в наш час в Україні), тож ці ситуації необхідно також враховувати.
Зручність використання (юзабіліті) та когнітивне навантаження Ну тут все ясно — продуктом повинно бути зручно користуватись (якщо це не ситуація з розряду монополії, олігополії, монопсонії), інакше юзер піде закривати свій біль на продукт-конкурент.
Бажаність як емоційний відгук користувача Хороший продукт завжди викликає в користувача довіру, позитивні емоції, консистентно спілкується з ним за допомогою мікроанімацій та tone of voice. Згадайте той самий monobank https://monobank.ua/ з його котиками. Люблю розповідати цю історію — колись ми з друзями літали в Копенгаген і в аеропорту десь загубили мого (тепер вже) кума. А він лише ходив в дьюті фрі щоб купити щось і відкрити чергового котика в МОНО. Андрюха, якщо ти це читаєш, дякую тобі за круту історію!
Бізнес логіка Тут все максимально просто — ваш продукт повинен бути не тільки самоокупним, а й прибутковим, тому команда завжди ретельно прораховує ROI та інші KPI.
Технічні особливості і обмеження Дизайнер повинен враховувати особливості технології, на якій написаний продукт. Тому бажано розуміти (хоча б мінімально) особливості використаного фреймворка/платформи/технології. Тоді імплементація дизайн-рішення буде коштувати дешевше крила літака.

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

Якщо вам потрібно враховувати обставини в яких знаходиться не користувач, а ВИ як дизайнер, то просто нагадую вам про Method • Reason • Price як метод підбору активностей.

Є ще цікавий нюанс про який нам розповідає відео від NNG — дуже часто дизайнери використовують бест практіси як сільвер булет — як щось, що працює завжди і в будь-якій ситуації. Звісно, бест практіси це вже перевірені дослідженням, часом і кейсами практики, вони є певним бенчмарком, але вони занадто загальні і ігнорують той самий контекст, тому не є оптимальними ЗАВЖДИ. Виходячи з цього, для забезпечення найкращих результатів (конверсії в щось важливе та інших KPI), бест практіси можна змінювати в залежності від того, в якій ситуації знаходиться юзер.

UX Slogan #15: Show Me the Data

Покажи Мені Дані або мені краще подобається Покажи Пруфи!

Дуже часто, коли команда обговорює якусь нову фічу, або лейаут, в обговорення прокрадається суб’єктивна думка ваших мейтів. Особливо дивно, коли розробники починають транслювати ЩО САМЕ потрібно користувачам, яка повинна бути кнопка чи чому макети погані. А дивно це тому, що то є суто думки ваших мейтів — вони є суб’єктивні і не підкріплені нічим. В цей момент мало просто нагадати слоган #1 «Ти Не Є Користувач», бажано ще додати «Покажи Мені Дані».

Якщо ми говоримо про продукт, який працює не суто на якісних дослідженнях, а й періодично проводить сурвеї, SUS і постійно міряє метрики з аналітики, то кількісні дані можуть легко підтвердити або спростувати асампшени ваших колег. Якщо ж це аутсорзний проект (без доступу до всього вищеперерахованого), то «відстрілювати рожеві поні» клієнта та мейтів, буде набагато важче (ми вже говорили трошки вище про HCD, DDD та TDD в слогані #6).

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

Саме тому на мою думку слоган #15 валідніше перекласти не як «Покажи мені дані», а як «Покажи пруфи!». Саме в наданні доказів і лежить суть слогану — тоді він допоможе знизити ризики прийняття невірного рішення.

UX Slogan #16: UX Researchers, We Like to Watch

Як UX-Дослідники, Ми Любимо Спостерігати

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

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

Юзер Інтерв’ю Касдев це найрозповсюдженіший метод дізнатись проблеми користувачів за допомогою спілкування з ними;
Модероване Юзабіліті Тестування Прекрасний метод якісного дослідження, що допомагає валідувати ваші інтерфейси;
Польові Дослідження Один з видів контекстного дослідження, під час якого дослідник може спостерігати за ЦА під час використання продукту;
Фокус-Групи Робота з групою користувачів. Зазвичай в фокус-групу беруть 6–10 людей (більше вже важко модерувати) і проводять якісь партисипативні активності;
Кард Сортінг / Трі Тестінг Класно допомагає пропрацювати інформаційну архітектуру і дає багато інсайтів;
Метод Виявлення Метафор Зальтмана (Zaltman Metaphor Elicitation Technique або просто ZMET) Цікава активність для отримання метафор та образів, які викликають у користувачів ваш продукт (бренд);
Метод Тріад Допомагає дізнатись відношення користувача до вашого продукту шляхом порівняння з продуктами-конкурентами;
Щоденникові Дослідження Чесно кажучи, от саме цього дослідження я ніколи не робив, але чув що крута штука. Юзерам видаються методи фіксації їх досвіду і протягом певного часу агрегуються інсайти. Очевидно, цей метод дослідження не дешевий і тому дозволити його собі можуть далеко не всі проекти.

UX Slogan #17: This is Too Easy to Understand

Це Занадто Легко Для Розуміння

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

Давайте на прикладі. Ви зараз читаєте статтю про дизайн (тож мені здається, що ви дизайнер) і якщо натрапите на вираз «перед проведенням A/B тестування буде валідно провести A/A тестування з метою рівномірного спліту трафіка», то ця фраза вас не злякає і буде зрозумілою. Але якщо сказати те саме фразою «перед тим як проводити A/B тестування, запевніться що трафік розділився рівномірно між варіантами», то ви також все зрозумієте. І проблем теж не буде.

Нічого поганого в спрощенні немає або як казала омеба «Навіщо все ускладнювати?»😂

п.с. Саме тому я використовую для написання статей саме такий стильок — імхо, пояснювати складні речі треба простими словами.

UX Slogan #18: Stop Solutioneering

Не Роби Рішення Зарано

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

Якщо говорити про цей слоган в рамках нашого дизайн-процесу (наприклад Double Diamond), то Solutioneering (solution engineering) — це нездорова схильність дизайнера одразу застрибнути на діамант вирішення (другий діамант), без розуміння самої проблеми (перший діамант). Дизайнер повинен бути скептиком і розбиратись в нюансах, адже диявол криється саме в деталях (тут також варто нагадати про Слоган #15 — Покажи Пруфи!).

Для того щоб правильно визначитись з рішенням проблеми, бажано відповісти на 3 прості питання:

Яку проблему ми сподіваємося вирішити?
Які в нас є докази того, що ця проблема існує?
Чому ми вважаємо, що саме це рішення допоможе?
Особисто я є апологетом Method-Reason-Price-Metric підходу, про який я вже писав вище і який мене поки жодного разу не підводив.

Але я б хотів проговорити ще один нюанс — можливо, коли ви читали про слоган #18, ви згадали про Lean, який передбачає створення продукту на припущеннях, кидання цього продукта в ринок і трекання респонду. Напевне ви подумали «Ей, але тут в нас припущення і ми не знаємо майже нічого про валідність проблеми». І ви десь навіть праві, але навіть, коли ви працюєте по ліновському процесу, робити рішення взагалі без розуміння проблеми — не є правильним. Хоча б базове розуміння проблем і болей користувачів ПОВИННО бути! Тож не ігноруйте проблематику і не поспішайте генерувати рішення.

UX Slogan #19: Clarify, Don’t Mystify

Прояснюй, Не Містифікуй або Роби Ясність, а Не Загадки

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

Тому як дизайнер ви є «впорядковувачами хаосу», завжди намагаєтесь мінімізувати невизначеність і виростити з неї конкретику інтерфейсу, який гарантує необхідну конверсію і відповідні KPI.

Якщо ж ми говоримо про проєкт (а не UX-процес в дизайн-тімі), то відмальований лейаут повинен бути очікуваним і виправдовувати припущення користувача. Саме для цього ми проводимо тестування наших макетів і так любимо використовувати різні Cognitive Walkthrough та Pluralistic Walkthrough.

Саме тому давайте «робити порядочек», а не загадки та несподіванки!

Перед висновками, давайте згадаємо всі слогани, які ми сьогодні згадали:

You ≠ User / Ти Не Є Користувач
Keep it Simple / Зберігай Простоту
You Can’t Impose Joy / Ти Не Можеш Нав’язати Радість
Communication not Decoration / Комунікація, а Не Декорація
Brevity = Brilliance / Лаконічність = Геніальність
«Why» Beats «What» in UX / «ЧОМУ» Важливіше Ніж «ЩО» в UX
UX is People / UX Це Люди
Make it Easy / Спрощуй
Less is More / Менше — Це Більше
Users Are Not Lazy / Користувачі Не Ліниві
If You’re Not Checking, You’re Guessing / Якщо Ти Не Перевіряєш — Ти Вгадуєш
More Choices More Trouble / Більше Вибору — Більше Проблем
Design for Them Not for You / Дизайнь Для Них, Не Для Себе
It Depends / Це Залежить Від…
Show Me the Data / Покажи Пруфи!
UX Researchers, We Like to Watch / Як UX-Дослідники, Ми Любимо Спостерігати
This is Too Easy to Understand / Це Занадто Легко Для Розуміння
Stop Solutioneering / Не Роби Рішення Зарано
Clarify, Don’t Mystify / Роби Ясність, а Не Загадки

Summary

В ПреСаммері (яке я став тут публікувати а лишив тільки на Медіумі) я планував розібрати по частинкам кожен слоган, адже думав, що всі вони будуть супер-сильно пов’язані між собою, корелювати з коммон сенсом, іншими законами UX, евристиками, критеріями юзабіліті і тд. Насправді мені стало нудно показувати взаємозв’язки і в певний момент я прийшов до висновку, що всі ці Слогани, евристики, правила — це все одне і те саме. Важко виділити НОВІ і оригінальні емпіричні тейки. Все занадто пов’язано між собою.

Тому мій особистий висновок зі Слоганів від NNGroup десь такий: пам’ятайте, що ВИ НЕ Є ЮЗЕРОМ (просто дуже вже мені подобається цей слоган) і намагайтесь всіма вашими силами і знаннями покращити досвід ЦА!

П.С. Якщо вам сподобалась моя стаття і якщо вам хочеться віддячити і допомогти мені особисто — зробіть донат на ЗСУ. Я буду задоволений і знатиму, що витратив час не дарма!

Сподіваюсь моя стаття допоможе зробити вашу роботу більш осмисленою та виваженою, а ваш продукт прибутковим. Тож щасти і до нових зустрічей в рубриці #задротствозбородатим 😂❤️🇺🇦

Головні новини WordPress та AI-інструментів: що варто знати власникам сайтів у 2026 році

Андрій Кот — Fri, 05 Jun 2026 12:45:13 +0000

Травень 2026 року приніс чимало важливих оновлень для екосистеми WordPress. Головний тренд останніх місяців залишається незмінним — активне впровадження штучного інтелекту в інструменти для створення, просування та адміністрування сайтів.

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

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

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

Власники інтернет-магазинів та бізнес-сайтів отримали нові можливості автоматизації завдяки появі Uncanny Agent. Це AI-помічник, який інтегрується безпосередньо в WordPress та може виконувати адміністративні завдання за текстовими командами. Він здатний аналізувати дані WooCommerce, створювати автоматизації, формувати звіти та взаємодіяти з популярними сервісами на кшталт Google Sheets, Slack або Mailchimp.

Значний розвиток отримала й веб-аналітика. Плагін MonsterInsights представив AI-асистента Charlie Chat, який дозволяє ставити питання звичайною мовою та отримувати зрозумілі відповіді на основі даних Google Analytics 4. Замість складних звітів користувачі можуть швидко дізнатися джерела трафіку, ефективність контенту чи динаміку продажів.

У сфері підтримки клієнтів увагу привернув сервіс HelpJet. Його AI-чатбот навчається на контенті сайту та документації компанії, після чого самостійно відповідає на запитання відвідувачів у режимі 24/7. Це дозволяє скоротити навантаження на службу підтримки та прискорити обробку звернень.

Водночас ринок WordPress переживає й структурні зміни. Компанія Liquid Web оголосила про припинення розвитку бренду StellarWP та об'єднання кількох популярних продуктів у межах нової програмної екосистеми. Для користувачів це стало нагадуванням про важливість контролю залежностей від сторонніх плагінів та необхідність регулярно переглядати свою стратегію розвитку сайту.

Окремо варто відзначити посилення уваги до конфіденційності даних. Останні оновлення WPConsent спрощують відповідність вимогам GDPR та інших нормативів, пропонуючи розширений аудит cookie-файлів, підтримку Google Consent Mode V2 та більш зручне керування згодою користувачів.

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

Джерело https://www.asper.pro/uk/

Як упаковка допомагає бренду продавати ще до першого контакту з продуктом

Андрій Кот — Fri, 29 May 2026 08:45:24 +0000

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

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

Чому упаковка впливає на рішення покупця

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

Для бренду упаковка виконує кілька функцій:

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

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

Що упаковка повідомляє без слів

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

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

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

Як бізнесу підготувати упаковку до продажу

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

Бізнесу потрібно продумати:

вагу, розмір і крихкість продукту;
спосіб продажу: retail, e-commerce, подарункові набори, промо;
очікуваний тираж;
матеріали та тип друку;
потребу у внутрішніх вставках або комплектації;
строки виробництва й логістику;
повторюваність якості в усій партії.

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

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

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

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

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

Українські дизайн-змагання дебютували в ЄС: Design Battle вперше пройшов на Digital Design Days у Мілані

Елизавета Семко — Fri, 22 May 2026 11:19:57 +0000

Українські змагання для UI/UX-дизайнерів Design Battle вперше провели в ЄС. Дебют відбувся на Digital Design Days у Мілані – одній із трьох найавторитетніших дизайн-подій у світі, за словами Бертона Раста, колишнього UX Design Lead в Google. Цього року конференція зібрала понад 3 500 учасників з усього світу, а серед партнерів DDD були Figma і Canva – глобальні лідери серед інструментів для дизайну та креативу.

Головою журі на міжнародному Design Battle став Стефан Загмейстер – відомий австрійський графічний дизайнер, співзасновник студії Sagmeister & Walsh, дворазовий лауреат Grammy Award, автор проєктів для Rolling Stones і HBO. Також роботи учасників оцінювали Джонас Лемпа, Хусейн Йилмаз і Сара Ланге з берлінської агенції Taikonauten, та Алексія Дантон з Figma.

За умовами змагання, цього разу учасники мали за дві години створити промо-лендинг для першої міжгалактичної дизайн-конференції – інтерфейс, зрозумілий не лише людям, а й будь-яким іншим формам життя. На міжнародний батл зареєструвалось понад 100 осіб з різних країн: Італії, Німеччини, Греції, Ізраїлю, України, Швейцарії, Іспанії, Швеції, Індії, Польщі, Йорданії та Австрії. Фінальні роботи надіслали 37 учасників.

Журі одностайно віддало перше місце Карло Марзулло (Carlo Doc) з Риму – арт-директору і UX-дизайнеру Pantheon Design & Technology і Yunastudio. Його лендинг дозволяв перемикатись між різними формами життя – людиною, міцелієм та іншими – і під кожну повністю змінювався інтерфейс.

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

Команда, що посіла друге місце, – Лоренцо Діана, Андреа Бонсіньйоре і Лоренцо Де Анджеліс – так описала свій досвід участі в Design Battle:

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

Український проєкт вже також отримав запрошення провести наступні батли в Римі, Німеччині та Ізраїлі. Українська команда вже почала вести перемовини стосовно проведення наступних івентів – щоб популяризувати формат по всій Європі.

Про Design Battle

Design Battle – змагання для UI/UX-дизайнерів, яке ще називають «Олімпійськими іграми» для дизайнерів. Авторкою проєкту є українка Ольга Шевченко – творча директорка Vintage Web Production, членкиня журі Awwwards та The Webby Awards, перша українка в міжнародному журі Awwwards. За умовами змагань, учасники отримують бриф і протягом двох годин мають створити дизайн – перед живою аудиторією, без жодної підготовки.

Ідея Design Battle виникла у 2016 році як внутрішній спосіб оцінки дизайнерів в агенції Vintage Web Production. У 2018-му пройшов перший публічний батл, у 2019-му офлайн-змагання охопили 10 міст України. Зараз проєкт передбачає щомісячні батли, щотижневі тренувальні завдання та Q&A з засновницею.

Про Ольгу Шевченко

Ольга Шевченко – творча директорка Vintage Web Production, авторка проєкту Design Battle, членкиня журі Awwwards та The Webby Awards. Перша з українців стала членкинею міжнародного журі Awwwards.

Що таке Figma Agent для дизайнерів і як він працює

Dinozavrix — Thu, 21 May 2026 08:44:21 +0000

Figma запустила власного AI-агента для дизайнерів

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

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

Раніше цього року Figma відкрила canvas для сторонніх агентів, щоб команди могли використовувати знання дизайн-систем у своїх агентних workflow. Тепер компанія йде далі — запускає Figma Agent, доступний безпосередньо на canvas та в лівій панелі.

Саме для цього Figma створила власного агента. Мета компанії — зробити агента, який добре розуміє Figma та природно вписується у спосіб роботи команд. Це означає, що сама Figma стає зрозумілою для моделі на рівні, недоступному стороннім інструментам: із глибоким контекстом компонентів, токенів, стандартів і best practices.

Як Figma Agent і MCP Server працюють разом

Figma Agent варто використовувати під час роботи на canvas: він вбудований у продукт і має додатковий контекст про дизайн-систему.

MCP Server та use_figma варто використовувати для перенесення коду на canvas або повернення дизайнів назад у код.

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

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

На відміну від MCP Server, агент працює безпосередньо на canvas — без окремого налаштування чи перемикання контексту. Це дозволяє:

запускати prompt із будь-якого design layer;
паралельно запускати кілька prompt’ів, щоб перевірити різні ідеї;
редагувати дизайн ітеровано, поки агент також продовжує ітерації.

Від пошуку нових напрямків до масових правок і впровадження feedback — Figma Agent має стати частиною дизайн-workflow вже сьогодні.

Дослідження більшої кількості напрямків

Найкращі дизайни рідко з’являються з першої ідеї або першого prompt’у. Дослідження напрямків, порівняння підходів та ітерації вже є базовою частиною роботи дизайнерів. Figma Agent має допомогти командам проходити більше варіантів за менший час.

Як Figma Make і Figma Agent вписуються у workflow

Користувач може почати у Figma Design і за допомогою агента згенерувати design layers, щоб уточнити intent у flows, states, copy та структурі. Потім результат можна передати у Make для генерації code layers і уточнення поведінки. Після цього його можна знову вбудувати назад у Figma Design.

Або навпаки: почати у Figma Make, скопіювати frames у Figma Design, доопрацювати їх через агента й повернути назад у Make.

Користувач може “йти вшир”: швидко генерувати різні стилістичні підходи до однієї задачі та досліджувати багато напрямків одночасно. Наприклад, порівняти кілька checkout flows, оптимізованих під різні бізнес-цілі, або попросити агента створити три різні information architectures.

Або можна “йти вглиб”: обрати один напрямок і попросити агента ітерувати його, порівнювати реалізації та переосмислювати наявні дизайни, залишаючись у межах дизайн-системи. Агент використовує найчастіше й нещодавно використані компоненти як стартову точку. Водночас користувач може керувати результатом, обираючи конкретну library або згадуючи через @ конкретні tokens, variables і components.

У Figma зазначають, що головний ризик AI-генерації — створення “посереднього” дизайну. Саме тому Figma Agent створений для того, щоб допомогти досліджувати більше напрямків і обрати правильний.

Приклад prompt для design exploration

Дай 3 стилістичні варіанти цього дизайну: один органічний, один modern і один retro.

Приклад prompt для design generation

Створи горизонтальний image carousel для mobile app. Заповни зображення placeholder-картинками outdoor/sports тематики. Дай кілька варіантів із різними title treatments: текст поверх зображення та під ним, щоб зрозуміти, що працює краще.

Автоматизація рутинної роботи

З Figma MCP Server робота може переходити між кодом і Figma без втрати точності. Команда може почати в коді, перенести результат у Figma через code-to-canvas, доопрацювати його або застосувати дизайн-систему, а потім повернути назад через Figma MCP Server — і все залишатиметься синхронізованим.

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

Figma Agent може:

перейменовувати variables;
масово змінювати компоненти;
оновлювати typography;
замінювати lorem ipsum на реальний контент;
переводити інтерфейси у dark mode;
оновлювати documentation дизайн-системи;
стандартизувати naming conventions;
створювати документацію для components, states та variants.

Приклади prompt для consistency

Переведи всі @ Tile / Callout components у highlight states.

Знайди весь текст більший за size 10 і зміни font на Inter.

Використай чистіший typeface.

Приклад prompt для documentation

Створи документацію для моїх компонентів, включно з усіма states і variants. Додай contextual examples, які показують, як ці компоненти слід використовувати.

Робота з feedback

У дизайн-процесі накопичується багато feedback, який часто розкиданий між comments і файлами: від crit notes та реакцій stakeholders до відкритих питань. Figma Agent допомагає перетворювати цей feedback на дію.

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

Figma Agent може:

узагальнювати feedback;
знаходити повторювані теми;
перетворювати comments у actionable next steps;
симулювати реакцію різних stakeholders;
допомагати готуватися до critique sessions.

Приклад prompt для feedback

Відсортуй ці comments за темами. Створи нову revision мого дизайну, яка враховує feedback для цього профілю.

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

Що далі

У найближчі місяці Figma планує:

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

Доступність

Figma Agent поступово запускається в beta протягом найближчих тижнів.

Під час beta:

AI credits не витрачатимуться;
після general availability функція стане usage-based.

Figma Agent буде доступний для користувачів:

Professional;
Organization;
Enterprise plans.

Collab і Dev seats зможуть використовувати агента в drafts.

Starter, Education і Government plans наразі не підтримуються.

Джерело: figma.com

Оцініть прототип платформи “Сфери” — візуального навігатору знань та ресурсів

yuri — Fri, 15 May 2026 08:00:33 +0000

Привіт! Я тестую прототип платформи “Сфери” і шукаю фідбек 🙂

Ідея: зараз корисні ресурси розкидані по десятках сайтів — окремо магазини, вакансії, послуги, спільноти, новини, події тощо.

Я хочу перевірити формат, де це можна досліджувати через єдиний інтерфейс.

Прототип: https://www.figma.com/proto/yZ9xSW90Gkdp13tiDIVAJv/
— Workaround: Люди * Харчування;
— Для перегляду на телефоні: натисніть поза областю прототипу → знизу в налаштуваннях “Zoom device to fill screen”

Було б корисно почути:
— чи зрозуміла ідея;
— чи зручно користуватись;
— чи хотіли б Ви досліджувати щось таке;
— що виглядає дивно або незрозуміло.

Сайт проекту: https://sharp-specialist-d09.notion.site/299d3333055080b7b120d752c931261e

Проект чи підписка: що насправді вигідніше для дизайнера?

ZeroOne Design — Tue, 12 May 2026 09:11:42 +0000

Попроектна модель: чому вона зручна лише на перший погляд

Дизайнер-фрилансер починає з проектів — і це логічно. Перший клієнт, перший дедлайн, перші гроші. Здається, що кожен новий проект — це можливість заробити більше. Але за цим ховається пастка.
Між проектами — порожнеча. Кілька тижнів пошуку, перемовин, брифів. Дохід скачить: місяць жирний, два наступних — сухі. Ти не можеш планувати ні відпустку, ні великі покупки, ні найм асистента. Кожен закінчений проект ставить запитання: а що далі?
Попроектна робота — це постійно стартувати з нуля. Ти не будуєш — ти просто пробігаєш дистанції.
Є ще один тонкий момент: клієнт, якого ти щойно закрив, вже завтра звернеться до іншого дизайнера. Ти витратив час на вивчення його бізнесу, його аудиторії, його тону — і все це просто зникло.

Що таке підписна модель для дизайнера

Підписка — це коли клієнт платить щомісяця фіксовану суму за певний обсяг дизайнерської роботи. Не за конкретний логотип чи лендінг, а за постійну присутність дизайнера поруч із бізнесом.
Це може виглядати як 20 годин на місяць, або пакет «до 8 завдань», або конкретний напрям — наприклад, SMM-дизайн, підтримка сайту, щомісячна рекламна графіка. Формат гнучкий, але суть одна: регулярний платіж — регулярна робота.

Чому підписка вигідніша — з усіх боків

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

Як перейти на підписку: з чого почати

Не треба різко розривати всі проектні контракти. Перехід — це процес, і він може бути м'яким.
Спочатку визнач, який обсяг роботи ти реально можеш давати щомісяця. Потім обери 1–2 існуючих клієнтів, з якими хочеш продовжити стосунки, і запропонуй їм пакет: «Замість нового проекту — щомісячна підтримка». Поясни вигоду для них: пріоритет, постійна готовність, знання їхнього бізнесу. Визнач чіткі межі — що входить, що ні, як рахуються додаткові завдання — і підпиши простий договір з автоматичним продовженням.
Початкова ціна підписки може бути трохи нижчою за разовий проект — це нормально. Ти отримуєш стабільність в обмін на невелику знижку. Але вже через 3–4 місяці ти побачиш: реальний дохід вищий, а голова вільніша.

Коли підписка не підходить

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

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.

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

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

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

Кейс: Як я перетворив 30 варіантів компоненту налаштувань в 1 варіант і зробив його ще гнучкішим

Edward Korytsky — Thu, 30 Apr 2026 19:08:50 +0000

Контекст і хід робіт

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

Після цього я почав налаштовувати дизайн-систему та паралельно збирав hi-fidelity екрани

Коли дійшов до меню налаштувань, реалізував його як окремий компонент з 10 варіантами під різні сторінки

На етапі адаптації з’явилось ще 10 варіантів для мобайлу.

І тут стало очевидно що планшет ще +10, а підтримка і правки перетворяться на повний треш.

Приблизно ось так виглядав старий компонент

Проблема

Поточна реалізація не масштабувалась і створювала технічний борг.

Основні болі:

3 девайси (Desktop / Tablet / Mobile) в одному компоненті без чіткої структури
Дублювання елементів, які доводилось правити вручну
Відсутність стратегії наповнення контентом усередині компоненту
Кожна нова правка = потрійна робота

Що потрібно було

Компонент має бути:

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

Рішення і підхід

Я повністю переосмислив логіку компоненту.

Компонент зі slot-підходом
Основний компонент меню має slot
У slot підставляються готові компоненти секцій
Контент винесений окремо
Кожна сторінка налаштувань = окремий компонент наповнення
Його можна незалежно редагувати і перевикористовувати
Також кожну таку сторінку можна адаптувати окремо.
Адаптив через токени
Desktop / Tablet / Mobile керуються токенами
Компонент автоматично адаптується без дублювання
Допоміжний навігаційний компонент
Створив компонент-обгортку на базі основного
В ньому зібрані всі сторінки одразу для швидкого перемикання і тестування

А тепер давайте детальніше по кожному моменту

Почав я з брейншторму в режимі максималізму.

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

Заздалегідь заклав такі вимоги:

Гнучке наповнення контенту без дублікатів
Адаптація всього компоненту і його вмісту без створення окремих варіантів або з мінімальною їх кількістю
Підтримка вспливаючих вікон підтвердження
Різна навігація для різних девайсів

Першим і основним кроком стало розділення компоненту на слоти (Доречі тут використані не нативні слоти від фігма, а зроблені власноруч).

Новий компонент зі слот підходом. Має тільки 1 варіант і все інше налаштовано через токени і слоти

Slot-підхід дав:

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

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

Компоненти сторінок для заміни в слот. (Всього таких 10)

Адаптив через токени і структурні компоненти

Наступним кроком я вирішив не робити адаптив через варіанти. Замість цього адаптація була закладена на рівні системи.

Основою стали: дизайн-токени та структурні компоненти, які керують головним компонентом.

Як це працює

Ключові параметри компоненту - відступи, розміри, поведінка навігації - винесені в токени.

При зміні брейкпоінту підтягується відповідний набір токенів та Структурні компоненти змінюють вид без дублювання логіки і контенту

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

Токени для адаптації.

Що це вирішило

Один і той самий компонент працює для Desktop, Tablet і Mobile
Адаптив перемикається автоматично
Відпала потреба створювати окремі варіанти під кожен девайс
Контент залишається незмінним і не ламається при адаптації

Заміна слотів і навігаційний компонент

Після цього робота з компонентом стала максимально простою.

У slot підставляється готовий компонент конкретної сторінки а Базовий компонент меню при цьому не змінюється взагалі

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

Готовий компонент з підтягнутим слотом.

Навігаційний компонент для зручності

Щоб не перемикати сторінки вручну, я створив додатковий навігаційний компонент поверх основного.

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

Що це дало

Швидкий перегляд і тестування всіх сценаріїв
Мінімум ручних дій
Збереження єдиної структури і логіки
Комфортну роботу з компонентом навіть при великій кількості сторінок

Документація для дизайнерів і розробників

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

Документація покриває:

структуру компоненту і логіку слотів
правила підключення готових сторінок
поведінку адаптиву через токени
сценарії навігації і використання
обмеження і принципи масштабування

Цінність документації

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

Загальний результат

Цей підхід дав відчутний системний ефект:

1 універсальний компонент замість 30+
Повністю прибрані дублікати
Автоматичне перемикання адаптиву
Швидке редагування без ризику щось зламати
Робота з компонентом стала у ~4 рази простішою
Компонент легко масштабується під нові сторінки і девайси