Construir un repositorio de investigación de usuarios es útil, satisfactorio y una herramienta para descubrir insights. Lo sé porque construí uno el mes pasado.

No soy el primero en hacerlo y el mejor que he encontrado a disposición del público es el que creó el Ayuntamiento de Hackney, en Londres.

Como investigador de usuarios autónomo, mi cliente me pidió que construyera un repositorio. Era necesario porque se perdían conocimientos, se duplicaba el trabajo y se perdía tiempo repitiendo el trabajo existente.

Mi proceso para crear el repositorio fue el siguiente:

Edición: Mi cliente se ha puesto en contacto con nosotros para decirnos que está encantado de ser mencionado. Así que un gran saludo al proyecto OneWeb de la Universidad de Southampton, que está creando una experiencia más centrada en sus usuarios. Ha producido una gran cantidad de resultados, por lo que necesitaba el repositorio y la actualización de sus necesidades.

Aquí hay que tener en cuenta dos cosas:

En lo que respecta a lo que cuenta como archivo relevante, adopté el siguiente planteamiento:

"¿Qué querría yo saber como usuario investigador que llega a ciegas a este proyecto?"

Por lo general, es peligroso que un investigador de usuarios se ponga en la mente de su usuario, pero como el público principal (aunque no exclusivo) son los investigadores de usuarios, me pareció justo. Si quieres una investigación de usuarios completa y adecuada, la página de Hackney tiene esto.

Los archivos típicos relevantes incluyen: historias de usuarios, personas, informes finales y resultados, planes de investigación, guías de discusión, listas de paneles de usuarios, fotos y vídeos de las sesiones, entre otros.

En cuanto a dónde se ubicarán estos archivos, eso es un dolor de cabeza. Cada organización en la que he trabajado ha variado su medio de almacenamiento en función del software principal utilizado en ese momento, las preferencias del equipo y el uso individual (por ejemplo, alguien tiene una suscripción a un software que declara que es "la mejor" solución que ningún otro equipo utiliza). Los equipos suelen disolverse después de un proyecto, sus miembros se dispersan y los archivos se pierden o se borran.

Así que, aunque haya una ubicación central obvia, como SharePoint, tendrás que preguntar por ahí y seguir los viejos enlaces a archivos en viejos ordenadores, Google Drives personales, DropBox, Miro, Optimal Workshop... ya te haces una idea.

Así que pregunta, pregunta y vuelve a preguntar a cualquiera que haya estado en un proyecto, entra en Linkedin y rastrea a antiguos miembros del equipo y pídeles que hagan memoria para ver qué archivos puede haber.

Una vez que tengas todos los archivos que necesites (o creas que los tienes), realiza una selección. A grandes rasgos, identifica:

A partir de ahí, crea tus enlaces en una ubicación central. Recomiendo encarecidamente una base de datos en lugar de una hoja de cálculo (como Excel o Google Docs) debido al control de versiones y la facilidad de búsqueda y actualización.

En una base de datos, hay una referencia única para cada registro y al actualizarla se actualiza todo lo que está vinculado a ella. En una hoja de cálculo, se tiende a copiar hojas, filas y columnas y es fácil perderse.

Hay una serie de opciones de bases de datos, pero primero hay que investigar los precios. Algunas organizaciones utilizan SharePoint, otras AirTable o Coda.io* (yo me decanté por esta última porque es la más económica y permite incluir texto para explicar el contenido).

En ambos casos, puedes abrir la base de datos para que otros la vean, pero restringir quién puede hacer cambios. He evitado las bases de datos más "tecnológicas" como MySQL porque, aunque son más potentes, pueden resultar confusas para el usuario medio.

No importa qué base de datos utilices o si cambias de opinión, ya que la mayoría de las bases de datos permiten exportarlas como un archivo CSV para que puedas importarlas y utilizarlas en otro lugar.

Aquí es donde el uso de una base de datos demuestra su valor. Idealmente, cuentas con una serie de etiquetas posibles — nombre del proyecto, tipo de artefacto (persona/informe, etc.), fase del proyecto — para etiquetar los elementos.

Pero esto puede cambiar y sólo es evidente una vez que puedes agrupar por etiquetas. Tener una base de datos significa que la actualización del nombre de una etiqueta actualizará el nombre en todos los registros.

Así que no te preocupes por tener las etiquetas correctas al principio, puedes editarlas y fusionarlas más adelante.

La parte más demandante de esto es encontrar los archivos y subirlos. No es lo más divertido, pero si te gusta la organización, es satisfactorio. Si no te gusta la organización, pues es una tarea imprescindible.

La agrupación es donde empiezas a tener que pensar. Con las etiquetas puedes agrupar los documentos por su nombre, proyecto, etapa y otras categorías que te ayuden a descartar cualquier documentación o cruce.

Esta sección se hizo tan larga debido a los ejemplos y la importancia que he dividido esto en un post separado sobre el refinamiento de las necesidades del usuario (N. del T.: enlace al post original en inglés).

Lo siento, un salto a mitad de camino no es la experiencia ideal para el usuario, pero tampoco lo es un post único muy largo.

Una vez que hayas creado tus repositorios debes dejar claro que son documentos vivos para ser consultados, revisados y actualizados. Has creado un repositorio, pero para que se convierta en la única fuente de verdad, hay que contar con otros.

Los puntos más importantes que hay que incluir en el proceso son:

También hay que explicar y evangelizar a los usuarios clave – user researchers, project managers, jefes de equipo – que el repositorio existe para su beneficio y por qué esto es un beneficio.

Esto incluye hacer demostraciones, dar charlas, escribir artículos en el blog y poner al día a los demás.

También recomiendo que, además de convertirlo en una parte clave del proceso de flujo de trabajo del proyecto, designes a alguien que te ayude a supervisarlo y que así sea una experiencia compartida.

¿Cuánto tiempo ha durado todo?

Para una organización madura con varios proyectos de investigación flotando en su sistema, yo dejaría un mes para que alguien que trabaje a tiempo completo en esto pueda crear tanto un registro de documentos como actualizar las necesidades de los usuarios:

Parece mucho trabajo, y lo fue, para hacerlo bien. Los beneficios apenas están empezando a ser percibidos, pero debería ahorrar tiempo.

Por ejemplo, suelo preguntar a quien tengo alrededor cuando empiezo un nuevo proyecto, pero las respuestas podrían ser incompletas. Puede que no haya contactado con las personas adecuadas, o que éstas no consideren que su trabajo es relevante, o que les falte tiempo para responder.

De esta manera, podía empezar un proyecto sin archivos esenciales que podrían haber ayudado a mi planificación.

En cambio, tener la información clave documentada en un lugar al que puedo acceder cuando la necesito, me ahorra tiempo y esfuerzo para conseguir la información.

Me gusta pensar que el tiempo invertido en crear esto se verá recompensado muchas veces por el tiempo que se ahorrarán los demás en la búsqueda de esta información, en la reducción del trabajo repetitivo, y por los nuevos insights que se obtendrán.

He identificado lagunas para que el cliente las investigue y esto debe considerarse sólo la primera revisión.

A medida que más investigadores y equipos de usuarios lo utilicen, más conectarán las necesidades de los usuarios, encontrarán la investigación existente que puede ayudarles y, en última instancia, mejorarán su vida y la de los usuarios en general.

No te olvides de leer la parte complementaria de este post de dos partes, sobre el refinamiento de las necesidades de los usuarios. También puedes conectar con el autor del post original en LinkedIn. (N. del T.: El enlace es al post original en inglés)