Бізнес-цінність внутрішнього UX

Скільки робочого дня йде на інструменти, які мали б допомагати людям працювати? Work Trend Index від Microsoft за 2025 рік, зібраний із телеметрії Microsoft 365 і опитування 31 000 працівників знань, нарахував переривання кожні дві хвилини в робочі години, близько 275 на день для найзавантаженішої п'ятої частини користувачів. Це зустрічі, пошта й чати, а не поганий інтерфейс, тому цю цифру я тримаю як фон. Ближчий вимір старіший. У дослідженні, опублікованому Harvard Business Review у 2022 році, 137 працівників із 20 команд трьох компаній Fortune 500 перемикалися між застосунками й сайтами приблизно 1 200 разів на день, а на повторну орієнтацію після цих перемикань ішло майже чотири години на тиждень, близько 9% робочого часу. Частина втрат походить із розрізнених процесів та інтеграцій. Але це наочно показує, що цифрове робоче середовище має ціну, навіть коли ніхто не виставляє за нього окремого рахунка.

Коли компанія створює продукт для клієнтів, вона відстежує conversion rate, bounce rate, retention і churn. Якщо люди не можуть завершити покупку чи реєстрацію, це видно у звітах. Але що відбувається, коли користувачем продукту є працівник компанії? Він не може просто відмовитися від незручної CRM, системи інвентаризації або адміністративної панелі. Він усе одно завершить роботу, навіть якщо для цього потрібні п'ять додаткових екранів, три уточнення в колег і власна таблиця для дублювання інформації.

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

“

Внутрішній продукт може не потребувати вражаючого інтерфейсу. Але він точно потребує ефективного способу роботи.

Спробуйте на своїй команді. Калькулятор на початку статті оцінює, скільки робочого часу може вивільнити навіть невелике покращення повторюваної задачі. Він відкривається трьома типовими командами: склад, що приймає товар, служба підтримки і відділ продажів, який заповнює CRM. Склад Майка, наприклад: 8 людей, 150 позицій на день, кожна на пів хвилини швидше. Це близько 2 300 годин на рік або $80 500 вартості часу за повної ставки $35 на годину. Ця сума ще не є заощадженими грошима: економією вона стає лише тоді, коли компанія справді використовує вивільнений час або їй потрібно менше годин на ту саму роботу.

Тисяча інструментів, одне число

Найбільшу версію цієї проблеми з відомих мені задокументувала UX-команда Technical Infrastructure у Google. У листопаді 2021 року вона розіслала опитування 10 000 випадково обраних інженерів. З 1 300 тих, хто відповів, 749 залишили відкриті коментарі, і 67% цих коментарів були про одне: дебагінг. Потрібна інженерам інформація існувала. Вона була розкидана по понад тисячі внутрішніх інструментів, зроблених різними командами, кожен зі своїм виглядом, своїм онбордингом і своїми дірками, і час ішов на те, щоб її знайти.

Найкориснішим мені здається не саме об'єднання, 600 інструментів в одну консоль, а те, як команда це аргументувала. Вони відмовилися від ще одного дашборда й обрали одну метрику: скільки повних інженерних ставок проєкт збереже за рік. Три оцінки, залежно від того, скільки вкласти на старті: 69 інженерів, 208 або 1 663. Це арифметика калькулятора вище, прогнана в масштабі компанії з десятками тисяч розробників. Хвилини на задачу, помножені на задачі за день, на людей, на рік.

Одне поле, 711 попереджень

2 травня 2022 року трейдер лондонського деску Citigroup хотів продати кошик європейських акцій на $58 мільйонів. Інструмент, яким такі кошики зазвичай збирали, був недоступний, тож кошик зібрали вручну. Форма замовлення дозволяла задати його розмір двома способами: номінальною вартістю або кількістю одиниць. Трейдер увів 58 мільйонів у поле одиниць. Кошик, що вийшов, коштував $444 мільярди.

Система попередила. О 08:56 з'явилося спливне вікно з 711 попередженнями одним списком, 65 із них жорсткі блоки, решта м'які. Вікно показувало 18 рядків за раз; щоб прочитати решту, треба було прогорнути ще 693, партіями по 18. М'які блоки можна було обійти, не читаючи, і їх обійшли. Жорсткі зупинили $255 мільярдів. Решта $189 мільярдів пішла в алгоритм, який почав продавати, і $1,4 мільярда акцій встигли продатися на європейських біржах, доки замовлення скасували. У травні 2024 року два британські регулятори оштрафували фірму на £61,6 мільйона. Слова самої FCA: через поганий дизайн трейдер міг обійти попередження, не прогортавши й не прочитавши його.

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

Є і зворотний бік, і він про контекст. Не кожен додатковий крок поганий. У платіжній системі людина хоче не швидкості, а впевненості, і підтвердження великої суми чи перевірка одержувача можуть додати секунди й прибрати дорогу помилку. Для критичних процесів time on task треба оцінювати разом із частотою помилок, їхньою серйозністю і тим, наскільки їх можна виправити. Зекономлені десятки секунд не компенсують неправильно відправленої транзакції.

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

Один запис, одинадцять відсотків продажів

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

Дослідження Rekik, Oliva, Syntetos і Glock, оновлене у 2026 році, охопило близько 24 000 товарів в одинадцяти продуктових магазинах на основі 150 000 інвентаризацій і 22 мільйонів записів денних продажів. Майже дві третини товарів, 64,7%, мали запис, що не збігався з полицею, у межах того, що галузь знаходить уже двадцять років. Для бізнес-кейсу важлива друга частина роботи. Після того як фізичний перерахунок виправив записи, продажі по всьому магазину зросли приблизно на 11% за наступні два місяці, і весь приріст дали товари, яких у системі значилося більше, ніж було насправді. Система думала, що полиця повна, і не замовляла. Покупець знаходив її порожньою.

Дослідження про точність обліку, а не про інтерфейси, і воно не каже, як помилки потрапили в систему. Але кожен запис заходить через чиїсь руки й чийсь екран: форма приймання, сканер, виправлення, набране наприкінці зміни. Яка частка з цих 64,7% припадає на процес введення й перевірки, кожній команді належить з'ясувати самій. І це той вид числа, якого калькулятор вище показати не може, бо це не зекономлений час. Це продажі, які тихо не відбулися.

Ціна незручності не обмежується годинами

У медичних системах можна особливо чітко побачити, як цифровий інструмент впливає на повсякденну роботу. За даними KLAS Arch Collaborative 2025, лише 18% лікарів і 22% медсестер, які брали участь у програмі вимірювань з 2017 року, повідомляли про досвід найвищих категорій. При цьому 35% медсестер витрачали щонайменше три години на тиждень на повторювану або непродуктивну документацію. Це показники з дослідницької програми KLAS, а не середнє для всіх медпрацівників світу.

Ще виразніші цифри показало дослідження 1 424 медпрацівників норвезької лікарні, опубліковане у 2025 році. Через шість місяців після впровадження нової електронної медичної системи медіанний бал за System Usability Scale становив лише 25 зі 100. Люди з найнижчими оцінками usability мали приблизно втричі вищі шанси повідомляти про вигорання і у 2,35 раза вищі шанси говорити про намір звільнитися, порівняно з групою найвищих оцінок. Це асоціація, а не доказ, що саме інтерфейс спричинив вигорання: на стан працівників впливають навантаження, кадрові ресурси й організація роботи.

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

“

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

До однієї задачі

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

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

Nielsen Norman Group використовує поняття interaction cost: сукупні фізичні й розумові зусилля для завершення завдання. Це не лише кількість кліків. Сюди входить пошук потрібної інформації, читання, очікування, введення даних, запам'ятовування значень із попереднього екрана й кожна мить, коли людина мусить вирішувати, що робити далі.

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

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

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

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

Що вимірювати, коли немає конверсії

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

Це не означає, що звичні продуктові метрики слід повністю відкинути. Наприклад, adoption і retention важливі для добровільних модулів корпоративного SaaS, а конверсія може мати сенс у внутрішньому процесі самообслуговування. Проте для обов'язкових робочих сценаріїв потрібна інша оптика.

Це не взаємозамінні формули, а інший спосіб поставити питання до продукту. Task success rate показує, яка частка спроб завершилася правильно. Time on task дає оцінку витрат часу. Error rate і rework показують, скільки разів доводиться виправляти вже зроблене. Time to proficiency допомагає зрозуміти, наскільки швидко новий працівник починає самостійно виконувати ключові задачі. А SUS чи SEQ дають змогу почути самих людей, але не замінюють спостереження за їхньою поведінкою.

Якщо операція скоротилася з 45 до 30 секунд, це хороший результат лише за умови, що якість не погіршилася. Якщо працівники почали працювати на третину швидше, але помилятися вдвічі частіше, ми могли просто перенести витрати з виконання в перевірку й виправлення. Ось чому одна метрика рідко розповідає всю історію.

Як перейти від проблеми до вимірюваного покращення

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

Далі варто спостерігати за тим, як люди виконують ці завдання в реальному контексті. Не лише запитати, чи подобається їм система, а подивитися, які поля вони пропускають, що копіюють між екранами, де звертаються до колег і які інструкції тримають поруч. Це дає матеріал для базового вимірювання, baseline, без якого немає з чим порівнювати результат.

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

Щоб говорити з бізнесом його мовою, варто переводити результати в операційні показники. Зекономлені години можна оцінити через повну вартість робочого часу. Меншу кількість помилок можна виразити через середню вартість виправлення та ризик наслідків. Скорочення часу навчання можна порахувати через швидше досягнення самостійної продуктивності новачка. Проте це не варто механічно складати в гарантований прибуток. Частина вигод може перетинатися, а частина вивільненого часу не перетвориться безпосередньо на економію.

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

Що змінюється з AI-розробкою

Ще недавно для внутрішніх інструментів часто обирали мінімально необхідну функціональність, а дослідження та прототипування вважали витратами, які легко скоротити. Тепер AI-assisted development дозволяє значно швидше створювати робочі прототипи та порівнювати альтернативи. У звіті Retool 2026 року на основі опитування 817 респондентів 35% повідомили, що їхні компанії вже замінили принаймні частину SaaS власними рішеннями, а 78% планували будувати більше внутрішніх інструментів. Вибірка пов'язана з аудиторією Retool, тому не є зрізом усіх компаній.

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

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

Внутрішні системи теж мають користувачів і бізнес-результат

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

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

“

Внутрішній UX не зобов'язаний вражати. Він має працювати. І ми можемо виміряти, наскільки добре.