What ING taught me about embedding behavioural design into product teams

Most product teams design for the customer they wish they had, not the one they actually have.

I learned this the hard way while working with ING's digital banking teams. They had built what should have been a brilliant savings feature. Clean interface, clear value proposition, logical user flow. But adoption was terrible.

The problem was not the product. It was that they had designed for someone who thinks rationally about money, plans ahead consistently, and follows through on financial intentions. That person barely exists.

Real people are distracted, optimistic about future willpower, and terrible at delayed gratification. The product assumed behaviour that just is not there.

The behavioural design gap

Here is what I see in most product teams. They understand their users' jobs to be done. They map customer journeys. They A/B test religiously. But they still design as if people are predictable, logical decision-makers.

The result is products that work perfectly in workshops and fail in the wild. Features that make sense on paper but get ignored in practice. Apps that solve real problems but never become habits.

At ING, we fixed this by embedding behavioural design directly into the product development process. Not as an add-on or afterthought, but as a core capability that shaped every design decision.

Three steps that actually work

You do not need a behavioural psychology PhD to make this work. You need three practical changes to how your product teams operate.

1. Start every feature with motivation mapping

Before you write a single user story, map the real motivations behind the behaviour you are trying to create. Not the rational reasons people give in interviews. The emotional, social, and psychological drivers that actually predict action.

For ING's savings feature, the rational motivation was "build financial security." But the real motivations were more complex. People wanted to feel in control. They wanted progress they could see immediately. They needed permission to spend on things that mattered to them without guilt.

Once we designed for those actual motivations, adoption jumped 40%.

Try this: For your next feature, list three rational reasons someone would use it. Then list three emotional or social reasons. Design for the emotional ones first.

2. Build friction audits into your design process

Every product team talks about reducing friction. Most only look at interface friction. How many clicks? How clear are the labels? How fast does it load?

That misses the bigger picture. Behavioural friction happens in people's heads, not just on screens. It is the mental effort required to start, the uncertainty about whether this is worth it, the worry about making the wrong choice.

At ING, we started auditing for both types. Interface friction was obvious. But we also found behavioural friction everywhere. Too many options creating choice paralysis. Unclear progress indicators making people give up halfway. Features that required sustained motivation over time without any intermediate rewards.

Make this practical: For every user flow, identify one point where people might hesitate or abandon. Then design specifically to reduce that hesitation. Sometimes it is as simple as showing progress differently. Sometimes it requires rethinking the entire approach.

3. Test for behaviour, not just usability

Most product teams test whether people can use their features. Can they find the button? Do they understand the flow? Do they complete the task in testing?

That tells you nothing about whether they will actually use it in their real life.

We changed how ING's teams think about validation. Instead of asking "can they use this?" we started asking "will they choose to use this when distracted, busy, and surrounded by other options?"

The testing changed completely. We stopped putting people in quiet rooms with clear tasks. We started testing during their actual routines. While commuting. During lunch breaks. When they were genuinely trying to accomplish their own goals, not ours.

The insights were completely different. Features that tested well in labs failed in context. Simple changes, like timing notifications differently, had massive impact on real-world adoption.

Your move: Pick one key user behaviour in your product. Test it in context, not in isolation. Watch how people actually use it when they are distracted and have other priorities.

Why this matters now

Product teams are under more pressure than ever to drive engagement, retention, and growth. But most are still optimising for the wrong thing. They are making features easier to use instead of easier to choose.

The companies that figure this out first will build products that people actually adopt and stick with. The ones that do not will keep wondering why their brilliant features get ignored.

ING's teams went from thinking about users to thinking about humans. That one shift changed everything they built.

Great products are not just usable, they are behavioural.

We've been helping big brands for over 28 years. Book a call and see how we can help you too!