
Como parte del proyecto para África del que os hablábamos en el post anterior, hemos tenido que hacer bastante trabajo de desktop research para familiarizarnos con el contexto en el que se va a desarrollar.
Siendo África un territorio tan nuevo para nosotros, sentíamos que antes de lanzarnos a investigar sobre el terreno había que mojarse un poco: leer, aprender, mirar alrededor y tratar de entender, aunque fuera a distancia, las realidades que íbamos a encontrar.
Esto significaba no sólo contextualizar el proyecto dentro de su área específica -salud móvil, proyectos europeos, etc.-, sino también comprender mejor el contexto cultural en el que íbamos a trabajar.
Hicimos una revisión exhaustiva de artículos académicos que describen experiencias de campo similares, informes de organismos de salud que recogen pautas usadas en los países donde se desarrollará el proyecto (Kenia, Senegal y Etiopía), descripciones de buenas prácticas, etc.
Nos repartimos los temas dentro del equipo y, cada semana, la persona encargada de una temática presentaba al resto lo más útil o relevante de lo que había leído. De esa forma pudimos abarcar más en menos tiempo. En total, dedicamos unas ocho semanas y terminamos construyendo una base de conocimiento común, tentativa y compartida, sobre el terreno que pronto visitaremos.
Un lujo poco habitual
Sabemos que disponer de dos meses solo para leer y empaparse de literatura relacionada es un lujo casi impensable en el mundo de la consultoría. Los proyectos suelen tener márgenes de tiempo muy ajustados, y los clientes necesitan los resultados “para ayer”.
Proponer en ese contexto un trabajo de inmersión bibliográfica previa suena, efectivamente, casi fantasioso.
Sin embargo, la experiencia con el proyecto SkincAIr nos ha hecho ver lo valioso que es este paso y todo lo que perdemos cuando no lo hacemos: ese reconocimiento inicial, del objeto con el que vamos a trabajar antes de sumergirnos en la fase de recopilación de datos (ya sean entrevistas, tests de usabilidad o similares).
Entrar a ciegas
En la mayoría de los proyectos nos vemos obligados a entrar en acción con muy poco contexto.
A menudo solo hay una reunión de kick-off de una hora en la que el cliente intenta transmitirnos todo: el trasfondo, las motivaciones y los objetivos.
Puede parecer eficiente, pero suele dejarnos lagunas que empobrecen la investigación.
Es como empezar una excavación sin mapa: acabas cavando mucho, pero no necesariamente en el lugar correcto.
No siempre hace falta un mes (ni diez papers)
Dicho así, parece que el desktop research requiere meses de lectura y un equipo completo, pero no tiene por qué ser así.
Podemos aplicar versiones más ágiles y realistas que se ajusten a los ritmos de la empresa o la consultoría.
La IA, por ejemplo, puede ayudar a acelerar las búsquedas y la síntesis de información que antes eran manuales.
Reservar unas horas al inicio de un proyecto solo para entender mejor el contexto puede marcar la diferencia.
Algunas ideas prácticas:
- Hacer una revisión rápida de proyectos similares, tanto internos como externos.
- Organizar una breve sesión con stakeholders, dos horas pueden ser suficiente, para compartir qué sabemos (y qué no) sobre el proyecto antes de empezar.
- Unificar toda la información proveniente de fuentes diversas en un único repositorio de consulta para el equipo (en nuestro caso, usamos Miro).
Parece una pérdida de tiempo, pero a la larga ahorra errores, duplicaciones y esfuerzo. En otras palabras: ahorra tiempo del bueno.
Conclusión
El desktop research no es un lujo académico, sino una forma de preparar el terreno, de entrar con los ojos abiertos.
No se trata solo de leer, sino de afinar la mirada, de comprender el contexto antes de empezar a hacer preguntas.
Como dice el refrán:
“Si tuviera ocho horas para talar un árbol, dedicaría seis a afilar el hacha.”
En UX Research, el desktop research es, precisamente, ese momento de afilar el hacha.




