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. La plupart des fiches de poste traitent la connaissance du domaine et le métier du design comme s'ils étaient équivalents. Ce n'est pas le cas. L'un prend quinze ans à construire. L'autre s'acquiert en trois mois.
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.
La plupart des fiches de poste traitent la connaissance du domaine et le métier du design comme s’ils étaient équivalents. Ce n’est pas le cas. L’un prend quinze ans à construire. L’autre s’acquiert en trois mois.
Une silhouette. Parfaitement immobile. Tout le reste n’est que flou.
C’est l’image. C’est aussi l’argument.
L’année où je suis passé de la conception d’une plateforme de streaming avec deux millions d’utilisateurs à un outil utilisé par des ONG, des gouvernements et des travailleurs de terrain dans quarante pays, je ne connaissais rien au développement international.
Ni le secteur. Ni le vocabulaire. Ni les méthodes de travail, les circuits de reporting, les frustrations de quelqu’un qui coordonne un projet d’eau en milieu rural au Kenya. Rien du tout.
J’étais sans doute le designer le moins qualifié pour ce domaine qu’Akvo pouvait recruter.
Dix-huit mois plus tard, j’avais contribué à reconcevoir des outils utilisés par l’UNICEF et le gouvernement néerlandais, et construit une pratique design de l’intérieur.
La connaissance du domaine est venue. Elle vient toujours. C’est la partie facile.
Ce que les fiches de poste ne comprennent pas
La plupart des offres d’emploi n’ont pas encore compris ça.
« 5 ans d’expérience en UX fintech requis. » « Expérience en design produit santé indispensable. » « Expérience préalable en agritech souhaitée. » Ces fiches traitent la connaissance du domaine et le métier comme la même catégorie. Ils n’en sont pas. L’un se construit sur quinze ans de pratique. L’autre s’acquiert en trois mois d’immersion.
Recruter sur la connaissance du domaine quand c’est le métier qu’il vous faut, c’est répondre juste à la mauvaise question.
Ce qui se transfère vraiment
Les compétences qui voyagent sont celles qui ont pris le plus longtemps à construire.
La formulation du problème : identifier ce qui ne va vraiment pas avant de décider quoi corriger. La méthodologie de recherche : savoir quelles questions poser, comment les poser, et comment distinguer ce que les gens disent de ce qu’ils font. La pensée systémique. L’architecture de l’information. Synthétiser la complexité en quelque chose qu’un utilisateur peut parcourir sans manuel. Défendre une décision de design avec une justification qui tient sous la pression de gens qui n’ont pas fait le travail.
Ce ne sont pas des compétences propres à un domaine. Un designer qui sait faire ça dans un contexte fintech sait le faire dans un contexte agricole. Les problèmes semblent différents en surface. En dessous, le processus est identique.
Ce qui ne se transfère pas, et pourquoi ça n’a pas d’importance
La connaissance propre au domaine, elle, doit s’acquérir. La terminologie. Le contexte réglementaire. Les modèles mentaux propres aux utilisateurs de ce domaine. L’histoire de ce qui a été tenté avant, et pourquoi ça a échoué.
Mais tout cela s’acquiert par la recherche elle-même.
S’asseoir avec des agriculteurs en Ouganda vous apprend l’agriculture. Parler avec des travailleurs de terrain qui coordonnent la distribution d’aide vous apprend le développement international. La recherche, c’est la façon dont on apprend le domaine, pas un prérequis pour la faire. Le designer qui entre sans idées préconçues pose de meilleures questions que celui qui croit déjà tout savoir. Des yeux neufs et une curiosité sincère ne sont pas des faiblesses dans un nouveau domaine. C’est toute la méthode.
Chez LiteFarm, je conçois pour des agriculteurs répartis sur différentes géographies, différentes langues, différents niveaux de connectivité. Je ne connaissais rien à l’agriculture en arrivant. C’est devenu un avantage. J’ai dû demander. J’ai dû écouter. Je n’avais aucune hypothèse à protéger. La recherche m’a appris le domaine. Le domaine ne m’a pas appris à faire de la recherche.
La carrière comme preuve
Ma carrière a couvert le divertissement, le développement international, l’agriculture durable et l’IA. Ce ne sont pas des domaines adjacents. Ils ne partagent ni vocabulaire, ni utilisateurs, ni cadre réglementaire, ni contraintes techniques.
Ce qu’ils partagent : des utilisateurs avec de vrais problèmes, qu’il fallait comprendre clairement avant de bien les résoudre. Une méthode pour y parvenir. Un métier pour le traduire en quelque chose d’utilisable.
Divertissement vers développement international. Développement international vers agritech. Chaque transition semblait recommencer de zéro, vue de l’extérieur. De l’intérieur, les outils étaient identiques.
Le domaine a changé à chaque fois. Le métier a voyagé avec moi.
L’erreur de catégorie
Une fiche de poste qui ouvre sur « 5 ans d’expérience dans le secteur » et relègue les compétences design au second plan a ses priorités inversées.
Cela arrive pour des raisons compréhensibles. Les recruteurs cherchent à réduire le risque. Ils veulent quelqu’un d’opérationnel tout de suite, qui connaît déjà la terminologie, qui n’aura pas besoin de trois mois pour comprendre ce que l’équipe construit. Préoccupation légitime.
Mais le calcul est faux.
Un expert du domaine aux compétences design faibles ne démarre pas vite. Il fonce avec assurance dans la mauvaise direction et entraîne l’équipe avec lui. Il connaît le vocabulaire et pose le mauvais diagnostic. Il livre vite et résout le mauvais problème. Le coût, ce n’est pas trois mois d’intégration. C’est tout un cycle produit.
Un designer au métier solide et sans connaissance du domaine contribue vraiment en trois mois. Un expert du domaine aux compétences design faibles aura toujours des compétences faibles après trois ans. Recruter sur la variable rapide en tenant la lente pour acquise, c’est une erreur de catégorie. Résultat : des équipes qui connaissent le domaine et ne savent pas concevoir pour lui.
Le designer qui a travaillé dans des domaines vraiment différents n’est pas un généraliste au sens dilué du terme. Il a confronté son métier à des problèmes radicalement différents, des utilisateurs différents, des contraintes différentes. Il a tenu. Ce n’est pas un trou dans un CV. C’est la preuve que le métier est réel.
Le domaine change. Le métier, non.
Actuellement Lead UX chez LiteFarm, je conçois pour des agriculteurs dans plusieurs géographies. Précédemment : développement international chez Akvo, divertissement chez Blinkbox. Contactez-moi si vous construisez quelque chose qui compte.