Бізнес-цінність юзабіліті

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

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

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

“

Новий інтерфейс є результатом роботи. Кращий користувацький досвід залишається результатом, який ще потрібно довести.

Ми покращуємо продукт чи просто змінюємо його?

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

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

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

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

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

А чи можна взагалі виміряти зручність?

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

Стандарт ISO 9241-11 визначає юзабіліті через результативність, ефективність і задоволеність у конкретному контексті використання. Мені подобається це визначення, тому що воно дозволяє перейти від абстрактних оцінок до запитань, на які можна знайти відповідь.

Чи вдалося людині виконати завдання? Скільки часу та зусиль їй знадобилося? Чи була вона задоволена процесом? І найважливіше: чи відповідає отриманий результат її реальним потребам?

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

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

Так ми переходимо від оптимізації окремого екрана до вимірювання цілого користувацького сценарію. У продуктовій аналітиці для цього часто використовують поняття time to first value, тобто час до отримання першої цінності.

І тут виникає цікаве питання: що важливіше: скоротити реєстрацію на п'ять секунд чи допомогти користувачу значно швидше зрозуміти цінність продукту?

Менше кроків не завжди означає менше зусиль

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

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

Подібне питання виникає під час проєктування оформлення замовлення. Чи буде один екран із великою кількістю полів простішим, ніж кілька послідовних етапів? Не обов'язково. Дослідження Baymard Institute показують, що кількість полів і складність взаємодії з ними можуть мати більше значення для юзабіліті, ніж сама кількість кроків.

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

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

“

Мета спрощення не в тому, щоб мінімізувати кількість елементів. Вона в тому, щоб зменшити зусилля, необхідні для досягнення результату.

Які метрики насправді мають значення?

Мені здається, що проблема багатьох UX-дашбордів полягає не у відсутності даних, а в тому, що ми не завжди розуміємо, навіщо вимірюємо саме ці показники. SUS, CSAT, NPS, conversion rate: усе це може бути корисним, але жодна метрика не є універсальною відповіддю на питання про якість продукту.

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

Для цього можна використати task success rate, тобто частку успішно виконаних завдань, time on task, тобто час виконання, та кількість звернень у підтримку на тисячу активних користувачів. Якщо ж хочемо зрозуміти суб'єктивну складність сценарію, можна додати Single Ease Question (SEQ), коротке запитання після виконання завдання.

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

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

Проте навіть найкращий набір UX-метрик не завжди відповідає на питання, яке цікавить бізнес: яку цінність створили ці зміни?

Як UX-метрики пов'язані з бізнесом?

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

Але це не окремі світи. Часто ми просто дивимося на той самий процес із різних боків.

Уявімо внутрішню платформу, якою користуються 200 працівників. Кожен із них виконує певну операцію десять разів на день. Після покращення сценарію середній час виконання скорочується на одну хвилину. Окремо ця хвилина здається незначною, але за 230 робочих днів вона перетворюється приблизно на 7 667 годин вивільненого часу.

Якщо умовна повна вартість робочої години становить $50, це відповідає приблизно $383 000 вартості робочого часу на рік. Звісно, мова не про автоматичну фінансову економію: щоб вона стала реальною, компанія повинна використати цей час продуктивно або зменшити витрати. Але масштаб потенційного ефекту вже можна оцінити.

Інший приклад: продукт із великим навантаженням на підтримку. Якщо після покращення сценарію налаштувань кількість звернень зменшується з 4 000 до 2 500 на місяць, а обслуговування одного звернення коштує $6, потенційна економія становитиме $9 000 щомісяця. Для коректної оцінки важливо перевірити, чи саме наші зміни спричинили скорочення звернень, а не сезонність, інша аудиторія чи зовнішні фактори.

Це лише ілюстративні розрахунки, але вони показують, чому UX-метрики не повинні існувати окремо від бізнес-показників.

Як зрозуміти, що покращення справді спрацювали?

Припустімо, після запуску оновленого продукту конверсія зросла на 12%. Чи можемо ми сказати, що це заслуга дизайну? Можливо. Але одночасно могла запуститися маркетингова кампанія, змінитися ціна або прийти нова аудиторія. Те, що показник змінився після релізу, не доводить, що саме дизайн став причиною.

Саме тому я вважаю важливим визначати критерії успіху ще до початку роботи. Спочатку ми фіксуємо базові показники (baseline), потім формулюємо гіпотезу, визначаємо, що саме будемо змінювати, і яким способом перевірятимемо результат. Де можливо, використовуємо контрольні групи або A/B-тести. Де це неможливо, повторюємо вимірювання за однаковою методологією та відкрито говоримо про обмеження результатів.

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

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

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

Що змінюється в епоху AI?

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

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

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

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

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

Можливо, нам варто переосмислити саме поняття редизайну?

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

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

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

“

Мета дизайну не в тому, щоб створювати зміни. Вона в тому, щоб створювати покращення та вміти довести, що вони відбулися.

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