Rebuilding onboarding around trust

Conversion had been sliding, and the team had already tried a few onboarding changes. None of them held.

Another redesign was the obvious next move. It didn't feel like the right one. When changes keep missing, the frame is usually wrong, not the execution.

Before proposing anything, I wanted to know what the onboarding was actually asking users to believe.

Mapping the flow end to end, reviewing LogRocket sessions, and auditing every decision a user faced before reaching the product surfaced a clear problem: some asks came far too early. Users set their speaking speed, a technical preference, before the product had shown a single moment of value.

Was this a Heylama problem, or the whole category's?

Comparing our onboarding against the big language-learning names and a few smaller AI-first players showed the same thing almost everywhere: they built confidence first, then asked for commitment. Heylama did it the other way around.

The research pointed one way: earn trust before asking for commitment. I designed a five-part onboarding system around that idea, each part building on the last, covering value, conversation, personalization, proof, and progress.

The concept was approved. Then reality got in the way.

In the first sprint, only one part shipped: the value proposition moved to the front. That was the right opening move, but only if the rest came with it, the conversation, the personalization, the proof, the plan.

Then a React Native upgrade broke core parts of the app, and fixing it took priority. Days turned into months, and what was left was a stripped version of the idea, a few screens and a paywall. Conversion fell to 4.3 percent. The direction wasn't wrong, but with a team stretched thin and only the first part live, the plan couldn't hold.

The team rolled back to the last stable release.

The rollback gave me the one thing the deadlines never had: time to test the hypothesis instead of designing around it.

Through moderated sessions with participants from different cultural and life backgrounds, I compared the live onboarding against a redesigned prototype. The goal wasn't to find where users dropped off. It was to find when they stopped believing the product could help them.

The old question mixed motivations, situations, and outcomes into one list, producing decision fatigue and answers the product couldn't really use. Skills changed that. Each one mapped to something the AI could act on immediately, which is what made the personalization credible rather than cosmetic. The cost was context about motivation, given up for choices users could trust.

The screens below cover what changed. What they don't say is why each one mattered. A0 wasn't about granularity, it was about a beginner's first impression: pick A1, hit content that assumes too much, and the takeaway becomes "I'm already behind." Social proof moved earlier because we were asking for effort before earning it. And the feature tour moved after personalization because, until then, features were just claims with nothing to attach to.

The finding was small. What it led to wasn't. We were Heylama with no llama in the product, so Karl went from absent to everywhere, welcoming users, guiding each step, fronting the plan. A lower-pressure first impression, and finally a brand that matched its name.

Personalization had been a promise: tell us about yourself now, we'll use it later. That creates a trust debt. Every question raises the expectation that the answer will matter, and if nothing visible comes back, users start wondering why you asked. Generating the plan in front of them paid the debt. If we ask people to spend effort and personal information, we have to show them where it went.