Madurez y stack para UX Research

Quien a estas alturas no esté convencido de que Reddit es, entre otras, muchas cosas, una fuente inagotable de conocimiento en forma de descubrimiento y contraste de pareceres, es que se ha dejado llevar definitivamente por el algoritmo. Contra eso vengo personalmente luchando desde que, en octubre del 22, el modorro de Melon tomó el control de lo que fue para mí siempre la herramienta de descubrimiento de referencia: Twitter.

Pues bien, en esta ocasión vengo por aquí compartir un hilo bastante interesante, no exento de polémica, sobre el stack de herramientas para equipos de UX Research. Y está bastante bien porque ejemplifica modelos de equipos de investigación con usuarios, pero también ofrece una panorámica bastante pedagógica sobre el tipo de herramientas que hay en el mercado, su función y la orientación para la que pueden estar optimizadas.

A ver, en el fondo estamos hablando de revisar una serie de cajas de herramientas para modelos de equipos de research, pero en el camino se pueden aprender cosas interesantes.

De momento, lo que he hecho, ha sido agarrar todas las herramientas sugeridas en el hilo y ordenarlas en varias tablas, en función de su utilidad y el enfoque para el que parecen optimizadas.

Ahora la pregunta es, y esto ¿cómo lo encajo en mi equipo? Obviamente, esto va a depender de cada equipo y de cada organización. Yo os puedo contar que en el equipo del estudio lo organizamos sin mucho drama, en primer lugar. A medida que han ido viniendo las necesidades, hemos modificado la caja de herramientas. Os cuento un poco cómo ha sido el proceso.

Al principio, cuando el equipo era pequeño inestable tirábamos de herramientas que nos daban la solución completa para las necesidades existentes. Al principio de los tiempos —habrá gente a la que esto le va a pegar una patada en el botón de la nostalgia— utilizábamos Morae. Dicho ahora suena gracioso, pero es lo que había en aquel momento. He de decir que valía una pasta y además tenía unas necesidades de hardware que ahora veríamos como marcianas.

Posteriormente, estuvimos utilizando Lookback. Era una herramienta que nos servía, especialmente para trabajar en remoto, daba una solución bastante razonable para el tema de los móviles, era muy asequible en precio, permitía integrar observadores externos, y podíamos lanzar URL con streaming en español y en inglés (con traducción simultánea). Pero ahí seguíamos con la fórmula de utilizar una herramienta que nos proporcionase todo lo que necesitábamos para solventar el reto de turno.

Cuando el equipo se volvió más estable y más maduro, nos configuráramos por nuestra cuenta la caja de herramientas basándonos en algo de lo que me habréis leído últimamente, el ecosistema de trabajo del Estudio. En nuestro caso, Google Workspace. Todo lo que tiene que ver con entrevistas y comunicación nos solventamos con Google Meet. La toma de notas la solventamos con un Google Spreadsheets personalizado para poder incorporar automáticamente timestamp y atajos de teclado para los eventos de las anotaciones. El análisis, exactamente igual, el Excel de Google.

Todo esto salta por los aires cuando el research lo hacemos para cliente corporativo, que tiene su propio stack de herramientas, y en su caso —como ejemplo máximo de flexibilidad, a la hora de abordar este tipo de proyectos— herramientas exclusivas, propietarias (para nosotros de un solo uso) sin posibilidad de registro y archivo, en el caso de clientes que tienen unos altísimos estándares de seguridad, privacidad y confidencialidad.

Así que la conclusión que yo puedo tener aquí al respecto de estos debates sobre las cajas de herramientas, tienen una relación directa con dos vectores. El primero es claro y evidente: el nivel de madurez del equipo de research. El segundo también es bastante contundente: el nivel de madurez del cliente.