Rethinking UX Research in Sri Lanka’s Digital Product Ecosystem

In Sri Lanka’s product ecosystem, UX research is treated as magic or an afterthought. Neither helps us build better products.

A few months ago, I sat in a feature review meeting where a stakeholder turned to me and asked, with genuine sincerity: “So you’ve tested this with eight users, and it seemed fine. Are we good? Is that enough?”

I’ve heard versions of this question more times than I can count. Sometimes it’s scepticism; sometimes it’s the opposite: an expectation that user interviews should tell us everything we need to know before launch. Either way, they reveal the same gap: we don’t yet have a shared understanding of what UX research actually does, and what it doesn’t.

That gap has real consequences. It leads teams to either skip UX research entirely or rely on it for answers it was never designed to give. And in Sri Lanka’s product ecosystem, where teams are lean, timelines are tight, and the pressure to ship is constant, getting this wrong can be expensive. This article is an attempt to bring clarity based on my experience working within Sri Lanka’s product environment and on available information about how UX research is positioned in more mature product ecosystems.

Where UX research fits in a product ecosystem

I find it useful to think about the different functions on a product team as answering different questions. Product decides what to build. Design shapes how it works for the person using it. Engineering builds how it functions at scale. Data shows you what is happening in your product.

UX research answers a different question entirely: why is it happening?

That sounds simple, but it changes everything about how you use it. UX research isn’t a replacement for data; it’s the thing that makes data legible. When your drop-off rate spikes in a particular flow, analytics can tell you where users are leaving. UX research can tell you why they’re confused, frustrated, or losing trust.

Nielsen Norman Group (NN/g) describes UX research as focused on understanding user behaviours, needs, and motivations through observation and feedback, not on validating business success. This distinction is critical for setting the right expectations.

What UX research is, and what it isn’t

At its core, UX research helps answer the question: are we building something people can understand and use effectively?

It contributes by:

• Identifying usability issues early
• Revealing gaps between user expectations and product behaviour
• Challenging assumptions with real user input

However, UX research is often misunderstood when it is expected to:

• Guarantee adoption
• Predict business success
• Fully validate a business solution

The Interaction Design Foundation (IxDF) describes UX research as a discipline that informs design decisions and reduces uncertainty, not one that eliminates it entirely.

There’s another dimension worth naming here. UX research doesn’t just help you understand your user; it helps you place the experiences your business needs within the product in a way people can actually use. A business might need users to complete a verification step, adopt a new workflow, or engage with a feature that drives revenue. UX research helps product teams identify ways to make those activities feel seamless and learnable, rather than forced. That’s UX research making business goals achievable.

The most misunderstood practice: usability testing

Usability testing is one method within a much broader UX research toolkit. However, it also happens to be the most frequently misunderstood in Sri Lanka’s digital product ecosystem. So it’s worth addressing directly.

Yes, testing with five to eight users can surface the majority of usability issues in a given flow. This is well-established in UX research literature, and it holds up in practice. Behavioural patterns emerge quickly when people interact with a prototype. You don’t need a hundred participants to notice that three out of five people can’t find the navigation menu.

But, and this is critical, that’s only true when your goal is to identify friction in a specific interaction. It is not a statement about whether your product will succeed in the market, whether the business model is sound, or whether your feature will drive adoption at scale.

The frustration teams feel about UX research is often a result of asking it the second set of questions and being disappointed when it can’t answer them. That’s not a failure of UX research; it’s a failure of expectations.

UX research as a shared capability, not a siloed service that can’t scale

One pattern I’ve noticed across Sri Lankan product teams is that UX research tends to be treated as a handoff; something that happens at a defined stage, produces a report, and then moves on. There’s an implicit assumption that UX research is something researchers do to a product team: a service function that delivers findings on request.

Scaling UX research starts with how teams think and how they are structured. In practice, this means product managers write sharper problem statements because they better understand the users, designers validate ideas earlier because they understand the value of catching assumptions before they become built features, and business analysts interpret behavioural data more meaningfully because they’ve seen what qualitative context does to a quantitative story. Teams, collectively, get better at questioning assumptions before they become decisions.

None of this requires everyone to become a researcher. It requires UX research to be embedded into how teams think and operate, not a service they occasionally commission.

What this means for how we build

Sri Lanka’s digital product building space is still maturing, and that’s actually an opportunity. We get to decide what good looks like, because we are not inheriting decades of entrenched process like the agency-modelled software delivery space.

That means building teams where UX research is embedded rather than bolted on. Where the question isn’t “did research sign off on this?” but “what do we still not understand about the person we’re building for?” and where data and qualitative insight are read together, not in separate rooms.

The products that will age well are the ones that build genuine trust with users, not the ones that shipped fastest. They’ll be the ones whose teams were most honest about what they didn’t yet know.

UX research, done well, is one of the primary tools for that honesty. Not as a validation stamp. Not as a safety net. As a way of keeping the real human in view, even when the pressure to move is strongest.