«Смерть кнопки»: як перейти від кліків до намірів у веб‑дизайні

Автор ·

У цьому розборі йдеться про підхід до UX, який описує Carrie Webster: відмова від «кнопкоцентричного» інтерфейсу на користь систем, що розуміють намір користувача й виконують рутину замість нього.

Від 10 кліків до одного наміру

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

Авторка описує типовий сценарій купівлі авіаквитка онлайн: вибір типу подорожі, введення міст, підбір дат у календарі, фільтри за ціною й пересадками, сортування, багатокрокова оплата з upsell‑пропозиціями. Це 10+ окремих дій, де користувач виступає «оркестратором», а комп’ютер — просто контейнером з даними.

У моделі intent-driven design (дизайн, керований намірами) все навпаки. Система питає: «Що ви хочете зробити?» — і сама розкладає завдання на кроки. Наприклад, замість форми бронювання користувач формулює: «Знайди мені прямий рейс до Чикаго на наступні вихідні до $300 з прибуттям до 17:00». Далі ПЗ:

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

Видимий інтерфейс ніби «стискається»: замість десятка кроків лишається один вираз наміру і зрозумілий результат. Саме цю зміну авторка пов’язує з ідеями Golden Krishna («The Best Interface Is No Interface») та принципами Дональда Нормана про людиноцентричний дизайн.

Кейс 1–3: як сайти вже працюють із намірами, а не з кнопками

1. Perplexity AI: пошук без десятка вкладок

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

Perplexity AI діє інакше: ви формулюєте запит людською мовою, а система:

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

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

2. Vercel v0: дизайн без drag‑and‑drop

Традиційний процес створення інтерфейсу — це годинами рухати прямокутники у Figma, змінювати кольори, відступи, верстати CSS або компоненти UI‑бібліотек. Кожна зміна — мікродія.

Платформа Vercel v0 показує іншу модель: користувач формулює бажаний результат у вигляді опису («зроби сучасну dark‑mode панель для SaaS зі щомісячною виручкою, активними користувачами та графіком відтоку»), а далі система:

  • інтерпретує цей намір з урахуванням патернів верстки й доступності;
  • генерує HTML, Tailwind CSS, React‑код;
  • відразу показує готовий інтерфейс.

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

3. Goblin.tools: розкладання завдань замість ручного планування

Більшість таск‑менеджерів змушує користувача самому структурувати роботу: створювати задачі, теги, стани, борди. Команда авторки наводить інший приклад — Goblin.tools, набір простих AI‑інструментів, орієнтований насамперед на нейродивергентних користувачів.

У модулі Magic Todo людина просто вводить загальний намір (наприклад, «Підготуватися до співбесіди»), а система:

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

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

Три опори intent-driven дизайну

Авторка посилається на аналітику Nielsen Norman Group та описує три ключові складові, без яких «невидимий» інтерфейс розвалиться.

Опора Традиційний підхід Intent-driven підхід
Ввід від користувача Мікро‑дії (кліки, списки, тумблери) Наміри й контекст (природна мова, звички)
Стан інтерфейсу Статичні макети для всіх Генеративний UI «на льоту»
Виконання завдання Ручні кроки користувача Автономні дії агентів у фоні

1. Наміри й контекст замість форм

Інтерфейс без кнопок не обмежується текстовими командами. Він активно використовує контекст: час, місце, історію дій. Apple у своїх Human Interface Guidelines для контекстного та «ambient» дизайну показує, як системи можуть:

  • пропонувати вечерю й адресу доставки в типову для користувача годину,
  • підхоплювати дані з пошти й показувати картку «Додати до календаря», не змушуючи вручну переносити деталі.

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

2. Генеративний UI замість «одного макета для всіх»

Статичний дизайн — це коли всі бачать однакову сторінку, незалежно від задачі. У підході, який описує Nielsen Norman Group, логіка інша: користувач задає бажаний результат (outcome), а система збирає інтерфейс на вимогу.

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

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

3. Виконання через агентів та акцент на «Undo», а не на попередженнях

У класичному UX превалює запобігання помилкам: нескінченні попапи «Ви впевнені?», «Підтвердити видалення?». У світі intent-driven систем автономні агенти діють від імені користувача, тому обмежувати їх спливаючими вікнами незручно й неефективно.

Авторка посилається на 10 евристик Юзабіліті Нільсена і показує зсув: замість надлишкової профілактики важливішими стають:

  • простий і видимий «Undo»;
  • зрозумілі способи переробити результат («Зроби цей підсумок коротшим»);
  • аудит‑лог дій агента, щоб можна було відкотити зміни.

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

Ризики «невидимого» інтерфейсу

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

Ілюзія контролю та маніпулятивні дефолти

Дослідження Stanford HCI Group показують, що надмірна автоматизація може викликати відчуття покровительства: система «знає краще» й не дає користувачу відчуття власного контролю. Center for Humane Technology у своїх матеріалах наголошує, що це особливо небезпечно, якщо бізнес‑цілі платформи не збігаються з інтересами людини.

Практична рекомендація, яку переказує авторка:

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

«Чорна скринька» та прозорі фідбек‑цикли

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

Google PAIR у своєму гайдбуку з фідбек‑циклів для AI пропонує підхід, який авторка адаптує до веб‑інтерфейсів:

  • система має явно пояснювати свою інтерпретацію («Шукаю прямі рейси до Чикаго на вихідні до $300…»);
  • користувач повинен мати змогу негайно скоригувати запит;
  • корисні «стани процесу»: що вже зроблено, що ще триває, яким буде наступний крок.

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

Що це означає для ролі UX‑дизайнера

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

  • опис та моделювання намірів користувачів (що вони насправді хочуть досягти, а не які кнопки натискають);
  • створення патернів генеративних UI‑компонентів, що адаптуються до контексту;
  • розробку прозорих механізмів фідбеку від AI до користувача (статуси, індикатори, пояснення);
  • етичні рамки: де автоматика припиняється й починається явне погодження.

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

Висновок: успіх не в кількості кліків, а в «невидимому завершенні»

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

Філософія, яку переказує авторка з книги Golden Krishna «The Best Interface Is No Interface» та ініціативи Center for Humane Technology «Time Well Spent», пропонує інший критерій: чи вирішує продукт задачу й як швидко він «йде з дороги» користувачу.

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

Джерело: Carrie Webster — Smashing Magazine