As part of the Africa project we mentioned in our previous post, we’ve had to do a lot of desktop research to understand the context in which the work will take place.
Because Africa is a completely new territory for us, we felt we couldn’t just jump straight into fieldwork. Before going on-site, we needed to read, learn, look around, and try to understand, at least from a distance, the reality we were about to encounter.
This meant not only learning about the project’s specific area (mobile health, European-funded initiatives, etc.), but also understanding the cultural context we would be working in.
We reviewed academic studies describing similar field experiences, reports from health organizations outlining practices used in Kenya, Senegal, and Ethiopia, and documents with recommended guidelines and best practices.
We divided topics among the team, and each week one person presented the most useful findings to everyone else. In this way, we covered more ground in less time. In total, we spent eight weeks building a shared, preliminary knowledge base about the field we’ll soon visit.
A Rare Luxury
We know that having two months just to read and learn is almost unheard-of in consulting. Timelines are tight, and clients usually need answers “yesterday.” Suggesting a bibliographic deep-dive before doing “real research” can sound unrealistic.
However, working on the SkincAIr project has shown us how valuable this step is and how much we lose when we skip it. Desktop research helps us understand what we’re investigating before we start collecting data (interviews, usability testing, etc.).
Starting Blind
In most projects, we are forced to start with very little context. Often there’s only one one-hour kick-off call in which the client tries to explain everything: background, goals, motivations. It may feel efficient, but it usually leaves gaps that weaken the research.
It’s like starting an excavation with no map: you dig a lot, but not necessarily in the right place.
It Doesn’t Always Take a Month (or Ten Papers)
All of this may make desktop research sound like a massive academic effort, but it doesn’t have to be. We can create lighter, realistic versions that fit business constraints.
AI, for example, can speed up searches and synthesis that used to take hours. Sometimes just a few hours at the beginning of a project can significantly change the outcome.
Practical ideas:
Do a quick review of similar projects, internally or externally.
Hold a short session with stakeholders, two hours can be enough, to share what we know (and what we don’t) before starting.
Centralize information from different sources into a shared repository (we used Miro).
It may seem like a waste of time, but in the long run it prevents errors, rework, and duplicated effort. In other words: it saves good time.
Conclusion
Desktop research isn’t an academic luxury. It prepares the ground so we can go in with our eyes open.
It’s not just about reading; it’s about sharpening our understanding before we start asking questions.
As the saying goes:
“If I had eight hours to chop down a tree, I would spend six sharpening my axe.”
In UX research, desktop research is exactly that moment of sharpening the axe.
