В свое время я довольно глубоко копал эту тему, изучал кейсы и подходы разных компаний. Самые известные примеры:
- MailChimp. В районе 2010 года они собрали базу исследований на Evernote.
- Head of UX из WeWork. Он сделал базу в Airtable — это, пожалуй, самый известный, хрестоматийный шаблон. Именно после его статьи все начали использовать Airtable — он очень подробно описал не только саму базу, но и весь процесс вокруг нее: рекрут, reporting. У него все очень круто автоматизировано и собрано на no-code.
- Microsoft. У них был похожий на WeWork подход — большая база с инсайтами по конкретным элементам.
Я тоже пробовал Airtable и какое-то время мы вели в нем базу, но столкнулись с двумя проблемами: непрактичность атомарного подхода (именно в наших условиях) и некоторая идеализация процесса работы с базой исследований.
Проблема 1. Непрактичность атомарности
Часть баз инсайтов основаны на атомарном подходе. Поясню на примере: обычно после юзабилити-тестирования нового интерфейса обнаруживается много проблем. В классическом подходе все они объединяются в отчет о тестировании конкретной функции — этот отчет и является основной единицей информации.
Атомарный подход работает по-другому: допустим, у нас есть проблемы, связанные с боковым меню, pop-up или антистейтами. Мы не складываем их в один объект-отчет: каждую проблему помечаем тегами, а потом можем делать выборку по всем проблемам — например, связанным с боковым меню.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Привлекательность такого подхода в том, что во время исследований нередко появляются дополнительные инсайты, которые почти не связаны с основной темой. И такие инсайты потом довольно сложно найти в общих отчетах. Но когда ты мыслишь не категориями проектов, а отдельными инсайтами, получаются более дробные кусочки информации, «атомы, и база данных состоит именно из них. При этом каждый из таких микроинсайтов — самодостаточная единица информации.
А еще в такой базе очень сильно разрастается таксономия и система тегов. У ребят из WeWork все было гораздо удобнее — они цепляли инсайты к конкретным пространствам, переговоркам или кухням, к физическому пространству (WeWork занимается коммерческой недвижимостью). Эти пространства работают как теги, поэтому их конечное количество и в базе относительно легко ориентироваться. В случае диджитал-продуктов элементов гораздо больше, вариаций тоже, контекст более сложный — и такая система тегов сразу рушится. В итоге мы обнаружили, что искать инсайты в базе сложно, а поддерживать ее — дорого, надо прикладывать слишком много усилий.
Проблема 2. Никто не пользуется такой базой инсайтов
У нас было идеальное представление, что дизайнеры и менеджеры продуктов будут самостоятельно пользоваться базой и искать в ней инсайты — так же, как они пишут SQL-запросы в базу данных аналитики. Но это не сработало — отчасти из-за отсутствия нужной культуры. Кстати, у тех же ребят из Microsoft основным интерфейсом между базой инсайтов и менеджерами продуктов тоже остается исследователь. То есть сотрудники все равно приходят и говорят: «Слушай, нам надо быстро собрать отчет», — а исследователь ищет информацию под их запрос. И я подумал: если у Microsoft не получилось, возможно, это и правда очень сложный процесс. Тем более, я видел мало других кейсов где исследователям удавалось выйти из этой цепочки.
Сама идея такой базы основана на том, что с любого исследования ты получаешь два вида инсайтов: те, которые связаны с целевым запросом, и инсайты-«огрызки», которые жалко выкидывать, но прямо сейчас необходимости в них нет. И мы думали, что если положим их базу, то потом они кому-то пригодятся, их будут искать. Однако на практике такие инсайты никто не ищет — исследователю самому приходится их продвигать, вспоминать, что они существуют, собирать из отдельных данных и инсайтов какие-то артефакты: персоны, Job Stories, CJM.
Почему так происходит? Думаю, многое зависит от продуктовой культуры и степени сформированности запроса на исследование. Проведу аналогию с продуктовой аналитикой. Есть компании, в которых принято, что менеджеры продуктов максимально опираются на аналитику и сами знают SQL, могут найти нужные данные. И если ты не знаешь SQL, то даже не сможешь работать в таких компаниях. Это часть культуры. А в других компаниях аналитику приходится постоянно всех подталкивать и проявлять инициативу: «Ребята, смотрите, я такую интересную штуку нашел».
То же и с качественными исследованиями. Наверняка есть компании, где работа с атомарными инсайтами — часть культуры менеджеров продуктов. И когда ты создаешь любое продуктовое или дизайн-решение, ты самостоятельно собираешь максимальное количество пользовательских данных, проявляешь инициативу, обращаешься к исследователям. В то же время в других компаниях менеджеры продуктов привыкли заказывать юзабилити-тестирование и самостоятельно искать что-то в огромной базе инсайтов не станут.
Например, так происходит в Microsoft и Facebook. Они тратят много сил на то, чтобы продвинуть в командах результаты исследований и не оставлять их пылиться на полках большого склада. И для них «продажа» результатов исследований, красивые презентации, понятные артефакты важнее, чем база инсайтов. А ситуация, когда исследование есть, но его никто не продвигает для них выглядит как новая фича, которая не промоутируется.
На каких принципах мы начали строить свою систему
В ходе размышлений и анализа я пришел к тому, что задача исследователя — максимально эффективно улучшать продукт с помощью своих ресурсов. А значит, нужна не столько удобная база, сколько максимальный КПД исследований. Итоговая задача — понятная витрина инсайтов, которая будет работать на улучшение продукта. Часто базы инсайтов, к сожалению, работают, как большой склад знаний о пользователях — там знания просто лежат, как товары на складах, покрываются пылью и почти не используются. При этом компания тратит лишние деньги на аренду и поддержание всей системы.
Поэтому в какой-то момент мы поменяли подход. В основу новой системы легли три основных принципа.
- Мы поняли: если наша цель — увеличить КПД от исследований, то необходимо по результатам каждого исследования создавать какие-то артефакты. Эти артефакты должны максимально подробно транслировать результаты исследований, а не пылиться на складе. Например, мы наглядно упаковываем отчеты, стараемся максимально донести их до всей команды и обучить коллег, как ими пользоваться. То есть у нас фокус сместился от хранения результатов к коммуникации.
- Мы все еще мыслим атомарными инсайтами, но размечать их дорого, поэтому в базе классифицируем информацию до уровня отчетов. Например, раньше у нас лежали атомарные инсайты, посвященные конкретным элементам интерфейса или каким-то микросценариям, а сейчас объекты — это исследовательские проекты. Наш стандартный подход такой: есть проект, по нему есть отчет, и этот отчет лежит в Confluence.
- Каждую идею и единицу информации мы стараемся связывать с другими. Добавляя отчет, мы думаем, с чем еще он может быть связан. Например, мы сделали отчет по онбордингу и продвижению какой-то фичи, и тематически он связан с другими отчетами про онбординг и продвижение. А значит, надо найти их и поставить кросс-линки. А еще этот отчет может быть связан с другими отчетами по конкретной фиче: как ее покупают, как продолжают ею пользоваться — или с персонами покупателей, как пользователи принимают решение об оплате (ведь онбординг — это часть покупки в широком контексте). Эту идею мы отчасти вынесли из метода Zettelkasten — именно поэтому стараемся максимально добавлять взаимные ссылки между отчетами. В Zettelkasten есть и еще одна идея — атомарность каждого объекта в базе, но ее мы исключили, это слишком затратный процесс.
На каких инструментах собрана наша система хранения результатов исследований
Для работы с результатами исследований мы используем три инструмента: Confluence, Jira и Otter.
Отчеты мы храним в Confluence, а инсайты из них сразу по-максимуму привязываем к задачам в Jira. У менеджеров продуктов есть бэклог, а у исследователей отчеты — и вместо того, чтобы вести две отдельных таблицы, мы стараемся их объединять. Получили инсайт — привязали его к задаче из бэклога, чтобы она максимально быстро шла в работу. Плюс к этому в Confluence мы максимально проставляем кросс-линки между отчетами — это как раз та самая концепция из Zettelkasten.
Чтобы проще было искать отдельные инсайты, которые нельзя сразу подвязать к задачам из бэклога, мы используем Otter. Это программа, которая интегрируется с Zoom и автоматически транскрибирует все интервью. Она работает только для английского языка— но у нас все интервью англоязычные и нам этого достаточно. Для русского языка есть потрясающее решение от Кирилла Улитина — оно собрано на базе «Яндекс.Облака». Я не использую его только потому, что у меня нет русскоязычных интервью, а вообще, я думаю, ему за это стоит поставить памятник 🙂
Итак, как работает Otter: например, в серии интервью мы говорили про репорты в продукте, но я хочу найти информацию о чем-то другом — например, о комплаенсе. Я вбиваю «комплаенс» в поле поиска и вижу все цитаты из интервью с пользователями. Такой подход позволяет очень быстро найти и собрать все, что пользователи говорили на эту тему.
По сравнению с атомарными базами инсайтов это более «грязный» способ: здесь нет четкой каталогизации, только набор цитат, часть из которых — мусор. Зато с точки зрения трудозатрат такая методика очень выгодна — транскрипты появляются автоматически, причем с разметкой по спикерам. Более того, расшифровка привязывается к названию встречи в календаре и можно посмотреть, с кем проходило интервью. То есть всегда остается возможность прийти к тем же пользователям и что-то уточнить, задать дополнительные вопросы — таким образом частично замыкается петля обратной связи.
Для нас такая система отчасти работает как замена базы инсайтов, потому что основная задача базы — быстро найти информацию по конкретному запросу. И когда нас спрашивают: «У вас есть информация о том, как в продукте работает регистрация?» — мы понимаем, что хотя и не исследовали эту тему специально, но раз 20 говорили об этом с пользователями на разных интервью. А это как раз один из основных юзкейсов базы инсайтов и у нас его практически полностью отрабатывает Otter. То есть в условиях нехватки времени и ресурсов на базу инсайтов Otter очень хорошо экономит время.
На чем еще собирают базы инсайтов
Встречаются решения, построенные на Google-таблицах. По сути, это тот же Airtable и основная проблема у них одинаковая: сложно ставить кросс-линки. А очень часто бывает, что нужно связать два абсолютно разных инсайта — и общий тег для этого не очень подходит.
Еще я слышал, что базы инсайтов делают прямо в инструментах типа Jira, потому что они уже используются всей командой и всегда под рукой. И этот фактор важнее, чем удобство самого инструмента. Лучше сделать базу там, где ее всегда будут видеть, чем в каком-то отдельном суперклассном ванильном инструменте, где будет сидеть только группа исследователей.
Подход простой: если это база инсайтов для нужд исследователей — например, чтобы быстрее сделать ad hoc-отчеты, то можно создавать ее в чем угодно. А если это база, с помощью которой вы хотите вовлечь в поиск инсайтов менеджеров продуктов, то лучше делать ее в том пространстве, где они уже привыкли искать информацию. Это может быть и SharePoint, и интранет, и Jira — потому что порог входа в отдельную базу инсайтов довольно высокий. Лучше, если это будет привычный инструмент, даже если он на первый взгляд для этого не совсем подходит.
Максим ведет канал об исследованиях UX Research. Подробнее о процессе исследований в Acronis можно узнать из его статьи на medium.
