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

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

---

Привет, Хабр! Меня зовут Екатерина Орешкова, в МойОфис я работаю над исследовательскими и дизайн-задачами.

В октябре на конференции ResearchExpo 2023 я рассказала о нашем подходе к проектированию базы данных (далее в тексте — БД) регулярного качественного исследования. Теперь же раскрою тему подробнее: пошагово опишу процесс создания БД, позволяющей отслеживать юзабилити-проблемы и оценки интерфейсов в динамике, проводить демо и грумить результаты с командой.

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

О продукте: предыстория

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

В рамках большинства бизнес-задач Mailion уже может заменить Microsoft Exchange, но есть нюанс. Пользовательские сценарии в почтовом продукте Microsoft и связанные с ним бизнес-процессы формировались десятилетиями. С момента же первого публичного релиза Mailion прошло всего 2 года. Разумеется, конкурируя с настолько зрелым продуктом мы постоянно находимся в ситуации, когда необходимо обрабатывать сотни бизнес-запросов на развитие функциональности, планировать и принимать в работу множество новых задач.

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

Регулярное исследование: возможные направления и профиты

«Регулярность» исследования, как правило, заключается в следующем: с определённой периодичностью мы можем делать схожие исследования по одному некогда утверждённому плану. Однако в нашем случае мы пришли к тому, что в зависимости от потребностей продукта и команды, можем организовывать каждую отдельную «волну» внутри регулярного исследования по-разному.

Варианты дизайна исследований

• Мы тестируем новые версии прода после релизов.

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

• Сейчас мы пересобираем на новой дизайн-системе ключевые разделы, основные почтовые и календарные сценарии продукта. Результат такой работы — основные сценарии в виде прототипов в Figma и новые гипотезы. Это значит, что мы можем провести исследование тех же сценариев, но в новом исполнении.

  • Механика: при проверке основных сценариев мы отслеживаем, какие старые проблемы (существовавшие до редизайна) ушли, какие новые проблемы появились, а какие проблемы воспроизвелись и потому требуют внимания при доработке новых макетов. Ещё здесь очень интересны оценки визуальной составляющей.

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

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

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

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

Плюсы от использования базы данных

Вот ключевые требования к проектированию БД тестирований, которые мы вывели для нашего большого исследования:

• Повторюсь: мы не хотим ограничиваться только «срезом» опыта на определённую дату — нам важны динамика данных и сравнение с предыдущими волнами исследования.

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

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

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

• Итоговая цель исследования — повышение качества пользовательского опыта. На языке команды разработки: исправление проблем, ошибок и багов в интерфейсе. Речь здесь идёт о фиксации проблемы -> продвижении её по приоритету в бэклоге при необходимости -> разработке -> фиксации факта исправления/невоспроизведения проблемы -> и наконец, улучшении показателей успешности выполнения заданий.

  • Профит: пользователи могут более легко, комфортно и эффективно работать с нашим продуктом.

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

1. Наша «дизайнерско-исследовательская» база может вестись как некая песочница, а непосредственно данные для планирования разработки — условные «тикеты» проблем и задач на доработку — могут импортироваться и храниться, например, в Jira. В основном таск-трекере минимизируем лишнее, но на стороне дизайнеров и исследователей — всё в одном месте, организовано и доступно.

2. Каждую следующую волну исследования (в любом дизайне!) мы можем планировать легче и быстрее, более автоматизировано, а не копипастить из старых документов с планами исследований. То же касается и накопления, анализа и представления новых результатов. Снижается объём ручной работы, наглядные результаты доступны быстрее.

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

Как все организовать?

Предпосылки

Итак, выполнить наши исследовательские и методологические задачи в продукте возможно, если мы корректно и полно спроектируем БД качественного исследования.

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

Но в то же время это первое упражнение позволило сформировать требования к нашей будущей БД. Здесь уместно вспомнить о подходе «Atomic Research», в который укладывается и наш кейс.

Прежде чем я перейду к вопросам, отмечу, что далее буду описывать наш кейс организации данных в инструменте AirTable. В статье «Про собираемые знания и то как хранить артефакты UX-исследований» хорошо рассмотрены разные инструменты для хранения результатов в стиле «Atomic Research». Для организации данных исследований, подобной нашей, можно использовать и табличные редакторы — и в них работать с таблицами, фильтрами, формулами и так далее, с той или иной степенью гибкости настроек. Мы же на данном этапе (в том числе для наглядной отладки всей структуры данных) выбрали AirTable: помимо прочего в нём есть средства визуализации данных.

Расскажу про принципы, которыми мы руководствовались при проектировании базы.

В качестве опорных точек — вопросы, которые мы задали сами себе:

1. Как организовать хранение данных?

   • Какие сущности нам нужны? Как настроить связи между ними?

   • Как хранить данные открытых вопросов?

   • Как хранить данные респондентов?

2. Как готовиться к очередной волне исследования?

3. Как облегчить ввод и обработку данных очередного замера?

4. Как представлять результаты анализа?

Как организовать хранение данных?

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

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

• Подумайте, что вам важно фиксировать и отслеживать и в конкретном замере, и далее в динамике:

  • например, мы хотим видеть, как в ходе развития продукта респонденты справляются с заданием «Написать письмо». Значит, нам точно понадобятся сущности «Задание» и «Респондент».

  • ещё для формирования заданий мы используем гипотезы, по которым хотим увидеть статус в конце конкретного замера. Значит, понадобится справочник сущностей «Гипотеза».

  • и ещё мы хотим проверять это задание в разное время — после исправления багов и во время редизайна, — значит, нам нужна сущность «Волна исследования». Таким образом, база будет разрастаться в зависимости от задач.

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

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

  • также вы хотите фиксировать и накапливать социально-демографические параметры ваших респондентов. Это значит, что в справочнике «Респонденты» каждая строка с отдельным человеком должна быть описана набором столбцов, каждый из которых, в свою очередь, описывает нужные вам переменные в виде определённых шкал — номинальной, порядковой, интервальной, пропорциональной, или связывается с другим справочником, но последнее — вовсе необязательно. Не факт, что вам понадобится отдельный справочник уровней образования для описания респондентов в юзабилити-тестировании: может быть достаточно простого столбца в справочнике «Респонденты», где образование будет закодировано в виде обычной переменной с порядковой шкалой.

• Следуя принципу «помоги себе будущему», я придерживаюсь подхода, что в сложной базе, раз уж мы начали её делать, те или иные сущности лучше фиксировать более подробно и детализировано. Укрупнить условные переменные или схлопнуть справочники можно в любой момент, а детализирировать, декомпозировать их потом — дольше и сложнее. Однако тут важно соблюсти баланс — не утяжелять базу слишком сильно, но и не ограничивать свои возможности ввода и анализа данных в будущем.

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

Далее я подробнее расскажу о наших сущностях и справочниках, в которых они хранятся.

Какие сущности нам нужны? Как настроить связи между ними?

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

• Задания

• Гипотезы

• Юзабилити-проблемы

• Респонденты

• Вопросы (открытые вопросы, как из интервью)

• Ответы (на наши открытые вопросы)

• Волны исследования

• Продукты (что проверяем)

• Тип юзабилити-тестирования

• Теги (для построения облака тегов)

• Раздел системы (специфика нашей системы: можно выделить отдельно приложения Почта, Календарь и другие)

• Тематическая группа и другие вспомогательные сущности для разметки данных

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

Определённую сущность из любого справочника можно описать через сущности или признаки из других справочников. Конечно, с учётом здравого смысла =). Для этого надо устанавливать связи между таблицами в БД. В инструменте AirTable, например, это решается через выбор типа столбца «Link to». Когда вы устанавливаете связи между справочниками, проконтролируйте, чтобы в обеих таблицах отображалась эта связь.

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

Как хранить данные открытых вопросов?

Я неоднократно слышала от коллег такую проблему-запрос: как фиксировать качественные данные, чтобы с ними можно было работать более-менее чётко, а не оперировать большими объёмами текста, и даже иметь количественные оценки тех или иных инсайтов, кейсов, контекстов? Это можно сделать через бесконечные доски вроде Miro, в обычных таблицах или специализированных инструментах вроде DoveTail или Atlas.ti.

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

Чтобы закрыть эту задачу, при подготовке к тестам были заведены два справочника: «Вопросы» и «Ответы».

Таблица с вопросами содержала перечень тех моментов, которые мы хотели узнать у респондентов. По сути, сущностью в этом справочнике, т.е. строкой в таблице, был конкретный вопрос, например: «Вы когда-нибудь сталкивались с ситуацией, когда отправляли письмо, но необходимо было сделать так, чтобы его не успели прочитать? Что это были за ситуации?».

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

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

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

Как хранить данные респондентов?

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

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

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

Как готовиться к очередной волне исследования?

У нас уже есть подготовленные таблицы для фиксации сущностей и настроенные связи между этими справочниками. Когда вы начинаете подготовку к первой или очередной волне исследования, то с командой готовите артефакты (новые гипотезы, задания, гайды, требования к респондентам и прочие). Из них выявляете нужные вам в новой волне исследования сущности, которые можете заранее внести в базу (если их ещё там не было), чтобы далее использовать их для разметки друг друга.

Три основных принципа:

1. Для новых сущностей — новые строки

2. Для старых сущностей — новые связи

3. Для динамики — новые столбцы

Рассмотрим примеры. Начать можно со справочника волн исследования — вы добавляете туда очередную строку, скажем, Vol.4. Она понадобится, например, когда в исследовании вы найдёте новую юзабилити-проблему и захотите прилинковать её к новому замеру. Аналогичным образом вы фиксируете продукт или номер релиза, который собираетесь тестировать. В перспективе это также понадобится для фильтрации данных.

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

Если вы повторно хотите дать старое задание (например, вы давали задание «Создать встречу» в первой, второй волнах и хотите ещё раз его проверить в четвертой волне), то заводить новую сущность, то есть строку в таблице, не требуется. У вас уже есть признак — столбец в таблице, показывающий, в каких волнах использовалось задание, и туда же вы можете прилинковать очередную волну из существующего справочника волн.

Или, скажем, вы выяснили, что в очередной волне исследования воспроизвелась юзабилити-проблема, которую вы встречали ранее. Здесь также не нужно заводить новую строку в таблице проблем: в столбце волн вы дополнительно указываете свежую волну исследования.

Но возникает вопрос: если мы храним данные по одному условному заданию или проблеме в одной строке, то как фиксировать динамику?

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

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

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

Как облегчить ввод и обработку данных очередного замера?

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

И тогда мы задались вопросом: можно ли как-то упростить ввод наблюдений, преобразовать структуру БД в относительно простую форму ввода? Тут пригодилась классная возможность в AirTable — средство визуализации «Интерфейсы».

Мы пришли к тому, что нам нужна форма ввода данных одного тестирования, по сути — одна сессия с респондентом. И тогда стало ясно: именно наш справочник респондентов может стать основной для упрощённого ввода данных.

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

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

Что дальше: представление результатов

К этому моменту у нас уже есть готовые справочники, все данные обработаны и внесены в базу — можно переходить к формированию и представлению результатов. Но на самом деле об этапе анализа данных стоит задуматься ещё в начале подготовке базы =) Как я писала выше, желательно заранее спланировать, как и что вы будете фиксировать, какие признаки для описания использовать и как эти признаки-переменные будут закодированы. Это, как в любом массиве данных, влияет на возможности вашего анализа средствами табличных редакторов или иных инструментов.

Демо на команду

Предлагаю поговорить о результатах сразу в формате командного демо. В этом разделе нужно отдать дань самому инструменту AirTable и его встроенным средствам визуализации данных.

Если демо результатов первой волны исследования (протоколы которой мы вели в Confluence) мы проводили в виде обычной презентации, то демо результатов второй волны сравнительного исследования проводили полностью в AirTable. И планируем пробовать это дальше — мы отказались от привычных слайдов в пользу интерактивного лонгрида.

Приведу несколько примеров визуализации находок исследования.

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

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

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

Другой формат представления данных, доступный благодаря базе, — это графики. Например, вы делаете сравнительное исследование и хотите продемонстрировать, как с одними и теми же заданиями справлялись респонденты в разных продуктах, какой ТОП выполненных заданий у вас и у конкурента.

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

В примере на скриншоте показано, что в первой волне исследования с заданием справился один человек (так как была проблема в интерфейсе), а во второй волне (после исправления проблемы) с заданием справились 8 респондентов. В качестве дополнительного «разреза» к данным мы добавили наличие опыта выполнения похожей задачи в прошлом в других продуктах. Оказалось, что у пятерых такого опыта в прошлом не было, что не помешало им справиться с заданием в нашем приложении.

Напоследок покажу представление облака тегов. Мы придумали, как фиксировать в базе эпитеты, которыми респонденты описывают разные версии нашего продукта и конкурентов. На выходе получилась упорядоченная «плитка» тегов. За тегами очень интересно наблюдать: как будет меняться восприятие нашего продукта с течением времени.

Груминг и приоритизация проблем

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

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

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

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

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

Вместо заключения: о проблемах и идеях

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

Многообразие инструментов

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

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

В случае с продуктом Mailion мы продолжаем работать с БД в AirTable и основным репозиторием в Jira. Однако предполагаем, что в перспективе нам нужно будет переехать в наш основной инструмент ведения задач — Jira.

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

Если же вы находитесь в начале пути и вам только предстоит запускать «многосерийный» исследовательский проект для вашего сложного продукта, попробуйте поработать в AirTable или аналогичном инструменте. Стоит поупражняться с данными и понять, что вы хотите получить от структуры данных в итоге. Тогда в перспективе, если вы всё-таки решите переехать в Jira, получится легче и предметнее составить техническое задание для Jira-специалистов, которые подготовят нужные формы тикетов, логику связей и дашборды.

Относительно высокий порог входа

Чтобы работать с БД на разных этапах исследовательского проекта, нужно знать, как база устроена, как установлены связи и как базу можно сломать. Важно и в целом мониторить наличие дублей, разметку сущностей, отсутствие пропусков в ячейках, кодировку переменных и прочее. Но во многих командах может быть принято вовлечение коллег в исследовательские процессы, и в работу с инструментами в частности. Конечно, риски возрастают, если с базой начинает работать несколько коллег, чей навык владения конкретным инструментом для ведения БД поначалу может быть недостаточен.

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

Идея для минимизации таких рисков: участие коллег в проектировании отдельных БД на более маленьких проектах, если это полезно для результата. А также подготовка БД и средств визуализации для очередной волны крупного «многосерийного» исследовательского проекта, как у нас в Mailion.