У матеріалі розбирається підхід Віктора Йокко до того, як продакт- і дизайн-команди можуть вирішувати, чи варто додавати AI в конкретний продукт або фічу, ще до початку великих вкладень у розробку.
Стартова ситуація — коли «працюючий» AI шкодить роботі
Автор описує кейс великого медичного страховика. Команда створює фічу, де AI повністю пише текстові рішення за підсумком апеляцій по виплатам. Технічно все працює: модель генерує грамотно оформлені тексти.
Але в реальній роботі відбувається протилежне очікуванням:
- частина спеціалістів просто ігнорує AI;
- ті, хто продовжує користуватися, витрачають на один кейс більше часу, ніж ті, хто працює по-старому.
Короткі розмови з користувачами пояснюють, чому так відбувається. Щоб підписати текст, написаний AI, фахівець має:
- прочитати його настільки уважно, ніби писав сам;
- перевірити помилки, яких сам ніколи б не зробив.
Фіча не забирає роботу, а додає ще один шар перевірки поверх завдання, яке спеціалісти й так давно освоїли.
Після перегляду постановки задачі команда змінює скоуп:
- другу версію інструмента AI використовують для пошуку — він підтягує релевантні положення політик та попередні рішення по схожих апеляціях;
- написання тексту рішення залишається за спеціалістом.
У результаті:
- зникає крок ручного пошуку документів;
- час розгляду справи скорочується;
- ключова експертна частина роботи залишається в руках людини.
Технологія та сама — змінилося лише те, на яку частину задачі її спрямували.
Лінія беззбитковості — коли AI справді «окупається» користувачу
Кожна зміна інтерфейсу коштує користувачу уваги. Тим більше AI-фіча, яка змінює не лише UI, а й сам спосіб виконання роботи.
Автор спирається на огляд Нельсона Коуена (2001) про робочу пам'ять: людина утримує приблизно 4 елементи одночасно. Будь-який новий інтерфейс або AI-інструмент забирає частину цього ліміту — людині треба:
- заново зрозуміти, як працює інструмент;
- засвоїти нові кроки;
- вирішити, наскільки можна довіряти результату AI.
В авторському підході є проста формула:
AI-фіча виправдана тоді, коли те, що вона дає, перевищує витрати уваги на її освоєння та використання — для однієї конкретної людини в одній конкретній задачі.
Цю межу можна назвати «лінією беззбитковості» (break-even line). Вигода для користувача найчастіше проявляється у трьох формах:
- менше зусиль (справді забрана робота, а не перенесена в перевірку);
- виявлення помилок, які людина зазвичай пропускає;
- сталість результату між різними виконавцями.
Наприклад, AI-скринінг шахрайських транзакцій дає вигоду в другому пункті: аналітик бачить підозрілі кейси, які сам би не помітив, і витрачає увагу на їх перевірку, окуповуючи це кращим виявленням помилок.
Щоб ще до дизайну зрозуміти, по який бік цієї лінії опиниться фіча, автор пропонує короткий аудит з чотирьох питань. Кожне питання закінчується конкретною «умовою для дизайну», яку варто включати в бриф.
Питання 1 — чи зменшується загальний обсяг зусиль для цього користувача
Перше питання змушує подивитися на задачу цілісно: скільки мислення, кліків та перевірок потрібно людині до і після додавання AI.
Ключова ідея автора: рахувати треба не лише виконання, а й перевірку результатів AI. Просте скорочення кліків не доводить, що фіча полегшує життя. Якщо замість ручного вводу людина тепер змушена ретельно перевіряти авто-заповнене поле, загальне навантаження може навіть зрости.
Приклад з тексту:
- кредитний офіцер читає 40 фінансових розкриттів, щоб знайти 3, які суперечать кредитній політиці. Це інтенсивна інтелектуальна робота. AI, який виділяє конфлікти, дійсно зменшує зусилля;
- введення номера кредиту в систему — це кілька секунд без суттєвого когнітивного навантаження. Якщо AI сам підставляє номер, офіцер змушений перевіряти, що він правильний. Дешева дія (набір кількох символів) замінюється дорогою (уважна перевірка).
Висновок з цього прикладу: автоматизація «рутинних» кроків може виявитися помилковою, якщо:
- початковий крок швидкий і не потребує концентрації;
- перевірка результату AI вимагає набагато більше уваги, ніж первинна дія.
Другий важливий фактор — хто саме користувач. Та ж сама фіча може:
- бути корисною для джуна (AI-драфт резюме ризиків дає йому старт там, де не вистачає досвіду);
- витрачати час сеньйора (він вже має в голові власний аналіз і лише звіряє його з AI).
Умова для дизайну: чітко назвіть сегмент користувачів, для яких фіча знижує зусилля, і спроєктуйте «вихід» або обхід для інших сегментів.
Питання 2 — чи справді AI кращий за поточний спосіб роботи
Друге питання порівнює AI не з ідеальною теорією, а з реальним способом, яким користувачі вже закривають задачу: своїми табличками, макросами, шаблонами.
AI часто виграє, коли:
- немає однієї «правильної» відповіді (пошук варіантів, дослідження, бреїншторм);
- масштаб або швидкість важливіші за точність одного рішення (пошук патернів, фільтрація великого масиву);
- треба зловити те, що поточний процес стабільно пропускає (знову ж таки, кейс з шахрайством).
У випадку з HR-командою, що робить інструмент для succession planning:
- AI, який допомагає знаходити внутрішніх кандидатів з нестандартними наборами навичок, виграє за масштабом та неоднозначністю (немає єдино правильної відповіді, ручний перегляд зайняв би тижні);
- AI-драфт листа кандидату програє — формат стандартний, написання займає 2 хвилини, а у відправника є чіткі уподобання щодо тону.
Автор підкреслює, що вибір інтерфейсної форми (чат, структура, візуалізація) — окреме рішення і його варто оцінювати окремо, зокрема за допомогою аналізу «AI-модальність проти наміру користувача».
Умова для дизайну: заберіть AI з тих кроків, де поточний процес уже дає відповідь швидко та стабільно.
Питання 3 — чи користувач взагалі помітить помилки AI
Третє питання переходить від зусиль до ризиків. У будь-якій AI-системі є помилки, і важливо зрозуміти, чи:
- вони помітні з першого погляду;
- їх наслідки суттєві, якщо ніхто їх не спіймає;
- користувач усе ще має компетенцію, потрібну для перевірки.
Автор наводить різницю між:
- AI-маршрутизатором поїздок, який пропонує музей у день, коли він зачинений — помилка «невидима», все виглядає правдоподібно, користувач дізнається про неї на місці;
- маршрутом з пересадкою, де наступний рейс вилітає раніше за попередній — суперечність очевидна у самому виводі.
До цього додається automation bias. Огляд Парасурамана і Манцея (2010) показує, що люди схильні надто довіряти автоматизованим системам у різних галузях. Після короткого періоду успішних підказок рівень довіри різко зростає, а критичне ставлення падає.
Рекомендація автора — ще до дизайну «розмалювати» поверхню помилок:
- виділити 3 найімовірніші типи помилок;
- оцінити видимість кожної для користувача;
- оцінити наслідки, якщо її не знайдуть.
Комбінація «низька видимість + високі наслідки» повинна перетворюватися на сувору вимогу до дизайну.
Ключовий інструмент, на який робить акцент автор, — це provenance (походження даних): показувати джерела, за якими AI сформував результат, і час, коли ці дані були отримані. Наприклад, користувачеві корисніше бачити, що години роботи ресторану взято зі сторінки, кешованої у березні, ніж просто гарний текст без джерел.
Умова для дизайну: якщо поєднання «низька видимість помилки + високі наслідки» неминуче, фіча має виходити з вбудованим відображенням джерел і тригерами на перевірку. Без цього її краще не запускати.
Питання 4 — чи зможе користувач через рік помічати, коли AI помиляється
Четверте питання виходить за межі поточного моменту. Навіть якщо зараз людина може якісно перевіряти AI, важливо зрозуміти, що буде через рік, коли частину роботи вона повністю делегує машині.
Автор посилається на дослідження в радіології (Dratsch та колеги, 2023). У ньому 27 радіологів читали мамографії із підказкою нібито від AI. Після короткого «тренування», де підказки були завжди правильними, у наступному наборі з 40 зображень у 12 випадках підказки були помилковими.
Результат: коли «AI» помилявся, правильність рішень падала у всіх групах, включно з найбільш досвідченими радіологами. Досвід пом'якшував, але не усував ефект. Це означає, що систематичне покладання на AI з часом підриває здатність фахівця самостійно оцінювати якість результату.
Автор пропонує мислити так: якщо через 12 місяців користувач раптово втратить доступ до AI, чи зможе він все ще критично оцінювати подібні рішення? Якщо ні — треба тримати навичку в тонусі.
Можливі механізми:
- періодичний «сліпий» перегляд — користувач спочатку робить власне судження, а вже потім бачить результат AI;
- обертання частини кейсів без AI-підтримки;
- регулярне порівняння двох версій — машинної та зробленої людиною.
Умова для дизайну: у потоці роботи має бути явний механізм, який змушує користувача періодично тренувати навичку перевірки. Освітній слайд на онбордингу це не замінить.
Рішення у вигляді матриці — як звести всі чотири питання разом
Автор збирає логіку чотирьох питань у таблицю «AI Addition Decision Matrix», де для кожного питання є:
- коли AI виправданий;
- коли він коштує користувачеві більше, ніж дає;
- яка конкретна умова повинна потрапити в бриф.
Загальний підхід до рішень такий:
- слабка відповідь на питання 1 не обов'язково «вбиває» фічу, якщо питання 2 показує вагому перевагу над поточним способом роботи;
- питання 2 і 4 працюють схожим чином: слабка відповідь потребує зміни скоупу або додаткових умов;
- питання 3 може повністю зупинити розробку, якщо неможливо безпечно обійти ризики.
Ключова практична порада — умови з аудиту мають потрапити в продуктовий бриф як обов'язкові вимоги (provenance, верифікаційні кроки, обмеження сегментів, механізм підтримки навичок), а не як «полірування» наприкінці.
Як аудит працює на реальних сценаріях
Страхові апеляції
Якщо прогнати стартовий кейс страховика через чотири питання:
- Питання 1: перша версія не зменшує загальні зусилля — інтенсивна когнітивна робота просто переміщується з написання в перевірку;
- Питання 2: структура рішення відпрацьована, спеціалісти швидко знаходять відповідь; зона неоднозначності — у пошуку релевантних політик, а не в оформленні тексту;
- Питання 3: помилки можуть бути невидимими в гладкому тексті, а наслідки для клієнтів високі; звідси вимога до другого варіанта — показувати джерела та дати витягів;
- Питання 4: у другій версії спеціалісти й далі самі формують рішення, отже навичка лишається у щоденному вжитку.
AI-конспекти зустрічей
На противагу, для AI-резюме мітингів результати інші:
- Питання 1: для більшості учасників конспект зменшує роботу, але для хронічного «ноуттейкера» баланс тонший, бо саме на нього лягає верифікація;
- Питання 2: AI, як правило, кращий за «друкувати й напівслухати» — записи стають повнішими та стабільнішими між зустрічами;
- Питання 3: помилка у приписуванні завдання неочевидна на вигляд, але має наслідки; рішення — додавати прив'язку до запису/таймкоду для кожного action item;
- Питання 4: суттєвої навички, яку варто захищати, немає — ніхто не має зберігати вміння швидко друкувати нотатки заради безпеки рішень.
Результат — фіча проходить аудит за умови, що:
- є джерела й мітки часу для ключових рішень;
- команда окремо дивиться на сегмент постійних авторів нотаток при оцінці впровадження.
Як провести 60-хвилинний аудит перед тим, як вести AI-фічу в roadmap
Автор пропонує скорочену практичну процедуру на одну годину:
- 10 хвилин — сформулювати задачу максимально конкретно. Не «допомагати підсумовувати документи», а, наприклад: «допомогти мідл-аналітику знайти 3 найризикованіші пункти у 40-сторінковому due diligence-репорті за 2 години».
- 25 хвилин — пройтися по 4 питаннях з людиною, яка реально робить цю роботу. З'ясувати, де саме для неї основна складність, чи торкається фіча цих місць і яку здатність до перевірки вона може втратити за рік делегування.
- 15 хвилин — промалювати поверхню помилок. Назвати три найімовірніші помилки, оцінити їх видимість і наслідки. Комбінація «низька видимість + високий ризик» автоматично переходить у вимоги до дизайну (наприклад, обов'язковий provenance і явні кроки верифікації для медичних рекомендацій).
- 10 хвилин — перенести знайдені умови у бриф. Сегментація, обов'язкові елементи інтерфейсу, робочі механізми підтримки навичок — усе це слід фіксувати поруч з описом фічі, а не виносити в «nice to have».
У підсумку цей аудит дає продуктовій команді аргументовану позицію на roadmap-обговореннях. Замість абстрактного «AI нам потрібен, бо конкуренти вже додали» з'являється конкретна пропозиція: кого саме фіча обслуговує, яку роботу знімає, які ризики створює і які механіки потрібні, щоб залишитися вище лінії беззбитковості для користувача.
Джерело: Victor Yocco — Smashing Magazine