Skip to main content

I Vibe-Coded a Journey-Map Generator: Auto-Synthesizing Docs and Demos Into Actionable Friction Maps

The Problem

A feature faced negative feedback but diagnosing root causes meant manually synthesizing help docs, demo transcripts, and scattered customer complaints. I vibe-coded a tool that automatically generates persona-based journey maps from help center content — exportable as HTML, PNG, or PDF — then integrated Zendesk and Slack to surface customer complaints and map friction points directly to specific journey steps. Shipped writing fixes fast; clearly scoped engineering work.

Why It Mattered

The feedback was clear but the root causes were opaque. You could read a support ticket saying “confusing,” but which specific steps were confusing? A demo transcript mentioned complexity, but where did users get lost? Without a way to systematically map complaints to journey stages, any fix was guesswork.

Worse: manually building journey maps from scattered docs and videos would take weeks. We needed to respond to negative feedback fast — shipping improvements, not studies.

My Role

I owned the full build solo: designed the tool, vibe-coded the generator, integrated it with Zendesk and Slack, ran the analysis, and authored the handoff report. My goal was to automate the synthesis problem — turn scattered docs and demos into actionable journey maps, then wire them to live customer data so friction wasn’t abstract, it was pinned to specific steps.

The Key Insight

The problem wasn’t just scattered feedback. It was that no one had a system to connect complaints to specific steps. Manually reading docs, watching videos, and reading tickets meant months of work. But those same sources contained everything needed to generate journey maps automatically — and once you had those maps, you could overlay customer complaints and surface exactly where the friction lived.So I built a tool that auto-generates journey maps from existing content, then integrates with live customer data.

Problem Statement:

“A feature faced heavy negative feedback, but diagnosing root causes meant manually synthesizing help docs, demo transcripts, support tickets, and Slack escalations — too much surface area to audit systematically. Friction evidence was scattered across formats and platforms with no way to connect complaints to specific steps in the user journey.”

Design Decisions

1. Auto-generate from existing content, not from scratch

  • What I did: Built the generator to ingest help center docs and demo video transcripts, automatically extracting personas and journey flows. No manual mapping; let the content speak.
  • Why it mattered: We already had authoritative docs and demos. Reusing them meant fast turnaround and high fidelity — the journey map was built from what the company actually shipped, not my interpretation.
  • Tradeoff: Generator quality depends on source content quality. Garbage docs = garbage maps. But the docs were good, so this was a win.

2. Export in multiple formats for different audiences

  • What I did: Journey maps rendered as interactive HTML (editable in browser), but also exportable as PNG (for Slack, quick sharing) and PDF (for formal reports). Same data, different surfaces.
  • Why it mattered: Engineers want to click and edit (HTML). PMs want to share in Slack quickly (PNG). Leadership wants a formal artifact (PDF). One tool, multiple use cases.
  • Tradeoff: Export logic overhead — repaid by adoption. A tool no one uses because the output format is wrong is worthless.

3. Integrate Zendesk and Slack to overlay live customer data

  • What I did: The tool pulls support tickets from Zendesk and escalations from Slack, then maps them to specific journey steps. Friction isn’t abstract — it’s pinned to where it actually occurs in the flow.
  • Why it mattered: A journey map is theoretical until you validate it against real complaints. Integration meant the tool surfaced the highest-signal friction automatically.
  • Tradeoff: Integration complexity — but the payoff was precision. A complaint about “configuration step 3” could now be mapped directly to the exact UI that caused it.

4. Separate writing-fixable friction from engineering blockers upfront

  • What I did: The tool classifies each friction point by ownership: writing can fix (terminology, clarity, helper text) vs. engineering-only (routing, validation, state logic). Two lists, two different action plans.
  • Why it mattered: Prevents wasted effort. A writing pass can’t fix a broken API. An engineering sprint won’t clarify confusing copy. Separating them means both teams ship faster.
  • Tradeoff: Requires judgment calls about what’s fixable. But making those calls in the tool meant the report was already filtered by ownership, not just by severity.

The Solution: Journey-Map Generator + Integrated Complaint Surfacing

The tool moved through three phases sequentially:

1. Generator Prototype (Week 1–2)

Built a simple version that ingested placeholder docs and video transcripts, auto-generating personas and journey flows in HTML. Proved the extraction and rendering logic worked before touching real content.

2. Live Generator with Export Options (Week 2–5)

Integrated real help center docs and demo video transcripts. Added export functionality: interactive HTML (browser-editable), PNG (quick sharing), PDF (formal reports). Single source, multiple outputs.

3. Zendesk + Slack Integration (Week 5–8)

Wired the tool to pull support tickets from Zendesk and escalations from Slack. The generator now maps each complaint to the specific journey step where friction occurs. Result: every customer complaint is pinned to a step, automatically classified by owner (writing vs. engineering), and ready for action.

Proof of concept: A customer journey map generated from help docs and customer feedback, showing how scattered friction data (support tickets, user confusion, product failures) gets systematically pinned to specific workflow steps. Orange friction boxes surface problems at each stage with priority, effort, and recommended fixes—demonstrating the tool’s ability to turn fragmentary complaints into actionable, scoped work for both writing and engineering teams.

Outcome

Within the eight-week window, the work went from validated prototype to shipped tool to engineering handoff.

Writing-Side Fixes: Complete

Across all four admin sections:

  • Jargon removed: confusing product terminology replaced with admin-centered language (6 terms total)
  • Toggle copy converted to declarative statements with both ON/OFF states explained
  • Helper text and progressive disclosure added for error prevention and conditional relevance
  • Visual progress indicator and step descriptions built with state clarity

Engineering-Owned Issues: Scoped

As of the final report, the following are explicitly owner-assigned and tracked separately:

  • Routing logic broken (notifications never reach designated recipients, multi-stage chains skip levels) — Owner: Engineering
  • Silent auto-submit when no valid recipient exists — Owner: Engineering
  • Irreversible state transitions (misclick requires full workflow reset) — Owner: Product + Engineering
  • Multi-recipient / any-of-group support not shipped — Owner: Product
  • Required-field validation not enforced at submit time — Owner: Engineering

Usability validation and baseline metrics: Defined in the report but not yet run. The report explicitly calls for moderated usability sessions and a post-launch support-ticket baseline to measure whether configuration-related inquiries drop.

A journey map table with persona swimlanes (Backend Admins and End Users) across the rows and six journey stages (Prerequisites, Setup, Configure, Deploy, Monitor, Complete) across columns. Red-bordered cells indicate friction points where customers complained about unclear workflows and missing context. Source tags show whether issues came from UX audits, Zendesk support tickets, or Slack escalations. Empty cells marked with dashes show where personas don't have actions in that stage.

The journey-map generator in action: A fully populated journey map showing two personas (Backend Administrator, End User) across six workflow stages (Prerequisites, Configure, Assign, Submit, Review, Complete). Orange friction-point boxes surface problems at step-level precision—each with a description, priority tag (UXA = UX audit, ZD = Zendesk ticket, Slack = internal signal), effort estimate, and green-highlighted suggested fix. Multiple tabs at the top show different workflow variants (Flow — Setup, Flow — Review and approval, Creating an approver role). The map is fully editable, with buttons to add persona rows, stage columns, step items, and friction points. Print/Export PDF and Save as HTML buttons enable sharing with engineering and product teams.

Reflections

What I’d validate next
Whether owner-tagging actually changed engineering’s prioritization — did scoped issues move faster than unscoped ones used to? This is the real test of whether the taxonomy added judgment or just organization.
What risk remained
A few findings sat in genuine ambiguity between a writing fix and an infrastructure issue. I flagged the ambiguity rather than resolving it — honest but leaves a gap that requires stakeholder conversation to close.
What I’d improve with more time
Build the usability-testing and baseline-metrics step into the tool itself, so the loop from hypothesis to measured outcome doesn’t depend on a separate, currently-unscheduled effort. The report is only as good as the measurement plan that follows it.