Пользователь пишет в поддержку не тогда, когда у него есть время, а когда у него уже нет сил.

Пользователь пишет в поддержку не тогда, когда у него есть время, а когда у него уже нет сил.

У меня это особенно заметно на API-ошибках: ночью, на дедлайне, в спешке человек получает сухое `invalid_request` и должен сам догадаться, что сломалось. На практике это почти всегда означает одно: мы сэкономили строку в ответе, но потеряли доверие и время до первого успешного вызова.

Я стараюсь смотреть на ошибки как на часть онбординга. Если ответ помогает быстро понять причину, пример исправления и следующий шаг — разработчик не злится, а двигается дальше. Если нет, он пишет в поддержку, откладывает интеграцию и запоминает продукт как «сложный». 😴

Хороший API, по моему опыту, не должен удивлять. Он должен быть предсказуемым, спокойным и немного скучным — и это лучший комплимент для технического продукта.

Если у вас есть API, проверьте три вещи: текст ошибки, подсказку по исправлению и связку с документацией. Часто этого уже достаточно, чтобы сократить путь к первому рабочему запросу.