Most job specs treat domain knowledge and design craft as the same category. They're not. One takes fifteen years to build. The other takes three months to acquire.
One figure. Completely still. Everything else a blur.
That’s the image. It’s also the argument.
The year I moved from designing for a streaming platform with two million users to a tool used by NGOs, governments, and field workers across forty countries, I knew nothing about international development.
Not the sector. Not the vocabulary. Not the workflows, the reporting structures, the specific frustrations of someone coordinating a water project in rural Kenya. Zero.
I was probably the least domain-qualified designer Akvo could have hired.
Eighteen months later I had helped redesign core tools used by UNICEF and the Dutch Government, and built a design practice from the inside out.
The domain knowledge came. It always does. It’s the easy part.
What job specs get wrong
Most job descriptions don’t know this yet.
“5+ years of experience in fintech UX.” “Background in healthcare product design required.” “Prior experience in agritech preferred.” These treat domain knowledge and design craft as the same category. They’re not. One you build over fifteen years of deliberate practice. The other you pick up in three months of serious immersion.
Hiring for domain experience when you need design craft is the right answer to the wrong question.
What actually transfers
The skills that travel are the ones that took the longest to build.
Problem framing: identifying what’s actually wrong before deciding what to fix. Research methodology: knowing what questions to ask, how to ask them, and how to tell the difference between what people say and what they do. Systems thinking. Information architecture. Synthesizing complexity into something a user can navigate without a manual. Defending a design decision with rationale that holds under pressure from people who haven’t done the work.
None of that is domain-specific. A designer who can do it in a fintech context can do it in a farming context. The problems look different on the surface. Underneath, the process is identical.
What doesn’t transfer, and why it doesn’t matter
Domain-specific knowledge does have to be acquired. The terminology. The regulatory context. The mental models users in that domain carry. The history of what’s been tried and why it failed.
But you acquire all of it through the research itself.
Sitting with farmers in Uganda teaches you about farming. Talking to field workers coordinating aid distribution teaches you about international development. The research is how you learn the domain, not a prerequisite for doing it. The designer who enters without preconceptions asks better questions than the one who thinks they already know the answers. Fresh eyes and genuine curiosity aren’t weaknesses in a new domain. They’re the whole method.
At LiteFarm I design for farmers across different geographies, languages, and levels of connectivity. I knew nothing about agriculture when I started. That turned out to be the advantage. I had to ask. I had to listen. I had no assumptions to protect. The research taught me the domain. The domain didn’t teach me how to do the research.
The career as evidence
My career has covered entertainment, international development, sustainable agriculture, and AI. These are not adjacent domains. They share no vocabulary, no user base, no regulatory environment, no technical constraints.
What they share: users with real problems that had to be understood clearly before they could be solved well. A method for getting to that understanding. A craft for turning it into something usable.
Entertainment to international development. International development to agritech. Every transition felt like starting over from the outside. From the inside, the tools were identical.
The domain changed every time. The craft traveled with me.
The category error
A job spec that leads with “5+ years of industry experience” and lists design skills second has its priorities inverted.
This happens for understandable reasons. Hiring managers are trying to reduce risk. They want someone who can hit the ground running, who already knows the terminology, who won’t need three months just to understand what the team is building. Legitimate concern.
But the calculation is wrong.
A domain expert with weak design skills doesn’t hit the ground running. They hit the ground confidently in the wrong direction and take the team with them. They know the vocabulary and misdiagnose the problem. They ship fast and solve the wrong thing. The cost of that isn’t three months of onboarding. It’s an entire product cycle.
A designer with deep craft and no domain knowledge is contributing meaningfully within three months. A domain expert with weak design skills still has weak design skills after three years. Hiring for the fast variable and treating the slow one as a given is a category error. It produces teams that know the domain and can’t design for it.
The designer who has worked across genuinely different domains isn’t a generalist in the diluted sense. They’ve tested their craft against radically different problems, different users, different constraints, and found it held.
That’s not a gap on a CV. That’s proof the craft is real.
The domain changes. The craft doesn’t.
Currently leading UX at LiteFarm, designing for farmers across multiple geographies. Previously: international development at Akvo, entertainment at Blinkbox. Get in touch if you’re building something that matters.