Most job specs lump domain knowledge and design craft into one category. Craft takes fifteen years to build. Domain knowledge takes about three months to acquire.
The year I moved from designing for a streaming platform with two million users to a tool used by NGOs, governments, and field workers in more than forty countries, I knew nothing about international development.
Not the sector, the vocabulary, the workflows, the reporting structures, or the specific frustrations of someone coordinating a water project in rural Kenya.
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 lump domain knowledge and design craft into one category. Craft you build over fifteen years of deliberate practice. Domain knowledge you pick up in about 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 teaches you about farming. Talking to field workers coordinating aid distribution teaches you about international development. The research is how you learn the domain. The designer who enters without preconceptions asks better questions than the one who thinks they already know the answers. In a new domain, fresh eyes and genuine curiosity are 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 was the advantage. I had to ask and listen, with no assumptions to protect. The research taught me the domain.
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, then on to agritech. Every transition felt like starting over from the outside. From the inside, the tools were identical.
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. That costs an entire product cycle, where onboarding would have cost three months.
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 has tested their craft against radically different problems, different users, different constraints, and found it held.
On a CV, that range is 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 hiring for a domain you think is new to me.