Как мы используем журналы трения для улучшения продуктов в Stripe

Эта статья написана в соавторстве с моим неподражаемым коллегой по команде Чарли Джерардом.

Регистрация трения — это практика, которая может использоваться инженерными командами, создающими продукты, для отслеживания и улучшения проблем, возникающих у пользователей при использовании продукта. Цель протоколирования трения — сделать данный продукт лучше для всех участников процесса. Конечные пользователи и разработчики получают продукт, который обеспечивает более непосредственную ценность, команда, создающая продукт, получает более привязанную, более счастливую базу пользователей, а продавцам легче показать ценность продукта потенциальным клиентам.

В Stripe мы используем журналы Friction для обмена отзывами с командами разработчиков о продуктах, которые мы создаем. Это, по крайней мере, часть миссии нашей команды DevRel. Наша цель — быть голосом разработчиков, которые используют продукты Stripe для создания своих собственных. Мы часто выступаем в качестве связующего звена между этими мирами: разработчиками, использующими наши продукты, и инженерными командами, создающими их.

Stripe также поощряет всех сотрудников активно участвовать в предоставлении обратной связи. Во время адаптации каждый новый сотрудник Stripe проходит обучение тому, как оставлять отзывы о продуктах, и процессу создания журналов трения.

Составные части журнала трения

Контекст

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

  • Насколько вы опытны в использовании этой функции?
  • Что вы пытались создать?
  • Каких частей функции касается этот журнал трения?

Ниже приведен пример контекста для журнала трения о настройке нового принтера:

Плюсы и минусы

После того как вы написали контекст, вы можете перейти к резюмированию плюсов и минусов, с которыми вы столкнулись.

Эта часть должна представлять собой список основных пунктов, в котором четко указаны те части функции или опыта, которые вам понравились или показались полезными, и те, которые, по вашему мнению, могли бы быть лучше или не соответствовали вашим представлениям о том, как должна работать функция.

Подробный поток сознания

Наконец, подробный поток сознания — это та часть, где вы должны дать отзыв, не обязательно следуя определенной структуре. Вы должны писать его по мере того, как вы пытаетесь использовать функцию. Сюда можно включить все, что, по вашему мнению, может быть полезным для команды, независимо от того, насколько это незначительно. Не стесняйтесь добавлять скриншоты, GIF-файлы, демонстрирующие ваше взаимодействие с инструментом, ссылки и т.д.

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

Чтобы дать вам представление, вот пример того, как может выглядеть эта часть журнала трения:

Рамки для отличного журнала трения

Размер доли (S/M/L) наперед

Маленький — Журнал трения небольшой и управляемый. Его можно заполнить за разумный промежуток времени, не чувствуя себя обузой.

Средний — Фрикционный журнал имеет умеренный размер. Его чтение может занять некоторое время, но он не слишком длинный.

Большой — журнал трения большой и может занять некоторое время. В них, скорее всего, отражены более крупные путешествия пользователей и показана целостная картина процесса, а не небольшая путаница с одной функцией.

Сделайте путешествие понятным

Журнал трения должен четко показывать, какой путь проходит пользователь, какие шаги он предпринимает на этом пути, а также контекст его персоны («Я новичок в сборе платежей в Интернете» или «Это уже третий крупный релиз моего продукта, но нам нужно добавить поддержку приема платежей в Канаде»). Кроме того, журнал должен быть простым для понимания целевой аудиторией — по возможности используйте язык, понятный команде разработчиков и заинтересованным сторонам без необходимости проводить собственные исследования.

Подчеркивайте как радость, так и разочарование.

Хотя очень важно делиться возможностями для улучшения продукта, также очень важно делиться тем, что идет хорошо. Это помогает укрепить доверие к команде инженеров и может стать хорошим напоминанием о том, что вы все преследуете одну цель: сделать продукт настолько хорошим, насколько это возможно.

Будьте наглядны

Везде, где это может быть полезно, приводите скриншоты, видео или другие наглядные материалы, которые помогут объяснить процесс, который вы проделали, и реальный опыт, который вы получили. Это может быть ссылка на скринкаст разработчика для более длинных журналов трения.

Описывайте проблемы объективно

Здесь эмоциональный интеллект играет решающую роль. Избегайте использования эмоционально окрашенных формулировок и вместо этого описывайте проблемы объективно. Что-то вроде «Я запутался между шагами 6 и 7 и вернулся к этой странице документации, чтобы найти то, что я пропустил» гораздо полезнее, чем «Я потратил на это 2 часа, это так плохо!».

Широко делитесь своими отзывами

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

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

Последующие действия!

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

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

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

О предоставлении обратной связи

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

Эмоциональный интеллект — это важно

Эмоциональный интеллект включает в себя самоанализ, социальную осведомленность, эмпатию и управление отношениями. Написание журнала трения сосредоточено на вашем личном опыте работы с функцией или продуктом, однако вы должны помнить, что его будут читать люди, которые потратили много времени и усилий на создание того, что вы используете.

Постарайтесь поставить себя на их место и избегайте использования не очень тактичных выражений. Например, вместо того чтобы говорить что-то вроде «Это, безусловно, худший API, который я когда-либо использовал», что не только грубо, но и бесполезно, вы можете изменить формулировку на «Мне было трудно использовать этот API, потому что X, Y, Z». Таким образом, ваш отзыв превратится из общего комментария в более сфокусированный на вашем личном опыте, и будет полезнее объяснить, с чем вы столкнулись, чтобы команда могла принять меры по улучшению ситуации. Кроме того, старайтесь не использовать местоимение «вы», обращаясь к своему отзыву. Вместо того чтобы сказать: «Конечная точка API, которую вы реализовали, не совсем понятна», вы можете сказать: «Эта конечная точка API была немного непонятна для меня». Это сфокусирует ваши комментарии на самой функции, а не на том, кто ее реализовал.

Доверие — важнейший компонент

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

Давать обратную связь трудно; получать ее еще труднее

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

Резюме

Если вы еще не используете протоколирование трения как часть процесса разработки продукта, вам определенно стоит задуматься о его внедрении. Вот почему:

  • Это может помочь вам определить возможности для улучшения вашего продукта, выявляя узкие места и слабые стороны. Демонстрация того, что вы прислушиваетесь к пользователям и активно вносите изменения в свой продукт на основе их отзывов, укрепляет доверие и лояльность пользователей.
  • Friction Logging может помочь построить культуру доверия и обратной связи, а также стимулировать эмоциональный интеллект в общении между вашими коллегами.
  • В долгосрочной перспективе протоколирование трения может помочь вам сэкономить время и деньги, обеспечивая постоянное улучшение вашего продукта. Получите наши шаблоны протоколирования трения
  • Мы создали набор инструментов для ведения журнала трения, который вы можете использовать, если хотите начать вести журнал трения в своей компании.
  • Вы также можете заглянуть на сайт frictionlog.com — там представлено множество отличных статей, примеров и ресурсов по протоколированию трения.

Об авторах

Чарли Джерард — представитель разработчиков в компании Stripe, креативный технолог и эксперт Google Developer Expert. Она любит исследовать и экспериментировать с технологиями. Когда она не занимается кодингом, ей нравится проводить время на свежем воздухе, пробовать новые сорта пива и читать.

Майк Бифулко (@irreverentmike on twitter) — представитель разработчиков в компании Stripe. Он также серийный предприниматель, ведущий подкаста APIs You Won’t Hate и фанатик эспрессо. На своем сайте mikebifulco.com Майк пишет о дизайне продуктов и создании приложений на основе React.

Оцените статью
devanswers.ru
Добавить комментарий