case study-leaming ecosystem design
They didn't need more training. They needed us to ask better questions.
CLIENT
Claros (B2B SaaS)
MY ROLE
Lead Learning Experience Designer
DURATION
5 months
SCOPE
Discovery · Stakeholder facilitation · Change strategy · Digital learning experience
What we achieved
-31%
Reduction in 18-month
churn
-34%
Support ticket volume,
weeks 4-12
-5 wks
Time-to-proficiency: 11
→ 6 weeks
+41%
Feature adoption at 90-
day mark
case study-leaming ecosystem design
How we achieved it
High completion. High confidence scores. 68% churn within 10 months. The training data said it was working. The adoption data said otherwise — and that gap is a change problem, not a content problem.
Next we started the power of asking why and following the steps below.
Discovery
Completion sat at 31%, yet the people who did finish scored well and reported high confidence. That gap was the first clue something deeper was going on. Workshops surfaced a pattern I came to call the Confidence Trap: users practised on clean demo data, scored well, and then froze the moment their own messy real-world data showed up in production. The training hadn't failed it had just never met the conditions people actually worked in. A readiness gap, not a content gap.
Define
A full-day workshop got Product and Customer Success in the same room for the first time. Two teams who'd never compared notes started describing the same customer moment in completely different language — one team saw a training gap, the other saw a support ticket. Naming the Confidence Trap gave both sides a shared problem to design against. The alignment that's usually missing before change can stick.
Design
Three iterations followed. The first made completion worse — proof that more content wasn't the answer. The second proved the branching-scenario format could work, but used demo data too clean to trigger the freeze we were designing for. The third paired real, messy data profiles with contextual in-product prompts placed at the exact moments users hesitate.
Build
Four weeks after the third version went live, I reviewed the module's usage data and found hesitation clustering hard around one specific decision point — the moment a learner had to judge whether something in front of them was a genuine data error or just normal real-world noise. That single moment became the one the in-product prompts were rebuilt around, and the same moment the support model was eventually tuned to catch first.
Measure
The data from the live pilot is what surfaced this — running it in production, not in a workshop, is what gave up the information that mattered.
Live learner dashboard .
View a dynamic dashboard with live data, which tracks real choices , decision time and drop off rates. All factors that were measured in order to ensure the learning solutions were updated to match learner data throughout the project.
To replicate LMS/LXP data tracking and handshakes between systems, for this prototype, I used App scripting, and Loocker Studio in Google.
Take this prototype for a spin.
The module I built around that single moment is called “When the demo data is gone.” It puts new users through the exact scenario where confidence used to break and before it happens to them for real, with their own messy data on the line.
This is the V2 branching scenario, the iteration that proved the format before I got the data right. It gives you a feel for the decision architecture, the branching logic, and what it’s like to structure scenario-based learning for a technically complex product.
12 minutes – branching scenario. 3 diverging paths Articulate Storyline 360