Case Study — AI Product Design at Tovuti LMS
JEM: An AI Journey-Mapping Tool, From Pain Point to Production
Product teams were losing 10–15 hours per discovery cycle synthesizing research by hand. I designed JEM — an AI tool that turns raw sources into editable journey maps — and shipped it with Tovuti's lead engineer inside eight weeks.
The problem#
Journey maps drove Tovuti's product discovery, but building one meant weeks of hand synthesis. The evidence existed — help articles, demo transcripts, support tickets, internal notes — scattered across systems, in formats built for reading, not for structuring. A ticket that says "confusing" does not say which step confused anyone, for which persona, at what stage. Every discovery cycle paid that synthesis tax again: 10–15 hours per cycle, and the resulting map was a static deliverable that started rotting the day it shipped.
The obvious fixes fail in predictable ways. A generic AI chat can summarize sources, but it produces prose, not a structured artifact a team can edit, version, and hand off. And skipping synthesis altogether means designing from the loudest recent complaint rather than the actual pattern. The gap was a tool purpose-built for the research-to-artifact pipeline.
Architecture#
JEM is a five-stage pipeline: ingest sources, scope the map through a guided AI conversation, generate a structured draft, edit it on an interactive canvas, and keep it versioned in a library. I designed the product end to end — the flow, the interfaces, and the underlying data model (Map → Tabs → Personas → Cells → Steps and Frictions) — and it was built on Tovuti's existing stack (Nuxt 3 + Vue 3, Tailwind, Pinia, Cloudflare D1 + R2, the Claude API) with the platform's lead engineer implementing and the principal engineer reviewing infrastructure. Staying on the house stack was a deliberate call: design-system components could be reused directly, and streaming responses made the scoping chat feel like a conversation instead of a batch job.
Source ingestion
Paste, upload, or link raw material. Every source gets a type — help article, transcript, support ticket, KB guide, notes — so the model knows what kind of evidence it is reading, and error states catch format problems before they poison a generation.
Guided scoping chat
A streaming Claude conversation narrows what the map should cover before anything is generated. Directional refinement buttons — "make it more tactical," "focus on one persona," "include error recovery" — steer scope without requiring prompt-writing skill.
Map generation
Claude synthesizes the scoped sources into the journey-map schema: personas as rows, stages as columns, cells carrying actions, touchpoints, thoughts and feelings, challenges, pain points, and opportunities.
Interactive editor
The generated map is a draft, not a deliverable. Teams add, edit, and delete stages and personas directly on the canvas, drag to reorder, and color-code pain and opportunity severity.
Library and versioning
Saved maps carry metadata — source count, persona count, dates — with v1/v2 version tracking and JSON or markdown export for engineering handoff.
What V1 deliberately did not include: a template library, real-time collaborative scoping, Figma export — and no automated Zendesk or Slack integration; sources enter by paste, upload, or link. The bet was to ship the core loop — ingest, scope, generate, edit — and let the first weeks of real use pick the roadmap, rather than guessing at integrations before anyone had used the tool in anger.
Results#
10–15 hrs
saved per discovery cycle
Hand synthesis of docs, transcripts, and tickets → a structured draft in one working session
10
fixes shipped in week one
Launched to an internal test environment, used immediately, iterated immediately
8 weeks
concept to engineering handoff
Product architecture, data model, and UI — designed, built, and verified in production
Lessons#
The first data model was designed in the abstract — and it showed
The schema only became right after it was run against a real discovery project mid-build, which forced changes a whiteboard session never would have surfaced. Next time the schema gets designed against a live project from day one.
Scoping as a conversation beat scoping as a form
The refinement buttons are the design insight I would reuse anywhere: constraining how people steer an AI is interface design, and it is what separates a usable AI tool from a prompt box with instructions.
Ten fixes in week one is the metric I trust most
A tool that surfaces ten real issues in its first week is a tool people are actually using. Adoption shows up as friction reports, not as praise.
FAQ#
Did you build JEM alone?
No. I conceived the product, designed every interface, and defined the data model and source taxonomy; Tovuti's lead engineer implemented it and the principal engineer reviewed the infrastructure. I own the design and the product thinking — the production code was a collaboration, and pretending otherwise would misrepresent both.
Why the Claude API instead of a cheaper model?
Two reasons: multi-source synthesis quality, and streaming. The scoping conversation is the product — if the model reasons poorly across mixed source types, the generated map is wrong in ways users cannot easily see, and if responses do not stream, the conversation stops feeling like one.
Want the mechanics?
Happy to walk through the data model, the scoping-chat design, or what the first week of production taught us.