Про собираемые знания и то как хранить артефакты UX-исследований

Всем привет, меня зовут Миша. Я работаю UX-лидом в SBER Automotive Technologies. Это подразделение, которое занимается беспилотным транспортом, а заодно я веду канал в телеге UX Horn, где публикую дайджесты свежих материалов по теме UX и смежных сфер.

За длительные выходные удалось разобрать и систематизировать всё, что накопилось по теме хранения знаний. Подтолкнуло написание статьи ряд болей, кажется, почти всех исследователей:

1. Команды не знают, какие источники знаний есть, и из каких источников собирается обратная связь

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

3. После презентации отчёта исследования большинство артефактов теряется, так как внимание уделяется основным проблемным местам

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

• Тяжело отследить целевой фидбек, особенно когда запускаются новые фичи

• В основном команды ориентируются на метрики и редко на обратную связь (хотя все помнят и знают, что метрики отвечают на вопросы: какой сегмент и где ошибается, ну или не пользуется фичёй, но не почему это происходит)

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

В редких случая это Word или Google Doc, чаще всего это PowerPoint или Keynote, где на каждом слайде присутствует скриншот интерфейса с описанием проблем или инсайтов. Конечно тут стоит сказать про Miro, в котором рисуют карты CJM или пользовательский путь. Реже используют Notion, но он бывает полезен, когда нужно не просто показать команде результаты, его отправляют изучить смежным командам. Надо отдать должное, что в этом инструменте отчёты получаются красивые и легко читаемыми.

Чаще всего формат отчёта определяется данными и конкретными пожеланиями/привычками заказчика или команды

Процесс

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

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

О чём нам это говорит? Верно, возвращаться и искать какие-то точечные ответы на появившиеся вновь вопросы становится сложно, долго и напряжно. Зачем это делать, если есть исследователь, которому всегда можно задать вопрос и он на него даст ответ. А если исследователь уволился или перешёл в другую команду? Получается всё? Данные потеряны?

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

И получается, что около 90% артефактов, найденных исследователем просто теряется и затмевается несколькими критичными проблемами. Особенно если сразу после презентации не было обсуждения с командой, а результаты обсуждения не превратились в тикеты в джире (или любой системе, где трекается процесс разработки)

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

Как с командой поработать над отчётом?

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

Указание даты реализации крайне важно, не чтобы «следить» за командой сделали или нет, а чтобы посмотреть, как была реализована фича, так как эффект испорченного телефона никто не отменял, а вы, как исследователь, являетесь наиболее близким к пользователям человеком, я уже не говорю о том, что исследователи часто отлично разбираются в особенностях поведения людей и особенно ЦА продукта

Принцип атомарности

Чтобы рассказать о том, как хранить знания, важно поговорить о данных, которые собираем и систематизируем свои об этом знания.

Для начала стоит упомянуть информационную иерархию знаний или DIKW (data, information, knowledge, wisdom), подробно об этом можно почитать в википедии по ссылке. Для нас важно понимать, что все знания, которые собираются — это просто данные, которые могут быть связаны с исследуемым объектом, а могут и не быть с ним связаны (информационный шум). Эти данные собираются в информацию об исследуемом продукте. Информация, в свою очередь, собирается в знания о продукте, на основе которых можно сделать какие-то практические выводы. А мудрость — это подтвежденные опытом знания , глядя на которые можно с уверенностью говорить о последствиях.

Вроде логично и не сложно, верно? Тогда идём дальше и поговорим про данные.

Данные можно представить в виде последовательности «превращений», где у нас есть:

Источник или метод — что мы сделали и как собирали данные

Факт — что мы нашли

Инсайт — что мы поняли

Рекомендация — как это применить

Давайте приведу совершенно фантазийный пример:

Источник или метод — провели юзабилити-тестирование

Факт — 7 из 8 пользователей не поняли*, что лягушка — это кнопка «купить»

Инсайт — непонятная форма или текст

Рекомендация — сделать как у всех и не выпендриваться

*Важно помнить, что в качественном исследовании количество людей, которые ошиблись, не отражают процент ошибок всей выборки. Рекомендую использовать доверительный интервал. Подробнее о нём можно почитать тут, но на английском языке.

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

Из всего вышесказанного стоит запомнить одно: методы и рекомендации могут меняться, а вот факты и инсайты остаются неизменными!

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

Работа с фактами

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

Посмотрите на следующую картинку и скажите, что вы видите, а уже после этого переходите к моему списку фактов — это будет полезным упражнением.

Перечислили?

Окей, теперь моя очередь:

• Человек (предположительно женщина, но совершенно не обязательно)

• Куда-то тянется палкой (мы не знаем что этой палкой делает главный герой)

• Висит бельё

• Рядом с домой (что за дом — нам неизвестно)

• Дом частично покрашен

• На встречу идёт человек с сумкой в руке

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

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

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

• Разные факты могут подтверждать или опровергать инсайты

• Из одного факта может следовать несколько инсайтов

• Разные источники или методы исследования могут давать каждый свои факты, но инсайты могут быть из разных источников или методов, соостветственно факты могут как подтвеждать их, так и опровергать

Промежуточный итог:

• DKIW — пирамида знаний

• В основе принципа атомарности — работа с отдельными частями знаний

• Знания, такие как выводы, рекомендации, предположения — могут меняться

• Факты и инсайты — отчуждаемые, не неизменяемые знания

• Разные источники, факты и инсайты — могут быть по-разному связаны между собой 

• Тестированию подвергаются рекомендации

Инструменты:

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

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

Excel

Использование тайм-кодов упрощает взаимодействие с сырыми данными, однако не даёт возможности работать с артефактами из большого количества исследований. Подробнее про тайм-коды в эксельке можно прочитать тут

Glean (beta)

• 22$ в месяц (есть 30-ти дневный триал)

• Поддержка: userzoom, GA, Hotjar, Power BI, trello, Servey Monkey

• На основе принципа атомарности (Atomic UX Research)

Минусы

• Beta

• Нет возможности привязать к Jira

• Могут быть проблемы при большом количестве тегов

Confluence

• Используется внутри компании

• Возможны интеграции с разными сервисами

• No Code пространство

Минусы:

• Нет связи с существующими задачами в Jira

• Чаще всего используется как инструмент хранения файлов с отчётами исследований

• Совершенно непонятно куда девать межкомандные артефакты

Notion

• Бесплатно для одного пользователя, ограничение в 5Мб для загружаемых файлов

• Поддержка: Slack, Google Drive/Images, Dropbox, Jira

• Продвинутый Confluence

Минусы

• Сложно организовать тегирование

• Нет визуализации результатов

EnjoyHQ

• Бесплатно для 1 эдитора и 100 элементов в базе, далее от 39$/мес

• Поддержка: Slack, Twitter, AppStore, Intercom, Trello, Jira, etc

• Продвинутый Notion

Минусы

• Хорош для разбора интервью/ю-тестов, но не подходит для всех видов собираемых данных

Airtable

• Бесплатно до 5к записей и 5 Gb, далее 10 и 20$ в месяц

• Поддержка: Google Forms, Jira, Salesforce, Outlook, Typeform, Miro, etc

• Дико продвинутая экселька

• Позволяет делать дашборды на основе размещённых данных

• Есть возможность получить ссылку на конкретную строчку в таблице для размещения в тикет

Минусы

• Порог входа чуть выше, чем у других инструментов

• Проблема версионности исследуемых объектов

MIRO

• Бесплатно до 3 досок

• Поддержка: Slack, Google Drive/Images, Dropbox, Jira

• Бесконечные доски и стикеры

Минусы

• Сложно организовать тегирование

• Частая потеря линков между артефактами исследований

Harvestr

• Бесплатно для 1 эдитора и 100 элементов в базе, далее от 39$/мес

• Поддержка: Zapier, Jira, Figma, GitHub, Trello, etc

• Агрегация фидбэка из разных источников

Минусы

Не очень подходит для хранения результатов качественных исследований, скорее для поддержки продукта и сбора обратной связи из разных источников

Итого по инструментам:

• Система тегирования — важная составляющая при сборе и хранении данных

• Для небольшого количества исследований подойдут:

  • Confluence

  • Notion

  • Miro

• Для подготовки красивых отчётов:

  • Презентация

  • Notion

• Для хранения результатов глубинок

  • Excel

  • EnjoyHQ

  • Glean

• Для хранения обратной связи из разных источников

  • Harvestr

• Для хранения большого количества результатов исследований

  • AirTable 

Лично я использую AirTable, как инструмент хранения артефактов исследований, там же веду учёт сроков, которые дают команды при разборе результатов исследований. Но помните, что часто именно данные определяют то, как хранить и структуру базы данных.

Ну и в конце, хочется пройтись еще раз по основным хайлатам:

1. Привлекайте на исследования как можно больше членов команды (продакты и дизайнеры обязательно)

2. Сразу после исследования — разбирайте с командой что и когда делается

3. Фиксируйте даты и не забывайте про тикеты (в тикетах хорошо если будет ссылка на конкретный артефакт исследования)

4. Декомпозируйте результаты исследований, перенося их в базу данных и не забывайте про теги

Спасибо, что прочитали до конца и интересных вам исследований 🙂

При подготовке материала были использованы в том числе материалы CX-команды СБЕРа, за что ребятам огромное спасибо