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

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

Розберемо, чого конкретно бракує і як це додати, не роздуваючи бібліотеку вдвічі.

Чому старі компоненти не тягнуть AI-фічі

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

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

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

1. Відповідь із потоковим текстом

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

Що тут треба закласти як параметри компонента, а не як імпровізацію верстальника:

  • Мінімальна висота контейнера. Найпоширеніший баг: блок росте по слову і штовхає вниз усе, що під ним. Кнопки тікають з-під курсора. Резервуйте висоту або тримайте дії у фіксованому доці.
  • Курсор або пульс кінця потоку. Один маркер, що текст ще йде, а не крутилка збоку.
  • Кнопка «Зупинити». Обовʼязкова, поки статус streaming. Це не додаткова фіча, це вихід із процесу.
  • Стани: idle, streaming, done, stopped, error. Пʼять, не два.

2. Індикатор процесу, а не спінер

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

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

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

3. Індикатор впевненості

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

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

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

4. Цитата-джерело

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

Компонент складається з двох частин:

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

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

5. Стан помилки моделі

У бібліотеці майже напевно є Empty state і Error state. Для AI цього мало, бо тут щонайменше чотири різні ситуації, і вони вимагають різних дій від людини:

  • Нічого не знайшов у ваших даних. Дія: змінити запит або розширити область пошуку.
  • Відповів частково, бо даних вистачило лише на частину. Дія: показати, чого бракує.
  • Відмовився відповідати через обмеження. Дія: пояснити межу, запропонувати альтернативу.
  • Технічно впав: таймаут, ліміт, обрив потоку. Дія: повторити, зберігши введений запит.

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

6. Панель дій над результатом

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

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

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

Токени, без яких це все розсиплеться

Спокуса - намалювати шість компонентів і покласти в бібліотеку. Через місяць виявиться, що в кожного свій відтінок «стану обробки» і своя тривалість пульсації. Тому спершу токени, потім компоненти.

Мінімальний набір семантичних токенів під AI:

  • color.ai.processing - колір активного стану генерації.
  • color.confidence.high / medium / low - три рівні довіри, зіставлені з вашими success, warning, danger, а не вигадані заново.
  • color.ai.surface - фон блоку, згенерованого системою, щоб він візуально відрізнявся від контенту, який написала людина.
  • motion.ai.pulse і motion.ai.stream - тривалість і easing, взяті з вашої motion-шкали.

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

Доступність: місце, де ламаються майже всі

Потоковий текст погано дружить зі скрінрідерами. Якщо повісити aria-live="polite" на контейнер, який оновлюється щосекунди, читалка почне зачитувати відповідь заново раз за разом, і користуватись фічею стане неможливо.

Робоча схема: під час стрімінгу тримати регіон тихим і оголошувати короткий статус («генерую відповідь»), а повний текст віддавати одним оголошенням після завершення. Плюс завжди залишати кнопку «Зупинити» доступною з клавіатури і поважати prefers-reduced-motion для пульсацій. Ці правила мають жити в специфікації компонента, бо самі собою вони не відтворяться.

Як додати це в систему за тиждень

План, який реально проходиться без зупинки продукту:

  1. День 1. Зберіть скріншоти всіх AI-екранів, які вже є в продукті. Зазвичай виявляється три-чотири різні спінери і два стилі помилок.
  2. День 2. Заведіть семантичні токени зверху існуючих примітивів.
  3. Дні 3-4. Зберіть компонент відповіді зі стрімінгом і панель дій. Це дві найчастіші штуки, вони закривають більшу частину екранів.
  4. День 5. Індикатор процесу і стани помилок з чотирма варіантами.
  5. Дні 6-7. Впевненість і джерела, якщо фіча працює з даними. Плюс специфікація з правилами доступності.

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

Якщо хочеться подивитись, як така робота виглядає руками, а не на словах, розбори компонентів і AI-воркфлоу є на YouTube-каналі UX Hero.

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