Дневниковое исследование - один из самых информативных методов в качественном арсенале. Респонденты фиксируют поведение в реальном времени, в естественном контексте, без эффекта интервью. Но у информативности есть цена: метод требует от команды больше ресурсов, чем почти любой другой. Десятки респондентов, у каждого отдельный чат, в который ежедневно приходят текстовые записи, фотографии, голосовые сообщения, видеокружочки. Данных много, и это известно заранее - ещё на этапе проектирования.
Поэтому три компромисса закладываются в дизайн исследования задолго до старта поля:
Голосовые сообщения не расшифровываются - работа идёт по тексту.
Исследователь собирает записи, но не вступает в глубокий диалог с каждым респондентом - на это нет ресурса.
В анализ идут не все дневники, а только те респонденты, которых пригласили на глубинное интервью. Остальные - страховка от отвала, и в дизайне это заложено изначально: запускают больше, чем планируют анализировать.
Дело не в ошибках планирования и не в нехватке квалификации - двое-трое исследователей физически не способны обработать такой объём данных и одновременно поддерживать глубину контакта с каждым респондентом. Все, кто работал с дневниковым методом, знают эту арифметику.
Мы в Cloud Research столкнулись с ней, когда запускали дневниковое исследование навигационного поведения - как люди используют навигацию на привычных маршрутах, какие привычки складываются, какие барьеры возникают. 32 респондента, неделя поля, команда из четырёх человек: руководитель, два исследователя, рекрутер.
Мы решили не выбирать. Вместо того чтобы нанимать дополнительных людей или сокращать выборку, мы встроили AI в рабочий процесс команды - с конкретными функциями на каждом этапе. В этой статье - три механизма, через которые это сработало: какие технические решения мы принимали, какие варианты отвергали и что это дало качеству выводов.
Итоговая арифметика проекта
Время
Проект был рассчитан на три недели: от дизайна исследования до финального отчёта. Команда - четыре человека: руководитель, два исследователя, рекрутер. Отчёт был сдан на пять дней раньше дедлайна.
Вот что стоит за этими сроками:
Решение | Вручную | С AI | Экономия |
|---|---|---|---|
Мониторинг 32 респондентов (7 дней) | 224 часа | ~2 часа | ~225 часов |
Статус дневников (4–5 прогонов) | 72 часа | 1.5 часа | ~72 часа |
Скоринг кандидатов (208 анкет + 60 детальных) | 37 часов | 15 минут | ~37 часов |
Портрет респондента (24 человека) | 48 часов | 12 часов | ~36 часов |
Гайд интервью (24 уникальных Гайда с общей бизнес-целью) v2.0 | 19.5 часа | 2 часа | ~17.5 часа |
Источник правды (аудит квот, карта фич, рецепты) | 14 часов | - | ~14 часов |
Контроль квот | 1.7 часа | 1 минута | ~1.7 часа |
Итого | ~403 часа |
403 часа - это примерно десять человеко-недель при сорокачасовой рабочей неделе. Для команды из четырёх человек на трёхнедельном проекте это означает, что AI взял на себя объём работы, эквивалентный ещё двум-трём полноценным сотрудникам.
Качество
Экономия времени имеет смысл только если качество не пострадало. Вот пять аргументов, которые мы можем привести.
Консистентность. AI классифицировал инсайты по одной и той же таксономии от первого дневника до тридцать второго без дрейфа. В ручном анализе к двадцатому дневнику критерии неизбежно начинают плавать - исследователь устаёт, и классификация становится менее строгой. Это известная проблема в качественных исследованиях, и она не связана с профессионализмом.
Взаимный контроль ошибок. AI поймал ошибки человека: скоринг выявил четыре неправильно классифицированных города в квотах рекрутера. Человек контролировал AI: алгоритм детекции поездок работал с точностью около 80%, и оставшиеся 20% исследователи корректировали вручную. Это не история про безупречный алгоритм - это система, в которой каждый ловит ошибки другого.
Верификация по сырым данным. В пайплайне выделения инсайтов был обязательный шаг: каждая карточка проверялась по исходным записям дневника. В карточку попадали проверенные факты с привязкой к конкретной записи, а не пересказ нарратива. Исследователь проверял и источник, и интерпретацию.
Глубина, которой не было бы. Четыре гипотезы из десяти выросли не из начального брифа, а из самих данных - потому что у исследователя был когнитивный ресурс заметить закономерности, которые не укладывались в заранее определённую структуру. Более трёхсот карточек инсайтов, двадцать кластеров функциональных запросов - в проекте, где анализируют 12–15 дневников вместо 32, этих цифр было бы примерно вдвое меньше.
Покрытие. Все 32 дневника вошли в анализ. Среди респондентов, которых в стандартном проекте отсеяли бы как буфер, оказались те, у кого дневники были богаче и содержательнее, чем у приглашённых на интервью.
Механизм первый: как высвобождение времени дало глубину общения
В стандартном дневниковом проекте исследователь - одновременно логист, архивист, расшифровщик и аналитик. Респондент отправил голосовое - его нужно скачать, прослушать, расшифровать, сохранить в нужную папку с понятным именем, внести в таблицу. Респондент прислал фото маршрута - то же самое. Видеокружочек с комментарием - скачать, извлечь аудио, расшифровать, сохранить и видео, и текст. Умножить на 32 человека и каждый день поля. Механическая работа съедает часы, которые могли бы уйти на содержательное общение с респондентами.
Но рутина - только первый уровень проблемы. Даже если исследователь найдёт время вступить в диалог, респондент ответит - и даст много информации, не вся из которой касается темы исследования. Как потом обработать этот объём неструктурированных данных? Неизвестно. Поэтому исследователи обычно осознанно ограничивают глубину контакта - не из лени, а из понимания, что на выходе получится массив, с которым не справиться.
Что мы построили
Первое, что мы сделали, - автоматизировали сбор и обработку дневников. Вместе с AI-ассистентом в терминале (Claude Code) руководитель проекта - человек без опыта в программировании - за один день написала Telegram-бота на Python и FastAPI, задеплоила его на облачный сервер и настроила весь pipeline. Бот получал каждое сообщение из 32 чатов через webhook в реальном времени и сохранял на Google Drive в структурированные папки: по респондентам, внутри - по датам. Текст сохранялся в Markdown, фотографии как есть, а голосовые сообщения и видеокружочки автоматически проходили через транскрипцию и падали в папку сразу с расшифровкой рядом с оригиналом.
За этим коротким описанием - несколько технических развилок, каждая из которых потребовала выбора.
Первая: как получать сообщения. Telegram API не позволяет боту читать историю чата - бот видит только то, что приходит в реальном времени. Поэтому единственный вариант - webhook: каждое сообщение обрабатывается в момент отправки. Если сервер упал, сообщения теряются (Telegram повторяет доставку, но не бесконечно). Мы приняли этот риск - и на шестой день он реализовался: OAuth-токен протух из-за того, что Google Cloud Console был в тестовом режиме (в этом режиме токен автоматически отзывается через 7 дней). 224 сообщения застряли в очереди Telegram. Починили за 20 минут - перегенерировали токен и опубликовали consent screen, чтобы токен стал бессрочным. Ни одно сообщение не потерялось.
Вторая развилка: как сохранять на Google Drive. Начали с сервисного аккаунта Google - стандартный подход. Но выяснилось, что сервисный аккаунт видит только раздел «Мой диск», а Google Drive for Desktop синхронизирует файлы в раздел «Компьютеры». Это разные пространства, и одно не видит другое. Пришлось перейти на OAuth-доступ с refresh-токеном - менее элегантно, зато файлы оказываются там, где их ждут исследователи.
Третья: формат файлов. Первая версия бота сохраняла записи в JSON. Руководитель проекта посмотрела и сказала: исследователи не будут читать JSON. Переделали в текстовый формат. Руководитель посмотрела снова: давай Markdown, с ним удобнее работать. Переделали. Три итерации за один день - и формат стал таким, в котором удобно и человеку, и последующей автоматической обработке.
Ещё одна деталь, которая кажется мелкой, но оказалась важной: в Telegram у бота по умолчанию включён Privacy Mode - он видит только команды (сообщения, начинающиеся с /), а обычные сообщения респондентов игнорирует. Если не отключить эту настройку в BotFather, бот просто не увидит дневниковые записи. На это ушло 30 секунд, но без этого шага ничего бы не работало.
Что мы сделали с освободившимся временем
Когда pipeline заработал, исследователи перестали заниматься архивной работой. Им не нужно было скачивать файлы, переименовывать их, прослушивать голосовые, расшифровывать, раскладывать по папкам. Всё это происходило автоматически.
И здесь важно: высвобождение времени само по себе ничего не даёт. Освободившиеся часы можно потратить на что угодно - административные задачи, отчётность, подготовку к следующему проекту. Руководитель проекта приняла осознанное управленческое решение: время, которое освободилось от рутины, исследователи направляют на включённое общение с каждым респондентом. Это была конкретная установка, а не побочный эффект автоматизации.
Что это дало качеству
Исследователи стали задавать респондентам уточняющие вопросы - не формальные «расскажите подробнее», а точные, основанные на конкретных записях: что имелось в виду, почему в этот раз поступили иначе, в чём было неудобство. Респонденты отвечали развёрнуто и часто голосом - потому что голосом быстрее и естественнее.
Причём исследователи работали не вслепую. Параллельно со сбором данных мы строили таблицу трекинга поездок (подробнее о ней - в следующем механизме), и в неё была заложена раскладка по таксономии инсайтов проекта. Каждая поездка каждого респондента раскладывалась по типам: барьер, драйвер, незнание ценности, проблема - с контекстом и силой влияния. AI не просто складывал записи хронологически: он понимал, где респондент описывает новую поездку, а где отвечает на уточняющий вопрос исследователя по предыдущей - даже если между ними прошло несколько сообщений о другом.
Благодаря этому исследователь мог в любой момент отфильтровать таблицу и увидеть: какие барьеры уже зафиксированы у этого респондента, какие зоны не покрыты, какие вопросы стоит задать и что именно они дополнят. Исследователь сам решал, какой вопрос задать, но мог подсмотреть предложение в таблице - и это сочетание собственной экспертизы и аналитической подсказки давало глубину, которая в обычном проекте невозможна. Анализ начинался не после завершения поля, а прямо в процессе.
Но самым неожиданным оказалось другое. Голосовые сообщения, которые в обычном проекте считаются проблемой (их нужно расшифровывать, а ресурса нет), в нашем проекте стали преимуществом. Человек, рассуждающий голосом, менее структурирован, чем печатающий по шаблону. Он выдаёт нюансы, оговорки, эмоциональную окраску - именно то, что ценно для качественного исследования. В обычном проекте исследователи не поощряют голосовые, потому что знают: расшифровка съест время, которого и так нет. У нас расшифровка была автоматической - и голосовые стали источником данных, которых в стандартном дневнике просто не существует.
Цепочка выстроилась целиком: автоматизация сбора сняла рутину, руководитель направила освободившееся время на общение, исследователи стали общаться с респондентами глубже, те в ответ давали больше контекста и часто голосом, голосовые автоматически расшифровывались, а объём неструктурированных данных перестал пугать, потому что дальше в процессе AI помогал его обработать. Каждое звено в этой цепочке зависело от предыдущего.
В цифрах: ежедневный мониторинг 32 респондентов вручную занимал бы около часа на каждого - 224 часа за неделю поля на двух исследователей. С автоматизацией обновление занимало около двадцати минут в день. Разница - порядка 220 часов, которые команда потратила на содержательную работу: уточняющие вопросы, анализ ответов, подготовку к интервью.
Без такой системы исследователь осознанно ограничивает глубину контакта с респондентом, потому что знает: он не справится с обработкой того, что получит в ответ. В нашем случае автоматизация сняла это ограничение, а управленческое решение определило, на что потратить освободившееся время.
Механизм второй: масштаб без потерь
В дизайне типичного дневникового проекта закладывается отсев. Запускают, скажем, 20 дневников, на глубинное интервью приглашают 12–15 человек. Остальные - буфер на случай отвала: кто-то бросит вести дневник, кто-то даст слишком мало информации, кто-то не подойдёт по квоте. В нашем проекте масштаб был крупнее - 32 респондента, из которых 24 планировались на интервью, - но принцип тот же.
Те, кто не попал на интервью, обычно выпадают из анализа. Частично потому, что у команды нет ресурса обработать и глубинные интервью по 24 людям, и ещё отдельно дневники оставшихся. Частично потому, что не все респонденты одинаково активны: кто-то молчит, кто-то даёт односложные ответы, кто-то плохо раскрывается - и в обычном проекте нет ресурса их «раскачивать». Выбор делается в пользу глубины по меньшему числу активных, а не охвата всех.
В нашем проекте исследователи, освобождённые от рутины (первый механизм), могли уделять время и тем респондентам, которые раскрывались медленнее. Задать дополнительный вопрос, переформулировать, предложить рассказать голосом вместо текста. Молчуны переставали быть балластом - они становились респондентами, которым нужно чуть больше внимания.
Мы построили систему, которая позволила не делать этот выбор. Она начала работать ещё до старта поля - с отбора кандидатов.
Скоринг кандидатов: формализация вместо интуиции
В обычном проекте рекрутер оценивает кандидатов по ощущению: смотрит анкету, решает «берём» или «не берём». При потоке в десятки человек критерии начинают плавать - первых оцениваешь строго, к двадцатому устаёшь и пропускаешь нюансы. Обоснование живёт в голове у рекрутера, и когда заказчик спрашивает «почему этого взяли, а того нет?», ответить нечего, кроме экспертного суждения.
Мы вместе с AI разработали 25-балльную рубрику из восьми критериев, каждый из которых привязан к задачам исследования. География, поведенческий профиль, частота контакта, разнообразие ситуаций, используемые инструменты, вовлечённость. Ключевое решение: ситуативный пользователь (тот, кто иногда включает навигацию, иногда нет) получал максимальный балл по профилю - именно у него самые интересные переключения и триггеры. «Всегда включает» - предсказуемый, «никогда» - мало материала, а «примерно в половине случаев» - исследовательское золото.
Скрипт на Python читал анкеты, применял критерии, проверял жёсткие скринеры и записывал результат в рабочую таблицу рекрутера: балл, рекомендацию и текстовое обоснование с разбивкой по каждому критерию. Рекрутер видела конкретные флаги и знала, что уточнить при звонке. Скоринг ловил ошибки, которые человек пропускал: рекрутер записала двух кандидатов из городов-миллионников в сегмент «крупный город», хотя по квотной сетке проекта они относились к «средним». Одна такая ошибка - сломанная квота и перекос выборки.
При этом скоринг не заменял живую экспертизу рекрутера, а дополнял её. Скрипт не слышит интонацию кандидата, не чувствует мотивацию, не отличает подлинный интерес от желания получить вознаграждение. Рекрутер звонила кандидатам из зон «рекомендован» и «условно» и проверяла именно это. Финальное решение принималось по сумме: формализованный балл плюс впечатление от разговора.
Каскад поля: каждое звено питает следующее
Когда выборка была сформирована и поле началось, заработал каскад из четырёх звеньев, где каждый слой создавал контекст для следующего.
Первое звено - ежедневный мониторинг. По каждому из 32 респондентов ежедневно генерировалась аналитическая карточка: выявленные паттерны, барьеры, драйверы, расхождения между заявленным поведением и реальным, конкретные вопросы для интервью.
Мы рассматривали три варианта генерации. Лёгкая модель на сервере - отвергли: выводы были слишком поверхностными для исследовательского анализа. API сильной модели на сервере - отвергли: избыточно на этом этапе, дополнительные расходы без необходимости. Выбрали третий путь: сильная языковая модель на компьютере исследователя, запуск вручную по команде «обнови мониторинг». Не полностью автоматически, зато максимальное качество анализа и полный контроль - человек видит результат и может поправить.
Карточки публиковались на защищённую веб-страницу. Команда и заказчик видели живую аналитическую картину по каждому респонденту без промежуточных отчётов и статусных встреч.
Второе звено - трекинг поездок. Каждая поездка каждого респондента становилась строкой в Google Sheets: 18 колонок описания (маршрут, цель, контекст, использование навигации, полный текст записи) и 8 колонок аналитического слоя (тип инсайта, формулировка, сила влияния, затронутый функционал, вопрос к интервью). О таблице я уже упоминала в первом механизме - она работала как аналитический инструмент для исследователей прямо в поле.
Почему Google Sheets, а не локальный файл - совместный доступ: исследователи могли фильтровать данные, оставлять комментарии, и эти комментарии обрабатывались при следующем обновлении. Лейаут таблицы прошёл через итерации: первая версия размещала портрет респондента сверху, занимая десять строк - таблица не помещалась на экране. Переделали в компактный sidebar слева, закреплённый при прокрутке: портрет всегда виден, таблица начинается с первой строки.
Больше ста поездок в день по 26 колонок каждая - заполнять вручную двумя исследователями физически невозможно. AI читал сырые записи из дневников, разбирал на отдельные поездки, заполнял все колонки, включая аналитический слой по таксономии проекта. При этом он различал, где респондент описывает новую поездку, а где отвечает на вчерашний вопрос исследователя - и дополнял существующую строку, а не создавал дубликат.
Третье звено - формализованный отбор на интервью. Кого из 32 позвать на глубинное интервью - решение по 100-балльной системе с пятью измерениями: активность ведения дневника, разнообразие поездок, качество комментариев (рефлексия, скриншоты, голосовые), исследовательская ценность (инсайты, барьеры, расхождения) и потенциал для 70-минутного разговора. Принципиальное решение: исследовательская ценность весила столько же, сколько активность - три глубокие записи с инсайтами ценнее двадцати формальных отметок «доехала нормально».
Четвёртое звено - digital interview для тех, кто не попал на основное интервью.
Вот здесь каскад замкнулся. По каждому респонденту, не отобранному на интервью, у нас уже была аналитическая карточка мониторинга с паттернами и пробелами, таблица трекинга со всеми поездками и выявленными вопросами, и неделя включённого общения из первого механизма. Это давало контекст, достаточный для целенаправленного диалога.
Исследователи задавали в чатах дневников конкретные уточнения по конкретным поездкам - не общие «расскажите подробнее», а точечные вопросы, выросшие из аналитики: «вы упоминали, что в такой-то ситуации не включили навигатор - почему именно в этот раз?». Респонденты отвечали развёрнуто, часто голосовыми, потому что к этому моменту привыкли к формату. Получался целенаправленный диалог из пяти-десяти обменов по ключевым зонам.
Мы отдаём себе отчёт: это не 70-минутное глубинное интервью. В таком формате нет свободного потока, нет возможности развернуть неожиданную тему, нет невербальных сигналов. Но альтернатива - не «провести полноценное интервью», а «выбросить данные». Digital interview позволил сохранить эти дневники в анализе.
Что это дало качеству
В итоге в анализ вошли все 32 дневника, включая тех респондентов, которые не попали на глубинное интервью. Информация по респондентам, не попавшим на интервью, оказалась не менее ценной: у нескольких из них дневники были богаче и содержательнее, чем у тех, кто пришёл на основной разговор.
В типичном дневниковом проекте аналогичного масштаба в анализ попадают 12–15 дневников из 20. Остальные - буфер, данные которого теряются. У нас в анализ вошли все 32. Ручная проверка статусов дневников (кто активен, кто молчит, кому нужен дополнительный стимул) заняла бы порядка 72 часов за проект - с автоматизацией это занимало минуты. Скоринг кандидатов по 25-балльной рубрике сэкономил ещё около 37 часов и попутно выловил четыре ошибки классификации в квотах, которые рекрутер пропустила.
Стандартный компромисс метода - анализировать часть выборки, а остальное списать - удалось снять, потому что каждый слой системы создавал контекст для следующего: мониторинг давал картину по каждому респонденту, трекинг давал структуру по каждой поездке, отбор давал обоснование для решений, а digital interview давал возможность сохранить в анализе тех, кто не прошёл на основное интервью.
Механизм третий: как мы разделили работу между AI и исследователем
Анализ качественного исследования - это ремесло. Исследователь читает данные, выделяет фрагмент, классифицирует: это барьер использования или просто жалоба? Это привычка или осознанная стратегия? Насколько сильное влияние - человек из-за этого вообще перестал пользоваться продуктом или просто поморщился? Какой функционал затронут? Какой вопрос стоит задать на интервью, чтобы копнуть глубже?
В нашем проекте таксономия инсайтов включала восемь типов - барьер, проблема, драйвер, незнание ценности, ценность, возможность, расхождение декларативного и реального поведения, пользовательский запрос - и в каждом типе свои обязательные поля: причина, контекст, сила влияния, триггер, источник. 32 дневника, обработанные по этой таксономии вручную - это недели кропотливой работы для двух исследователей. И к двадцатому дневнику неизбежно: внимание проседает, классификация дрейфует, формулировки становятся шаблоннее. Монотонная классификационная работа утомляет любого человека, и это никак не связано с профессионализмом.
Почему мы не отдали AI весь анализ
Альтернативный подход напрашивался: пусть AI и классифицирует, и интерпретирует, а исследователь вычитает готовые выводы. Мы сознательно не пошли этим путём. Если человек не проходит через данные сам - не формирует суждения, не спорит с классификацией, не замечает то, что не ложится в таксономию, - он теряет контакт с материалом. Вычитка чужих выводов принципиально отличается от формирования своих: в первом случае ты проверяешь логику, во втором - видишь, что за ней стоит.
Вместо этого мы разделили работу по природе задач. Заполнение инсайтов по таксономии - это, по сути, структурированная задача. Есть данные (дневник, поездки, диалоги). Есть структура (восемь типов, обязательные поля, критерии классификации). Есть правила (что считать барьером, что драйвером, как оценить силу влияния - всё прописано в методологии проекта с примерами «хорошо» и «плохо» для каждого типа). AI получал данные и структуру - и раскладывал по полям.
Человек получал заполненные карточки - и начинал работу другого рода. Перепроверял: действительно ли это барьер, или респондент просто пожаловался, но поведение не изменил? Задавал провокационные вопросы: а если перевернуть - может, это не барьер навигации, а привычка, которая делает навигацию ненужной? Сопоставлял с другими респондентами: трое описывают похожее - это паттерн или совпадение?
Это два разных типа когнитивной нагрузки. Классификация по таксономии - монотонная работа, на которой человек устаёт и дрейфует. Критический анализ классифицированного - интеллектуальная работа, на которой исследователь как раз силён. AI выдаёт одинаковое качество классификации на тридцать втором дневнике, а исследователь тратит свою экспертизу на то, где она действительно нужна.
Два примера, как это работало
Карта функциональных запросов. AI обработал дневники всех респондентов, извлёк упоминания функционала с контекстом (кто, что, почему, что происходит без этой функции), сгруппировал в кластеры. К концу поля получилось 20 кластеров по количеству упоминаний - от «фонового режима навигации» (9 респондентов) до единичных запросов.
Среди кластеров AI выделил мета-паттерн: часть запросов на «новый функционал» - на самом деле не запросы, а незнание существующего. Респондент делает скриншоты карты перед поездкой, потому что не знает, что маршрут можно сохранить. Другой не пользуется определённым слоем карты, потому что не подозревает о его существовании - а обнаружив случайно, начинает пользоваться регулярно. Это AI обнаружил при кластеризации - и это честно: закономерность в данных нашёл алгоритм, а не человек.
Но перевод этой закономерности в рекомендацию - работа исследователя. Разница между «разработать новую функцию» и «сделать существующую обнаруживаемой» принципиальна для продукта: первое требует месяцев разработки, второе - изменений в интерфейсе и коммуникации. Это экспертное суждение, которое алгоритм сделать не может.
Расхождение декларативного и реального поведения. AI заполнил шесть гипотез на основе дневниковых данных - каждая с доказательной базой из цитат и привязкой к конкретным респондентам. Исследователь, просматривая хронологию поездок одного из участников, заметил расхождение: в скрининговой анкете человек написал «использую навигацию примерно в половине поездок», а по дневнику за неделю - около 7%. Это оказался не единичный случай: по выборке в целом декларируемые «примерно половина» превращались в реальные 25–30%.
Отсюда родилась седьмая гипотеза - о системном расхождении между тем, что люди говорят о своём поведении, и тем, что они реально делают. AI не мог её сформулировать: у него нет ощущения «что-то не сходится», нет исследовательской интуиции, которая заставляет сравнить анкету с дневником. Но без AI, заполнившего первые шесть гипотез с доказательной базой, у исследователя не было бы времени и когнитивного ресурса на то, чтобы заметить седьмую.
Что это дало качеству
В этом проекте AI и исследователь делали разную работу, каждый ту, в которой сильнее. AI брал на себя структурную классификацию по таксономии - восемь типов, обязательные поля, сотни записей с одинаковым качеством от первого дневника до тридцать второго. Исследователь занимался тем, что невозможно формализовать: критическим взглядом на заполненные карточки, провокационными вопросами, обнаружением расхождений между тем, что респондент говорит, и тем, что делает.
Масштаб этого разделения: более трёхсот карточек инсайтов по восьми типам, двадцать кластеров функциональных запросов, десять гипотез - из которых четыре выросли не из начального брифа, а из самих данных. В проекте без AI-ассистента, где анализируют 12–15 дневников вместо 32 и где классификация к двадцатому дневнику неизбежно дрейфует, этих цифр не было бы - не потому что исследователи хуже, а потому что человеческого ресурса на такой объём не хватает.
В результате такого разделения анализ стал глубже, потому что экспертиза исследователя была направлена туда, где она незаменима, а не расходовалась на раскладывание данных по полям.
От анализа к синтезу: как команда выстроила исследовательский конвейер
Три механизма выше - про сбор данных, масштаб обработки и разделение труда при анализе. Но между анализом отдельных записей и финальным отчётом лежит ещё один слой - синтез: превращение сотен классифицированных инсайтов в связную картину, понятную заказчику. На этом этапе команда использовала тот же инструмент - Claude Code, AI-ассистент в терминале, - но уже не для сбора данных, а для аналитической работы. Руководитель проекта и исследователи вели весь синтез - от ежедневного мониторинга до нарративных портретов и бизнес-статей - опираясь на AI как на инструмент, который берёт на себя структурную часть, пока человек занимается содержательной.
Как мы создавали инструменты для AI
В Claude Code есть механизм скиллов - это текстовые файлы с детальными инструкциями, которые AI загружает перед выполнением задачи. Скилл описывает формализуемую часть экспертизы: последовательность шагов, критерии качества, типичные ошибки, примеры хорошего и плохого результата. Ту часть, которую специалист выполняет по отработанной схеме и которую можно передать, не потеряв точности. AI читает этот файл и дальше работает по нему как по инструкции. Но у экспертизы есть и неформализуемая часть - интуиция, критический взгляд, способность увидеть то, чего нет в схеме, - и она остаётся за человеком.
В этом проекте мы написали несколько таких скиллов под задачи исследования.
У нас была для этого важная предпосылка. В Cloud Research на протяжении нескольких лет мы разрабатывали внутренние стандарты качества - для подготовки методологии, для дизайна исследования, для анализа и синтеза. От проекта к проекту мы фиксировали, что работает, что нет, как отличить качественный инсайт от поверхностного, как должна выглядеть хорошая карточка барьера и чем она отличается от плохой. Эти стандарты - по сути формулы: они не допускают двоякого толкования. Что считать барьером, а что проблемой. Какие поля обязательны. Какие формулировки допустимы, какие нет.
Когда мы создавали скиллы для AI, мы передавали ему именно эти стандарты - с примерами из реальных проектов. Вот карточка барьера с причиной, контекстом и силой влияния - так выглядит качественная работа; вот «не включает навигацию» без объяснения - и почему этого недостаточно. AI принимает такие стандарты буквально и работает по ним с одинаковой точностью на первом и на тридцать втором дневнике. Человек-исследователь, даже отлично знающий стандарты, может недосмотреть, может устать, может прочитать невнимательно. Стандарты - это именно та часть работы, где точность алгоритма превосходит человеческую, и было бы неразумно этим не воспользоваться.
А человек при этом освобождается для того, что стандартами не покрывается: быть любознательным, задавать неожиданные вопросы, замечать то, что не вписывается в таксономию, сопереживать респонденту, ставить провокационные гипотезы. Всё то, ради чего человек-исследователь и нужен в проекте.
Процесс создания каждого скилла проходил через три этапа. Сначала - диалог: руководитель проекта объясняла AI, как она сама решает эту задачу, как думает, на что обращает внимание. По сути, это передача исследовательского мышления, а не просто техническое задание. Затем - проектирование: структура, режимы работы, обязательные поля, стандарты качества с примерами. Затем - стресс-тесты: намеренные попытки сломать, подать противоречивые данные, проверить, как скилл справляется с пограничными случаями.
За проект мы создали около десяти скиллов - под каждый этап исследовательского процесса. С помощью скилла UX-аналитика с девятью режимами работы команда вела мониторинг всех 32 респондентов на протяжении недели поля: от структурирования отдельной записи до кросс-респондентного сравнения. В него были заложены правила проекта: не додумывать за респондента, различать барьер и проблему, всегда связывать контекст поездки с фактором и частотой. Скилл трекинга поездок заполнял таблицу в Google Sheets и различал новые записи от дополнений к старым. Скилл рекрутера считал квоты и оценивал кандидатов по 25-балльной рубрике. Скилл отбора на интервью работал по 100-балльной системе с волновым принципом. Скилл выделения инсайтов извлекал карточки из нарративов по семишаговому пайплайну с верификацией по сырым данным. Три из этих скиллов - UX-аналитик, портрет респондента и ревью гайда интервью - мы переупаковали в универсальные промпты и выложили в открытый доступ (подробнее - в разделе «Попробуйте на своём проекте»).
Отдельно стоит скилл портрета респондента - с тремя командами: нарративная аналитика, подготовка к интервью, бизнес-статья. Ключевое решение в нём: скилл адаптировался к входным данным, а не к методу исследования. Исследователь говорил «напиши нарратив по респонденту 017», и скилл сам определял, какие данные доступны - только дневник, только транскрипт интервью или оба источника.
Нарративная аналитика
Стандартный выход из анализа дневника - структурированная сводка: паттерны, барьеры, драйверы, хронология поездок. Для ежедневного мониторинга этого достаточно. Но для подготовки к интервью и для финального отчёта нужно другое - понимание человека: как он думает, почему так перемещается, что стоит за цифрами.
Мы определили для этого жанр «нарративная аналитика»: скелет текста строится вокруг механизмов поведения и их причин, а конкретные ситуации и цитаты из дневника дают этим механизмам живой контекст. Вместо хронологического пересказа «день первый, день второй» такой текст отвечает на вопрос: почему этот человек ведёт себя именно так?
Для одного из респондентов, у которого было 177 файлов дневника за неделю и 36 поездок, исследователь с помощью нарративной аналитики обнаружил три режима использования навигации: предварительный просмотр маршрута перед выездом, мониторинг загруженности дорог в процессе поездки и фоновый режим во время рабочих звонков. AI структурировал данные, а исследователь увидел в этой структуре человека - и подготовил восемь конкретных зон для глубинного интервью.
По каждому из 32 респондентов были созданы персональные папки с четырьмя-пятью файлами: нарративная аналитика, экстракция диалогов, зоны для интервью, а после интервью - обогащённый нарратив и бизнес-статья.
Бизнес-статья: перевод поведения на язык продукта
Отдельный артефакт - бизнес-статья по каждому респонденту, в которой поведение конкретного человека соотносится с целями бизнеса: какие функции он использует и почему, какие игнорирует и что стоит за этим решением, где продукт теряет этого пользователя и где мог бы выиграть.
Этот артефакт появился не просто так, подробнее про концепцию “Наша цель – привести бизнес из точки А в точку Б” смотрите в выступлении Михаила Правдина
Исследователь строил бизнес-рекомендации, опираясь на первичный маппинг, который делал AI: сопоставление паттернов из нарратива с целями проекта, заложенными в методологию. Маппинг давал структуру, но выводы формулировал человек - потому что решение «разработать новую функцию» и решение «сделать существующую обнаруживаемой» требуют экспертного суждения о продукте, а не механического сопоставления данных.
Система выделения инсайтов: от историй к числам
Нарративы и бизнес-статьи давали глубину по каждому респонденту. Но для финального отчёта нужен был кросс-респондентный анализ: сколько человек столкнулись с этим барьером, в каких сегментах он встречается, какова его сила влияния.
Для этого мы создали систему выделения инсайтов: восемь файлов по типам (барьеры, драйверы, проблемы, незнание ценности и другие), в каждом - карточки инсайтов с шестью обязательными блоками: контекст, решение и причина, действия респондента, результат, ожидание, значение для продукта. Хранение по типам, а не по респондентам - осознанный выбор: финальный отчёт строится по типам инсайтов, и данные уже в нужной структуре.
Исследователь работал с карточками инсайтов, которые AI предварительно извлекал из нарративов по формализованному пайплайну из семи шагов - с обязательной верификацией каждого инсайта по сырым данным дневника, чтобы в карточку попадали проверенные факты, а не пересказ нарратива. Исследователь оценивал точность классификации, переформулировал выводы, добавлял то, что алгоритм пропустил, и отбрасывал то, что при ближайшем рассмотрении оказывалось артефактом, а не инсайтом.
Сайт как формат подачи результатов
Когда исследование было завершено, мы подготовили подробный PDF-отчёт - как делается обычно. Но быстро поняли, что пользоваться им неудобно. Отчёт длинный, искать конкретный барьер или инсайт по конкретному сегменту - значит листать десятки страниц. Есть оглавление с переходами на нужный раздел, но потом нужно как-то вернуться обратно. Для заказчика, который хочет быстро найти ответ на конкретный вопрос, формат PDF - скорее архив, чем рабочий инструмент.
Руководитель проекта вместе с Claude Code создала веб-сайт - HTML, CSS, JavaScript, защита паролем, деплой на облачный сервер. Структура сайта повторяла логику отчёта, но с навигацией: разделы по сегментам, по типам инсайтов, по респондентам - с возможностью перемещаться между ними без потери контекста. Для этого не привлекались ни программисты, ни дизайнеры - всё сделал тот же тандем руководителя и AI, который работал на протяжении всего проекта. И даже осталось время на творчество: для сайта были созданы иллюстрации.
https://cloud-research.onrender.com/cloud-diaries/index.html Формат подачи результатов исследования. Вся чувствительная информация заменена, контент этого сайта – демонстрационный. Но мы все равно постарались сохранить глубину выводов, чтобы было понятнее, почему в формат PDF объемные результаты ложатся плохо.
Это ещё один пример того, как снятие рутины высвобождает ресурс не только на глубину анализа, но и на форму подачи. Когда не нужно тратить недели на механическую обработку данных, появляется время сделать результат удобным для тех, кто будет им пользоваться.
Попробуйте на своём проекте
В этом проекте мы работали со скиллами Claude Code - текстовыми файлами, которые задают AI последовательность шагов, критерии качества и формат результата. Для нас как для команды, работающей в терминале и с кодом, это удобный формат: скиллы загружаются автоматически, встроены в рабочую среду, умеют обращаться к файлам проекта.
Но мы понимаем, что большинство исследователей и руководителей проектов пользуются AI иначе - через веб-интерфейс ChatGPT, Claude, Gemini или другого ассистента. Для них скилл как формат бесполезен: нечего копировать в папку, не с чем запускать.
Поэтому мы пошли дальше. Из трёх скиллов, созданных для этого проекта, - UX-аналитика, портрета респондента и ревью гайда интервью - мы извлекли методологическое ядро и переупаковали его в тринадцать самостоятельных промптов. Каждый промпт - это готовая инструкция, которую можно вставить в любой LLM и сразу получить структурированный результат, не устанавливая зависимостей и не настраивая среду.
Тринадцать промптов покрывают полный цикл дневникового исследования: от структурирования отдельной записи и ежедневного мониторинга до подготовки к интервью, кросс-респондентного сравнения и финального синтеза. Отдельные промпты посвящены нарративной аналитике, бизнес-статье по респонденту и оценке качества гайда интервью.
Мы убрали привязку к навигации и конкретному заказчику. Таксономия инсайтов, структура портрета, критерии качества - всё это осталось, но стало конфигурируемым. В каждом промпте есть секция «Customize for your project», где можно подставить свой бизнес-контекст, свои исследовательские вопросы и свой формат данных.
Чтобы получить весь playbook промптов, вступите в группу @ai_pravdinm мы выложим все там =)
Что изменилось в итоге
В начале этой статьи мы описали три компромисса, которые закладываются в дизайн любого дневникового исследования: голосовые не расшифровываются, с респондентами не разговаривают, анализируют часть выборки. Мы от этих компромиссов отказались - и вот что получилось.
Голосовые сообщения стали одним из самых ценных источников данных в проекте. Включённое общение с респондентами дало информацию, которая в стандартном дневнике не появляется. Все 32 дневника вошли в анализ - включая тех респондентов, которых не приглашали на глубинное интервью. Система выделения инсайтов позволила провести кросс-респондентный анализ по восьми типам, а нарративная аналитика и бизнес-статьи по каждому респонденту дали заказчику понимание поведения конкретных людей, а не просто набор цифр.
На выходе получился отчёт, который соответствует тому, как исследование задумано методологически, но каким оно обычно не получается из-за ограничений человеческого ресурса.
AI в этом проекте менял роль в зависимости от задачи и роль каждый раз назначал человек. Когда нужно было собирать и расшифровывать дневники, AI работал как исполнитель; когда заполнял таксономию инсайтов по формализованным правилам - как помощник; когда находил паттерны в данных, которые человек потом переводил в рекомендации - как коллега. Но ни одно решение о том, что означает найденный паттерн, какой вопрос задать респонденту и что рекомендовать заказчику, AI не принимал.
Выводы исследования стали сильнее, потому что экспертиза команды была направлена на анализ и критику, а не на обслуживание процесса.
Для руководителей исследовательских команд это означает конкретную арифметику: проект на три недели, четыре человека, 32 респондента, сдан на пять дней раньше дедлайна, при этом 403 часа рутинной работы выполнены AI без потери качества. Не нужно нанимать дополнительных людей и не нужно сокращать выборку - нужно перераспределить задачи между человеком и алгоритмом так, чтобы каждый делал то, в чём сильнее.
AI работает так, как его направляет человек - и в этом проекте мы направили его туда, куда сами бы не добрались.
