Тултипы против документации: когда подсказки в продукте бьют базу знаний

Рано или поздно этот спор случается в каждой продуктовой команде. Одни хотят тултипы на всё: «документацию всё равно никто не читает». Другие — нормальную базу знаний: «тултипом ничего по-настоящему не объяснишь». Обе стороны точно видят слабость оппонента и обе неверно ставят вопрос, потому что тултипы против документации — не мировоззренческий выбор. Это решение о маршруте, которое принимается по каждому вопросу отдельно, и для него есть рабочая схема.

Отправная точка — перестать думать о содержании и начать думать о моменте. Один и тот же вопрос пользователя — скажем, «что на самом деле меняет эта настройка?» — это совершенно разные задачи в 9:04 утра, посреди работы, с горящим сроком, и во время спокойного изучения продукта перед покупкой. Формат должен следовать за моментом, а не за темой.

На что каждый формат действительно годится

Сверхспособность тултипа — место. Он стоит ровно в том пикселе, где возникает вопрос, не требует никакой навигации и может появиться ровно в секунду замешательства. Ему не нужен поисковый запрос, и это важно: растерянный человек часто не может назвать то, чего именно он не понимает. Ограничения у тултипа такие же резкие: ёмкость в одно-два предложения, никакого места для процедур и исключений и полная невидимость для всех, кто сейчас не стоит на этом экране.

Документация переворачивает каждое из этих свойств. У статьи неограниченная глубина: в неё помещаются процедуры, скриншоты и таблицы исключений; её находят через поисковик люди, которые ещё даже не стали вашими пользователями; на неё можно сослаться в ответе поддержки, в письме или в цепочке онбординга. Её слабость — расстояние. Дойти до статьи значит выйти из задачи, сформулировать запрос, просмотреть выдачу и перенести общий ответ обратно на конкретный экран — цепочка, где отвал есть на каждом звене, и проходит её человек, который уже раздражён.

Ни одну из этих слабостей не починить: каждая — цена соответствующей силы. Именно поэтому ответ никогда не звучит как «выберите что-то одно».

Пять вопросов, которые определяют маршрут любой подсказки

Когда вопрос пользователя всплывает в обращениях поддержки или на ревью дизайна, прогоните его через пять фильтров:

1. Блокирует ли вопрос работу прямо сейчас? Человеку, застрявшему посреди сценария, ответ нужен там, где он стоит. Срочность в момент замешательства — самый сильный аргумент за подсказки внутри продукта: ответ из базы знаний на блокирующий вопрос приходит уже после того, как раздражение случилось.
2. Какой длины честный ответ? Если он умещается в два предложения — его место в интерфейсе. Если это процедура, дерево решений или что угодно со словами «кроме случаев, когда» — нужна отдельная страница. Инструкция, утрамбованная в череду тултипов, — так и рождаются худшие подсказки внутри продукта.
3. Кто спрашивает? Новичок посреди сценария не может найти поиском то, чего не умеет назвать, — покажите ему ответ сами. Опытный пользователь, настраивающий редкий случай, администратор, планирующий внедрение, и тот, кто сравнивает вас с альтернативами, ищут глубину осознанно, причём последний делает это, ещё не имея доступа к вашему интерфейсу. Документация — единственный ваш голос, который дотягивается до людей за пределами продукта.
4. Как часто вопрос возникает у одного человека? Вопрос, который каждый пользователь задаёт ровно один раз и в самом начале, — это задача онбординга: решается тултипом, пунктом чек-листа или пустым экраном. Вопрос, который изредка и бесконечно задают немногие, — это задача справочника: решается статьёй, которую находит поиск, ваш и поисковой системы.
5. Зависит ли ответ от состояния пользователя? У вопроса «почему у меня эта кнопка неактивна?» свой ответ для каждого тарифа, роли и конфигурации. Статичная документация отвечает на все варианты разом — и плохо. Подсказка внутри продукта, знающая сегмент пользователя, отвечает тем вариантом, который верен именно для него: здесь контекст не приятное дополнение, а весь ответ целиком.

Где тултип выигрывает безоговорочно

Некоторые ситуации почти всегда уходят в подсказки внутри продукта: незнакомый термин и заминка над конкретным полем («кто здесь считается активным пользователем?»), страх последствий («если я это удалю, оно пропадёт у всех?»), пустые экраны, которые обязаны научить, чем их заполнить, и момент сразу после ошибки. Общее у них одно: вопрос маленький, срочный, привязанный к месту — и часто ещё даже не осознанный. Никто не открывает новую вкладку ради вопроса, о наличии которого не подозревает; удачно поставленный тултип отвечает на него всё равно.

Где безоговорочно выигрывает база знаний

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

Свяжите форматы, вместо того чтобы выбирать

Настоящая работа здесь — спроектировать переход. Тултип отвечает одним предложением и ведёт ссылкой на статью для тех десяти процентов, кому нужна глубина; статья, в свою очередь, исходит из того, что читатель мог прийти именно с того экрана, и отвечает в первой же строке, а разворачивает мысль потом. Держите один источник истины на каждый вопрос: один и тот же факт, живущий отдельно в тултипе и в статье, рано или поздно разойдётся сам с собой, а расхождение пользователи замечают куда лучше, чем заметили бы любую из ошибок по отдельности.

Кликабельность самой ссылки — тоже сигнал. Если в тултипе часто жмут «Подробнее», значит, его единственная строка на вопрос не отвечает: либо переписывайте строку, либо повышайте тему до более ёмкой поверхности внутри продукта.

Как это ломается и за чем следить

Подсказки внутри продукта ломаются через инфляцию: стоит команде получить инструмент, как тултип отрастает у всего подряд, и интерфейс превращается в шепчущий музей, где важные подсказки тонут среди декоративных. Держите подсказки на той же планке, что и уведомления: каждая тратит внимание, принадлежащее задаче пользователя. Документация ломается через энтропию: статьи написаны однажды, скриншоты тихо стареют, и база знаний постепенно становится местом, где ответы когда-то были. Лечение у обеих поломок одно — измерять и подрезать. Доля закрытий и вовлечение показывают, какие тултипы перестали отрабатывать занятые пиксели; поисковые запросы без единого клика по результату и статистика обращений по статьям — где база знаний тонка или протухла.

Мерить эту пару стоит как систему, а не как два независимых актива. Если ваша платформа подсказок умеет нацеливаться по сегментам — так, как NudgePath нацеливает тултипы и сценарии по роли, тарифу и поведению, — фильтр «кто спрашивает» перестаёт быть редакторской догадкой и превращается в маршрутизацию, которую можно реально выкатить: новички получают ответ сами, ветераны перестают видеть подсказки, из которых давно выросли, а статья обслуживает всех, до кого интерфейс не дотягивается.

Честный итог

Тултип выигрывает у документации, когда вопрос маленький, срочный, привязанный к контексту и общий для всех. Документация выигрывает у тултипа, когда ответ длинный, полный условий, редкий или его ищут снаружи продукта. Любая настоящая система помощи — это и то и другое, соединённое осознанными переходами. И выигрывают не те команды, у которых есть философия форматов, а те, что отправляют каждый вопрос на поверхность, где он гаснет быстрее всего.