{"id":17286,"date":"2021-02-12T14:04:04","date_gmt":"2021-02-12T12:04:04","guid":{"rendered":"https:\/\/www.hiberus.com\/crecemos-contigo\/?p=17286"},"modified":"2026-01-12T13:17:04","modified_gmt":"2026-01-12T12:17:04","slug":"disenar-con-las-personas-el-test-de-usuarios-ayuda-a-mejorar-el-gestor-de-expedientes-del-gobierno-de-aragon","status":"publish","type":"post","link":"https:\/\/www.hiberus.com\/crecemos-contigo\/disenar-con-las-personas-el-test-de-usuarios-ayuda-a-mejorar-el-gestor-de-expedientes-del-gobierno-de-aragon\/","title":{"rendered":"Dise\u00f1ar con las personas: mejorando el gestor de expedientes del Gobierno de Arag\u00f3n"},"content":{"rendered":"

El equipo de dise\u00f1o de SDA (Servicios Digitales de Arag\u00f3n)<\/a><\/strong> lleva varios meses trabajando en el dise\u00f1o y desarrollo de una nueva herramienta para la gesti\u00f3n de expedientes.<\/strong> Todo proceso de dise\u00f1o lleva un proceso previo de \u2018Descubrimiento\u2019 para conocer bien las necesidades de los usuarios y problemas a resolver, entre otras cosas.<\/p>\n

Para esta herramienta -el gestor de expedientes- en esa fase de descubrimiento se desarrollaron otro tipo de recursos de trabajo con usuarios: las encuestas<\/strong><\/a>.<\/p>\n

Una vez pasado ese proceso previo, se comienza con la fase de ideaci\u00f3n y prototipado<\/strong>, lo que llamamos la fase alfa. Es aqu\u00ed donde entran en juegos los test de usuarios<\/strong><\/a>, para hacer una primera validaci\u00f3n del prototipo, previa al desarrollo de este.<\/p>\n

Un test de usuario consiste en observar y analizar el comportamiento de un grupo de usuarios reales sobre un producto digital para evaluar la interfaz, no al usuario<\/strong>. De este test se detectan problemas con los que se puede encontrar el usuario, para poder solucionarlos y evitarlos posteriormente.<\/p>\n

 <\/p>\n

Hemos realizado tests de usuarios como recurso de trabajo para desarrollar la nueva herramienta digital de gesti\u00f3n de expedientes del Gobierno de Arag\u00f3n, una manera de lograr detectar las dificultades a las que se enfrentan las personas que utilizan el servicio y poder mejorar el proceso.<\/p><\/blockquote>\n

 <\/p>\n

La idea que hay bajo el hacer tests con usuarios para este servicio es generar retroalimentaci\u00f3n sobre c\u00f3mo iba a funcionar la nueva herramienta.<\/strong> Consisti\u00f3 en hacer una serie de pruebas con las personas usuarias, buscando simular escenarios de uso reales. Esto nos ayudar\u00eda a definir mejor el producto y detectar problemas desde fases tempranas, evitando cambios posteriores para que sea un proceso lo m\u00e1s eficiente posible.<\/p>\n

\"test-usuarios\"

Uno de los usuarios del futuro gestor de expedientes durante la realizaci\u00f3n del test.<\/p><\/div>\n

\u00bfCon qui\u00e9n testeamos?<\/h2>\n

Las personas usuarias para el test, en este caso, estaban acotadas por la premisa de que en su d\u00eda a d\u00eda gestionen expedientes o est\u00e9n involucrados de primera mano en estos procesos como parte de su trabajo.<\/strong><\/p>\n

La cantidad de usuarios necesarios oscila entre 5-15 usuarios: de acuerdo con lo que dijo Jakob Nielsen, el padre de la usabilidad, con 5 usuarios podemos detectar el 85% de los problemas.<\/strong> Esa premisa se cumpli\u00f3 en nuestro proceso, ya que despu\u00e9s del quinto observamos los mismos resultados sin ninguna novedad. Si bien es cierto que esto acaba dependiendo de la complejidad del producto y los objetivos del test.<\/p>\n

Por este motivo, finalmente hicimos los tests con 9 personas usuarias<\/strong>, entre ellas, jefes y jefas de secci\u00f3n, servicio o unidad, personal asesor -t\u00e9cnico o ejecutivo- y unidades de apoyo.<\/p>\n

\u00bfC\u00f3mo fue el proceso?<\/h2>\n

<\/h3>\n

1. Definici\u00f3n de objetivos<\/h3>\n

\u00bfQu\u00e9 quer\u00edamos obtener del test? Se trabaja en una lista con todos los aspectos que se quieren validar en el test<\/strong>. Esto nos ayudar\u00e1 a tener m\u00e1s claro cu\u00e1l debe ser el flujo y las tareas que tienen que ponerse a prueba. Tener los objetivos bien formulados nos ayudar\u00e1 a poder definir los escenarios, las tareas y los criterios de evaluaci\u00f3n del test.<\/p>\n

Para este test de usuarios, fuimos apuntando a lo largo de todo el proceso de dise\u00f1o diversos aspectos que ser\u00eda clave verificar con los usuarios en el test. Bas\u00e1ndonos en ellos construimos correctamente los objetivos y las tareas.<\/p>\n

Los objetivos concretos<\/strong> que determinamos para el test del gestor de expedientes fueron:<\/p>\n

    \n
  1. Evaluar la usabilidad de la herramienta.<\/li>\n
  2. Verificar el user flow de las acciones.<\/li>\n
  3. Comprobar si el usuario dispone de toda la informaci\u00f3n necesaria para su trabajo diario.<\/li>\n<\/ol>\n

    <\/h3>\n

    2. Formular escenarios y tareas y construcci\u00f3n de un guion<\/h3>\n

    Es importante no condicionar a los participantes con palabras presentes en el prototipo,<\/strong> por ello se prest\u00f3 especial atenci\u00f3n a la redacci\u00f3n de tareas. As\u00ed, se redactaron un total de 10 tareas muy concretas, coherentes, entendibles y que siguieran un orden l\u00f3gico.<\/p>\n

    La clave de las tareas es plantear una situaci\u00f3n real y observar c\u00f3mo se desenvuelven en ella y si completan la tarea con \u00e9xito.<\/p>\n

    Ejemplo: Tarea 3: \u00abAccedes al expediente ZA-SP-ENE-AT-2020-014 y, al consultar su documentaci\u00f3n, ves que falta un documento. Como tienes el CSV de este documento, decides a\u00f1adirlo\u00bb.<\/em><\/p>\n

    Con las tareas ya definidas, se construye un guion para el test.<\/strong> Se trata m\u00e1s que nada de un documento que permite estandarizar el test y asegurar que el orden y las instrucciones dadas a los participantes sean las mismas, evitando sesgos. Muchas veces, como en este caso, los tests que se realizan no los lleva siempre la misma persona, por eso este documento resulta clave para que todos se desarrollen siguiendo las mismas l\u00edneas.<\/p>\n

     <\/p>\n

    \"guion

    El guion del test resulta fundamental para moderar el test, teniendo siempre presentes los aspectos a evaluar y evitando posibles subjetividades en caso de haber diferentes personas moderadoras.<\/p><\/div>\n

     <\/p>\n

    Este guion debe contener una introducci\u00f3n en la que se le resume al participante en qu\u00e9 consiste el proyecto y se le explica tambi\u00e9n la prueba.<\/strong> Es importante dejar claro que el prototipo de la prueba no es 100% navegable ni funcional y, por lo tanto, habr\u00e1 elementos que no tengan el comportamiento final.<\/p>\n

    Muy importante: hay que mencionar que NO se le est\u00e1 evaluando a \u00e9l, sino a la herramienta<\/strong>, y remarcar que, si no sabe realizar cualquiera de las tareas que se le proponen, no es culpa suya.
    \nTras la introducci\u00f3n, se pasa a las tareas, las cuales se explican en detenimiento en el siguiente punto.<\/p>\n

    El guion adem\u00e1s tiene que contener un apartado destinado al cierre y los agradecimientos al usuario por su participaci\u00f3n, en este momento se le puede informar de pr\u00f3ximos pasos del proyecto si se considera pertinente.<\/p>\n

    <\/h3>\n

    3. Durante el test<\/h3>\n

    Los usuarios no se deben preparar el test, por ello, en el caso del gestor de expedientes, no les pasamos el link del prototipo hasta el momento de empezar el test para que as\u00ed se enfrenten a \u00e9l por primera vez en ese momento.<\/strong> Nada m\u00e1s abrir el prototipo y antes de comenzar con las tareas, se le realizan una serie de preguntas previas para conocer de forma subjetiva qu\u00e9 le parece la interfaz y qu\u00e9 le trasmite con un primer golpe de vista.<\/p>\n

    A continuaci\u00f3n se le van exponiendo las tareas para que el usuario las realice. En esta parte no se le proporciona nada de ayuda, ni se gu\u00eda al participante para completar la acci\u00f3n con \u00e9xito.<\/strong> La figura del investigador se debe corresponder con un facilitador del test, no un gu\u00eda. La idea es conocer c\u00f3mo ser\u00eda el comportamiento e interacci\u00f3n del usuario con la herramienta a diario.<\/p>\n

    Es importante pedirle al usuario que hable en alto durante la prueba<\/strong> y vaya describiendo todo lo que se le pase por la cabeza, adem\u00e1s de que vaya contando los obst\u00e1culos con los que se encuentra. De esta forma, conseguimos sacar un mont\u00f3n de informaci\u00f3n valiosa que nos permitir\u00e1 definir aspectos a mejorar en el prototipo.<\/p>\n

     <\/p>\n

    \"test

    Gesti\u00f3n de la documentaci\u00f3n del expediente: una de las tareas a realizar en el test.<\/p><\/div>\n

     <\/p>\n

     <\/p>\n

    Al finalizar las tareas, se le realizan al participante una serie de preguntas para averiguar su valoraci\u00f3n general de la herramienta<\/strong>, adem\u00e1s de conocer sus sensaciones realizando el test con el prototipo.<\/p>\n

    Finalmente se lleva a cabo el cierre, en el que se le agradece al usuario su predisposici\u00f3n para participar en el test.<\/p>\n

    <\/h3>\n

    4. Documentaci\u00f3n<\/h3>\n

    Tras el test se revisan las grabaciones de las sesiones para extraer todas las conclusiones y sacar debilidades y oportunidades de mejora.<\/strong> Toda la documentaci\u00f3n de los test se recoge en una base de datos.<\/p>\n

     <\/p>\n

    \"test

    Una buena base de datos, permite que el an\u00e1lisis de resultados sea mucho m\u00e1s \u00e1gil.<\/p><\/div>\n

     <\/p>\n

     <\/p>\n

    En esta base de datos -compartida con todos los miembros del equipo de dise\u00f1o- agrupamos todo el contenido individual de cada test para facilitar luego la creaci\u00f3n y redacci\u00f3n del informe de resultados.<\/strong><\/p>\n

    De todas las conclusiones extra\u00eddas del test, se plantean unas oportunidades de mejora<\/strong>. Dichas oportunidades suponen peque\u00f1os cambios que har\u00e1n la interfaz m\u00e1s usable y proporcionar\u00e1n una mejor experiencia de usuario.<\/p>\n

    Por ejemplo, en el caso del gestor de expedientes, cuando recibes un documento en tu bandeja de entrada y lo a\u00f1ades a un expediente existente puedes seleccionar la ubicaci\u00f3n en la que lo quieres a\u00f1adir. Sin embargo, estando dentro del expediente, si a\u00f1ades un documento no se ofrece esta posibilidad, ya que, una vez a\u00f1adido, vuelves a la estructura de carpetas y documentos del expediente y ah\u00ed puedes reorganizarlo.<\/p>\n

    Aunque esto pueda parecer incoherente, nos pareci\u00f3 importante testear la reacci\u00f3n de los usuarios, para ver si notaban esta diferencia<\/strong> y prefer\u00edan dar un paso m\u00e1s en el flujo de la acci\u00f3n eligiendo la ubicaci\u00f3n del documento o prefer\u00edan poder hacerlo posteriormente de forma voluntaria.<\/p>\n

    Por lo general, los usuarios eran partidarios de incluir este \u00faltimo paso para seleccionar la ubicaci\u00f3n del documento incluso estando dentro del expediente, por lo que se lleva a cabo esta modificaci\u00f3n.<\/p>\n

    Con toda esta informaci\u00f3n se crea un informe de resultados donde se recogen todos los hallazgos, problemas y oportunidades de mejora. Testear un prototipo e iterar en su planteamiento son aspectos clave del proceso de dise\u00f1o que se centra en el usuario.<\/strong><\/p>\n

    <\/h2>\n

    BONUS: Buenas pr\u00e1cticas de cara a realizar tests con usuarios<\/h2>\n