Атомарные исследования: как перестать платить за ресёрч дважды

Атомарные исследования (atomic research) — способ хранить результаты исследований не отчётами, а отдельными фактами с источником, датой и связями с инсайтами и решениями. За исследование перестают платить дважды, потому что перед новым заказом команда ищет готовые факты по сегменту и теме, а не вспоминает, было ли похожее. Связи показывают, на чём держится каждое решение и что пересмотреть, когда новый факт опроверг старый.

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

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

Что такое атомарные исследования

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

Даниэль Пидкок в статье «Atomic UX Research» описывает слои фразами, которые складываются в одно предложение:

Слой	Фраза Пидкока	Что хранится	Пример
Эксперимент (Experiment)	«Мы сделали это…»	Что, когда, с кем и каким методом исследовали	12 интервью с администраторами клиентов, март
Факт (Fact)	«…и выяснили вот что…»	Одно наблюдение без интерпретации: цитата, число, поведение	«Отчёт для финдиректора я каждый месяц собираю вручную в Excel»
Инсайт (Insight)	«…это наводит нас на мысль…»	Интерпретация, опирающаяся на один или несколько фактов	Встроенные отчёты не закрывают задачу отчётности перед финансами
Вывод (Conclusion)	«…поэтому мы сделаем вот что»	Решение или рекомендация со ссылкой на инсайты	Сделать выгрузку в формате, который принимает финансовый отдел

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

Откуда метод: Пидкок и Шэрон

Две похожие идеи появились почти одновременно: User Interviews называет модели Шэрона и Пидкока разработанными параллельно.

Томер Шэрон в WeWork построил систему Polaris. В статье «Democratizing UX» (январь 2017) он описывает её единицу — nugget: наблюдение (что мы узнали), доказательство (аудио- или видеофрагмент, где пользователь своими словами описывает опыт, или фото) и теги для нарезки данных. Создавать «наггеты» мог любой сотрудник WeWork, а не только исследователи, — почему это важно, видно по четвёртой проблеме ниже.

Даниэль Пидкок предложил четырёхслойную модель «эксперимент → факт → инсайт → вывод» и описал её в статье для блога Marvel; запись его доклада на UX Brighton 2018 есть у User Interviews. Он один из основателей сервиса для исследовательских репозиториев Glean.ly. Обе модели вдохновлены atomic design — подходом, который собирает интерфейсы из мелких переиспользуемых частей.

Разница в акцентах. У Шэрона упор на доказательство и теги, чтобы находить наблюдения. У Пидкока — на связи между слоями, чтобы видеть, на чём держится вывод.

Почему руководителю это важно: исследования, за которые платят дважды

Атомарные исследования лечат не плохие исследования, а их короткую жизнь: отчёт отвечает на вопрос одного проекта и умирает вместе с ним.

Шэрон в статье про Polaris называет четыре проблемы, знакомые любой продуктовой компании:

Плохая исследовательская память. Исследователи не помнят, какие исследования проводили три года назад.
Никто не сводит данные вместе. Каждая команда копит свою кучу материалов, общей картины нет.
Отчёты слишком узкие. Они сосредоточены на том, что нашли в одном исследовании, и недостаточно дробные, чтобы пригодиться в будущем.
Диктатура исследователей. Делать выводы из исследований «разрешено» только исследователям. Шэрон называет это самой большой проблемой: командам с продуктовыми идеями нужен исследователь, чтобы получить знание о пользователях.

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

Есть и вторая цена, менее заметная. Документ, который никто не читает, создаёт иллюзию, что решение обосновано. Это та же механика, что и в ловушке тяжёлого ТЗ: объём текста подменяет ясность.

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

Цепочка «эксперимент → факт → инсайт → вывод»: трассируемость решений

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

Это даёт три управленческие возможности:

Проверить обоснование. Открыть решение «делаем выгрузку для финансов» и увидеть: оно стоит на двух инсайтах, а те — на семи фактах из трёх разных исследований.
Найти решения под угрозой. Новое исследование опровергло факт — система показывает все инсайты и решения, которые на него опирались. Без такой связи опровергнутый факт тихо живёт в чужих презентациях.
Увидеть слабые опоры. Решение на одном инсайте, а инсайт на одной цитате одного клиента — это гипотеза, а не знание. Её стоит проверить до того, как вкладывать квартал разработки.

Второй пункт меняет культуру: опровержение становится рутинной операцией «обновить связи», а не спором о том, кто был прав. Это прямое противоядие от confirmation bias в данных, когда команда месяцами «валидирует» то, во что уже верит.

Шаблоны записей: факт, инсайт, решение

Атомарная база работает, только если у каждой записи одинаковый набор полей. Ниже минимальный шаблон факта. Его можно перенести в таблицу, Notion, Airtable или специализированный инструмент без изменений.

Поле	Что писать	Пример
ID	Уникальный номер, на который ссылаются инсайты	F-0142
Факт	Одно наблюдение, без интерпретации, одной-двумя фразами	Администратор ежемесячно вручную собирает отчёт для финдиректора в Excel
Доказательство	Цитата, ссылка на запись, скриншот, выгрузка	Ссылка на фрагмент записи интервью, 14:20
Источник	Эксперимент, из которого факт, со ссылкой	E-031 «Интервью с администраторами, март»
Дата	Когда наблюдение получено, а не когда записано	2026-03-12
Метод	Интервью, опрос, аналитика, юзабилити-тест, поддержка, продажи	Глубинное интервью
Сегмент	Кто это сказал или сделал	Клиенты среднего размера, роль — администратор
Сила доказательства	Уровень по шкале (см. ниже)	Повторено
Связи	Инсайты, которые опираются на факт	I-027, I-031
Статус	`<актуален / опровергнут фактом F-…>`	Актуален
Автор записи	Кто внёс, к кому идти с вопросом	Исследователь продукта
Теги	Тема, этап пути клиента, фича	отчётность, финансы, экспорт

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

Метод держится на связях, поэтому у инсайта и решения тоже есть свои записи. Скопируйте блок и замените поля в угловых скобках:

ИНСАЙТ
ID:              I-<№>
Формулировка:    <интерпретация одной фразой>
Опирается на:    <F-…, F-…>
Уровень:         <не выше, чем у самого слабого факта под ним>
Статус:          <актуален / требует пересмотра>
Владелец:        <кто отвечает за формулировку>

РЕШЕНИЕ
ID:              D-<№>
Решение:         <что делаем или не делаем>
Опирается на:    <I-…, I-…>
Цена ошибки:     <что потеряем, если инсайты неверны>
Дата:            <когда принято>
Статус:          <в силе / требует пересмотра>
Кто принял:      <роль или имя>

Когда факт получает статус «опровергнут», все инсайты со ссылкой на него переходят в «требует пересмотра», а за ними — решения. Именно эта цепочка статусов работает в примере ниже.

Уровни доказательности: сколько стоит каждый факт

Не все факты весят одинаково. Цитата одного клиента и поведение тысячи пользователей в аналитике не должны лежать в базе с одним статусом.

Совет статьи: завести короткую шкалу и ставить уровень каждому факту и инсайту. Например:

Уровень	Что значит	На что можно опираться
Проверено (verified)	Подтверждено наблюдаемым поведением или данными, источник доступен	Решения с высокой ценой ошибки
Повторено (replicated)	Наблюдалось независимо в нескольких исследованиях или сегментах	Приоритизация, планирование квартала
Заявление (claim)	Сказано одним или несколькими людьми, не подтверждено поведением	Повод для проверки, не для запуска
Гипотеза (hypothesis)	Предположение команды, пока без фактов	Только как кандидат в эксперимент

Названия и число уровней — договорённость команды, а не стандарт. Важнее, чтобы уровень у инсайта не мог быть выше, чем у фактов под ним. Тот же принцип используют инструменты репозиториев: Glean.ly, например, считает для инсайта показатель уверенности по типу, возрасту и количеству доказательств.

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

Как начать без покупки инструмента: пошаговый план

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

Создайте четыре листа или базы: «Эксперименты», «Факты», «Инсайты», «Решения». В Notion связи делаются полем relation, в таблице — колонкой со списком ID.
Зафиксируйте шаблоны факта, инсайта и решения из раздела выше и шкалу доказательности. Не больше 10–12 полей, иначе заполнять перестанут.
Возьмите одно текущее решение, по которому идёт спор или подготовка к запуску. Не пытайтесь оцифровать архив целиком.
Разберите под него 2–3 последних исследования. Выпишите факты, отдельно — инсайты, свяжите их. На этом шаге обычно выясняется, что часть «инсайтов» в отчётах на самом деле факты, а часть — мнения без опоры.
Запишите решение со ссылками на инсайты. Решение без ссылок в базу не принимается.
Назначьте владельца базы. Это не обязательно исследователь, но у базы должен быть человек, который следит за полями и связями.
Введите правило для новых исследований: результат сдаётся записями в базе, презентация — по желанию и со ссылками на ID.
Через месяц проверьте использование: сколько раз база помогла ответить на вопрос без нового исследования. Если ни разу — упрощайте шаблон или меняйте место хранения.

Архив старых отчётов переносите только по запросу: оцифровка целиком редко окупается.

Пример: атомарная база в B2B SaaS

Пример условный, компания и ситуация придуманы для иллюстрации.

Компания делает SaaS для управления складом. Продакт-директор готовит квартальный план, и команда предлагает строить мобильное приложение для кладовщиков. Обоснование — «клиенты много раз просили».

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

Дальше видно то, чего не видно в презентации:

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

Новый факт противоречит старому инсайту, и база помечает инсайт и решение как «требует пересмотра». Вместо спора на планировании у руководителя конкретный вопрос: что мы знаем о поведении кладовщиков, а что — только со слов их начальников.

Атомарные факты как формат базы знаний для RAG и AI-агентов

Корпоративная база знаний для LLM обычно строится через RAG (retrieval-augmented generation): модель получает вопрос, система находит подходящие фрагменты документов и подаёт их модели как контекст. Качество ответа сильно зависит от того, какие фрагменты попали в контекст.

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

Атомарная запись решает это по построению:

Одна запись — одна мысль. Её не нужно резать, она и есть готовый фрагмент для поиска.
Метаданные встроены. Дата, метод, сегмент и уровень доказательности позволяют фильтровать до поиска: например, отдавать агенту только факты не старше года и не ниже уровня «повторено».
Источник всегда рядом. Агент может процитировать ID факта и ссылку на запись интервью, а человек — проверить ответ за минуту.
Связи дают рассуждение. Агент видит не только факт, но и инсайты, которые на нём построены, и решения, которые из них выросли. Это позволяет спрашивать «на чём основано решение X» и «какие решения затронет этот новый факт».

Если в компании планируют внутреннего AI-ассистента «по нашим исследованиям», начинать стоит не с выбора модели, а с формата знаний. Ассистент поверх папки с презентациями будет пересказывать презентации — без указания, насколько каждому утверждению можно верить.

Для сверки конкурирующих объяснений по фактам из базы подходит анализ конкурирующих гипотез: атомарные факты ложатся в его матрицу «гипотезы × доказательства» почти без доработки. А если исследование собирает ИИ по открытым источникам, как STORM, проверенные ссылки удобно сразу сохранять атомами.

Когда атомарные исследования не нужны: ограничения метода

У метода есть понятная цена и известная критика.

Мало исследований. Если команда проводит пару исследований в год и они не пересекаются по темам, база не окупит усилий на ведение.
Потеря контекста. Критики называют дробление на факты «упрощением» находок: цитата без истории клиента теряет смысл. Пидкок отвечает, что хорошая атомарная база несёт столько же контекста, сколько отчёт, — но только если в записи есть ссылка на исходник и сегмент.
Нагрузка на команду. Разметка каждого исследования добавляет работу и может тормозить быстрые итерации. Если нет владельца, теги расползаются, и поиск перестаёт работать.
Количественные данные. Результаты A/B-тестов удобнее хранить как факты-ссылки на эксперимент и дашборд, а не копировать числа в базу.
Риск кладбища данных. Репозиторий, в который пишут, но из которого не читают, — та же папка с отчётами, только дороже.

Что спросить у команды: чек-лист руководителя

Внедрить метод можно за неделю, если начать с вопросов, а не с выбора инструмента.

Где лежат результаты исследований за последний год, и сколько времени займёт найти ответ на вопрос «что мы знаем о сегменте X»?
Были ли случаи, когда мы заказывали исследование, ответ на которое уже был?
На какие факты опирается решение, которое мы сейчас обсуждаем? Кто их наблюдал, когда и каким методом?
Какие из этих фактов — поведение, а какие — слова клиентов?
Если завтра новое исследование опровергнет один из фактов, как мы узнаем, какие решения это затрагивает?
Кто владелец базы знаний и сколько часов в неделю на неё выделено?
Если мы делаем AI-ассистента по внутренним знаниям, в каком формате он будет получать исследования?

План на неделю: понедельник — шаблон и шкала доказательности; вторник–среда — разбор двух-трёх исследований под одно живое решение; четверг — запись решения со ссылками и разбор на встрече команды; пятница — правило «новые исследования сдаются записями» и назначение владельца.

Частые вопросы

Чем атомарные исследования отличаются от обычного research repository?

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

Нужен ли специальный инструмент для atomic research?

На старте нет. Таблица или Notion с четырьмя связанными базами достаточны, чтобы проверить метод на одном решении. Инструмент стоит выбирать, когда стало понятно, какие поля и связи команда реально использует и сколько записей в базе.

Чем факт отличается от инсайта?

Факт — то, что наблюдали или услышали, без интерпретации: цитата, число, действие пользователя. Инсайт — вывод команды из одного или нескольких фактов. Частая ошибка — записывать в факты интерпретации вроде «клиентам неудобно», хотя наблюдали только жалобу одного человека.

Как атомарная база помогает AI-агентам и RAG?

Короткие записи с датой, методом, источником и уровнем доказательности — готовые фрагменты для поиска. Их не нужно резать, по ним можно фильтровать до подачи в модель, а ответ агента можно проверить по ID факта. Связи позволяют агенту отвечать, на чём основано решение.

Кто должен вести базу знаний исследований?

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

Источники

Tomer Sharon. Democratizing UX. WeWork Ideas, 12 января 2017 — четыре проблемы, которые решает Polaris, и nugget: наблюдение, доказательство, теги.
Daniel Pidcock. Atomic UX Research. Marvel Blog — четыре слоя модели и фразы «We did this… / …and we found out this… / …which makes us think this… / …so we’ll do that».
User Interviews. Atomic Research Nuggets. UX Research Field Guide — модели Шэрона и Пидкока, связь с atomic design, ссылка на доклад Пидкока на UX Brighton 2018, критика метода.
Maze. What is Atomic Research? — слои модели Пидкока, Polaris как параллельный подход 2017 года, ограничения.
Glean.ly. Atomic research — показатель уверенности для инсайта, поддержка и опровержение инсайтов новыми исследованиями.