«Немає екрана — немає UX»: дороге припущення в автоматизації

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

У моїй роботі з клієнтами, які ставлять перед собою задачу сформулювати UX-стратегію, є одна важлива частина. Вона полягає в тому, щоб допомогти створити всередині організації такі умови, за яких продуктова команда буде здатна переосмислити свої цілі не з точки зору того, який функціонал необхідно запустити, а сформулювати цілі в першу чергу через призму інтересів користувача. І чимала частина цієї задачі, можливо, найбільш критичний її етап, — це формулювання UX-результатів (UX outcomes), які має забезпечити продукт чи сервіс. Під UX-результатами я тут маю на увазі конкретні зміни у суб’єктивному досвіді користувача (і, як наслідок, зміни у його поведінці), які безпосередньо впливають на досягнення бізнес-цілей організації.

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

Одна з речей, які мають на меті змінити усі мої програми з UX-стратегії, — це те, як команда визначає «готово»: як формулюється definition of done. Замість того щоб «готово» означало «ми випустили фічу», воно починає означати «користувачі тепер досягають того UX-результату, заради якого ця фіча створювалася, — і ось як ми знаємо, що це дійсно так». Ми визначаємо ці результати наперед, у світі і термінах користувача. І далі це формулювання очікуваних результатів беспосередньо впливає на те, що ми будуємо, у якому порядку і як саме. Весь цей процес зазвичай працює добре — хоча перепрошивати сам спосіб мислення команди щодо постановки цілей завжди непросто.

Заперечення з’являється тоді, коли ми доходимо до тих частин продукту, де робота користувача певною мірою (або повністю) автоматизована. А трапляється це нерідко, тому що кожен продукт нині щось та автоматизує — дедалі частіше за домомогою ШІ-агентів, які тепер виконують ту роботу, яку людина раніше виконувала вручну.

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

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

Картування процесу vs. картування досвіду

Почнімо з того, звідки береться це заперечення. В якийсь момент наша галузь (з купи причин, у які ми тут не вдаватимемося) почала вживати «UX» на позначення інтерфейсу, а «UI» — на позначення графічного дизайну інтерфейсу. «Інтуїтивний досвід», «консистентний користувацький досвід», «UX та UI етапи у дизайн-процесі» — уся та маячня, що далі метастазує в описах вакансій на LinkedIn і у внутрішніх кар’єрних фреймворках компаній.

Окрім того, що це просто дуже далеко від реальності, таке переосмислення термінів приносить продуктовим командам нескінченні проблеми, бо задає спосіб мислення про дизайн, з якого важко вибратися. Щойно досвід стає екраном (чи послідовністю екранів), з цього випливає, що немає екрана означає немає досвіду, а немає досвіду — значить немає UX-результату, який потрібно сформулювати. Тож щойно ми щось автоматизуємо — потреби в орієнтованій на користувача постановці цілей нібито більше немає. Немає взаємодій користувача з інтерфейсом — немає й користувацького досвіду.

Звісно, процес роботи користувача з продуктом та досвід користувача — це дві різні речі:

• Процес роботи — це послідовність кроків: спершу стається це, тоді те, дали це і т.д. Це погляд ззовні. Цю послідовність можна зафіксувати на карті процесу або в тих частинах карти шляху користувача (user journey map), які стосуються етапів, дій, активностей і точок контакту.
• Досвід — суб’єктивний. Це те, як воно — бути людиною посеред усього цього процесу, погляд зсередини. Його фіксують у тих частинах карти шляху, що стосуються цілей, фрустрацій (і того, як вони розгортаються в часі), потреб і моментів захвату.

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

Дашборд, який сам готує підсумок

Зробимо це більш конкретним на прикладі. Аналітик стежить за набором бізнес-метрик. Донедавна його робота полягала в тому, щоб передивлятися нові дані, ті цифри, де відбулиця певні зрушення — аналізувати та порівнювати з тим, що він знає про сезон і ринок. Після цього писати короткий звіт про те, що відбувається, і відправляти його нагору. Читання, аналіз і написання підсумку — усе це були частини роботи.

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

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

Погляньмо, що аналітик, власне, робить тепер. Він вирішує, чи довіряє підсумку настільки, щоб переслати його раді директорів або винести на обговорення на мітингу. Він з’ясовує, чи не сплутала модель сезонний спад зі справжнім падінням показників. Він зважує, чи зможе відтворити хід міркувань достатньо добре, щоб захистити цифру, коли хтось почне заперечувати. І він помічає — або не помічає, — коли впевнене, гарно написане речення є галюцинацією ШІ.

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

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

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

Нова робота аналітика стала складнішою за попередню, бо тепер вона вимагає більше аналізу, а не менше.

Почнімо з того, чого аналітик насправді хоче від такого інструмента. Це не підсумок, який він потім має перевіряти рядок за рядком, бо це просто повертає йому стару роботу, але ще й з необхідністю додаткової перевірки. Чого він хоче — це прочитати підсумок і повірити йому настільки, щоб передати його далі, не перевіряючи цифри про всяк випадок вручну. Ось результат, який тут має значення, — він лежить у площині суб’єктивного досвіду використання аналітиком його системи.

Tableau це явно розуміли, бо не просто згодували дані мовній моделі й випустили продукт. Вони зробили роботу із завоювання довіри. Підсумки не беруться з того, що ШІ вигадує історію навколо цифр: спершу Tableau робить статистичний аналіз і лише тоді дозволяє моделі сказати простими словами те, що цифри показують насправді, тож вона не може вигадати неіснуючий тренд. Підсумок також каже тобі, що саме керує змінами, тож аналітик бачить міркування, а не голе твердження. І він може розгорнути будь-яку цифру й закопатися в деталі під нею, замість того, щоб бездоказово вірити висновку. Tableau подає весь цей апарат як «шар довіри» (Einstein Trust Layer).

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

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

Ми знаємо це з 1983 року

Нічого з цього не нове — і це дещо іронічно для галузі, яка раз у раз називає UX-проблеми ШІ-автоматизації незвіданою територією. У 1983 році психологиня Лісанн Бейнбрідж опублікувала коротку статтю «Ironies of Automation». Тоді панував оптимізм: людські помилки — ось що треба усунути, і автоматизація обіцяла це зробити. Менше втомлених, неуважних, перевантажених людей на критичних задачах. Сьогодні настрій протилежний — страх, що ШІ зробить людину зайвою. Обидва настрої хибні — і Бейнбрідж пояснила, чому: що більше ми автоматизуємо задачу, то важливішою (і складнішою) стає роль, яка лишається людині.

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

Роботи, що з’явилися після Бейнбрідж, дали назви режимам відмов — і їх варто знати, якщо ви робите ставку на автоматизацію:

• Самозаспокоєність від автоматизації: ми перестаємо перевіряти систему, яка зазвичай не помиляється.
• Проблема випадання з контуру керування (out-of-the-loop): оператор так довго був пасажиром, що до моменту, коли керування повертається до нього, він уже не розуміє, що відбувається.

Найпохмуріша ілюстрація — рейс Air France 447, де автопілот відключився й повернув цілком придатний до польоту літак екіпажу, який уже не мав точної картини того, що відбувалося.

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

Чому це питання бюджету

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

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

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

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

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

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

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