
Repositorio de investigación: que los hallazgos no se pierdan
Qué guardar en un repositorio de investigación, cómo etiquetarlo y buscarlo, quién lo mantiene y por qué la mayoría de los repositorios acaban abandonados.
¿Qué problema resuelve?
La mayoría de los equipos investiga más de lo que recuerda. Un estudio termina con un informe en una carpeta, un par de diapositivas en una reunión y un hallazgo que nadie vuelve a leer. Seis meses después, otro equipo empieza la misma investigación, y el conocimiento ya estaba disponible.
NN/g lo define como un lugar central donde se guardan los artefactos y resultados de la investigación para que otras personas de la organización puedan acceder a ellos. Su valor no está en almacenar, sino en que otros encuentren y reutilicen lo que necesitan.
¿Por qué le importa a un diseñador junior?
Porque cada estudio que haces deja material que otros podrían reutilizar. Si cada entrevista queda en un documento con un nombre distinto, el trabajo se vuelve invisible. Un junior que propone una convención de nombres, un resumen de una página por estudio o una etiqueta común ya está contribuyendo a la memoria del equipo.
Además, un repositorio te obliga a pensar en lo que realmente importa de una investigación: el hallazgo, su evidencia y el nivel de confianza que tiene.
¿Qué conviene guardar?
En Research Repositories 101, NN/g recoge una encuesta a 411 profesionales sobre qué guardan sus repositorios. Los resultados muestran un patrón claro:
- Informes: los guarda el 70 %.
- Grabaciones, transcripciones, notas e insights: más de la mitad.
- Clips y materiales del estudio (planes, cuestionarios de reclutamiento): entre un tercio y la mitad.
- Datos de participantes y consentimientos: menos de un tercio.
Ese último dato es el que más conviene revisar. Guardar una grabación sin el consentimiento asociado puede ser un problema legal y ético, y sin datos de participantes es difícil volver a contactar a la misma persona. Un repositorio sano guarda el hallazgo, la evidencia que lo respalda y la base legal para usarla.
¿Cómo se organiza?
NN/g distingue dos modelos. Las bibliotecas de documentos son fáciles de alimentar y mantener, porque cada estudio se sube como un bloque, pero cuesta encontrar un insight concreto. Las bases de insights hacen fácil encontrar hallazgos específicos, pero les falta contexto, aportar lleva tiempo y exigen mantenimiento: actualizar, refinar o retirar insights. Un híbrido, donde la base de insights enlaza a la carpeta del estudio de origen, es posible y suele ser la opción práctica.
Para las etiquetas, NN/g recomienda:
- Empieza con pocas etiquetas amplias. Una taxonomía pequeña es más fácil de aprender y de cambiar.
- Evita las etiquetas demasiado granulares y asume que iterarás.
- Prueba la estructura con tree testing o card sorting, como harías con la arquitectura de un producto, para validar etiquetas y carpetas.
- Permite buscar por palabras clave como grupo de usuarios, producto o funcionalidad.
Para arrancar, NN/g propone cuatro pasos: conseguir apoyo (con el retorno esperado si hace falta presupuesto), hacer investigación de descubrimiento antes de elegir herramientas o estructura, empezar simple migrando primero lo más útil, y planear la incorporación y el manejo del cambio, porque la resistencia es habitual. También señala rasgos que favorecen la adopción: acceso fácil, permisos flexibles (no debe ser público), navegación clara y buena búsqueda.
Para la lógica de estas decisiones, el artículo sobre arquitectura de la información explica principios que se aplican igual aquí.
¿Quién lo mantiene?
Esta es la parte más olvidada. NN/g indica que crear y mantener un repositorio suele ser responsabilidad de ResearchOps, y que los insights necesitan actualizarse, refinarse o retirarse. Pero en la práctica el dueño casi nunca es ese perfil, como muestra la sección siguiente.
Un hallazgo de hace tres años sobre un flujo que ya no existe no es un activo: es un riesgo, porque alguien puede tomarlo como verdad. Por eso un repositorio necesita una cadencia de revisión, aunque sea pequeña. Para el papel de esa función en el equipo, mira ResearchOps.
¿Por qué fallan los repositorios?
En Why Research Repositories Fail, NN/g analiza una encuesta a más de 400 profesionales de UX y ReOps, con entrevistas de seguimiento. Algunos hallazgos:
- Pocos prosperan. Solo el 9 % tenía un repositorio maduro y activo, y el 11 % dijo que el suyo estaba estancado u olvidado. Menos de la mitad reportó buena adopción y el 19 % la calificó de mala.
- Sin dueño. El 29 % no tenía dueño, y solo el 8 % tenía a un profesional de ResearchOps como dueño.
- Cuatro motivos de fracaso. Madurez UX muy baja, frustración con las herramientas (el 23 % estaba insatisfecho con la suya), falta de dueño y demasiado trabajo para contribuir. NN/g no los ordena por frecuencia.
- Herramienta equivocada. El software genérico de colaboración, como SharePoint o Confluence, tuvo una satisfacción mediana de 3 sobre 5, frente a 4 de las plataformas de investigación y de las herramientas de bases de datos. La diferencia fue estadísticamente significativa.
Las recomendaciones de NN/g: fijar desde el inicio las reglas de etiquetado y la estructura, porque cuesta cambiarlas cuando el contenido se acumula; documentar la taxonomía y compartirla con quienes aportan; mantenerla simple; y programar una revisión periódica de gobierno y mantenimiento. Que pocos prosperen no vuelve imposible el repositorio: indica que el mantenimiento es la parte difícil.
¿Cuándo NO conviene montar un repositorio?
- Sin objetivos de investigación claros. Un repositorio vacío o lleno de cosas que nadie consulta no sirve. Por eso NN/g recomienda hacer investigación de descubrimiento antes de elegir herramientas o estructura.
- Si no hay nadie que lo mantenga. Sin dueño, es mejor una carpeta compartida con un formato sencillo que un sistema complejo sin mantenimiento.
- Si el estudio es tan pequeño que un resumen de una página por investigación basta.
Ejemplo
Ejemplo ilustrativo: una empresa de logística tiene tres equipos que investigan sobre la app de conductores. Un equipo acaba de descubrir que los conductores no entienden la notificación de retraso.
- Antes: el hallazgo está en un informe de 40 páginas en una carpeta de otro equipo. Nadie lo encuentra.
- Después: el equipo crea una ficha de una página, con la pregunta, los participantes (sin datos personales), el hallazgo, la evidencia y la etiqueta “notificaciones”. Lo guarda en el repositorio.
- Mantenimiento: a los seis meses, el equipo de notificaciones revisa las fichas de su etiqueta, marca una como superada por un rediseño y la retira.
La ficha de una página hace más por el equipo que un informe perfecto que nadie abre. Si quieres trabajar con la síntesis de estas fichas, el artículo sobre síntesis de entrevistas con IA muestra qué puede automatizarse y qué conviene revisar a mano.
Errores comunes
- Subir la investigación después del hecho, en vez de durante el análisis.
- Guardar grabaciones sin consentimiento ni datos del participante.
- Etiquetar con demasiado detalle desde el primer día.
- Comprar un repositorio antes de definir cómo se guardan los hallazgos.
- Dejar que los insights viejos se queden como verdades vigentes.
- No asignar un dueño con tiempo para mantenerlo.
Fuentes
- Nielsen Norman Group, Research Repositories 101
- Nielsen Norman Group, Why Research Repositories Fail