Portal de voluntariado
Es una aplicación creada para gestionar acciones de voluntariado por parte de las empresas que trabajan con el cliente.
Resumen
Este proyecto consiste en el refactoring de la herramienta Portal de Voluntariado, dentro de la plataforma Sygris. Es una aplicación creada para gestionar acciones de voluntariado por parte de las empresas que trabajan con el cliente.
ROL
UX/UI Designer
CLIENTE
Fundación Mapfre
EQUIPO
- Senior Data Analyst
- UX/UI Designer → Sofía García
- UX/UI Designer → Andrea Romero
Objetivos
Mejorar los flujos de usuario de la aplicación
Rebajar la curva de aprendizaje de la aplicación
Hacer más atractiva y sencilla la aplicación al completo
Funcionalidades de la herramienta
En la aplicación la gestión incluye todo el proceso:
Creación de convocatorias y sus turnos correspondientes.
La gestión de que los empleados y familiares que se apuntan a las actividades.
Digitalización y explotación de los datos obtenidos, por partipaciones, resultados, asistencias...
La gestión de los resultados de las actividades.
Estructura
Plataforma Sygris
En ella se desarrollan el resto de gestiones necesarias para completar el proceso completo.
Web Externa
En esta sección los empleados se apuntan a las actividades que ellos quieran realizar (estos datos luego se guardan en Sygris). El uso de la web pública fue necesario debido al gran volumen de usuarios de la plataforma.
A tener en cuenta
Esta sección no entró en el alcance del refactoring.
Contexto
El cliente ya llevaba tiempo utilizando la herramienta Sygris. Pero tras tiempo de uso, y mucha cantidad de cambios sin gestionar, la herramienta se veía poco atractiva y los flujos eran inabordables.
Por parte de la base de datos, la relación de toda la convocatoria, turnos, localizaciones, para su correcto funcionamiento, dependía de unos flujos internos entre colecciones muy complejos.
Cada parte del proceso, se hacía desde un sitio diferente. Había cantidad de elementos que no se usaban pero que consumían recursos …y estaba toda la plataforma en una misma pantalla. Pidieron que había que mejorar los flujos, agrupación de funcionalidades, secuencia de pasos etc…
También había una cantidad de usuarios grande, como 10.000 usuarios, 50.000 asistentes etc...con lo cual el proceso debía separarse en una solicitud e inscripción externa (web pública) y una gestión interna de los datos (Sygris)
Roles
Administradores
Tiene acceso a toda la aplicación y su función es validar las convocatorias en la última fase del proceso.
Gestores
Son los encargados de crear las convocatorias, publicarlas y una vez que se hayan realizado, deberán introducir los resultados de las convocatorias.
Voluntarios/Empleados
Se apuntan a las actividades y las realizan. Tienen su propio espacio y gestionan sus familiares, hacen encuestas de satisfacción y sus certificados.
Análisis y definición
Análisis
De primeras, se hizo un análisis integral de toda la aplicación para saber realmente a qué nos estábamos enfrentando.
Por ejemplo, un ejemplo de un flujo analizado en el que participaban los 3 roles:
Tras realizar unos cuantos análisis más, nos metimos de lleno a tratar de ver qué es lo que había dentro de la plataforma realmente.
La cantidad de modales anidadas y de flujos complejos, que eran complicados de encontrar a no ser que te lo supieras de memoria, era enorme.
Se analizaron además, los 3 roles diferentes.
Resultados del análisis
Aquí se pueden observar las conclusiones a las que llegamos tras el análisis.
- Falta de feedback en varios puntos
- Información descentralizada en diferentes modales
- Multitud de datos y acciones en la misma pantalla
- Falta de jerarquía entre acciones
- Procesos y flujos complejos
Encuestas de usuario
Uno de los problemas con los que nos encontramos era la dificultad de conseguir feedback del usuario final, voluntario o gestor, que utiliza la herramienta. Realizamos dos encuestas que mandamos a cliente para que lo pudiera enviar a sus empleados. Se realizó una para los usuarios gestores y otras para los voluntarios, pero tras insistir varias veces, no se llevó a cabo.
Esto impidió que las hipótesis que hacíamos se validasen correctamente.
Aún así, continuamos poniendo el máximo empeño y cuidado en los flujos y los diseños y validando con otros usuarios que no eran finales.
La web pública fue algo que también incluímos dentro de todo el proceso, ya que directamente causaba fricción al no centralizar todo el flujo de usuario y tener que saltar de plataforma para cumplir el objetivo, pero por limitaciones técnicas, debía mantenerse de esa forma.
Definición
Se realizó una nueva arquitectura de la información teniendo en cuenta todo lo que necesitaba cada tipo de usuario, tratando de agrupar los objetivos y realizar secuencialmente las tareas.
La idea principal que se defendió era:
- Centralización de la información
- Mejorar de la arquitectura de la información, yendo de lo general a lo específico.
- Jerarquización de las acciones más importantes.
- Simplificar los procesos y hacerlos más lineales.
Diseño
Una vez realizado el site map anterior y aprobado por el equipo de consultoría, trabajamos directamente en realizar los módulos más importantes, que eran el núcleo de la aplicación. El resto de módulos orbitaría alrededor de ellos.
La complicación real de llevar todo esto a buen puerto, era que estas dos funcionalidades, se mezclaban en una misma pantalla. Había que separarlas correctamente y que fuera sencillo de utilizar. El equipo hizo un esfuerzo grande en esta sección para que llegara al objetivo. El mayor reto fue la cantidad de pequeños flujos y funcionalidades ad-hoc que habían introducido a lo largo del tiempo y que hacían que fuera una masa inmensa sin jerarquizar de “corner cases” que había que tener en cuenta.
Se hicieron varias versiones, en las que fuimos refinando poco a poco la idea que teníamos.
Gestión de convocatorias
En esta sección los gestores son los encargados de crear nuevas convocatorias, publicarlas o editarlas. Es la base de la funcionalidad de la aplicación entera. Ella orquesta al resto de funcionalidades, que surgen a través de las convocatorias y sus necesidades.
Anteriormente estaba todo metido “con calzador” en la misma página y fue uno de los problemas que se atacó de frente sin comprometer todas las funcionalidades que debía tener.
Se quedaron dos secciones diferenciadas:
Página principal
Sección donde puedes observar el estado de cada convocatoria de forma general y realizar acciones principales.
Las funciones principales de esta página eran:
- Crear nueva convocatoria
- Editar y duplicar convocatorias
- Publicar convocatorias
Ficha de convocatoria
Al pulsar en la convocatoria, te llevaba a otra página dedicada a toda la información relacionada con la convocatoria.
Dentro incluía:
- Estado de la convocatoria
- Información relacionada y capacidad de modificarla
- Asistencia: Los gestores aquí pueden tener un control de los participantes de la convocatoria desagregados por localización y turno. También de la lista de espera.
- Mails: En la pestaña de mails, el gestor puede ver todas las comunicaciones llevadas a cabo relacionadas con la convocatoria. Además, puede crear un nuevo correo en caso de querer realizar una comunicación a un grupo o usuario concreto.
Gestión de resultados y asistencia
En esta sección los gestores y administradores pueden ver y gestionar los resultados de las actividades realizadas.
Una vez terminada la convocatoria, los responsables tienen que realizar una serie de pasos:
- Los gestores tienen que imputar los resultados de la convocatoria y confirmar la asistencia de los participantes. Una vez se hayan registrado todos los datos, los gestores tienen que marcar la actividad como “gestionada”.
- Una vez gestionada, los administradores de la plataforma son los encargados de comprobar que todos los datos de la convocatoria cuadran, y si todo es correcto, ellos validarán la convocatoria y esta se dará por finalizada.
Página principal
Podías elegir, con los filtros los diferentes parámetros. Con las pestañas, se veían las convocatorias en función del estado en el que se encuentren, una vez realizadas. Debajo, se encuentra la lista de convocatorias en la que se puede hacer clic y ver su ficha de convocatoria.
Ficha de convocatoria
Dentro de la ficha, al haber finalizado la convocatoria, había nuevas pestañas abiertas con las que se podía trabajar.
Estas eran las siguientes:
- Resultados
El gestor puede ver los resultados, añadir certificados y modificar todo lo que necesite. Anteriormente, todos estos datos se veían en una tabla gigantesca en una sola pantalla. Aquí se puede ver uno de los ejercicios de arquitectura de la información que realizamos. Se podían ver también KPIs importantes de la convocatoria.
- Comentarios
Se introducían comentarios para avisar los administradores y/o otros gestores de información relevante
- Resultados de encuesta
Cuadro de mando donde se visualizan los datos de las encuestas mandadas a todos los voluntarios que han participado en la convocatoria.
Validación de convocatoria
En esta sección del módulo el administrador, una vez gestionada la convocatoria (es decir, con los resultados introducidos y marcada como gestionada), tenía que validarla. De esta forma se finalizaba todo el proceso. Esta sección solo la puede utilizar el administrador pulsando en las convocatorias con estado “gestionadas”. Podía ver incluso una serie de KPIs de los resultados por localización y turno y mandar comentarios finales antes de cerrar al completo la actividad.
Otros módulos
El resto de módulos se hicieron posteriormente y eran secciones que orbitaban alrededor de las convocatorias como:
- Informes donde se podía ver la explotación de datos
- Gestión de usuarios: donde mandar correos para inscribir a la plataforma a voluntarios que lo quisieran, dar de baja o cambiar los roles de los mismos.
- Mi espacio, donde el voluntario podía gestionar sus certificados, consultar o modificar su información personal y gestionar sus propios familiares.
Prototipo
El prototipado por sí solo fue un reto. Cada vez que había que cambiar algún contenido, había que hacerlo por cada paso de forma manual, y había muchos datos y muchas pantallas. Sobre todo en las modales, la parte de la pantalla que estaba debajo (tapada por una veladura) nos hizo perder el tiempo.
Pero nos sirvió para identificar que era un punto a mejorar para los siguientes prototipados.
Conclusiones
Este proyecto fue (y es) uno de los más grandes que se ha realizado en Sygris en cuanto a UX. Como se comentaba más arriba, la complicación radicaba en resolver un proyecto con tanto bagaje, tantos casos específicos y tanta trayectoria.
Realmente se cambiaron muchos elementos, flujos y hubo que hacer un esfuerzo grande por parte de todo el equipo para romper con todo lo anterior, ya que supuso un cambio estructural incluso en la forma de trabajar del cliente.
Ha sido uno de los proyectos de los que, sin duda, más he aprendido. Sobre todo a no caer en costumbres que no funcionaban y tratar siempre de ir hacia la mejor usabilidad y experiencia de usuario, dentro de lo que Sygris puede permitir.
El hecho de realizar entregas prototipadas a cliente en Sygris, este trabajo fue uno de los pioneros. Y nos costó bastante, sobre todo al principio entender cómo hacerlo de forma más optimizada en las fases iniciales, pero tras identificar esto, tratamos de mejorar en los otros módulos y lo conseguimos a través de las interacciones por variantes.
