Как провести литературный обзор (literature review) для UX: практический гайд с AI-промптами

Что такое литературный обзор?

Литературный обзор (literature review) — это вторичный исследовательский метод, в котором исследователь собирает, отсеивает и синтезирует опубликованные исследования по заданному вопросу — академические статьи, индустриальные отчёты, peer-reviewed исследования, библиотеки дизайн-паттернов и внутренние репозитории — чтобы понять, что уже известно, до того как запускать новое исследование. В отличие от широкого desk research скана, который тянет любой релевантный материал, literature review — сфокусированный, time-boxed аудит опубликованных доказательств, который выдаёт структурированный синтез с явными gaps и рекомендациями. Для UX-команд scoping или rapid literature review по сфокусированному вопросу занимает от пяти часов до двух недель и многократно окупается, останавливая команду от пересоздания того, что другие исследователи уже задокументировали и валидировали.

На какой вопрос отвечает метод?

Что уже известно про эту группу пользователей, домен или дизайн-паттерн, и где опубликованные доказательства сильны, а где слабы?
Не отвечали ли другие исследователи уже на вопрос, на который мы собираемся потратить спринт?
Какие дизайн-паттерны были протестированы и валидированы в опубликованных исследованиях, а какие — всё ещё непроверенный фольклор?
Что академическая и индустриальная литература говорит о failure modes того подхода, который мы собираемся выкатить?
Какие исследовательские пробелы оправдывают запуск собственного primary study, а на какие вопросы можно прямо сейчас ответить из существующих данных?
Для регулируемого или незнакомого домена (медицина, финансы, accessibility) — что опубликованные исследования говорят об обязательных требованиях перед дизайном?

Когда использовать литературный обзор

Перед любым крупным исследовательским проектом, чтобы поднять вопросы, на которые уже есть ответы, и освободить бюджет primary research под настоящие неизвестные.
При входе в новый домен, продуктовую категорию или сегмент пользователей, где у команды нет прошлого опыта и нужно быстро встать на established findings до начала дизайна или интервью.
Когда нужно обосновать дизайн-решение перед стейкхолдерами, которым нужны доказательства сильнее, чем «best practices» — peer-reviewed исследования и индустриальные отчёты весят больше, чем мнения.
Когда аудируется спорный дизайн-выбор (паттерн взаимодействия, копирайт, метрика) против опубликованных данных, чтобы подтвердить или опровергнуть интуицию команды.
При подготовке исследовательского предложения, гранта или стратегического документа, рекомендации которого нужно заземлить в существующем своде знаний.
Когда бюджет полностью исключает primary research, а команде всё равно нужен защитимый, доказательно обоснованный ответ на стратегический вопрос.

Не подходит, когда вопрос специфичен для ваших уникальных пользователей и продукта, а аналогов в опубликованной литературе нет — в таком случае primary research (интервью, юзабилити-тесты, аналитика) — единственный честный ответ. Также неуместен, когда команде нужен свежий, ситуативный инсайт о живом пользователе — литература это снимок того, что было верно в момент публикации, а не realtime чтение текущей клиентской базы. Literature review нельзя использовать как способ откладывать решения бесконечно; если вопрос срочный, а литература тонкая, запустите маленькое primary study и задокументируйте, чему научились, для следующей команды. Наконец, не путайте его с прочтением пары блог-постов; настоящий literature review отсеивает по качеству источника, включает противоречивые данные и синтезирует поверх исследований, а не пересказывает каждое в отдельности.

Что вы получаете на выходе

Документ research questions: однополосное описание двух-четырёх сфокусированных вопросов, на которые ответит обзор, scope (временное окно, типы источников, языки) и критерии включения/исключения для источников.
Source log: структурированная таблица или база с одной строкой на источник, где зафиксированы автор, год, тип источника, дизайн исследования, ключевые находки, оценка релевантности и однопасусная экстракция релевантных инсайтов.
Тематический синтез: находки, организованные по темам, а не по источникам, с явно выделенными конвергентными доказательствами, противоречиями и пробелами.
Аннотированная библиография: короткий оценочный абзац для каждого ценного источника, чтобы будущие читатели могли решить, стоит ли нырять в оригинал.
Gap analysis: явный список вопросов, на которые литература не отвечает, и рекомендации по primary research, которые закрыли бы пробелы.
Документ рекомендаций: конкретные дизайн- или исследовательские импликации, привязанные к конкретным источникам, чтобы у каждой рекомендации были цитата и обоснование.
Readout brief: документ на пять-десять страниц или короткая презентация с вопросом, методом, заголовочными темами, пробелами и рекомендациями; служит базой, на которой будущие literature reviews по той же теме смогут строиться.

Участники и команда

Участники: никого не рекрутируют. Literature review — desk-метод по опубликованным данным, который ведут один-три исследователя в зависимости от типа и масштаба.
Исследователи: для UX scoping или rapid review достаточно одного исследователя; для systematic review с целью полного покрытия минимум два, потому что dual screening и dual extraction снижают bias одного ревьюера.
Определение вопроса: 1–3 часа на написание сфокусированных research questions, scope и критериев включения. Это шаг, который новички недоинвестируют и расплачиваются позже.
Стратегия поиска: 1–3 часа на дизайн поисковых терминов, выбор баз и первый pull. Для systematic reviews расширяется до дня и более с информационным специалистом.
Скрининг: 0,5–1 день для scoping review с 50–150 кандидатами, дольше для systematic с сотнями.
Экстракция и синтез: 1–3 дня для UX scoping review (15–25 высококачественных источников), 2–8 недель для scoping review нового домена, несколько месяцев для полного systematic review.
Написание брифа: 0,5–1 день для UX scoping формата, дольше для академических и систематических выводов.
Полное календарное время: 5 часов для сфокусированного микро-обзора, 1–2 недели для UX scoping review по определённому вопросу, 4–6 недель для широкого scoping review нового домена, 6 месяцев — 2 года для полного systematic review с двумя исследователями.

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

1. Определите сфокусированный research question

Напишите два-четыре конкретных вопроса до того, как открыть любую базу. Расплывчатые вопросы вроде «что такое хороший UX» дают расплывчатые обзоры и потраченное время; сфокусированные вопросы вроде «что опубликованные исследования говорят про влияние guest checkout на конверсию для первых мобильных пользователей» дают actionable находки за несколько дней. Тестируйте каждый вопрос вопросом самому себе: можете ли вы представить конкретный ответ; если нет — вопрос ещё слишком широкий. Привязывайте каждый вопрос к реальному дизайн- или исследовательскому решению, чтобы синтез оставался actionable. Если проект покрывает больше одного решения, запускайте отдельный обзор для каждого, а не пытайтесь свернуть их в один.

2. Выберите тип обзора и scope

Решите заранее, какой тип literature review подходит проекту: narrative review для сфокусированного вопроса с одним исследователем и бюджетом одна-четыре недели, scoping review для маппинга доступных данных в новой области с двумя-восемью неделями работы, rapid review для более строгого синтеза под жёстким дедлайном (два-шесть месяцев), или полный systematic review для академической публикации или решений уровня evidence-grade (восемь месяцев — два года). Для большинства UX-работы правильный выбор — scoping или narrative review с явным time box. Зафиксируйте scope письменно: минимальное и максимальное число источников, временное окно (источники за последние пять-десять лет для UX, дольше для foundational studies), языки и типы источников.

3. Дизайн стратегии поиска

Перечислите ключевые слова и синонимы для каждого research question, потом выберите базы и типы источников. Внутренние источники сначала: любые исследовательские репозитории, прошлые юзабилити-тесты, тикеты поддержки и дизайн-документация, которыми команда уже владеет. Внешние источники потом: Google Scholar и ACM Digital Library для академики, Nielsen Norman Group, Baymard Institute, dscout People Nerds и другие индустриальные блоги для практиков, Litmaps и Connected Papers для citation mapping, и кейсы конкурентов где они есть. Для systematic reviews работайте с информационным специалистом по дизайну поиска; для UX scoping review набросайте ключевые слова сами и протестируйте их против benchmark списка из трёх-пяти источников, которые вы уже знаете релевантными, а потом доточите.

4. Скрининг источников по релевантности и качеству

Тяните candidate set (30–150 источников для scoping review, больше для systematic) и отсейте их по критериям включения, используя только заголовок, абстракт и первый абзац — не читайте каждую статью целиком на этой стадии. Применяйте два фильтра: релевантность (отвечает ли источник на один из research questions для вашего user context) и кредибельность (peer-reviewed и высоко-авторитетные индустриальные источники сначала, блог-посты потом, маркетинговый шум никогда). Оцените каждый источник High / Medium / Low по релевантности и стремитесь к 15–25 High источникам, а не к 100 поверхностным. Всегда фиксируйте источники, которые вы отбросили, и почему, чтобы будущие ревьюеры могли аудировать решение.

5. Экстракция находок в структурированный лог

Для каждого High и Medium источника прочитайте полный текст и зафиксируйте пять полей в общей таблице: research questions, на которые отвечает источник, использованные методы, ключевые находки, релевантные вашему проекту, ограничения или контекст, которые могут влиять на применимость, и импликации для вашего конкретного дизайн- или research-вопроса. Используйте прямые цитаты или точную перифразу, а не свободный пересказ, чтобы экстракцию можно было аудировать. Тегируйте каждую строку темой(ами), к которой она относится, чтобы шаг синтеза получил чистую структуру для работы. Для платных или paywalled источников, к которым у вас нет доступа, зафиксируйте цитату и попробуйте найти публичное саммари или препринт, прежде чем сдаваться.

6. Синтез по источникам, не по одному источнику за раз

Самая большая ошибка в literature reviews — пересказывать каждый источник по очереди вместо того, чтобы синтезировать поверх них. Реорганизуйте экстракцию по темам, потом для каждой темы напишите абзац, который комбинирует данные из нескольких источников, называет конвергентные находки, флагует противоречия и оценивает силу доказательств. Ищите паттерны («три исследования mobile checkout flows нашли, что guest checkout повышает конверсию, причём одно отметило downstream retention cost»), а не список разрозненных абзацев. Останавливайте добавление источников, когда новые перестают давать новые темы — это момент насыщения, и он обычно наступает раньше, чем ожидают новички.

7. Явно определите пробелы и противоречия

Literature review наиболее полезен, когда говорит читателю, что не известно, так же ясно, как говорит, что известно. Сделайте отдельную секцию для пробелов: на какие из research questions литература не отвечает, какие контексты не были изучены (ваш сегмент пользователей, ваша индустрия, ваше устройство, ваш язык), и какие находки противоречат друг другу так, что существующая литература не разрешила противоречие. Каждый пробел — кандидат на primary research; каждое противоречие — место, где команда должна явно решить, какому доказательству верить и почему. Это секция, которая превращает обзор из summary в research roadmap.

8. Свяжите находки с дизайн- или research-решениями

Для каждой темы в синтезе напишите одну-две конкретные рекомендации, привязанные напрямую к дизайн- или research-вопросам проекта. Находка без рекомендации — мёртвый пересказ; рекомендация без находки — мнение. Будьте явны в том, насколько сильны доказательства — «пять peer-reviewed исследований сходятся на этом» — это другая рекомендация, чем «один индустриальный блог утверждает это». Где литература противоречит интуиции команды, поднимайте противоречие в рекомендации, а не закапывайте его. Рекомендации должны быть секцией, которую дизайн- и продакт-лиды реально читают.

9. Напишите бриф и презентуйте стейкхолдерам

Сделайте бриф на пять-десять страниц или короткую презентацию. Откройте research questions, методом (стратегия поиска, типы источников, критерии включения) и заголовочными находками на первой странице. Пройдитесь по каждой крупной теме с конвергентными данными, противоречиями и импликацией. Закройте gap analysis и приоритизированными рекомендациями. Презентуйте лично дизайн-, продакт- и research-лидам, чтобы они могли спросить о качестве источников и применимости — разговор и есть место, где синтез становится решением. Source log приложите как аппендикс для команды, которая захочет нырять глубже в конкретные исследования.

Как AI меняет литературный обзор

AI compatibility: partial — Literature review — один из самых AI-amenable исследовательских методов, потому что большая часть работы механическая: query базы, прочитать абстракты, экстрагировать структурированные поля и кластеризовать находки в темы. Современные AI-инструменты, построенные специально под этот workflow (Elicit, Consensus, SciSpace, Scite, Litmaps), могут провести поиск, суммировать абстракты, поднять конвергентные находки по сотням статей и выдать черновик синтеза за часы, а не недели. Загвоздка в том, что AI стабильно сверх-уверен в качестве источников, плохо справляется с противоречиями и контекстными оговорками, которые важнее всего, и с радостью фабрикует цитаты, если на него надавить. Работа исследователя смещается от экстракции к её верификации, оценке того, какие данные действительно сильные, и переводу находок в рекомендации, по которым команда может действовать.

Что AI умеет

Семантический поиск литературы: Elicit, Consensus и SciSpace выходят за рамки keyword search и находят статьи, семантически совпадающие с research question, поднимая релевантные источники, которые традиционный database search пропускает. Это сжимает шаг поиска с дня запросов в базы до часа доточки вопроса.
Суммирование и экстракция структурированных находок из статей: на PDF или цитате современные AI-инструменты выдают однопасусное саммари, экстрагируют методы, размер выборки, ключевые находки и ограничения в структурированную строку и привязываются к релевантным предложениям. То, что раньше занимало 20–30 минут на статью, теперь занимает 2–3 минуты.
Синтез по нескольким источникам на масштабе: инструменты вроде Elicit и Consensus могут запустить запрос «что литература говорит про X» на 50–500 статьях и выдать черновик синтеза с конвергентными находками, противоречиями и счётом поддерживающих и опровергающих исследований. Это шаг, который исторически плохо масштабировался по объёму выборки.
Маппинг сетей цитирования и поиск смежных источников: Litmaps, Connected Papers и Research Rabbit визуализируют, как стартовый набор статей цитирует друг друга, поднимая seminal работы, которые исследователь пропустил, и связанные статьи, которые поисковый запрос не поймал. Это заменяет часы ручного citation chasing.
Сделать черновик синтез-брифа: на экстрагированном source log LLM Claude или GPT-4o может выдать первый драфт брифа, организованный по темам, с цитатами на конкретные источники за каждой находкой. Исследователь потом переписывает его под тон, заостряет gap analysis и убирает неизбежную ложную уверенность.
Флагать статьи, которые противоречат друг другу: модель может прочитать экстрагированные находки по source log и поднять случаи, где два или больше источников расходятся, что и есть начало gap analysis. Делать это вручную медленно и легко пропустить.

Что требует человека-исследователя

Определение research question, который важен: AI с радостью ищет любой вопрос, который вы ему дадите, но выбор вопроса, который реально мапится на решение команды, — это продуктовое суждение, опирающееся на знание проекта, стейкхолдеров и того, что команда уже пробовала. Ошибётесь — и обзор технически тщательный, но нерелевантный.
Верификация качества источника и дизайна исследования: AI-инструменты систематически переоценивают свои входы и будут ранжировать маркетинговый блог и peer-reviewed RCT как одинаково релевантные, если совпадают ключевые слова. Исследователь должен прочитать секцию методов высокоимпактных источников и понизить вес тех, которые не проходят базовую critical appraisal.
Ловить галлюцинированные цитаты: общие LLM (не специализированные literature-инструменты) будут фабриковать правдоподобно выглядящие референсы, которых не существует. Любая цитата, которая вышла из чат-стиль взаимодействия, должна быть верифицирована против реальной базы перед попаданием в бриф.
Калибровка находок к локальному контексту: находка, которая держится в опубликованном исследовании, может не держаться для вашего сегмента пользователей, индустрии или устройства. AI не может сделать это суждение; исследователь должен спросить, совпадает ли опубликованный контекст с контекстом команды, и понизить вес источников, где не совпадает.
Решение о том, что команда должна сделать: рекомендации — часть брифа, которая двигает следующий спринт, и они требуют человека, который знает, что команда может выкатить, какие инженерные ограничения и сколько риска бизнес примет. AI может их драфтить; только человек может на них коммититься.

AI-усиленный workflow

До AI один UX scoping literature review по сфокусированному вопросу занимал одну-две недели исследовательского времени: день на дизайн поиска, день на скрининг 100+ кандидатов, три-пять дней на чтение и экстракцию из 15–25 выбранных источников, два дня на синтез и написание брифа. Бутылочное горлышко — шаг экстракции, медленный, повторяющийся, и легко уплывающий от изначального research question по мере усталости.

С AI в workflow тот же проект сжимается до одного-трёх дней. Исследователь тратит два часа на формулировку research question и scope, потом запускает вопрос через Elicit или Consensus, чтобы получить first-draft список релевантных источников с экстрагированными находками. Исследователь читает абстракты, которые поднял модель, принимает очевидные совпадения, отбрасывает нерелевантные и добавляет всё, что модель пропустила, через Litmaps citation chasing. Шаг экстракции потом гонится против вычищенного source list на машинной скорости, исследователь выборочно проверяет 10–20% строк вручную и читает методы самых высокоимпактных источников целиком. Проход синтеза использует драфт модели как стартовую точку, исследователь переписывает темы для нюансов, противоречия для честности, и рекомендации для actionability.

Загвоздка та же, что и для AI-усиленного desk research и эвристической оценки: ускорение реально только тогда, когда человек читает самые высокоимпактные источники целиком и верифицирует цитаты. Исследования LLM-генерированных literature reviews показывают, что модели надёжно кластеризуют лёгкие темы, но пропускают противоречия и переоценивают тот фрейминг, который появляется в большинстве статей, даже когда меньшинство методологически сильнее. Исследователи, которые получают от AI здесь больше всего пользы, относятся к специализированным инструментам (Elicit, Consensus, SciSpace) как к компетентному младшему research-ассистенту, к общим LLM — как к draft writer, который врёт про цитаты, а к себе — как к критическому читателю, который знает, на какие данные команда может ставить решение.

Пример из практики

Компания B2B-финтеха собиралась переделать flow многофакторной аутентификации для high-stakes payment продукта, и команда безопасности хотела «индустриальные best practices» перед тем, как коммититься на подход. У продакт-менеджера было две недели до начала дизайн-спринта и сильная интуиция использовать SMS one-time passwords, потому что этого просила команда поддержки. Лид исследователь беспокоилась, что SMS — неправильный выбор, и предложила сфокусированный literature review, чтобы решить вопрос доказательствами, а не мнениями.

Она определила три research questions («что опубликованные исследования говорят про user friction в MFA flows для B2B payments», «какой задокументированный security/usability trade-off между SMS, authenticator apps, hardware keys и passkeys для нетехнических пользователей», «у каких MFA-паттернов самые низкие abandonment rates в financial services»), поставила time box в одну неделю и использовала Elicit и Consensus, чтобы поднять candidate set из 87 статей и индустриальных отчётов через академические HCI-площадки, NIST guidance, отчёты FIDO Alliance, Baymard и три peer-reviewed исследования по MFA usability. Она отскринила кандидатов до 22 высоко-релевантных источников, экстрагировала их в Notion-базу со структурированными полями и провела проход синтеза с Claude по экстрагированному логу. Она прочитала секции методов восьми самых высокоимпактных peer-reviewed источников целиком и верифицировала цитаты, которые поднял модель.

Синтез выдал чёткий ответ: по девяти peer-reviewed исследованиям и четырём индустриальным отчётам у SMS one-time passwords была самая высокая abandonment rate (12–18%) и самый низкий security score, тогда как у authenticator apps была средняя позиция, а у passkeys — самая низкая abandonment для пользователей с совместимым устройством. У hardware keys была самая сильная безопасность, но самая высокая setup friction. Рекомендация — дефолтить на passkeys с authenticator-app fallback, полностью пропустить SMS, кроме как recovery механизм, и принять, что запрос команды поддержки был запросом на неправильный фикс. Рекомендация пошла в дизайн-спринт как стартовая точка, редизайн вышел через шесть недель с passkeys по дефолту, abandonment rate на новом flow упал с 14% до 4% за первый месяц, и команда поддержки забрала свой исходный запрос, увидев данные. Literature review занял у исследователя около 26 часов работы вместе с синтез-брифом — против многонедельного primary study, который был бы единственной альтернативой.

AI-промпты для этого метода

4 готовых AI-промптов с placeholder’ами — скопируйте и подставьте свой контекст. Все промпты для «литературного обзора» →.