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

Але що відбувається, коли кінцевий "користувач" інтерфейсу – не людина?

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

Так з'являється окремий напрямок, який вже отримав назву Machine Experience, або скорочено MX. Це не нова технологія і не черговий фреймворк. Це зміна в постановці базового питання: для кого ми проєктуємо?

Що таке Machine Experience і звідки він з'явився

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

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

По-перше, це розвиток API-економіки. Починаючи з середини 2010-х, компанії все активніше проєктували свої продукти як платформи з відкритими програмними інтерфейсами. API – це вже не internal tool для розробників, а повноцінний канал взаємодії, яким користуються інші системи. Коли Stripe, Twilio або Shopify думали про "user experience" свого API, вони вже фактично думали про Machine Experience.

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

По-третє, і це найсвіжіший і найвагоміший фактор, – це AI-агенти нового покоління. GPT-4, Claude, Gemini та їхні наступники вміють не просто відповідати на запитання, а виконувати багатоетапні задачі в цифровому середовищі. Вони можуть зайти на сайт, прочитати контент, заповнити форму, зробити бронювання, написати лист. Frameworks на зразок LangChain, AutoGPT, Cursor або нещодавно анонсованих агентних режимів у Claude і GPT, це вже не демо, а виробничі інструменти.

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

Як машина "бачить" інтерфейс

Щоб зрозуміти, чому MX – це окрема дисципліна, а не просто підмножина UX, треба розібратися в тому, як AI-агент сприймає цифровий простір.

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

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

Це означає кілька конкретних наслідків для дизайну.

  • Візуальна ієрархія, яка очевидна людині, може бути повністю невидимою для агента. Якщо ви розрізняєте "головну кнопку дії" і "другорядне посилання" виключно через колір і розмір, без семантичної різниці в розмітці - агент цього не побачить. Для нього це просто два клікабельних елементи.
  • Іконки без підписів, кнопки з написом "Далі" без контексту, форми без чітких label-елементів, модальні вікна, які з'являються динамічно – все це є нормальними елементами людського UX і кошмаром для автоматизованого агента.
  • Навігація через hover-стани, drag-and-drop-інтерфейси, капчі, нестандартні кастомні елементи форм - агент або не може з ними взаємодіяти, або витрачає непропорційно багато "зусиль" (токенів, кроків, часу) на те, щоб зрозуміти, як це зробити.

MX на практиці: що це означає для продуктів

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

Інтернет-магазини і AI-шопінг-агенти

Компанії на кшталт Perplexity, Google і OpenAI вже тестують або запустили режими, де AI-асистент може знаходити товари і здійснювати покупки замість користувача. Агент відвідує сторінку продукту, читає характеристики, порівнює варіанти, додає до кошика.

Магазини, де інформація про продукт розкидана між вкладками, де ціна відображається тільки після вибору варіанту через JavaScript-рендеринг, де кнопка "додати в кошик" захована під складною логікою – ці магазини просто не будуть правильно оброблені агентом. Він або зробить помилку, або відмовиться від спроби, або попросить людину втрутитися.

Магазини з чіткою семантичною розміткою, структурованими даними (Schema.org), простими і передбачуваними формами - вони отримають перевагу в AI-шопінг-каналах так само, як свого часу отримали перевагу в SEO ті, хто першими почав думати про структуровані дані.

SaaS-продукти і автоматизаційні агенти

Уявіть CRM-систему, яку менеджер із продажів хоче підключити до AI-агента для автоматичного логування дзвінків і оновлення статусів угод. Якщо CRM має добре задокументований API – все відносно просто. Якщо ж агент змушений діяти через веб-інтерфейс (що трапляється, коли немає API або API не покриває потрібну функцію) – все залежить від того, наскільки цей інтерфейс "машиночитабельний".

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

Медичні і юридичні сервіси

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

Принципи MX-дизайну: що варто змінити вже зараз

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

Семантика понад естетику (там, де це важливо)

HTML-семантика завжди мала значення для доступності і SEO. У контексті MX вона набуває ще одного виміру. Правильне використання заголовків, ролей ARIA, атрибутів label, data-атрибутів для ідентифікації інтерактивних елементів – це вже не тільки про screen readers. Це про те, чи зможе AI-агент зрозуміти структуру вашого інтерфейсу без додаткових підказок.

Передбачувані патерни взаємодії

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

Текстова ясність у всіх критичних елементах

Назви кнопок, підписи полів, повідомлення про помилки, підтвердження дій. Усе, що людина може зрозуміти з контексту, агент повинен мати можливість прочитати прямо. "Відправити" – краще, ніж іконка зі стрілкою. "Підтвердити видалення файлу invoice_2024.pdf" – краще, ніж "Ви впевнені?".

Структуровані дані як частина дизайн-системи

Schema.org і JSON-LD розмітка – це вже давно стандарт для SEO-орієнтованих команд. В MX-контексті це ширше: структуровані дані дозволяють агентам точно розуміти, що є ціна, що є назва продукту, що є дата доступності, що є рейтинг. Без цього агент змушений "здогадуватися" на основі положення елемента на сторінці і сусіднього тексту, з очікуваними результатами.

API-first як архітектурний принцип

Найчистіший MX – це коли агент взаємодіє не з інтерфейсом, а з API. Продукти, що проєктуються за принципом API-first, де веб-інтерфейс є лише одним зі способів доступу до даних і функцій, а не єдиним, – природно краще підходять для агентної взаємодії. Це не завжди можливо або доцільно для всіх продуктів, але для B2B-сервісів і платформ це стає все більш очевидною стратегічною перевагою.

Нова роль UX-дизайнера в MX-просторі

Поява MX як дисципліни не витісняє UX-дизайнерів. Але вона суттєво розширює їхній мандат і вимагає нових компетенцій.

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

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

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

Конкуренти і паралельні концепції

MX розвивається не у вакуумі. Кілька суміжних концепцій вже існують і частково перетинаються з ним.

  • Agent-ready design – термін, який використовують переважно в технічних спільнотах і який фокусується на тому, як продукти мають бути готові до взаємодії з агентами. Технічніший за MX, менше орієнтований на дизайн-практику.
  • LLM-friendly interfaces – підхід, де інтерфейси проєктуються з урахуванням того, що LLM-моделі будуть їх читати або описувати. Зокрема, це стосується документації, help-центрів і контент-архітектур, де AI-асистенти шукають відповіді для користувачів.
  • API-first design і headless architecture – архітектурні підходи, що вже давно існують у розробці і природно підтримують агентну взаємодію, але не є дизайн-дисципліною в строгому сенсі.
  • Conversational UX – проєктування діалогових інтерфейсів для чат-ботів і голосових асистентів. Частково перетинається з MX там, де агент взаємодіє через природну мову, але загалом це ширша і старіша дисципліна.

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

Де MX вже відчувається: реальні приклади

Деякі компанії вже явно або неявно рухаються в MX-напрямку, навіть якщо не використовують цей термін.

Anthropic у своїй документації для Claude активно розвиває концепцію "computer use" – здатності моделі взаємодіяти з реальними інтерфейсами. Вони публікують рекомендації для розробників про те, як будувати продукти так, щоб агент міг ефективно з ними працювати.

Notion і Linear — два продукти, де API є повноцінним громадянином першого класу, паралельним веб-інтерфейсу. Будь-яка дія, доступна через UI, доступна і через API. Це не випадково і не тільки для розробників - це фундаментальне архітектурне рішення, яке одночасно є MX-рішенням.

Vercel зі своєю платформою v0 і набором AI-інструментів для розробників будує інфраструктуру, де AI-агенти є нормальними учасниками development workflow. Це не тільки про генерацію коду – це про те, що весь продукт проєктується з урахуванням того, що з ним взаємодіятимуть автоматизовані системи.

Ризики і дискусійні точки

MX - не безхмарна концепція. Є кілька питань, на які дизайн-спільнота ще не має консенсусу.

  • Конфлікт між людським і машинним UX. Деякі рішення, що покращують Machine Experience, можуть погіршити досвід людини. Надмірна текстова експліцитність може зробити інтерфейс громіздким. Обов'язкова семантична розмітка може обмежити дизайнерську свободу. Знайти баланс - нетривіальне завдання.
  • Безпека і зловживання. Інтерфейс, оптимізований для AI-агентів, також є легшою ціллю для зловмисних ботів і скрейперів. MX-дизайн не може ігнорувати питання безпеки - потрібно думати про те, яким агентам ви хочете дозволяти взаємодію і як.
  • Невизначеність стандартів. На відміну від WCAG (стандарти доступності) або специфікацій HTML, для MX поки що немає єдиних стандартів. Різні AI-агенти і платформи мають різні можливості й обмеження. Те, що добре читається одним агентом, може бути проблемою для іншого.
  • Ризик надмірного спрощення. Якщо дизайнери почнуть оптимізувати продукти переважно для машинної взаємодії, є ризик втратити складність і нюансованість, яка робить деякі продукти дійсно чудовими для людей. Не все повинно бути машиночитабельним - є інтерфейси, де людський досвід важливіший за будь-яку автоматизацію.

Що це означає для дизайнерів і студій вже зараз

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

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

Варто почати з розуміння того, як агенти технічно взаємодіють із веб-контентом. Не потрібно ставати розробником, але базове розуміння DOM, семантичного HTML і структурованих даних – це вже частина компетентності сучасного UX-дизайнера. Так само, як колись базове розуміння адаптивного дизайну чи принципів доступності ставало частиною загального мандату.

Для студій, що працюють із B2B-клієнтами або SaaS-продуктами, варто вже зараз включати MX-аудит у свої дизайн-огляди. Запитання "як із цим інтерфейсом взаємодіятиме AI-агент?" повинно стояти поруч із "як із цим інтерфейсом взаємодіятиме людина?".

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

Що буде далі

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

Стандартизація протоколів для агентної взаємодії вже відбувається. Model Context Protocol (MCP), розроблений Anthropic, – це спроба стандартизувати спосіб, яким AI-агенти підключаються до зовнішніх інструментів і сервісів. Якщо такі протоколи отримають широке поширення, вони стануть для MX тим, чим HTML і CSS стали для веб-дизайну: стандартним інструментом з відомими правилами і очікуваною поведінкою.

Інструменти тестування для MX будуть з'являтися як природне розширення існуючих accessibility і SEO-аудит-інструментів. Уже зараз деякі платформи пропонують симуляцію того, як AI-агент "бачить" вашу сторінку. Це стане стандартною частиною дизайн-тулкіту.

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

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

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