Майже в кожному B2B-застосунку, який останнім часом бачив дизайнер, з'явилося вікно чату: іноді як бокова панель, іноді як перебудова інтерфейсу, де запит стає головним входом. Функція зазвичай добре зроблена, але головне питання часто лишається без відповіді: для кого вона створена і чим ці люди займалися хвилину тому. Саме в професійних продуктах це питання важить найбільше, бо їхні користувачі не відвідувачі, а фахівці з роками досвіду в конкретній сфері та в конкретному програмному забезпеченні.
Автор статті, який роками спостерігає за такими користувачами, описує типових представників: страховий експерт, що щотижня обробляє сотні справ, юрист, який пам'ятає різницю між уступкою права вимоги та зміною контролю без відкриття документа, планувальник постачання, що знає кожен код винятку напам'ять. Вони щоранку відкривають одні й ті самі шість екранів і точно знають, де що лежить. Для таких людей розмова з системою є обхідним шляхом через текстове поле, а не спрощенням. Саме тому автор вважає, що деякі сценарії не варто переводити на ШІ взагалі, бо він їх не перевершить.
Головна проблема, за словами автора, у тому, що команди рідко проводять межу до того, як ухвалюють рішення про інтерфейс. Щоб її окреслити, він пропонує шість критеріїв. Перший: чи не ламає нова функція вже наявні навички. Експерт створив у продукті власні робочі шляхи: клавіатурні комбінації, збережені подання, обхідний маневр, придуманий ще 2019 року і записаний на стікер, який економить півтори хвилини щоденної роботи. Усе це не видно в аналітиці, але зникає разом із поверхнею, на якій існує.
Автор посилається на Якоба Нільсена, який називає ШІ «першою новою парадигмою інтерфейсу за 60 років», і нагадує, що для галузі кожна така зміна тривала довго, а користувачі платили за навчання щоразу. Опір змінам часто називають ефектом невилученої вартості, але автор вважає це помилковим ярликом: витрачений час користувача вже є активом, який приносить віддачу щодня. Він також згадує дослідження Баррі Сто про «Knee-Deep in the Big Muddy», за яким команди найчастіше вкладають ресурси в провальний напрям саме тоді, коли вже мали попередні втрати. Механізм, який описує ефект реверсу експертності, полягає в тому, що підтримка, корисна новачкам, стає обтяжливою для тих, хто знає предметну область.
Другий критерій стосується вимірюваної переваги. Природна мова може здаватися привабливою, але рекрутер чи юрист із чотирма сотнями збережених пошуків хоче мати регулятори під рукою, бо знає краще за будь-яку модель. Планка має бути конкретною: новий шлях або втричі швидший, або робить те, чого раніше не було можна зробити взагалі. Якщо назвати цифру не виходить, нову функцію варто запускати поруч зі старим шляхом, щоб дізнатися, чи вона справді працює. Автор нагадує, що графічні інтерфейси залишили командний рядок на двадцять років, і ті, кому він був потрібен, його не полишили.
Третій критерій: чи чат призначений лише для новачків. Розмова розв'язує проблему пригадування. Якщо людина не знає системи, кожне меню є тестом зі словникового запасу, який вона провалює на очах у всіх, тому багато корпоративних застосунків такі складні для орієнтування. Натомість речення переносить тягар на машину. Для експерта все працює навпаки: він давно засвоїв назву поля й статусний код, а запит повертає йому ту саму складність у вигляді проблеми формулювання. Закон Тесла описує, що складність не зникає, а лише переходить від одного місця до іншого. Чат її не скорочує, а переносить.
Четвертий і п'ятий критерії стосуються прямої взаємодії з об'єктами та відповідальності. Бен Шнейдерман у 1983 році описав принцип прямого маніпулювання: об'єкти видно на екрані, з ними можна працювати і скасовувати дії. Для новачка запит є рятівним колом, для експерта це шар перекладу над системою, якою він уже вільно володіє. Нарешті, шостий критерій: кому належить рішення і хто відповідає за помилку, коли модель помиляється в юридичній чи страховій справі. Саме тут автор радить не поспішати з заміною звичних поверхонь на розмовні, а спершу окреслити, для кого продукт створюється і що з цим користувачем уже працює.
2
