
ResearchOps: escalar la investigación sin perder calidad
Qué es ResearchOps y sus áreas (participantes, gobernanza, conocimiento, herramientas, competencias), cómo empezar sin resolverlo todo y cuándo no hace falta.
¿Qué es ResearchOps y qué no es?
ResearchOps no es un rol ni un software. Es un conjunto de decisiones sobre cómo se hace la investigación en una organización: quién recluta a los participantes, dónde se guarda lo que se aprendió, cómo se pide consentimiento, con qué herramientas se trabaja y cómo se forma a los nuevos investigadores.
La comunidad ResearchOps describe ocho pilares: entorno, alcance, personas, contexto organizacional, reclutamiento y administración, gestión de datos y conocimiento, gobernanza, y herramientas e infraestructura. Nielsen Norman Group propone un marco de seis áreas: participantes, gobernanza, conocimiento, herramientas, competencias y advocacy. Los dos modelos coinciden en lo esencial, aunque se dividen las áreas de forma distinta. NN/g aclara que su modelo no es exhaustivo, y que las áreas están relacionadas entre sí, no aisladas.
¿Por qué le importa a un diseñador junior?
Porque la mayoría de los equipos empiezan a investigar de forma artesanal: un investigador, un documento y un correo para reclutar. Funciona hasta que el equipo crece, y entonces aparecen problemas que no son de diseño: estudios repetidos, participantes contactados tres veces en un mes, consentimientos que nadie encuentra y hallazgos que se pierden cuando alguien cambia de empresa.
Entender ResearchOps te permite proponer mejoras pequeñas sin esperar a una gran reestructuración. Un junior que organiza una carpeta común de hallazgos ya está haciendo ResearchOps.
¿Qué áreas cubre?
Según Nielsen Norman Group:
- Participantes: reclutar, filtrar, programar y compensar a los participantes.
- Gobernanza: procesos y guías para el consentimiento, la privacidad y el almacenamiento de la información.
- Conocimiento: procesos y plataformas para recopilar, sintetizar y compartir los hallazgos.
- Herramientas: conjuntos de herramientas y plataformas consistentes que hacen más eficiente la investigación.
- Competencias: capacitar e incorporar a otras personas para que hagan actividades de investigación.
- Advocacy: definir, compartir y dar a conocer en la organización el valor de la investigación.
Kate Towsey, una de las figuras de la comunidad, enumera ocho funciones parecidas en un diagrama propio (reclutamiento de participantes, gestión del conocimiento, incorporación y soporte, herramientas y proveedores, ética y privacidad, dinero y métricas, gestión de programa, y personas y habilidades). Su advertencia es que, al trabajar en una función, acabas trabajando en todas. Las áreas están conectadas, y tocar una obliga a revisar las demás.
¿Por dónde empezar?
- Identifica el dolor más fuerte. Nielsen Norman Group recomienda empezar por los problemas actuales que justifican ResearchOps, porque no se puede abordar todo a la vez. Pregunta al equipo qué le quita más tiempo.
- Empieza por una sola área. Si los estudios se repiten, empieza por el conocimiento: una carpeta común con un formato de resumen. Si faltan participantes, empieza por un registro sencillo de personas dispuestas a participar. Para el reclutamiento en sí, la guía de reclutar participantes es un buen punto de partida.
- Escribe el proceso antes de comprar la herramienta. Una herramienta sin proceso solo copia el desorden a otro lugar.
- Mide el costo a medida que crece. NN/g plantea un escenario hipotético: si la empresa hace diez veces más investigación, el costo no debería ser once veces el presupuesto anterior, sino cerca de nueve por las economías de escala, y la meta de ResearchOps debería ser ocho veces o menos. No son resultados medidos.
- Revisa cada trimestre. Pregunta si el sistema ahorra tiempo o si solo añade pasos.
Towsey advierte, además, que el tiempo que exige ResearchOps se subestima mucho. Conviene empezar con un proyecto pequeño y acotado, no con todo el sistema.
¿Cuándo NO conviene montar ResearchOps?
- Cuando no hay objetivos de investigación definidos. Invertir en sistemas sin preguntas claras produce un repositorio vacío o lleno de cosas que nadie consulta. Towsey advierte que no se puede crear un sistema específico sin tener claro qué se quiere lograr, y llama knee-jerk operations a reaccionar a una urgencia sin pensar en los objetivos de la organización.
- Cuando el equipo es muy pequeño y hace pocos estudios. Con un investigador y dos estudios al año, unas buenas notas y un documento compartido suelen bastar.
- Como excusa para no investigar. El objetivo es que se investigue más y mejor, no que se generen procesos.
Además, el modelo de NN/g no cubre la carrera profesional, la contratación ni el onboarding de investigadores. Esos temas tienen sus propias prácticas.
Ejemplo
Ejemplo ilustrativo: una empresa de software tiene cuatro equipos de producto que investigan por separado.
- Problema: dos equipos entrevistaron a los mismos clientes en el mismo mes. Un tercero no sabía que existía un estudio sobre facturación de hace un año.
- Primera acción: un documento compartido con una plantilla de resumen de 1 página por estudio, con fecha, objetivo, participantes y hallazgos.
- Segunda acción: una lista única de participantes con fecha del último contacto, para no repetir contactos en menos de tres meses.
- Revisión: tres meses después, el equipo pregunta si ya encuentra estudios previos antes de empezar uno nuevo.
Ninguna de estas acciones necesitó una herramienta nueva. Lo que cambió fue el orden. Para el repositorio en sí, el siguiente paso natural es el repositorio de investigación.
Si tu equipo usa entrevistas con apoyo de IA, revisa también el artículo sobre síntesis de entrevistas con IA, porque la gobernanza de los datos de los participantes aplica igual.
Errores comunes
- Creer que ResearchOps es solo reclutar participantes.
- Comprar un repositorio antes de definir cómo se guardan los hallazgos.
- Intentar montar los seis componentes en el mismo trimestre.
- Olvidar el consentimiento y la privacidad hasta que aparece un caso concreto.
- No dejar claro quién es responsable de mantener el sistema.
- Medir el éxito por el número de estudios en vez de por las decisiones que cambiaron.
Fuentes
- Nielsen Norman Group, ResearchOps 101
- Nielsen Norman Group, ResearchOps: An Interview with Kate Towsey
- ResearchOps Community, About ResearchOps