Senior Product Designer · 4 months
Rethinking HERE's in-platform developer assistant after it stalled at around 3% retention.
The story in three acts
Act 1 · The setup
v1 helped you orient and generate a snippet, then left you to it. Retention sat at ~3%, the code and map panels barely got used, and the assistant kept handing developers generic answers to specific problems.
Act 2 · The turn
I synthesised tickets, Jira, and analytics into a six-stage journey with an emotional curve, then turned each bet into a falsifiable hypothesis with an explicit kill signal. The reframe: the assistant doesn’t lack information, it lacks context, integration, and actionability.
Act 3 · The payoff
Retention moved from ~3% to ~18% at four weeks, self-resolution jumped 35 points, time to resolution dropped 45%, and support tickets fell 30%. Two of the five capabilities shipped fully validated; the rest are sequenced behind them.
What
A v2 of HERE's in-platform developer assistant that finishes work instead of just answering questions: detects intent, contextualises responses, returns clickable actions, keeps work in the conversation, and hands support a pre-filled ticket.
Why
v1 was an LLM tool that dumped generic answers on developers and hoped for the best. They tried it once and didn't return. Retention sat at ~3%, and people barely touched the code and map panels.
How
Synthesized tickets, Jira, and analytics into a 6-stage as-is journey with an emotional curve, then clustered pains into four problem areas.
Turned each bet into a falsifiable hypothesis with an explicit kill signal, defining success before designing.
Validated v1-vs-v2 prototypes with a moderated study (n=10) and a 2-week instrumented pilot with test customers.
Journey map, as-is vs to-be
01
Orient
As-is: 🤔 Curious
To-be: 🧭 Oriented
02
Learn
As-is: 🌱 Hopeful
To-be: ✅ Confident
03
Build
As-is: 🥴 Friction
To-be: 🚀 Flowing
04
Debug
As-is: 😣 Frustrated
To-be: 🛟 Supported
05
Escalate
As-is: 😮💨 Resigned
To-be: 🤝 Handed off
06
Return
As-is: 👋 Gone
To-be: 🔁 Re-engaged
Emotional curve
Dashed grey traces the as-is emotional arc, solid indigo shows the redesigned to-be arc. Pains and needs feed directly into the design principles and problem set.
Measured impact
What I learned
Retention isn’t a content problem, it’s a finishing problem. Developers came back when the assistant completed the task, not when it explained it better.
Falsifiable hypotheses with kill signals saved months. Defining what would make us stop before designing kept the team honest when results were mixed.
A journey map with an emotional curve is the artifact that aligned product, engineering, dev rel, and support faster than any deck I’ve written.