Эти четыре промпта покрывают те части анализа ошибок, где AI экономит больше всего времени без потери строгости: кластеризация сырых наблюдений в таксономию режимов отказа, структурный проход кодирования на масштабе, диагностика корневых причин для топовых провалов и построение приоритизированного плана действий. Каждый промпт надо заполнить своим продуктом, scope и наблюдениями, а потом запустить в Claude, ChatGPT, Gemini или любой LLM с достаточно длинным контекстным окном. Промпты предполагают, что в контуре остаётся человек-исследователь — модель делает черновик, а исследователь читает, редактирует и отвечает за финальное решение.
Промпт 1: Кластеризация сырых наблюдений в таксономию режимов отказа
You are an experienced UX researcher building a failure taxonomy from raw error observations.
Product: [тип продукта, например, потребительское финтех-приложение, B2B-аналитический дашборд]
Flow being analyzed: [описание сценария и задачи, которую пытались выполнить пользователи]
User segment: [новичок, эксперт, конкретная роль, устройство]
Data source: [заметки модерируемого юзабилити-теста, самоотчёты немодерируемых сессий, тикеты поддержки, фидбек в продукте, логи ошибок]
Below is the raw set of error observations from the sample. Each line is one observation in free text.
[вставьте наблюдения, по одному в строке]
Please:
1. Read every observation carefully. Do not skim.
2. Group observations that describe the same underlying failure into a single cluster.
3. Propose 6-10 named failure categories that cover the data, with a one-line definition for each. Categories should be mutually exclusive and grounded in the actual observations, not invented.
4. For each category, list the count of observations and 3-5 representative verbatim quotes.
5. Flag any observation that does not fit cleanly into a category as an outlier and explain why.
6. End with a short paragraph on which failure modes appear to be the most frequent and which appear to be the most severe based on the language used in the observations.
Do not invent failure modes that the data does not support. If you only see one example of something, it is an outlier, not a category.Промпт 2: Структурное кодирование против существующей таксономии
I have a taxonomy of failure modes for [сценарий] and a set of error observations to label against it. Apply the taxonomy consistently and flag anything that does not fit.
Taxonomy:
[вставьте каждое название категории с однострочным определением]
Severity rubric:
- Critical: blocks task completion or causes irreversible harm
- Major: significant friction, likely to cause errors or hesitation, task may still succeed
- Minor: noticeable friction, task succeeds without help
- Cosmetic: visual or wording polish, no impact on task
Observations to label:
[вставьте каждое наблюдение с ID]
For each observation, return a row with:
- ID
- Category (from the taxonomy, exactly one)
- Severity (from the rubric)
- Confidence (high / medium / low — how certain you are about the category)
- One-sentence justification quoting the relevant part of the observation
- Flag: "fits cleanly" / "edge case" / "does not fit"
At the end:
1. List every observation flagged as "edge case" or "does not fit" and propose whether the taxonomy should be extended or whether the observation belongs under "other"
2. Report the count per category and per severity level
3. Highlight any category where you assigned low confidence to more than 30% of the observations — that suggests the category definition is too vagueПромпт 3: Диагностика корневых причин и предложение фиксов
You are helping me write the diagnosis section of an error analysis report. For each high-priority failure mode below, propose the most likely root cause and a concrete recommended fix.
Product context: [описание продукта, тип пользователя, бизнес-модель]
Flow: [описание сценария с ключевыми шагами]
Failure modes (each with frequency and severity):
[вставьте каждый режим отказа с числом уникальных пользователей, серьёзностью и 2-3 дословными наблюдениями]
For each failure mode:
1. Diagnose the most likely root cause and pick exactly one of: design problem, mental-model mismatch, content/terminology, technical bug, content gap, other (explain). Quote the strongest piece of evidence from the observations to support the diagnosis.
2. List 2-3 alternative root causes you considered and explain in one sentence why you picked the one above each.
3. Propose a concrete recommended fix in one paragraph. State the specific change to make, which team should own it (design, content, engineering), and a rough effort estimate (small, medium, large).
4. Identify any failure mode where the evidence is too thin to diagnose confidently and recommend additional research that would resolve the ambiguity.
5. Flag any failure mode that may be a symptom of a deeper systemic problem rather than a stand-alone bug.
End with a 3-sentence summary of the overall pattern: which root-cause type appears most often across the high-priority failures, and what does that suggest about where the team should invest next.Промпт 4: Построение приоритизированного плана действий
I have a coded error analysis backlog of [N] failure modes for [сценарий] in [продукт]. The team has roughly [ресурсы разработки, например, одна неделя дизайнера и три недели инженеров] for the next sprint.
Backlog:
[вставьте каждый режим отказа с категорией, серьёзностью, частотой (число уникальных пользователей), бизнес-контекстом и рекомендованным фиксом]
Please:
1. Score each failure mode on three dimensions (1-5 each):
- Severity: how badly it hurts the user when it happens
- Frequency: how often a real user hits it (use the number of distinct users)
- Business impact: effect on activation, retention, conversion, or support cost
Briefly justify each score in one sentence.
2. Compute a priority score (sum of the three dimensions) and sort the backlog from highest to lowest priority.
3. Recommend the top 5-10 failure modes to fix in the next sprint based on the priority scores and the available capacity, with a rough effort estimate per fix (small, medium, large).
4. Identify any failure mode that scores low on this rubric but feels strategically important (e.g., a failure with legal exposure, a brand-trust issue, a failure that hits a high-value customer segment) and explain why it should be elevated.
5. Suggest 2-3 failures that should be tracked but deferred, with a rationale for not fixing them now.
6. Identify any cluster of 3+ failures in the same category — these may deserve a single redesign rather than incremental patches.
7. Draft a 5-sentence executive summary the lead can use as the opening of the readout brief.