Фото: Ружо
Когда вы обычно разрабатываете часто задаваемые вопросы или материалы для самопомощи для вашего продукта?
Для большинства стартапов, с которыми я работал, ответ «как раз перед запуском». Это кажется явно разумным, не так ли?
К тому времени вы точно определили , что это за продукт, для чего он предназначен и для кого он предназначен. На первый взгляд кажется, что это идеальное время, чтобы собрать несколько вероятных часто задаваемых вопросов, возможно, вокруг вопросов, возникших в результате пользовательского тестирования.
Или это?
Я обнаружил, что лучший способ создания справочной информации — это разработка пользовательского интерфейса.
В конце концов, ваша поддержка является частью этого опыта, верно?
Если вы сделаете самопомощь частью дизайна UX, вы можете:
- не тратьте время на написание справки ни у кого нет необходимости читать
- во избежание «документирования функций»
- Ссылка справки на точки, в которых пользователи действительно нуждаются
- разработать контекстно-ориентированную помощь, которую пользователи фактически используют — и ценить.
Полагаю, вы согласитесь, в принципе, что ориентированный на пользователя подход — хорошая идея. Тем не менее, многие менеджеры по продукту, владельцы и разработчики хотят документировать процессы или функции полностью.
Дело в том, что пользователи не часто борются с целым процессом, сквозным. Если они это сделают, у вас есть большие проблемы UX для решения.
Чаще всего в процессе возникают определенные препятствия, когда пользователь запутывается, как правило, вокруг идей или задач, с которыми пользователи не знакомы или не ожидают. Ориентированная на пользователя справка позволяет вам обращаться к этим элементам напрямую и конкретно на месте.
Он позволяет вам получать пользователей, которым на самом деле нужна помощь для вашей самопомощи прямо из вашего приложения или продукта, поскольку вы создали целевую помощь, на которую стоит ссылаться в ключевых точках интерфейса, например сообщения об ошибках или обзор функций.
И это также помогает сократить нагрузку на создание справки.
Альтернатива самосовершенствованию, ориентированному на пользователя, состоит в том, чтобы угадать: предоставить более общий контент (поскольку вы не знаете, когда пользователи получат к нему доступ), и надеяться, что они пройдут по нему, чтобы найти то, что им нужно. Это менее чем идеально и менее чем полезно. Помощь как это видит увеличение затрат службы поддержки.
Итак, давайте посмотрим, насколько сложно — или просто — это разработать ориентированную на пользователя помощь.
Процесс разработки ориентированной на пользователя справки
Чтобы создать ориентированную на пользователя справку, вам нужно вовлечь вашего писателя (или человека, который будет создавать ваш контент для самопомощи) на ранних этапах процесса разработки UX, прежде чем начнется пользовательское тестирование.
Они смогут помочь выявить потенциальные препятствия во взаимодействиях и предоставить многословную информацию, которая эффективно предоставит пользователям дверные проемы для помощи — призывы к действию, если хотите. В зависимости от вашего приложения этот текст может иметь вид:
- связи
- всплывающие подсказки
- Сообщения об ошибках
- содержание тура
…и более.
Дело в том, что писатель и дизайнер UX смотрят на опыт , а не на функцию. Они рассматривают пользовательские потоки с точки зрения варианта использования, а не с точки зрения чистого процесса.
Например, продукт, над которым я работал, зависел от Java, и пользователи в разных системах получали разные ошибки от самой Java и от нашего приложения, взаимодействующего с Java, в зависимости от того, была ли у них текущая версия Java.
Таким образом, мы упростили их путаницу простой ссылкой из соответствующих сообщений об ошибках в нашем приложении на страницу справки, которая показала, как решить эту непосредственную проблему на месте, обновив их версию Java.
Мы написали отдельный фрагмент справочного контента, который показал пользователям, как проверить, обновлена ли их версия Java, и обновить ее, если это не так. Вы можете подумать, что эта страница справки может справиться с обеими задачами, но это не так.
Хотя эта вторая часть была полезной, она оказалась менее полезной, чем первая, для людей в этом случае использования, поскольку она не предполагала контекста.
Первая часть, с другой стороны, помогла пользователям преодолеть непосредственное техническое препятствие и продолжить выполнять задачу, которую они уже начали.
В этом ценность ориентированной на пользователя справки.
Вовлечение писателя в процесс проектирования UX также гарантирует, что языковые и словарные стандарты и стили могут быть разработаны и поддерживаться в вашем продукте. Это, наряду с визуальными стилями, поддерживает понимание пользователями того, какие результаты они генерируют при взаимодействии с вашим продуктом.
Следующим шагом, конечно же, является тестирование и доработка интерфейсов — опять же, в команде. Таким образом, писатель становится частью процесса UX, отвечая на отзывы пользователей через интерфейсы и справочные страницы, на которые они ссылаются.
Но, что важно, при таком подходе содержание справки становится частью теста UX.
В конце концов, может ли пользователь самостоятельно достичь своей цели с помощью вашего продукта, в конечном итоге все сводится к удобству вашей самопомощи.
Общие возражения
Давайте подведем итог нескольким наиболее распространенным возражениям, которые я слышу о таком подходе к самопомощи.
Но где будет наша документация по продукту?
Если вы хотите документацию продукта, сделайте это. Только не называйте это справкой пользователя или не делайте это первым портом захода пользователя на вашем сайте самопомощи.
Но как пользователи получат обзор всего процесса?
Определенно есть случаи, когда пользователям понадобится обзор процесса, как в примере, который я упоминал выше. Но важно знать, где провести черту.
В приведенном выше примере пользователь, который получает ошибки Java, может перестать делать то, что он делает, проигнорировать ссылку справки в приложении и перейти на сайт поддержки, чтобы найти что-то вроде «Ошибка Java».
Конечно, вы не хотите предлагать только контент для самопомощи, который предполагает, что он находится в середине определенной процедуры в вашем приложении. Вы хотите дать им решение, которое будет работать вне очень специфических вариантов использования, и в этом случае, которое требовало пошаговых инструкций.
Однако мы не документировали каждую ошибку, которую пользователь может или не может получить из нашего приложения. Опять же, предоставление полезной самопомощи — это знание того, где провести черту.
Но как мы расскажем всем об этих замечательных функциях?
Это не то, для чего предназначен ваш сайт самопомощи. Нет смысла документировать нюансы каждого элемента вашей новой функции только ради вашего эго.
Вместо этого документируйте то, что должно быть задокументировано, как ориентированную на пользователя информацию, которую можно доставлять в соответствующих посылках по мере необходимости. И сохраните рекламу для ваших маркетинговых коммуникаций.