Мікротексти та UX-комунікації

1) Що таке мікротексти і навіщо вони потрібні

• пояснює «що зараз відбувається» і «що робити далі»;
• зменшує помилки і підтримку;
• підвищує конверсію і довіру.

2) Базові принципи

1. Ясність> дотепність. Ніяких двозначностей і сленгу.
2. Контекстність. Пишемо рівно те, що корисно тут і зараз.
3. Стислість. Прибираємо зайві слова, не жертвуючи сенсом.
4. Активна застава і дієслова дії. «Зберегти», «Продовжити», «Надіслати документи».
5. Конкретика і орієнтири. Що, чому, як виправити, скільки часу займе.
6. Послідовність термінів. Один термін - одне значення по всьому продукту.
7. Голос бренду і тон ситуації. Доброзичливо, але без панібратства; у стресових кроках - нейтрально і спокійно.
8. Доступність. Зрозуміла мова, читабельність вголос, сумісність зі скрінрідерами.
9. Локалізація-first. Дизайн-токени для довжини рядків, чисел, часу; уникаємо культурно-залежних жартів.
10. Етика і відповідальність. Прозорість умов, чесні очікування, без маніпуляцій.

3) Карта точок мікротекстів

Навігація та CTA: назви пунктів, кнопки, стану disabled.
Форми та КУС/реєстрація: лейбли, плейсхолдери, маски, підказки, inline-валідація, помилки, підтвердження.
Порожні стани і «нульові» екрани: що це і як почати.
Статуси і прогрес: завантаження, черга, кроки, час очікування.
Системні повідомлення: тости, банери, пуши, e-mail/інбокс.
Пошук і фільтри: приклад запитів, нульові результати, сортування.
Оплати/висновки: вимоги до даних, терміни, комісії, ліміти.
Налаштування та безпека: паролі, 2FA, сесії, ризик-алерти.
Допомога в інтерфейсі: хінти, tooltips, FAQ-врізки, посилання на довідку.

4) Патерни по ключових зонах (з прикладами)

4. 1 CTA і назви дій

Принцип: кнопка = дія користувача + об'єкт.

До: «Ок» → Після: «Зберегти зміни»

До: «Дізнатися більше» → Після: «Читати правила бонусу»

До: «Відправити» → Після: «Надіслати документ»

Добре: коротко, конкретно, за місцем. Погано: абстрактно, жартівливо, двозначно.

4. 2 Лейбли і плейсхолдери

Лейбл обов'язковий; плейсхолдер - приклад формату.
До: плейсхолдер «Іван Іванов» без лейблу → Після: лейбл «ПІБ», плейсхолдер «Іван Іванов».
Форматувати очікування: "ДД. ММ. ГГГГ», «Мін. 8 символів, 1 цифра".

4. 3 Inline-валідація і помилки

Формула повідомлення про помилку: що не так + як виправити + (чому/обмеження).

До: «Помилка 400» → Після: "Неправильний формат дати. Використовуйте ДД. ММ. ГГГГ".
До: «Не вдалося завантажити» → Після: "Файл занадто великий (макс. 10 МБ). Виберіть файл меншого розміру".
До відкриттів/блокувань: додавайте посилання «Показати вимоги» поруч.

4. 4 Порожні стани

Мета: пояснити цінність і запропонувати дію.

Шаблон: "Тут буде [результат/історія], як тільки ви [дія]. [Кнопка-крок]".
Приклад: "У вас поки немає збережених методів оплати. Додайте картку - це прискорить виплати. [Додати карту]".

4. 5 Завантаження, прогрес, очікування

Повідомляйте, що відбувається і скільки займе: «Перевіряємо документи (до 2 хвилин)».
Пропонуйте альтернативу: «Можна закрити вікно - ми повідомимо, коли все готово».

4. 6 Нульові результати пошуку

Приклад: "Нічого не знайдено за запитом "live blackjack". Спробуйте "blackjack" або приберіть фільтр "Провайдер: X”. [Скинути фільтри]".

4. 7 Повідомлення (тости/банери/пуши)

Успіх: "Заявка відправлена. Ми повідомимо про рішення по e-mail".
Інфо: «Верифікація адреси обов'язкова для збільшення ліміту».
Увага: "Сесія закінчується через 1 хвилину. Продовжити? [Продовжити] [Вийти]".
Помилка: "Платіж відхилено банком. Спробуйте інший метод або зв'яжіться з банком".

4. 8 Платежі, ліміти, терміни

Чітко пишіть про комісії/терміни: «Комісія 1,5% утримується провайдером», «Виплата - до 15 хвилин».
Пояснюйте причини відмов: «Метод недоступний у вашому регіоні через правила провайдера».

4. 9 Безпека і чутливі кроки

Нейтральний тон, нуль жартів.
Приклад: "Ми помітили вхід з нового пристрою. Це ви? [Так, це я] [Ні]".

5) Тон і стиль: налаштування під ситуацію

Нормальний потік: доброзичливий, лаконічний.
Навчання/онбординг: підтримуючий і мотивуючий.
Стрес/помилка/оплата: нейтральний, спокійний, конкретний.
Правові/умови: формально-прозорий, без маркетингових обіцянок.

• Використовуємо: «будь ласка», «готово», «не хвилюйтеся», «перевірте».
• Уникаємо: «ой», «упс», «хак», «магія», сарказм, зменшувально-пестливі.

6) Локалізація та міжнародізація

Закладайте запас по довжині рядків (DE/UK довше).
Числа/валюти/дати - форматуйте локально.
Не шифруйте сенс в гуморі/метафорах.
Ведіть глосарій термінів і tone-map за мовами (набір прикладів фраз на кожну ситуацію).

7) Доступність (A11y)

Помилки і важливі статуси - aria-live.
Контраст і читаність на рівні WCAG.
Сенс - в лейблі/aria-label, не тільки в placeholder.
Текстові еквіваленти для іконок: «Видалити», «Приховати пароль».
Порядок табуляції = порядок сенсу.

8) Процес і дизайн-система контенту

Контент-пайплайн: бриф → драфт → UX-рев'ю → легал/комплаєнс (якщо потрібно) → локалізація → тести → реліз.

• бібліотеки станів (успіх/інфо/увага/помилка);
• шаблони помилок за типами полів;
• гайд за CTA-назвами;
• tone-map і глосарій;
• «дозатори» довжини (max chars для станів).
• Версіонування тексту: зберігайте рядки поруч з кодом/компонентами, використовуйте ключі та описи.

9) Метрики та експерименти

Основні метрики: конверсія кроку, CTR по CTA, час до завершення, частота помилок (type-specific), NPS/CSAT для сценарію, частота звернень на підтримку по темі.
Дослідження: UX-інтерв'ю, юзабіліті-тести, читання вголос, eye-tracking для виявлення «сліпих зон», аналіз клік-карти порожніх станів.
A/B-тести microcopy: тестуйте один смисловий фактор за раз (дієслово дії, конкретика терміну, формулювання помилки).

10) Анти-патерни

Гумор у критичних кроках («упсик!» при платіжній помилці).
Абстрактні CTA («ОК», «Далі») без об'єкта дії.
Технічні коди без перекладу («Error 500» замість «Сервіс недоступний»).
Плейсхолдер замість лейблу.
Приховані умови і невиправдані очікування («Миттєво», коли є затримки).
«Нульові» порожні стани без next-step.
Пасивна застава і безособові конструкції («повинно бути заповнено»).

11) Шаблони фраз (можна брати і вставляти)

• «Введіть номер телефону у форматі + 380...»
• "Пароль занадто короткий. Мінімум 8 символів"
• "Документ розмитий. Завантажте більш чітке фото"

• "Готово! Ми перевіримо документи (до 2 хвилин) і надішлемо повідомлення"
• "Платіж прийнято. Квитанцію відправили на e-mail"

• "Тут з'явиться історія операцій після першого поповнення. [Поповнити]"

• "Підключаємо провайдера... зазвичай це займає до 30 секунд"

• "Ми заблокували спробу входу з незнайомого місця. Якщо це ви - підтвердите в додатку"

12) Чек-листи

• Чи зрозуміло, що робити користувачеві далі?
• Чи є конкретика: формат, ліміт, термін, причиною/наслідком?
• Чи збігаються терміни з глосарієм?
• Тон відповідає ситуації?
• Повідомлення читабельно вголос і на екрані 320 px?
• Доступність: лейбли, aria-атрибути, фокус, контраст.
• Чи готовий варіант для локалізації (без культурних пасток)?

• Повідомлення пояснює причину?
• Підказує виправлення?
• Не звинувачує користувача?
• Не розкриває зайві технічні деталі?

13) Приклади «до/після»

1. Платіж відхилено

До: «Помилка проведення платежу»

Після: "Платіж відхилено банком. Спробуйте іншу картку або зв'яжіться з банком. Комісія не списана"

2. Двозначна кнопка

До: «Продовжити» (незрозуміло, що саме)

Після: «Перейти до підтвердження особи»

3. Нульовий пошук

До: «Нічого не знайдено»

Після: "Нічого не знайдено по "roulette live". Приберіть фільтр «Тільки high-limit» або спробуйте «roulette». [Скинути фільтри]"

4. Порожній гаманець

До: «Тут порожньо»

Після: "Щоб почати, прив'яжіть карту або гаманець. Це прискорить поповнення і виплати. [Додати спосіб оплати]"

14) Вбудовування microcopy в продуктову роботу

Плануйте текст одночасно з дизайном і логікою.
Тримайте «банк рядків» в репозиторії та дизайн-системі.
Закладайте етап тестування текстів на копіях екранів.
Документуйте рішення: чому обрано формулювання, які гіпотези перевірені.

Коротка шпаргалка

Сенс → Дія → Слово. Спочатку що потрібно зробити, потім як це сказати.
Один екран - одна мета. Мікротекст обслуговує мету кроку.
Більше контексту - менше підтримки. Пояснюйте вчасно і по справі.
Тестуйте слова так само, як і UI. Тексти - частина інтерфейсу, не прикраса.