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

> Атомарные исследования (atomic research) — база фактов вместо отчётов: шаблоны факта, инсайта и решения, уровни доказательности, трассируемость и формат для RAG.

Статья · Алексей Ишманов · 18 октября 2026 · https://aleksishmanov.ru/blog/atomic-research-atomarnye-issledovaniya/

Атомарные исследования (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 называет четыре проблемы, знакомые любой продуктовой компании:

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

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

Есть и вторая цена, менее заметная. Документ, который никто не читает, создаёт иллюзию, что решение обосновано. Это та же механика, что и в [ловушке тяжёлого ТЗ](/blog/lovushka-tyazhelogo-tz-30-stranits-vmesto-2-nedelnogo-testa/): объём текста подменяет ясность.

В [цикле решений при неопределённости](/blog/produktovye-resheniya-pri-neopredelennosti/) атомарные исследования стоят на шаге «проверить дёшево». [Ценность информации по Хаббарду](/blog/value-of-information-hubbard/) говорит, какое знание стоит покупать. Атомарная база отвечает на вопрос до покупки: может быть, оно у вас уже есть.

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

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

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

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

Второй пункт меняет культуру: опровержение становится рутинной операцией «обновить связи», а не спором о том, кто был прав. Это прямое противоядие от [confirmation bias в данных](/blog/confirmation-bias-v-dannyh-komanda-6-mesyatsev-validiruet-to-vo/), когда команда месяцами «валидирует» то, во что уже верит.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для сверки конкурирующих объяснений по фактам из базы подходит [анализ конкурирующих гипотез](/blog/ach-analiz-konkuriruyushchih-gipotez/): атомарные факты ложатся в его матрицу «гипотезы × доказательства» почти без доработки. А если исследование собирает ИИ по открытым источникам, как [STORM](/blog/storm-ii-issledovanie-stanford/), проверенные ссылки удобно сразу сохранять атомами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Источники

- Tomer Sharon. [Democratizing UX](https://www.wework.com/ideas/democratizing-ux). WeWork Ideas, 12 января 2017 — четыре проблемы, которые решает Polaris, и nugget: наблюдение, доказательство, теги.
- Daniel Pidcock. [Atomic UX Research](https://marvelapp.com/blog/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](https://www.userinterviews.com/ux-research-field-guide-chapter/atomic-research-nuggets). UX Research Field Guide — модели Шэрона и Пидкока, связь с atomic design, ссылка на доклад Пидкока на UX Brighton 2018, критика метода.
- Maze. [What is Atomic Research?](https://maze.co/collections/user-research/atomic-research/) — слои модели Пидкока, Polaris как параллельный подход 2017 года, ограничения.
- Glean.ly. [Atomic research](https://glean.ly/atomic-research) — показатель уверенности для инсайта, поддержка и опровержение инсайтов новыми исследованиями.