Коли в продукті з’являється помилка, користувач не думає про те, що «не пройшла валідація payload» або «сервер повернув 422». Він думає одне: «Щось пішло не так. І, скоріше за все, це я криворукий. А взагалі цей сервіс кривий.»
І тут розвилка: або ми залишаємо його наодинці з цим відчуттям (читай — він іде й більше не повертається), або ми пояснюємо, що сталося, що робити далі і чому це взагалі виникло.
Помилки — це не побічний продукт розробки. Це частина інтерфейсу, як кнопки, поля і текст. Тільки на відміну від кнопок, помилки проявляються у найгірший момент. І саме в цей момент вони показують, наскільки ви взагалі думаєте про користувача.
Сьогодні проллємо цифровий чай на тему, про яку майже ніхто не замислюється.
Чому помилки — це важливий UX-інструмент
У звіті NN Group за 2024 рік сказано: «Погані повідомлення про помилки — одна з трьох головних причин фрустрації користувачів та кидання дій у цифрових продуктах.»
Звичайно, найкраще — це коли помилки взагалі не виникають, і все йде гладко. Але якщо вже щось іде не так, правильно оформлена помилка дає продукту:
- Прозорість — пояснює, що трапилося і хто винен.
- Контроль — повертає відчуття, що «все під контролем».
- Зворотний зв'язок — допомагає швидше досягти цілі, навіть якщо користувач помилився.
- Зростання конверсії — у формах із зрозумілими помилками люди менше йдуть.
- Менше звернень у підтримку — якщо все зрозуміло, ніхто не пише в сапорт.
Де живуть помилки і хто за них відповідає
У будь-якій системі є два основні типи валідації:
1. Frontend-валідація
Це помилки, які виникають на клієнті — до відправки даних на сервер. Вони «зашиті» в компонент і забезпечують швидкий фідбек:
- Порожнє поле
- Невірний формат email
- Перевищення максимальної довжини і т.д.
2. Backend-валідація
Це помилки, які повертає сервер після перевірки. Вони вже не належать до конкретного поля — ідуть окремим рядком або флагом. Тут вже враховується бізнес-логіка, права доступу, взаємозв’язки тощо:
- Email уже зареєстровано
- Користувач не має права завантажувати файл
- Невірний код підтвердження
- Неприпустима комбінація даних
Є ще третій тип, але я не виділятиму його окремо: системні помилки — користувач без інтернету, закінчився токен, база не відповідає.
І всі ці помилки врешті-решт бачить користувач. Не команда. Не QA. Не розробник. А справжня людина, яка просто хотіла зареєструватися або натиснути «відправити».
Навіщо потрібна систематизація
Помилки — це як офіціанти в ресторані: ти їх не помічаєш, поки все добре, але варто щось піти не так — і стає зрозуміло, чи тут узагалі вміють працювати з людьми.
Уявімо типовий цифровий ресторан, тобто наш продукт. Користувач заходить, хоче «замовити» — наприклад, оплатити або зареєструватися. А йому у відповідь:
- «Щось пішло не так»
- «422: Validation failed»
- «Invalid email»
- «Такий email уже існує»
Кожне повідомлення — ніби з іншої епохи, іншої команди, іншого проєкту. Одне англійською, інше російською, третє — витягнуто з логів сервера, випадково засвічене у UI.
Якби продукт був людиною, він би говорив голосами трьох незнайомців з різними акцентами і рівнем агресії.
Саме тому потрібна систематизація. Тому що помилка — це теж інтерфейс. Якщо вона виглядає як випадковий текст із глибокого бекенду, користувач теж буде почуватися випадковим. З’являється відчуття, що все летить у прірву, а керма немає.
Систематизація — це спосіб сказати: «Так, у нас теж буває хріново. Але ми хоча б можемо пояснити, чому.»
Якщо у продукту є чітка структура: категорії помилок, ключі повідомлень, єдиний стиль текстів, передбачуване відображення — все стає спокійніше. Помилка — це вже не катастрофа, а інструкція: що пішло не так, де саме, і що з цим робити. І все це написано мовою, яка відповідає характеру продукту, а не нагадує технічну документацію 2005 року.
Помилки — це обличчя продукту. Просто не тоді, коли все добре, а тоді, коли щось зламалось. І якщо це обличчя криве, зле і говорить латиною — уяви, що залишиться в пам’яті користувача.
Що таке tone of voice у помилках
Tone of voice (TOV) — це характер продукту. Він має бути всюди: у назвах кнопок, у пушах, у хедерах. І, звісно, в помилках.
Поганий TOV:
- “Required field”
- “Minimum length 6 characters”
Хороший TOV:
- “Будь ласка, заповніть поле”
- “Пароль має бути не менше 6 символів — без пробілів”
І тут відкривається поле для творчості. Уяви собі помилки, написані з гумором, молодіжним сленгом або мовою професіоналів у вузькій ніші. Користувач не просто виконає дію — він запам’ятає, посміхнеться і повернеться. Бо ви говорите з ним, як люди.
Як це роблять у нормальних системах
Трошки корпоративної жовчі — але по ділу:
Shopify Polaris: кожна помилка — це ключ, наприклад, errors.email.invalid; компонент InlineError сам витягує локалізований текст.
Atlassian: помилки приходять із кодом і мапляться на flag або inline message. Компонент сам вирішує, як показати.
Salesforce: структура повідомлень йде через спеціальний JSON, наприклад: errors.models.USER.EMAIL.TAKEN.
Якщо не чули про це — погугліть. Вивчіть. І додайте до списку «треба зробити».
Проблема з Zod: він не знає, що у вас tone of voice
Zod — це сучасна бібліотека на TypeScript для опису схем валідації. Вона дозволяє задавати очікувану структуру даних та автоматично перевіряти її. По суті — це як JSON Schema, тільки з людським обличчям і типами «із коробки».
Використовується в React, Next.js, Node і будь-де, де хочеться валідацію писати поруч із кодом.
І от розробник каже: «Я використовую Zod, там усе вже є.»
По факту — і так, і ні.
Бо: Zod видає машинні помилки. Типу: “Invalid input”.
Якщо не задати повідомлення вручну — буде дефолт, і часто англійською. Ніякої локалізації. Ніякого TOV. Ніякої любові.
Що робити (і як дизайнеру не стати жертвою Zod'а)
Помилки не з’являються красивими самі. І розробники не зобов’язані про них думати. Якщо ви не дасте їм сценарії, вони візьмуть перше, що спаде на думку — і ваш продукт буде звучати як BIOS.
Тому:
1. Зробіть бібліотеку помилок з людським обличчям
Простий документ: у Figma, Notion або в таблиці. Там:
- Ключі: validation.required, auth.emailTaken, network.timeout.
- Повідомлення: не “Invalid input”, а “Будь ласка, заповніть поле”.
- Варіанти для локалізації (UA, EN, інші).
Це буде словник tone of voice для всього продукту.
2. Визначте, де і як показуються помилки
Одна і та сама помилка виглядає по-різному в залежності від контексту:
- Порожнє поле → підказка під полем
- Помилка оплати → toast або банер
- Системна помилка → модалка з кнопкою «Повторити» Задача дизайнера — описати ці патерни у гайді дизайн-системи.
3. Працюйте з розробниками, а не замість них
Моя улюблена порада: підсуваємо стілець до розробника.
Поговоріть:
- Можна підключити централізовано повідомлення?
- Як зв'язати код помилки і ключ повідомлення?
- Як вивести помилку з бекенда у нормальному вигляді?
4. Прототипуйте помилки, як частину UX
У макетах обов’язково показуйте:
- Стани з порожніми полями
- Стани з неправильними даними
- Системні збої
Бо якщо не покажете — фронтенд вигадає щось сам. І здогадайтесь, наскільки це буде красиво.
5. Зробіть візуальний реєстр помилок
Figma-сторінка типу “Error system” або окремий розділ у Storybook. Там:
- Як виглядають inline-помилки
- Як виглядає toast
- Як виглядає помилка 500
Це місце, куди команда йде не вигадувати — а брати перевірене.
Помилки — це ваша зона відповідальності
Ви не повинні писати регулярки. Але ви повинні зробити так, щоб продукт не говорив з користувачем, як термінал техпідтримки.
Що потрібно:
- Таблиця з ключами і текстами
- Компоненти помилок у дизайн-системі
- Візуальні патерни
- Комунікація з фронтом
Якщо все це є — помилки не просто «не заважають». Вони працюють на продукт. Бо саме в момент, коли все пішло не так, користувач дивиться в екран і думає:
«Ці хлопці знають, що роблять.»
Як завжди, добра 🦫
Топ коментарі (0)