# Переписала повідомлення про помилки застосунку за письмовим стандартом тону після того, як у разі відмови у вході застосунок звинувачував користувача в помилці введення, хоча провайдер насправді вимагав пароль для застосунку, і покрила це тестом, який називає провайдера. вересень 2026 **Ситуація.** Вхід в обліковий запис великого поштового провайдера не вдався, і застосунок повідомив користувачеві, що пароль неправильний. Пароль був правильний. Цей провайдер вимагає для сторонніх клієнтів окремого пароля застосунку й відхиляє пароль облікового запису, хоч би як ретельно його набирали. Повідомлення змушувало користувача знову вводити те, що ніколи не могло спрацювати, а справжньої вказівки — створити пароль іншого типу — не було ніде. **Завдання.** Повідомлення про помилки треба було переписати за письмово зафіксованим стандартом, а не виправляти по одному, бо цей випадок був лише помітним проявом звички, яка проходила крізь усі повідомлення. **Дія.** Стандарт містить три вимоги: сказати, що сталося; ніколи не натякати, що користувач зробив щось не так, якщо причина в іншому; і назвати наступний крок, якщо він є. Коли стандарт застосували до всіх повідомлень про помилки, виявилося, що більшість порушує принаймні одну вимогу — кілька повідомлень були просто рядком помилки базової бібліотеки, переданим без змін, а такий рядок описує стан для програміста, а не ситуацію для людини. Повідомлення для випадку з провайдером переписали так, щоб воно називало провайдера, пояснювало, що для інших клієнтів він вимагає окремого пароля застосунку, і вказувало, де такий пароль створити. Повернутися до старого не дає тест, і він навмисно конкретний: він відтворює невдалий вхід у цього провайдера й перевіряє, що повідомлення містить назву провайдера та фразу з описом потрібного типу облікових даних. Тест, який перевіряв би лише появу якоїсь помилки, пройшов би й на початковому неправильному повідомленні, тому перевірка стосується змісту — єдиної частини, яка взагалі була зламана. **Результат.** Повідомлення про помилки відповідають сформульованому стандарту, а випадок, з якого все почалося, покрито тестом, що не проходить на старому тексті. Невирішеним лишається масштаб: дотримання стандарту забезпечують рев'ю та один тест для одного повідомлення, а для інших провайдерів з їхніми особливими вимогами аналогічних тестів немає, тож цей клас помилок задокументовано, а не закрито. --- - Роль: Контент‑дизайнер - Категорії: [Frontend‑розробка](https://advisory.engineer.company/uk/categories/frontend/), [Безпека](https://advisory.engineer.company/uk/categories/security/), [Тестування та QA](https://advisory.engineer.company/uk/categories/testing/), [UX / UI‑дизайн](https://advisory.engineer.company/uk/categories/ux-ui/), [Продукт і вимоги](https://advisory.engineer.company/uk/categories/product/), [Документація](https://advisory.engineer.company/uk/categories/documentation/) - Послуги: [UI/UX‑дизайн та дизайн‑системи](https://advisory.engineer.company/uk/services/ui-ux-design/), [Продуктова стратегія та вимоги](https://advisory.engineer.company/uk/services/product-strategy/), [Технічна документація](https://advisory.engineer.company/uk/services/technical-documentation/)