Jun 23

The Bet: Build a Tool Instead of Reading 200 Tickets by Hand

By Erik Taylor AI, Claude, Claude Code, Journey Mapping, Product Owner, Uncategorized, UX Research, Vibe Coding

The Problem

A feature faced negative feedback, but diagnosing root causes meant manually synthesizing help docs, demo transcripts, and scattered customer complaints. I could have spent weeks reading through all of it by hand — instead I made the call to vibe-code a tool that automatically generates persona-based journey maps from help center content, then integrates Zendesk and Slack to map complaints directly to journey steps. The bet: if the tool was wrong, I’d lose a week building something useless. If it worked, I’d turn months of manual audit into days.

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 Insights

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.
What I killed: I considered building a confidence score per friction point, but cut it. A number that looked precise but wasn’t backed by real measurement would have been worse than no number — better to flag ambiguity honestly than fake certainty.

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.

Nov 19

Love0

Why I Didn’t Solve Adoption with More Training

By Erik Taylor IBM, Product Owner, Seller Enablement

Solution Oveview

IBM’s Cognitive Sales Advisor platform was live, but sellers weren’t using it — they saw it as one more thing competing with time they needed for closing deals. The easy fix would have been more training sessions or a mandate from leadership. I made a different call: build a centralized guidebook on WordPress that met sellers and managers where they already worked, rather than asking them to adopt a new tool on top of a tool they were already resisting.

Success Metrics

Increased platform adoption: A noticeable uptick in Cognitive Sales Advisor usage among both managers and sellers.
Executive recognition: The guidebook was praised as IBM’s most comprehensive internal resource for sellers.
Sustained engagement: Content expansion supported new initiatives and adapted to evolving user needs.

The Problem

Sellers viewed the platform as overhead, not help. Managers had incentive to push adoption but no real way to demonstrate value in the time sellers had available. The actual constraint wasn’t awareness — it was that every existing solution added cognitive load instead of removing it. Any fix that asked sellers to learn something new, in a new place, was going to fail the same way the platform itself had.

Key Decisions

User-Centered Approach

What I did: Brought sellers and managers directly into the design process instead of designing from assumptions about their workflow.
Why it mattered: Stakeholder interviews surfaced the real blockers — high cognitive load and no time for training — that wouldn’t have shown up in a requirements doc.
Tradeoff: Slower start than building from existing specs, but it meant the guidebook solved the problem sellers actually had, not the one that looked obvious from outside.

Tool Familiarity

What I did: Built the guidebook on WordPress rather than a purpose-built platform.
Why it mattered: WordPress integrated cleanly with tools IBM sellers already used, so the guidebook didn’t ask anyone to learn new infrastructure.
Tradeoff: Less flexibility than a custom build, but adoption mattered more than capability — a more powerful tool nobody opened would have been worse than a simpler one people actually used.

Centralized Information

What I did: Designed one entry point with strong search and segmented content (general users, enterprise sellers, other roles), instead of separate resources per team or product line.
Why it mattered: Sellers had no time to figure out which of several resources applied to them. One searchable hub removed that decision entirely.
Tradeoff: Centralizing meant taking on more upfront content architecture work, so the navigation and segmentation had to be right before launch — there was no easy way to course-correct structure later without disrupting a resource people had started to rely on.

Process

Research and Analysis
To understand the barriers to platform adoption, I conducted stakeholder interviews with sellers and managers. These sessions revealed key pain points: high cognitive load, limited time for training, and a lack of clear, accessible resources. I also analyzed existing workflows and tools to identify opportunities for integration.
Content Strategy
Based on the research, I developed a content strategy that prioritized user needs. This included:
- Product Pages: Detailed overviews of features, benefits, and seller testimonials to quickly convey value.
- Knowledge Base: Segmented articles tailored to general users, enterprise sellers, and other specific roles.
- Video Library: Organized recordings of training sessions and meetings, searchable by user goals.
Prototyping and Testing
Using wireframes and interactive prototypes, I tested the guidebook’s usability with key user groups. Feedback from these sessions informed improvements in navigation, content layout, and search functionality.
Development and Launch
I collaborated with developers to build the guidebook on WordPress, ensuring seamless integration with existing IBM tools. After thorough QA testing, the guidebook was launched as a centralized resource for sellers and managers.
Iterative Updates
Post-launch, I continued to gather feedback and expand the guidebook’s content to support new initiatives and adapt to evolving user needs. This iterative process ensured the guidebook remained relevant and effective over time.

Learnings

The Importance of User Involvement
Engaging users early in the design process provided invaluable insights into their pain points and needs. By including sellers and managers in interviews and testing sessions, we were able to design a solution that genuinely resonated with them, driving adoption and satisfaction.
Cognitive Load Matters
Simplifying workflows and reducing the cognitive burden were critical to the guidebook’s success. Sellers and managers were more willing to adopt the platform when it felt intuitive and didn’t interrupt their primary focus: closing deals.
Iterative Design is Key
The iterative approach—building prototypes, gathering feedback, and making improvements—ensured the guidebook addressed real-world challenges. Continuous feedback loops enabled us to fine-tune features and keep the resource relevant post-launch.
Effective Content Strategy Drives Engagement
Providing tailored content, organized for different user roles and needs, significantly improved usability and engagement. A one-size-fits-all approach would not have worked in such a diverse user environment.
Collaboration Enhances Outcomes
Working closely with cross-functional teams, including developers and stakeholders, allowed for seamless implementation and alignment with business objectives. This collaboration ensured the guidebook met both user and organizational needs.

These learnings have strengthened my approach to user-centered design and reinforced my commitment to creating solutions that balance user needs with business goals.

Final Thoughts and Impact

The core decision underneath this project was resisting the instinct to add more training or more push from managers, and instead removing friction from the tool itself. That meant treating cognitive load as the real constraint, not adoption numbers. The guidebook worked because it asked less of sellers, not because it offered more content — and that’s the tradeoff I’d point to first if someone asked what actually moved the needle here.