Дневниковое исследование — один из самых информативных методов качественного анализа. Респонденты фиксируют поведение в реальном времени, в естественной среде, без эффекта интервью. Но высокая информативность требует больших ресурсов: десятки участников, ежедневные тексты, фото, голосовые и видео. Объём данных заранее известен — и с ним приходится считаться ещё на этапе проектирования.
Поэтому в дизайн традиционного дневникового исследования закладывают три компромисса:
- Голосовые сообщения не расшифровываются — анализ ведётся только по тексту.
- Исследователь не вступает в глубокий диалог с каждым — не хватает ресурсов.
- В анализ включаются не все дневники, а только те, кого пригласили на интервью. Остальные — страховка от отвала.
Это не ошибка и не недостаток квалификации. Двое-трое исследователей физически не могут обработать такой объём и одновременно поддерживать глубокий контакт. Все, кто работал с этим методом, знают эту арифметику.
Мы в Cloud Research столкнулись с ней при исследовании навигационного поведения: как люди используют навигацию на привычных маршрутах, какие привычки формируются, какие барьеры возникают. 32 респондента, неделя поля, команда из четырёх человек — руководитель, два исследователя, рекрутер.
Мы решили не выбирать между масштабом и качеством. Вместо найма новых сотрудников или сокращения выборки мы встроили ИИ в рабочий процесс — с чёткими функциями на каждом этапе. В этой статье — три механизма, которые позволили это реализовать: какие решения мы приняли, какие отвергли и как это повлияло на качество выводов.
Итоговая арифметика проекта
Проект рассчитывался на три недели — от дизайна до финального отчёта. Команда — четыре человека. Отчёт был сдан на пять дней раньше срока.
Вот что стояло за этими сроками:
Мониторинг 32 респондентов (7 дней)
~225 часов
Статус дневников (4–5 прогонов)
Скоринг кандидатов (208 анкет + 60 детальных)
Портрет респондента (24 человека)
Гайд интервью (24 уникальных гайда с общей бизнес-целью) v2.0
~17,5 часа
Источник правды (аудит квот, карта фич, рецепты)
Контроль квот
403 часа — это примерно десять человеко-недель при сорокачасовой рабочей неделе. Для команды из четырёх человек на трёхнедельном проекте это означает, что ИИ взял на себя объём работы, эквивалентный двум-трём дополнительным сотрудникам.
Экономия времени оправдана только при сохранении качества. Вот пять аргументов в пользу того, что качество не пострадало.
Консистентность. ИИ классифицировал инсайты по одной и той же таксономии — от первого до тридцать второго дневника — без дрейфа. В ручном анализе к двадцатому дневнику критерии неизбежно начинают плавать: исследователь устаёт, классификация становится менее строгой. Это известная проблема, не связанная с профессионализмом.
Взаимный контроль ошибок. ИИ выявил ошибки человека: скоринг обнаружил четыре неправильно классифицированных города в квотах рекрутера. Человек контролировал ИИ: алгоритм детекции поездок работал с точностью около 80%, оставшиеся 20% исследователи корректировали вручную. Это не история о безупречном алгоритме — это система, в которой каждый ловит ошибки другого.
Верификация по сырым данным. В пайплайне выделения инсайтов был обязательный шаг: каждая карточка проверялась по исходным записям дневника. В карточку попадали проверенные факты с привязкой к конкретной записи, а не пересказ нарратива. Исследователь проверял и источник, и интерпретацию.
Глубина, которой не было бы. Четыре гипотезы из десяти выросли не из брифа, а из данных — потому что у исследователя был когнитивный ресурс заметить закономерности, не вписывающиеся в заранее заданную структуру. Более трёхсот карточек инсайтов, двадцать кластеров функциональных запросов — в проекте с анализом 12–15 дневников этих цифр было бы примерно вдвое меньше.
Покрытие. Все 32 дневника вошли в анализ. Среди тех, кого в стандартном проекте отсеяли бы как буфер, оказались респонденты с более богатыми и содержательными дневниками, чем у приглашённых на интервью.
Механизм первый: как высвобождение времени дало глубину общения
В стандартном дневниковом проекте исследователь — одновременно логист, архивист, расшифровщик и аналитик. Респондент прислал голосовое — его нужно скачать, прослушать, расшифровать, сохранить. Фото маршрута — то же самое. Видеокружочек — извлечь аудио, расшифровать, сохранить. Умножить на 32 человека и каждый день поля. Механическая работа съедает часы, которые могли бы уйти на содержательное общение.
Но рутина — только верхушка проблемы. Даже если исследователь найдёт время на диалог, респондент ответит — и даст много информации, не всю по теме. Как обработать этот неструктурированный поток? Неизвестно. Поэтому исследователи осознанно ограничивают глубину контакта — не из лени, а потому что понимают: с таким объёмом не справиться.
Что мы построили
Мы автоматизировали сбор и обработку дневников. Вместе с ИИ-ассистентом в терминале (Claude Code) руководитель проекта — без опыта в программировании — за один день написала Telegram-бота на Python и FastAPI, задеплоила его на облачный сервер и настроила весь пайплайн.
Бот получал сообщения из 32 чатов через webhook в реальном времени и сохранял на Google Drive в структурированные папки: по респондентам, внутри — по датам. Текст — в Markdown, фото — как есть, голосовые и видеокружочки — автоматически транскрибировались и сохранялись с расшифровкой рядом с оригиналом.
За этим коротким описанием — несколько технических решений, каждое из которых потребовало выбора.
Первая развилка: как получать сообщения. Telegram API не позволяет боту читать историю чата — он видит только то, что приходит в реальном времени. Единственный вариант — webhook. Если сервер падает, сообщения теряются (Telegram повторяет доставку, но не бесконечно). Мы приняли этот риск — и на шестой день он реализовался: OAuth-токен протух из-за тестового режима Google Cloud Console. 224 сообщения застряли в очереди. Починили за 20 минут — перегенерировали токен и опубликовали consent screen, чтобы он стал бессрочным. Ни одно сообщение не потерялось.
Вторая развилка: как сохранять на Google Drive. Начали с сервисного аккаунта — стандартный подход. Но он видит только «Мой диск», а Google Drive for Desktop синхронизирует файлы в раздел «Компьютеры». Это разные пространства. Пришлось перейти на OAuth-доступ с refresh-токеном — менее элегантно, зато файлы оказались там, где их ждут.
Третья развилка: формат файлов. Первая версия бота сохраняла записи в JSON. Руководитель посмотрела и сказала: исследователи не будут читать JSON. Переделали в текстовый формат. Руководитель снова: давайте Markdown — с ним удобнее. Переделали. Три итерации за день — и формат стал удобен и человеку, и последующей обработке.
Ещё одна важная деталь: в Telegram по умолчанию включён Privacy Mode — бот видит только команды (сообщения с «/»), а обычные игнорирует. Если не отключить это в BotFather, бот не увидит дневниковые записи. На это ушло 30 секунд, но без этого ничего бы не работало.
Что мы сделали с освободившимся временем
Когда пайплайн заработал, исследователи перестали заниматься архивной работой. Им больше не нужно было скачивать, переименовывать, прослушивать, расшифровывать, раскладывать по папкам. Всё происходило автоматически.
Но освобождение времени само по себе ничего не даёт. Его можно потратить на отчётность или подготовку к следующему проекту. Руководитель приняла осознанное решение: время, освободившееся от рутины, направить на включённое общение с каждым респондентом. Это была не случайность, а управленческая установка.
Что это дало качеству
Исследователи начали задавать точные уточняющие вопросы — не «расскажите подробнее», а «что вы имели в виду?», «почему в этот раз поступили иначе?». Респонденты отвечали развёрнуто, часто голосом — потому что так быстрее и естественнее.
Исследователи работали не вслепую. Параллельно со сбором данных мы строили таблицу трекинга поездок, где каждая поездка раскладывалась по таксономии: барьер, драйвер, незнание ценности, проблема — с контекстом и силой влияния. ИИ понимал, где респондент описывает новую поездку, а где отвечает на вопрос по предыдущей — даже если между ними было несколько сообщений.
Благодаря этому исследователь мог в любой момент отфильтровать таблицу: какие барьеры уже зафиксированы, какие зоны не покрыты, какие вопросы стоит задать. Исследователь сам решал, что спросить, но мог подсмотреть предложение в таблице. Это сочетание экспертизы и аналитической подсказки дало глубину, невозможную в обычном проекте. Анализ начинался не после поля — а прямо в процессе.
Самым неожиданным стало другое. Голосовые сообщения, которые в обычных проектах считаются проблемой (их нужно расшифровывать), у нас стали преимуществом. Человек, рассуждающий голосом, менее структурирован, но выдаёт нюансы, оговорки, эмоции — именно то, что ценно для качественного исследования. В обычном проекте исследователи не поощряют голосовые, потому что знают: расшифровка съест время. У нас она была автоматической — и голосовые стали источником данных, которых в стандартном дневнике просто нет.
Цепочка выстроилась: автоматизация сняла рутину, руководитель направила время на общение, исследователи стали глубже общаться, респонденты давали больше контекста, часто голосом, голосовые автоматически расшифровывались, а объём неструктурированных данных перестал пугать, потому что ИИ помогал его обрабатывать. Каждое звено зависело от предыдущего.
В цифрах: ежедневный мониторинг 32 респондентов вручную занял бы около часа на каждого — 224 часа за неделю на двух исследователей. С автоматизацией — около двадцати минут в день. Разница — порядка 220 часов, которые команда потратила на содержательную работу: уточняющие вопросы, анализ ответов, подготовку к интервью.
Без такой системы исследователь осознанно ограничивает глубину контакта — потому что знает: не справится с обработкой ответов. У нас автоматизация сняла это ограничение, а управленческое решение определило, на что потратить освободившееся время.
Механизм второй: масштаб без потерь
В типичном дневниковом проекте закладывается отсев. Запускают 20 дневников, на интервью приглашают 12–15. Остальные — буфер на случай отвала. Те, кто не попал на интервью, обычно выпадают из анализа. Частично — из-за нехватки ресурсов, частично — потому что не все респонденты активны. Выбор делается в пользу глубины по меньшему числу, а не охвата всех.
В нашем проекте исследователи, освобождённые от рутины, могли уделять время и тем, кто раскрывался медленнее. Задать дополнительный вопрос, переформулировать, предложить рассказать голосом. Молчуны переставали быть балластом — они становились респондентами, которым нужно чуть больше внимания.
Мы построили систему, которая позволила не делать этот выбор. Она заработала ещё до старта поля — с отбора кандидатов.
Скоринг кандидатов: формализация вместо интуиции
В обычном проекте рекрутер оценивает кандидатов по ощущению. При потоке в десятки человек критерии плывут — первых оцениваешь строго, к двадцатому устаёшь. Обоснование живёт в голове, и на вопрос «почему этого взяли?» ответить нечего, кроме «экспертного суждения».
Мы разработали 25-балльную рубрику из восьми критериев, привязанных к задачам исследования: география, поведенческий профиль, частота контакта, разнообразие ситуаций, используемые инструменты, вовлечённость. Ключевое решение: ситуативный пользователь (иногда включает навигацию, иногда нет) получал максимальный балл — именно у него самые интересные переключения и триггеры. «Всегда включает» — предсказуемый, «никогда» — мало материала, а «примерно в половине случаев» — исследовательское золото.
Скрипт на Python читал анкеты, применял критерии, проверял жёсткие скринеры и записывал результат в таблицу рекрутера: балл, рекомендацию, текстовое обоснование с разбивкой по критериям. Рекрутер видела конкретные флаги и знала, что уточнить при звонке. Скоринг поймал ошибки, которые человек пропустил: два кандидата из городов-миллионников были записаны в сегмент «крупный город», хотя по квотам относились к «средним». Одна такая ошибка — сломанная квота.
При этом скоринг не заменял живую экспертизу. Скрипт не слышит интонацию, не чувствует мотивацию. Рекрутер звонила кандидатам из зон «рекомендован» и «условно» и проверяла именно это. Финальное решение — сумма: формализованный балл плюс впечатление от разговора.
Каскад поля: каждое звено питает следующее
Когда выборка была сформирована и поле началось, заработал каскад из четырёх звеньев, где каждый слой создавал контекст для следующего.
Первое звено — ежедневный мониторинг. По каждому из 32 респондентов ежедневно генерировалась аналитическая карточка: выявленные паттерны, барьеры, драйверы, расхождения между заявленным и реальным поведением, конкретные вопросы для интервью.
Мы рассматривали три варианта генерации. Лёгкая модель на сервере — отвергли: выводы слишком поверхностные. API сильной модели на сервере — отвергли: избыточно и дорого. Выбрали третий путь: сильная языковая модель на компьютере исследователя, запуск вручную по команде «обнови мониторинг». Не полностью автоматически, зато максимальное качество и полный контроль — человек видит результат и может поправить.
Карточки публиковались на защищённой веб-странице. Команда и заказчик видели живую аналитическую картину по каждому респонденту без промежуточных отчётов и встреч.
Второе звено — трекинг поездок. Каждая поездка становилась строкой в Google Sheets: 18 колонок описания (маршрут, цель, контекст, использование навигации, полный текст записи) и 8 колонок аналитического слоя (тип инсайта, формулировка, сила влияния, затронутый функционал, вопрос к интервью). Таблица работала как аналитический инструмент для исследователей прямо в поле.
Почему Google Sheets, а не локальный файл — совместный доступ: исследователи фильтровали данные, оставляли комментарии, которые обрабатывались при следующем обновлении. Лейаут таблицы прошёл итерации: первая версия размещала портрет респондента сверху, занимая десять строк. Переделали в компактный sidebar слева, закреплённый при прокрутке: портрет всегда виден, таблица начинается с первой строки.
Больше ста поездок в день по 26 колонок — заполнять вручную физически невозможно. ИИ читал сырые записи, разбирал на отдельные поездки, заполнял все колонки, включая аналитический слой по таксономии. При этом он различал, где респондент описывает новую поездку, а где отвечает на вчерашний вопрос — и дополнял существующую строку, а не создавал дубликат.
Третье звено — формализованный отбор на интервью. Кого из 32 позвать на глубинное интервью — решение по 100-балльной системе с пятью измерениями: активность, разнообразие поездок, качество комментариев (рефлексия, скриншоты, голосовые), исследовательская ценность (инсайты, барьеры, расхождения) и потенциал для 70-минутного разговора. Принципиальное решение: исследовательская ценность весила столько же, сколько активность — три глубокие записи ценнее двадцати формальных отметок «доехала нормально».
Четвёртое звено — digital interview для тех, кто не попал на основное интервью.
Здесь каскад замкнулся. По каждому респонденту, не отобранному на интервью, у нас уже была аналитическая карточка с паттернами и пробелами, таблица трекинга со всеми поездками и выявленными вопросами, и неделя включённого общения из первого механизма. Это давало контекст для целенаправленного диалога.
Исследователи задавали в чатах конкретные уточнения по конкретным поездкам — не общие «расскажите подробнее», а точечные: «вы упоминали, что в такой-то ситуации не включили навигатор — почему именно в этот раз?». Респонденты отвечали развёрнуто, часто голосовыми. Получался целенаправленный диалог из пяти-десяти обменов по ключевым зонам.
Мы отдаём себе отчёт: это не 70-минутное глубинное интервью. Нет свободного потока, нет возможности развернуть неожиданную тему, нет невербальных сигналов. Но альтернатива — не «провести полноценное интервью», а «выбросить данные». Digital interview позволил сохранить эти дневники в анализе.
Что это дало качеству
В итоге в анализ вошли все 32 дневника, включая тех, кто не попал на глубинное интервью. Информация по ним оказалась не менее ценной: у нескольких дневники были богаче и содержательнее, чем у приглашённых на основной разговор.
В типичном проекте аналогичного масштаба в анализ попадают 12–15 дневников из 20. Остальные — буфер, данные которого теряются. У нас — все 32. Ручная проверка статусов дневников заняла бы порядка 72 часов — с автоматизацией это занимало минуты. Скоринг кандидатов сэкономил ещё около 37 часов и выловил четыре ошибки классификации в квотах, которые рекрутер пропустил.
Стандартный компромисс — анализировать часть выборки, а остальное списать — удалось снять, потому что каждый слой системы создавал контекст для следующего: мониторинг давал картину по каждому респонденту, трекинг — структуру по каждой поездке, отбор — обоснование для решений, а digital interview — возможность сохранить в анализе тех, кто не прошёл на основное интервью.
Механизм третий: как мы разделили работу между ИИ и исследователем
Анализ качественного исследования — это ремесло. Исследователь читает данные, выделяет фрагмент, классифицирует: это барьер или просто жалоба? Это привычка или осознанная стратегия? Насколько сильное влияние? Какой функционал затронут? Какой вопрос стоит задать на интервью?
В нашем проекте таксономия включала восемь типов — барьер, проблема, драйвер, незнание ценности, ценность, возможность, расхождение декларативного и реального поведения, пользовательский запрос — и в каждом типе свои обязательные поля: причина, контекст, сила влияния, триггер, источник. 32 дневника, обработанные вручную — это недели кропотливой работы. И к двадцатому дневнику внимание проседает, классификация дрейфует, формулировки шаблоннее. Монотонная работа утомляет любого — и это не связано с профессионализмом.
Почему мы не отдали ИИ весь анализ
Альтернативный подход напрашивался: пусть ИИ классифицирует и интерпретирует, а исследователь вычитает выводы. Мы сознательно не пошли этим путём. Если человек не проходит через данные сам — не формирует суждения, не спорит с классификацией, не замечает то, что не ложится в таксономию — он теряет контакт с материалом. Вычитка чужих выводов принципиально отличается от формирования своих: в первом случае ты проверяешь логику, во втором — видишь, что за ней стоит.
Вместо этого мы разделили работу по природе задач. Заполнение инсайтов по таксономии — структурированная задача. Есть данные, структура, правила. ИИ получал данные и структуру — и раскладывал по полям.
Человек получал заполненные карточки — и начинал другую работу. Перепроверял: действительно ли это барьер, или респондент просто пожаловался? Задавал провокационные вопросы: может, это не барьер, а привычка, делающая навигацию ненужной? Сопоставлял с другими: трое описывают похожее — это паттерн или совпадение?
Это два разных типа когнитивной нагрузки. Классификация по таксономии — монотонная работа, на которой человек устаёт. Критический анализ — интеллектуальная работа, на которой исследователь сильнее. ИИ выдаёт одинаковое качество на тридцать втором дневнике, а исследователь тратит свою экспертизу там, где она нужна.
Два примера, как это работало
Карта функциональных запросов. ИИ обработал дневники всех респондентов, извлёк упоминания функционала с контекстом, сгруппировал в кластеры. К концу поля — 20 кластеров по количеству упоминаний.
Среди них ИИ выделил мета-паттерн: часть запросов на «новый функционал» — на самом деле незнание существующего. Респондент делает скриншоты перед поездкой, потому что не знает, что маршрут можно сохранить. Другой не пользуется слоем карты, потому что не подозревает о нём — а обнаружив, начинает пользоваться регулярно. Закономерность нашёл алгоритм.
Но перевод в рекомендацию — работа исследователя. Разница между «разработать новую функцию» и «сделать существующую обнаруживаемой» принципиальна: первое — месяцы разработки, второе — изменения в интерфейсе и коммуникации. Это экспертное суждение, которое алгоритм сделать не может.
Расхождение декларативного и реального поведения. ИИ заполнил шесть гипотез на основе дневниковых данных — каждая с доказательной базой. Исследователь, просматривая хронологию поездок одного участника, заметил расхождение: в анкете человек написал «использую навигацию примерно в половине поездок», а по дневнику — около 7%. Это оказался не единичный случай: декларируемые «примерно половина» превращались в реальные 25–30%.
Отсюда родилась седьмая гипотеза — о системном расхождении между тем, что люди говорят, и тем, что делают. ИИ не мог её сформулировать: у него нет интуиции, которая заставляет сравнить анкету с дневником. Но без ИИ, заполнившего первые шесть гипотез, у исследователя не было бы времени и ресурса заметить седьмую.
Что это дало качеству
В этом проекте ИИ и исследователь делали разную работу, каждый — ту, в которой сильнее. ИИ брал на себя структурную классификацию по таксономии — восемь типов, обязательные поля, сотни записей с одинаковым качеством. Исследователь занимался тем, что невозможно формализовать: критическим взглядом, провокационными вопросами, обнаружением расхождений.
Масштаб: более трёхсот карточек инсайтов, двадцать кластеров функциональных запросов, десять гипотез — из которых четыре выросли не из брифа, а из данных. В проекте без ИИ-ассистента, где анализируют 12–15 дневников и где классификация дрейфует, этих цифр не было бы — не потому что исследователи хуже, а потому что человеческого ресурса не хватает.
В результате анализ стал глубже: экспертиза исследователя была направлена туда, где она незаменима, а не расходовалась на раскладывание данных по полям.
От анализа к синтезу: как команда выстроила исследовательский конвейер
Три механизма — про сбор данных, масштаб обработки и разделение труда при анализе. Но между анализом и финальным отчётом лежит синтез: превращение сотен инсайтов в связную картину. На этом этапе команда использовала тот же инструмент — Claude Code — но уже не для сбора, а для аналитической работы. Руководитель и исследователи вели весь синтез — от мониторинга до нарративных портретов и бизнес-статей — опираясь на ИИ как на инструмент, который берёт на себя структурную часть, пока человек занимается содержательной.
Как мы создавали инструменты для ИИ
В Claude Code есть механизм скиллов — текстовые файлы с детальными инструкциями, которые ИИ загружает перед задачей. Скилл описывает формализуемую часть экспертизы: шаги, критерии, ошибки, примеры. То, что можно передать, не потеряв точности. ИИ работает по инструкции. Но у экспертизы есть и неформализуемая часть — интуиция, критический взгляд, способность увидеть то, чего нет в схеме — и она остаётся за человеком.
В этом проекте мы написали несколько скиллов под задачи исследования.
У нас была важная предпосылка. В Cloud Research на протяжении лет мы разрабатывали внутренние стандарты качества — для методологии, дизайна, анализа и синтеза. Мы фиксировали, что работает, как отличить качественный инсайт от поверхностного, как должна выглядеть хорошая карточка барьера. Эти стандарты — по сути формулы: они не допускают двоякого толкования.
Когда мы создавали скиллы для ИИ, мы передавали ему именно эти стандарты — с примерами из реальных проектов. Вот карточка барьера с причиной, контекстом и силой влияния — так выглядит качественная работа; вот «не включает навигацию» без объяснения — и почему этого недостаточно. ИИ принимает такие стандарты буквально и работает по ним с одинаковой точностью на первом и на тридцать втором дневнике. Человек-исследователь, даже отлично знающий стандарты, может недосмотреть, устать, прочитать невнимательно. Стандарты — это именно та часть, где точность алгоритма превосходит человеческую.
А человек освобождается для того, что стандартами не покрывается: быть любознательным, задавать неожиданные вопросы, замечать то, что не вписывается в таксономию, сопереживать респонденту, ставить провокационные гипотезы. Всё то, ради чего человек-исследователь и нужен.
Процесс создания каждого скилла проходил через три этапа. Сначала — диалог: руководитель объясняла ИИ, как она сама решает задачу, на что обращает внимание. По сути, это передача исследовательского мышления. Затем — проектирование: структура, режимы, обязательные поля, стандарты с примерами. Затем — стресс-тесты: намеренные попытки сломать, подать противоречивые данные, проверить, как скилл справляется с пограничными случаями.
За проект мы создали около десяти скиллов — под каждый этап. С помощью скилла UX-аналитика с девятью режимами команда вела мониторинг всех 32 респондентов. Скилл трекинга поездок заполнял таблицу в Google Sheets. Скилл рекрутера считал квоты и оценивал кандидатов по 25-балльной рубрике. Скилл отбора на интервью работал по 100-балльной системе. Скилл выделения инсайтов извлекал карточки по семишаговому пайплайну с верификацией по сырым данным. Три из этих скиллов — UX-аналитик, портрет респондента и ревью гайда интервью — мы переупаковали в универсальные промпты и выложили в открытый доступ.
Отдельно стоит скилл портрета респондента — с тремя командами: нарративная аналитика, подготовка к интервью, бизнес-статья. Ключевое решение: скилл адаптировался к входным данным, а не к методу. Исследователь говорил «напиши нарратив по респонденту 017», и скилл сам определял, какие данные доступны — только дневник, только транскрипт или оба.
Нарративная аналитика
Стандартный выход из анализа дневника — структурированная сводка: паттерны, барьеры, драйверы, хронология. Для мониторинга этого достаточно. Но для подготовки к интервью и отчёта нужно понимание человека: как он думает, почему так перемещается, что стоит за цифрами.
Мы определили жанр «нарративная аналитика»: скелет текста строится вокруг механизмов поведения и их причин, а конкретные ситуации и цитаты дают им живой контекст. Вместо хронологического пересказа такой текст отвечает на вопрос: почему этот человек ведёт себя именно так?
Для одного из респондентов, у которого было 177 файлов дневника за неделю и 36 поездок, исследователь с помощью нарративной аналитики обнаружил три режима использования навигации: предварительный просмотр маршрута перед выездом, мониторинг загруженности дорог в процессе поездки и фоновый режим во время рабочих звонков. ИИ структурировал данные, а исследователь увидел в этой структуре человека — и подготовил восемь конкретных зон для глубинного интервью.
По каждому из 32 респондентов были созданы персональные папки с четырьмя-пятью файлами: нарративная аналитика, экстракция диалогов, зоны для интервью, а после интервью — обогащённый нарратив и бизнес-статья.
Бизнес-статья: перевод поведения на язык продукта
Отдельный артефакт — бизнес-статья по каждому респонденту, в которой поведение конкретного человека соотносится с целями бизнеса: какие функции он использует и почему, какие игнорирует и что стоит за этим, где продукт теряет этого пользователя и где мог бы выиграть.
Исследователь строил бизнес-рекомендации, опираясь на первичный маппинг, который делал ИИ: сопоставление паттернов из нарратива с целями проекта. Маппинг давал структуру, но выводы формулировал человек — потому что решение «разработать новую функцию» и решение «сделать существующую обнаруживаемой» требуют экспертного суждения о продукте.
Система выделения инсайтов: от историй к числам
Нарративы и бизнес-статьи давали глубину по каждому респонденту. Но для финального отчёта нужен кросс-респондентный анализ: сколько человек столкнулись с этим барьером, в каких сегментах он встречается, какова его сила влияния.
Для этого мы создали систему выделения инсайтов: восемь файлов по типам (барьеры, драйверы, проблемы и другие), в каждом — карточки инсайтов с шестью обязательными блоками: контекст, решение и причина, действия респондента, результат, ожидание, значение для продукта. Хранение по типам, а не по респондентам — осознанный выбор: финальный отчёт строится по типам инсайтов, и данные уже в нужной структуре.
Исследователь работал с карточками, которые ИИ предварительно извлекал из нарративов по семишаговому пайплайну — с обязательной верификацией каждого инсайта по сырым данным. Исследователь оценивал точность, переформулировал выводы, добавлял то, что алгоритм пропустил, и отбрасывал артефакты.
Сайт как формат подачи результатов
Когда исследование было завершено, мы подготовили PDF-отчёт — как обычно. Но быстро поняли, что пользоваться им неудобно. Отчёт длинный, искать конкретный барьер — значит листать десятки страниц. Есть оглавление, но потом нужно как-то вернуться обратно. Для заказчика, который хочет быстро найти ответ, PDF — скорее архив, чем рабочий инструмент.
Руководитель проекта вместе с Claude Code создала веб-сайт — HTML, CSS, JavaScript, защита паролём, деплой на облачный сервер. Структура сайта повторяла логику отчёта, но с навигацией: разделы по сегментам, по типам инсайтов, по респондентам — с возможностью перемещаться между ними без потери контекста. Для этого не привлекались ни программисты, ни дизайнеры — всё сделал тот же тандем руководителя и ИИ. И даже осталось время на творчество: для сайта были созданы иллюстрации.
Это ещё один пример того, как снятие рутины высвобождает ресурс не только на глубину анализа, но и на форму подачи. Когда не нужно тратить недели на механическую обработку данных, появляется время сделать результат удобным для тех, кто будет им пользоваться.
Что изменилось в итоге
В начале статьи мы описали три компромисса, закладываемых в дизайн любого дневникового исследования: голосовые не расшифровываются, с респондентами не разговаривают, анализируют часть выборки. Мы от этих компромиссов отказались — и вот что получилось.
Голосовые сообщения стали одним из самых ценных источников данных. Включённое общение дало информацию, которой в стандартном дневнике нет. Все 32 дневника вошли в анализ — включая тех, кого не приглашали на глубинное интервью. Система выделения инсайтов позволила провести кросс-респондентный анализ по восьми типам, а нарративная аналитика и бизнес-статьи по каждому респонденту дали заказчику понимание поведения конкретных людей, а не просто набор цифр.
На выходе получился отчёт, который соответствует тому, как исследование задумано методологически, но каким оно обычно не получается из-за ограничений человеческого ресурса.
ИИ в этом проекте менял роль в зависимости от задачи: когда нужно было собирать и расшифровывать дневники — как исполнитель; когда заполнял таксономию — как помощник; когда находил паттерны в данных — как коллега. Но ни одно решение о том, что означает найденный паттерн, какой вопрос задать респонденту и что рекомендовать заказчику, ИИ не принимал.
Выводы стали сильнее, потому что экспертиза команды была направлена на анализ и критику, а не на обслуживание процесса.
Для руководителей это означает конкретную арифметику: проект на три недели, четыре человека, 32 респондента, сдан на пять дней раньше. 403 часа рутинной работы выполнены ИИ без потери качества. Не нужно нанимать дополнительных людей и не нужно сокращать выборку — нужно перераспределить задачи между человеком и алгоритмом так, чтобы каждый делал то, в чём сильнее.
ИИ работает так, как его направляет человек — и в этом проекте мы направили его туда, куда сами бы не добрались.