Как создать хороший FAQ
Привет, Хабр! Я Евгения Береснева, технический писатель в X5 Tech, и я считаю, что классный раздел вопрос-ответов нужен любому продукту. В статье как раз расскажу о том, как его создать.
FAQ про FAQ
Что это за формат?
В буквальном переводе Frequently Asked Questions — часто задаваемые вопросы. Формат, с которым вы, наверняка, сталкивались много раз. Набор популярных вопросов про продукт, которые могут интересовать пользователей, и коротких ответов на них. Раздел с типичными проблемами и их решениями, скорее всего, есть даже в инструкции к вашей микроволновке.
Кстати, как правильно — «Вопросы и ответы» или «Проблемы и решения»?
На самом деле, вариантов больше. Иногда пишут дословный перевод «Часто задаваемые вопросы» или просто «Частые вопросы», а первопроходцы рунета могут вспомнить аббревиатуру «ЧаВо».
Все варианты (кроме, пожалуй, последнего, успевшего устареть) имеют право на существование, единственного верного нет. Но мы предпочитаем называть такой раздел «Вопросы и ответы». Кажется, это лучше всего выражает суть и звучит просто и понятно. «Проблемы и решения» тоже хороший и привычный вариант, но если в нем действительно содержатся только проблемы и их решения, а не вопросы и ответы про продукт.
Где публиковать?
Самый удобный вариант для пользователя — непосредственно в продукте, чтобы раздел вопросов и ответов можно было легко найти через меню. Если такой возможности нет, опубликуйте отдельно, например, в корпоративной Вики (для внутренних продуктов) или на лендинге продукта в сети. Но попробуйте встроить в продукт хотя бы ссылку на FAQ.
Чем хорош формат вопрос-ответов?
Почему, даже когда есть полноценное руководство пользователя, многие идут сразу в раздел с частыми вопросами? Прежде всего, это максимально естественно для пользователя. Будем честны, мало кто открывает документацию к продукту просто из любопытства или желания расширить кругозор. Человек чаще всего идет искать ее тогда, когда у него возникает вопрос или проблема.
Сам по себе формат предполагает краткие ответы на конкретные вопросы, без лишних слов и простыней текста, что тоже привлекает, даже на визуальном уровне.
Так что если хотите меньше обращений в поддержку по одним и тем же вопросам, соберите их и напишите ответы. Да, даже если у вас уже есть комплект пользовательских инструкций.
Может ли раздел с частыми вопросами заменить инструкции?
Может. Но лучше, чтобы было и то, и другое. Инструкция нужна, чтобы детально изучить сценарий какого-то действия в продукте. FAQ позволяет получить ответы на конкретные вопросы и, в идеале, длинных пошаговых инструкций содержать не должен. Когда есть и то, и другое, раздел с вопросами может служить еще и входом, даже своеобразным промо для раздела с инструкциями — мы же помним, что обычно он намного популярнее у пользователей.
Давайте на примере. Вопрос из FAQ интернет-магазина: «Можно ли отменить уже оплаченный заказ?». В ответе мы должны только рассказать о том, что такая возможность, допустим, есть и кратко описать, на каких условиях это происходит. Давать пошаговую инструкцию о том, как именно это сделать, в какие разделы идти и на какие кнопки нажимать, тут не нужно. Пользователь только спросил о возможности, он может быть еще на этапе решения о том, делать ли заказ. Но после ответа мы можем дать ссылку на раздел руководства, где дается пошаговая инструкция по отмене.
Иногда частые вопросы добавляют прямо в руководство пользователя. Так можно?
Да, можно увидеть раздел с вопросами в конце руководства пользователя или комплекта инструкций. А иногда небольшой FAQ сопровождает вообще каждый раздел руководства. Это тоже хорошая идея, но рекомендую тогда все же собрать все вопросы из всех разделов и продублировать в одном месте, как единый раздел.
Скажем так, главное — обеспечить быстрый поиск FAQ для пользователя. Если мы просто скроем его в конец длинного руководства, мало кто туда доберется. Но если дать прямую ссылку на него из меню продукта или где-то еще, где пользователь легко ее увидит, то без проблем.
Кто может написать FAQ?
Это работа технического писателя. Но формат не самый сложный, можно поручить любому сотруднику, кто в вашей команде неплохо дружит с буквами — аналитику, тестировщику, деливери-менеджеру и т. д. Конечно, после того, как он изучит этот гайд! :) Но помните, что раздел вопрос-ответов обычно хорошо посещаемый, так что все должно быть красиво.
В идеале найти технического писателя, редактора или корректора хотя бы на разовую услугу, вычитать текст, поправить возможные стилистические и грамматические ошибки, добиться единства оформления всех вопросов.
Если FAQ будет пополняться, постарайтесь, чтобы за это отвечал кто-то один в команде. Если по мере возникновения новых тем будут каждый раз дописывать разные люди, у вас получится письмо дяди Федора, как в мультике про Простоквашино.
FAQ пошагово
Шаг 1. Набираем вопросы
На первом этапе задача — собрать максимум вопросов, которые могут интересовать пользователей. Пока не нужно пытаться их фильтровать и докручивать формулировки, просто наберите список.
Вот несколько основных источников для вопросов:
Пройдите все сценарии как пользователь. В процессе фиксируйте возникающие вопросы и сомнения.
Покажите коллегам не из продукта. Можно и друзьям, если они согласятся и NDA позволяет. Главное — незамыленный взгляд.
Спросите пользователей. Если есть возможность добраться до конечных пользователей, спросите у них, что им непонятно про продукт и какие проблемы возникают при его использовании. Можно использовать рассылки, формы обратной связи и т. д. Но аккуратнее с B2C-продуктами, чтобы пользователи не сочли ваши просьбы за спам. С внутренними продуктами проще — пользователей-коллег можно попросить о такой помощи.
Спросите поддержку. Если продукт уже действующий и передан на поддержку, у специалистов, работающих с обращениями, наверняка уже набрался большой пул частых вопросов.
Почитайте отзывы в магазинах приложений. Если вы работаете над приложением, которое есть в AppStore и Google Play, мониторьте отзывы там. Пользователи часто пишут там о возникающих проблемах и непонятных моментах.
Добавьте стандартные вопросы. Практически любой FAQ разумно начать с вопросов о том, зачем нужен сервис и кто может им пользоваться. Всегда актуальны вопросы об учетной записи — проблемах с авторизацией, удалении своего аккаунта и т. п. Если у вас есть нестандартные или временные решения, тоже «подсветите» их отдельно. Например, вы опубликовали бета-версию приложения, где созданную заявку невозможно удалить в интерфейсе, а нужно для этого писать в поддержку. Это нетипичный сценарий, такие стоит описать в FAQ, так как у пользователей точно будут вопросы.
Шаг 2. Создаем структуру
Когда вопросы набраны, разберите и отсортируйте их, чтобы сформировать структуру будущего раздела.
Объедините похожие вопросы и, наоборот, разделите вопросы, в которых затронуто сразу несколько тем.
Удалите вопросы, которые кажутся вам слишком частными или касающимися уже решенных проблем.
Если вопросов больше 15, разбейте их на разделы по темам, дав каждой название.
Список формируйте от более общих вопросов к более частным, от самых востребованных — к менее.
Если вопросов больше 10, добавьте оглавление, чтобы пользователю легко было сразу найти нужный вопрос. Вместо оглавления можно использовать каты — при такой верстке пользователь видит по умолчанию только вопросы, а нажатием на вопрос раскрывает ответ.
Шаг 3. Формулируем вопросы
Настало время отточить формулировки вопросов.
Убедитесь, что формулировки однотипны. Или все они должны быть сформулированы как вопросы, или как описание проблем. Если в списке есть и то, и другое, переделайте все в вопросы. Например, «Не могу войти в свой аккаунт» можно переформулировать как «Что делать, если я не могу войти в свой аккаунт?».
Задавайте вопросы от лица пользователя: «Как мне сделать то-то?», а не «Как пользователю сделать то-то?».
Пишите естественным языком: как мы обычно спрашиваем, если что-то непонятно. Ни один пользователь не спросит «В какие сроки осуществляется возврат денежных средств по отмененным заказам?». Он, скорее, скажет «Когда вернутся деньги за отмененный заказ?».
Формулируйте максимально кратко и убедитесь, что каждый вопрос посвящен одной теме.
Отдавайте предпочтение открытым вопросам. На вопрос «Можно ли списывать баллы при покупке онлайн?» придется ответить просто «Да». Открытый же вопрос «Как списывать баллы при покупке онлайн» даст возможность рассказать немного о том, как пользоваться этим функционалом.
Не говорите в вопросах на маркетинговом языке. Ни один пользователь не станет задавать вопрос вроде «Какие уникальные возможности дает ваш сервис?».
Шаг 4. Пишем ответы
Наконец, пришло время написать ответы на вопросы. Рекомендации здесь те же, что и к любым другим текстам для пользователей. И если у вас есть стайлгайд и Tone of Voice продукта, конечно, нужно придерживаться описанных там принципов. Если нет, то общих принципов инфостиля.
Тем не менее, вот несколько основных советов:
Пишите максимально простым языком, без терминов, которые могут быть непонятны хотя бы части читателей. И здесь тоже избегайте маркетингового языка, просто рассказывайте о возможностях.
Если для сервиса написаны инструкции и другая пользовательская документация, не описывайте в ответах на вопросы подробные сценарии действий, а давайте ссылки на инструкции. Хороший тон — обходиться без схем и скриншотов, это загромождает и утяжеляет текст.
Не пишите лишнего, отвечайте ровно на заданный вопрос. Если вопрос звучит «Как списать баллы?», сразу начинайте отвечать на него, а не рассказывайте обо всех преимуществах вашей программы лояльности.
Отвечайте на тот вопрос, который задан. Кажется очевидным, но я регулярно встречаю в FAQ кейсы, когда вопрос задан об одном, а ответ — о чем-то другом. Проверьте и, если нужно, подкорректируйте или вопрос, или ответ.
Шаг 5. После публикации
После публикации работа над вопрос-ответами не заканчивается.
Следите за актуальностью текста. Особенно, если в каких-то ответах вы рассказывали про временные акции, описывали бета-решения и т. п. Вовремя удаляйте или редактируйте устаревшие вопросы. Обычно FAQ устаревает чаще и быстрее, чем другая пользовательская документация.
Добавляйте вопрос-ответы. Ваш продукт продолжает работать, функционал может расширяться, а пользователи продолжают задавать вопросы. FAQ — живой формат, его можно и нужно дополнять новыми кейсами. Только старайтесь, чтобы за дополнения всегда отвечал один человек.
Собирайте обратную связь. В конце раздела с вопросами и ответами логично сделать блок вроде «Остались вопросы? Напишите нам». Так вы не оставите пользователя наедине с проблемой, если ответ ему найти не удалось, а сами получите ценную информацию о том, чем дополнить раздел.
