Аудит gap'ов в user journey

Gap-анализ от лидеров категории даёт competitive baseline. User-journey audit даёт evidence-based список: где конкретно ваши пользователи buksuют. Эти два угла дают разные ответы, и оба нужны.

Продукт: {{product_url}} Главный journey: {{primary_journey}}

1. Источники evidence

Если у тебя меньше 4 источников — discovery будет однобоким.

2. Карта journey

Возьми главный {{primary_journey}}. Разбей на 5-9 шагов с координатами «entry → next step → success».

Пример для SaaS signup:

landing → signup → email verify → onboarding → empty state → first value → second value → retention

Для каждого шага измерь:

• Conversion rate (или approximate из analytics)
• Time spent (avg)
• Mentions в support tickets (часто ли тут жалуются?)
• Documented or not (есть ли help-page для этого шага)

3. 5 типов gap'ов

A. Drop-off (drop в conversion >20% между шагами)

Где? Что юзер видит до того как уйти? Что говорит «не моё»?

B. Friction (юзер проходит, но долго / с трудом)

• Time-on-step выше benchmark
• Support tickets «как сделать X» — это значит UX неочевиден
• Repeat clicks (session recording) — кликает в empty space, ищет CTA

C. Dead-end (юзер пришёл, и нет следующего шага)

• Empty states без «add first item» CTA
• Search вернул 0 результатов без «попробуйте X»
• Settings → save → нет confirmation, юзер не уверен сработало

D. Capability gap (юзер хочет, но не можем)

• «Could you add Y» в support тикетах
• Tickets закрытые с «not supported» / «on roadmap»
• Workarounds юзеры придумали (плохой UX = creative usage)

E. Trust gap (юзер сомневается)

• «Is X secure?» / «Can I trust this with my data?»
• Long contracts in B2B
• Hesitation before key action
• Customers do action elsewhere to verify

4. Pattern recognition

После прохода по 4+ источникам, ищи повторения. Один пользователь сказал «X» — anecdote. 5+ сказали «X» — pattern.

Топ-10 паттернов рассортируй:

• Frequency: сколько раз упомянуто
• Severity: блокирует или раздражает
• Customer tier: enterprise / mid / SMB / free
• Stage: какой шаг journey
• Type: A / B / C / D / E (см. выше)

5. Decoding: что на самом деле просят

Пользователи говорят solutions, не problems. «Дайте мне сортировку по дате» = «я ищу свежий результат и не могу». Подумай:

• Что юзер пытается СДЕЛАТЬ? (job-to-be-done)
• Какие альтернативы он уже пробовал?
• Что мешает использовать что есть?

Например, «дайте API» → может оказаться «дайте экспорт в CSV» — решает 80% потребности без построения API.

6. Output: 10 feature кандидатов

Для каждого:

• Pattern (что наблюдаем)
• Evidence count (сколько раз услышали, из каких источников)
• Customer tier hit (кого касается)
• Type (drop-off / friction / dead-end / capability / trust)
• Underlying JTBD (что на самом деле делают)
• Possible solution (1-3 варианта, не обязательно «фича»)

7. Anti-patterns

• ❌ Один источник (только support) → bias к «жалующимся»
• ❌ Слушать только loud customers → они не репрезентативны
• ❌ «Юзер хочет X» = «строим X» → пропуск underlying JTBD
• ❌ Игнорить «happy users» — они дают сигнал что уже работает, не трогай это
• ❌ Без квантификации → «иногда жалуются» vs «60% тикетов на этой неделе»
• ❌ Журнал-анализ без проверки на проде — anecdotes старее реального состояния
• ❌ Не отделять friction от dead-end — разные fix-pattern

8. Output

1. Journey map с conversion / time / mentions per step
2. Топ-10 patterns в таблице с frequency / severity / type
3. 5 candidate fixes с possible solutions (multiple per pattern)
4. Список «не пользователи» — что просят, но это не наша target audience (можно проигнорировать)
5. Input для discovery cycle: что пойдёт в adjacent-feature-opportunities и next-iteration-pitch