The Case for Industry-Agnostic UX

Why cross-industry experience is a strength, not a gap — and what to do with it on both sides of the hiring table.

Why cross-industry experience is a strength, not a gap — and what to do with it on both sides of the hiring table.


Somewhere along the way, tech hiring started treating industry experience as a credential. Engineers need to know the stack. Product managers need to have shipped in the vertical. And UX practitioners — researchers, designers, and design leaders — need five or more years in fintech, or healthcare, or enterprise SaaS, or whatever space the company happens to be in. I have written before about the broader ways UX hiring is broken — the credential gatekeeping, the algorithmic screening, the fear-based processes that protect no one. Industry experience requirements are another symptom of the same thing. Risk avoidance dressed up as a standard.

Most of my career decisions have come in sideways. I did not plan a clean progression through a single vertical. I moved across industries and disciplines because the right opportunity was in a different space, or because a problem in a new context was more interesting than staying put, and I figured out the domain when I got there. Over time, that stopped feeling like a liability and started feeling like a point of view. I have become what I call industry agnostic.

Here is what that experience has taught me. Industry can be learned. The discipline — especially for experienced practitioners — is much harder to learn. And when hiring filters prioritize domain familiarity over craft depth, they are optimizing for the easier thing to acquire while screening out the harder one.

This is for the practitioners who have moved across industries and wonder if that is working against them. And for the hiring managers who have been requiring industry experience without fully examining what they are actually screening for.

What Industry Experience Actually Provides

Before making the case against industry requirements, it is worth being honest about what they provide.

A UX practitioner with prior experience in your industry brings context that takes time to build otherwise. They know the users, the stakeholders, the regulatory environment, the vocabulary, and the specific failure modes of products in that space. In a role with a short runway or a team with no bandwidth to onboard someone slowly, that context has real value.

The question is not whether domain knowledge matters. It does. The question is whether requiring it before hiring is the right way to get it, and whether the practitioners who have it are actually better at the fundamental work than the ones who don’t.

That question has gotten sharper in the last few years. The ramp on domain knowledge is faster now than it has ever been. AI knowledge bases, internal documentation tools, and AI-assisted onboarding mean that a practitioner joining an unfamiliar industry in 2026 can build context in weeks that would have taken months before. Institutional knowledge that used to live exclusively in the heads of long-tenured employees is increasingly findable, queryable, and synthesizable on day one. The gap between “knows the industry” and “can learn the industry quickly” has narrowed significantly. Using prior industry experience as a hiring filter made more sense when the alternative was a slow, unassisted ramp. That is no longer the only alternative.

What Does Not Change Across Industries

I have done UX and product work across supply chain software, payroll and HR tech, financial services, e-commerce, and live-streaming sports. The industries are genuinely different. The users, the product constraints, the organizational cultures, and the domain vocabulary are all different.

What does not change is the actual work.

User research methods do not change because the product is a warehouse management system instead of a mobile banking app. The principles behind a well-structured information architecture do not shift based on industry. The skill of facilitating a usability test, synthesizing findings, building a design system, running a design critique, or earning organizational credibility for UX work — none of that is industry-specific.

The craft of UX is transferable. The domain knowledge is learnable. Conflating the two is where hiring goes wrong.

For Practitioners: How to Position Cross-Industry Experience

If you have worked across industries, you have probably encountered one of two reactions. Either a hiring manager sees the breadth as evidence of adaptability and curiosity, or they see it as a lack of focus and pass.

The second reaction is worth addressing directly rather than hoping it does not come up.

The practitioners who move across industries are not generalists without depth. They are people who have had to build credibility fast in contexts where they could not rely on domain familiarity. They have had to ask the foundational questions that domain specialists sometimes stop asking because the answers feel obvious. They have seen how different industries approach similar problems and can bring that pattern recognition to bear.

That is a capability. It should be positioned as one.

When talking about cross-industry experience, be specific about what transferred and how fast the domain ramp took. Show the evidence. If you moved from consumer apps into enterprise SaaS and were effective within a quarter, say so and explain what made it possible. The concern hiring managers have is the ramp time and the risk. Address it directly with concrete examples rather than letting the resume speak for itself.

The resume will not win this argument. Your account of how you actually work will.

For Hiring Managers: What to Screen for Instead

If industry experience is standing in as a proxy for something you actually need, the more useful thing is to name that something and screen for it explicitly.

If you need someone who can learn a complex domain quickly, ask how they have done it before. How long did the ramp take? What did they do to accelerate it? What still felt unfamiliar at six months. The answers will tell you more than a resume line.

If you need someone who understands enterprise B2B constraints like long sales cycles, power users, and implementation complexity, ask about those constraints specifically. A practitioner who has worked in enterprise contexts understands these dynamics, whether they came from your vertical or not.

If you need someone who can navigate your specific type of organizational dynamic, describe it and ask how they have handled something similar. That is a capability question, and it does not require prior industry experience to answer well.

These interviews take more preparation than a credential check. They also tell you far more about whether someone will actually be effective in the role.

The Broader Point

Chameleon as a metaphor for being industry-agnostic

Industry experience is one way to reduce the uncertainty in a hire. It is not the only way, and for many roles it is not the best way.

The practitioners who have moved across industries and delivered in each one are not lucky generalists. They have built something more durable than domain knowledge. They have built the ability to learn a domain while doing the work. That is a skill. In a field that is changing as fast as UX is right now, it is arguably the more important one.

For practitioners, own it. Be specific about what transfers between industries and how you built the context you were missing. Make the case yourself rather than waiting for someone to make it for you.

For hiring managers, examine what the requirement is actually doing in your process. If it is filtering out practitioners who have demonstrated they can learn and deliver across contexts, it is not a quality bar. It is just a narrower pool.


Amber Hansford is a Director of UX based in Atlanta who has led design organizations across enterprise SaaS, HR tech, and financial services, with earlier career experience as a Product Manager in ecommerce and live streaming sports. She writes about design leadership, hiring, and the structural decisions that determine whether organizations build well or just build fast.

Leave a Reply

Your email address will not be published. Required fields are marked *