A new way of working rarely fails because the material was wrong. It fails because the design started from the content — the modules, the deck, the e-learning — instead of from the behaviour you actually want, and what's stopping people from getting there. Information has never been behaviour change, but most rollouts are built as if it were: explain it well enough and people will do it. They mostly don't.
Whether a learning journey changes how people work is decided mostly before you build anything — in how sharply you name the goal, how well you understand the blockers, and whether the people who have to live the new behaviour helped shape it. This article is about that earlier, harder part: what to design, and how to know it's right.
If you already know what you want and just need to build it, building a learning journey covers the mechanics. Here we're upstream of that — deciding what should go in the journey in the first place.
Start from the behaviour, not the content
Begin with a plain question: what do we want people to do differently — which behaviours, in which roles, in which situations? Not "what should we teach," but "what should change." Most rollouts skip this and start broadcasting everything in the playbook at once. If you don't prioritise — pick out what genuinely matters and what needs support — you leave it to chance, and something will get the attention anyway, just not on purpose.
The reframe matters most for complex behaviours — a needs analysis, a difficult customer conversation, a manager's first hard piece of feedback. There's no single right move to memorise; "right" depends on the situation. You can describe the principles, but you can't explain judgement into existence. So the design goal shifts: not to transfer information, but to build practice, reflection, and discussion around real work.
Find what "good" looks like — in your own people
Generic best practice doesn't travel. What lands is what good looks like here — in this company, this role, this week. And you already have it: the people who quietly do the new behaviour well before anyone rolls it out.
So before you write a single module, find them and study what they actually do, step by step. The account manager who already uses the new tool to prep difficult calls. The salesperson whose account plans are the ones you'd want everyone copying. Their real, local examples are worth more than any polished generic tip, because colleagues recognise them — that's someone like me, doing my job — and recognition is what makes a new behaviour feel possible instead of aspirational.
Find the blockers, and design from the gap
The other half of the picture is what's stopping people — and not every blocker is the same kind. That matters, because the kind of gap decides whether training is even the right tool, and what it should look like. Four show up again and again:
They don't know what to do. A real knowledge gap — a brand-new manager who's never heard of situational leadership. It's the easiest to close, and sometimes a clear email is enough.
They know, but can't yet. They can describe a good feedback conversation but have never had one — like watching swimming videos, then standing at the edge of the deep end. This needs practice, not more explanation.
They can, but don't. The manager who gives great feedback to her kids but never to her team. Nobody asks, nothing rewards it, a hundred things feel more urgent — a motivation gap no course fixes.
The everyday prevents it. She wants to, knows how, could — but the calendar's been full since eight. Her week makes the behaviour impossible, and a workshop changes none of that.
Only the first is really an information problem, and it's the rarest. Often it's a mix — but naming which gaps you're actually facing stops you building a workshop for something a workshop can't touch. So ask the target group directly, and ask all of them, not the handful who'd volunteer for a workshop. In Knowly you can send the questions to the whole group as an evaluation and get structured answers back, so you're designing from what most people actually said, not from ten replies. Then design from the gap: these behaviours, these examples, these blockers — not guesses about what information might be missing.
Bring the target group into the design
Here's the move that makes the whole thing hold: don't design for the target group, design with them. Turn what you heard into a first sketch of the goal — the behaviours, why they matter, what's hard about them, what good looks like. Then send it back to a slice of the group with one question: what did we get wrong? what's missing? you have details we don't. They answer. You revise.
Then do it again one level down: a design plan — what each part of the journey focuses on, how the sessions and peer meetings run — back to the group and their managers for comment. They answer. You revise again. Only when the goal and the plan hold up do you actually build the journey in Knowly.
It's slower up front, and it's exactly why the finished design feels right to the people using it — because it's their right, not one imposed on them. A design nobody argued with is usually one nobody owns.
Once the design holds up, the build is the easy part
When the goal and the plan have survived the target group's scrutiny, building it in Knowly is the straightforward part — and the pieces that carry a behaviour past the content are already there to lean on. The manager track runs in parallel so the new behaviour gets noticed and protected in the everyday, and peer groups carry what the content can't — the local, emergent know-how no module can write down.
If running the discovery yourself feels like a lot — the interviews, the goal sketch, the rounds of feedback — that's the part the Knowly team can do with you. Learn the mindset here; reach for help on the heavy lifting.
Either way, the point holds: a design that starts from the goal, and from the people who have to live it, is the one that changes how they work. Everything else is just content, well delivered.