I had a great discussion with Maayan Klimenko about the Quant UX book and she asked:

What's the difference between a "Consumer Insight Manager" [CX] and a "Quant UXR"?

I've heard this question many times over the years — often asked by executive-level stakeholders. There are several reasons it confuses many stakeholders:

Quant UX and CX both collect information from users/customers and share it with stakeholders, so there is an obvious overlap. Executives may believe it is efficient to combine the two roles.
In any given organization, either UX or CX will be stronger or have a better audience with executives for random reasons (and perhaps one of the roles is not even present). This leads to the question of whether one team's mission should be expanded to incorporate the other.
Stakeholders may consider research to be about "numbers," and then everything numbers-related seems like the same thing to them.
Many organizations confuse "customers" with "users." I say more about this below.

In my experience, CX and Quant UX roles overlap anywhere from slightly to substantially. It depends on the company, its organizational structure, and the product. However, I think CX and UX are distinct albeit overlapping. Although every company has a unique pattern, on average I see several important differences between CX and UX.

I will caveat the discussion here by saying that I've always worked in UX organizations, so I have far greater experience with the UX side of the discussion. These are my reflections from a long-time UX perspective.

Customer != User

Customers are a partial subset of users. People use products they did not purchase, and some purchasers buy products for other people. That occurs in small and obvious ways, such as purchases of gifts, and occurs in systemic, structural ways, such as IT services and self-service kiosks. Thus, the explicit targets of CX and UX are imperfectly overlapping.

Even more importantly, the term "customer" encourages — perhaps unconsciously — a focus on purchases, channels, and revenue. "User" encourages a focus on needs, interaction, and experience.

In practice, this leads CX organizations to focus on the post-purchase experience, such as customer satisfaction, reasons for product returns or churn, and so forth.

UX organizations focus much more (although not exclusively) on the initial phases of product design and engineering. In those early stages of a product lifecycle, UX research identifies unmet needs, issues with a product's interaction model, and so forth.

Again, these are imperfect distinctions and the roles overlap. It is common, for instance, for Quant UX research to examine retention/churn (a "customer" focus) and for CX to report unmet needs that they uncover (a "user" focus). But on average, the focal points of UX and CX activities differ.

Decisions vs. Tracking

Another difference I've observed is how UX and CX relate to decisions. To the extent that the roles inform decisions — in addition to activities such as descriptive research — UX tends to inform decisions early in the product development lifecycle, whereas CX tends to inform decisions that are addressable later. For example, UX may inform A/B decisions about designs or feature implementations, while CX may inform outreach to customers to resolve or fix problems.

Closely related to this is that CX often implements tracking systems, such as customer satisfaction tracking (CSat), analysis of top issues in support logs, and similar efforts, often with monthly or quarterly reporting and goals. The stakeholders for such efforts are typically organization-wide, and the processes become important internal deliverables, such as a dashboard. When UX undertakes such efforts, such as CSat surveys, they are somewhat more likely to target an Engineering organization as the key stakeholder and to have less emphasis on reach and complexity.

UX processes are more closely related to Engineering decisions while CX processes are more often related to broader organizational knowledge. Again, there is a lot of overlap.

Research Novelty

Related to the focus on decisions vs. tracking, UX research is typically designed to answer a single crucial question to inform a particular engineering choice. What needs should we target? Which design is better for users? What issues block or interfere with usage? How do users feel about the product? How does it compare to competitors? When using the product, where do users abandon it?

As a general matter, the implementation of UX research for such questions requires one-off, customized research plans. An appropriate plan to assess A/B preference for this feature, in this product, with this audience, answering to this stakeholder will differ from a plan for that feature, that product, that audience, or that stakeholder.

To the extent that there are similarities across UX research projects, they reflect the embedding of UX researchers within product teams (and thus the product, stakeholder, and perhaps audience remain constant for a particular researcher) as well as the skills and preferences of a given researcher. Yet over time, UX researchers may expect to engage in a vast array of different research projects, and the most fundamental skill for UX researchers is the ability to design research to fit many different situations, selecting among many different methods.

By contrast, the research questions in CX projects tend to be more stable over time, reflecting the greater breadth of stakeholders who are informed by the efforts and the importance of consistent reporting and tracking as noted above. Whereas UX researchers are called upon to develop plans on the fly and deliver quick turnaround, CX builds systems and relationships that endure.

That implies that the fundamental skills for CX analysts emphasize stakeholder engagement, continuity of deliverables, effective communication, and cross-team interaction rather than novel research design. Again, there is overlap and those skills are also important for UX (especially communication) but the degree of emphasis differs.

Technical Complexity

This difference is based on observation: Quant UX tends to have somewhat higher technical complexity than CX. Because it informs immediate decisions and often works with point-in-time data, Quant UX research demands a high degree of research "rigor" (however that may be defined, ranging from data quality to analytic method).

There is a significant downside to complex Quant UX research: it is difficult to explain and also may be difficult to repeat (not because of irreproducible results, but as a practical matter of effort). The complexity becomes valuable in a particular case because of the importance of a specific decision. That makes it worth the effort to explain on a one-off basis with the relevant stakeholders.

CX projects need to be simpler, clearer, and easier to explain because they emphasize broader engagement across an organization. Or, to put it differently, CX projects target foundational informational needs that may be met by straightforward descriptive statistics and time series visualization (backed up with the capability to slice, filter, cross-tabulate, and drill into cases).

When Quant UX addresses one-off decisions, it often forces complexity on the side of data acquisition. When a problem is new, there may be no data pipelines or data quality processes in place. Longer-term projects, as are common in CX, are more likely to work with mature data pipelines. A traditional, informal rule for Quant UX is that it takes at least a month to figure out what data is available for a new question before any analysis occurs. That would be intolerable in many CX organizations.

As for software skills, CX tends to emphasize general data analytic and visualization tools such as Excel, Tableau, Google Analytics, and SQL. Quant UX tends to emphasize R, Python, and/or SQL.

Organizational Position

Finally, there is an organizational difference on average. UX is typically embedded in an Engineering organization as part of product development. This may parallel (but remain separate from) the Product Management team. UXRs are generally assigned to specific products in development. Thus, the UXR team will often directly mirror the allocation of developers and PMs to specific engineering projects.

CX teams appear in many different places, including as part of Marketing, Operations, Engineering, and elsewhere. I have not yet seen a case where the structure of a CX team closely mirrors the composition of the product engineering teams. CX groups are staffed to meet broad goals that span teams.

However, occasionally one of these roles may appear in an organization devoted to the other. For instance, I've seen UXR jobs posted inside CX organizations at government agencies. In those cases, I strongly encourage job candidates — and, even more importantly, managers in those organizations — to inquire carefully about the details of positions to make sure they align with expectations and career success.

Final Thoughts

Any given researcher may enjoy either CX or UX/Quant UX, depending on their preferences, personality, and goals. At the most general level, I expect Quant UX to appeal to researchers who like continual research novelty and somewhat independent research, whereas CX may appeal to those who enjoy building long-term processes and systems with broader, collegial engagement.

For more on Quant careers and organizations, check out Chapters 2-4 in the Quant UX book, or this article about Quant UX at Google. Cheers!

What's the difference? Quant UX vs. CX Insights