Portal de Afiliados en Tránsito entre Obras Sociales
Portal web para gestionar el registro y transferencia de afiliados en tránsito a través de convenios entre distintas obras sociales del país.
Este proyecto, parte de una iniciativa mayor, implicó trabajar con tecnología predefinida y enfrentar limitaciones de tiempo y recursos. A pesar de tener un equipo de diseño reducido, logramos crear una solución eficiente y funcional, mejorando la organización y gestión del registro de los afiliados.
Roles: Facundo Azocar – Diseñador UX. Companía: Tekhne. Timeline: 4 semanas.
Background
El proyecto surgió de la necesidad de organizar el registro de personas en tránsito (afiliados) entre distintas obras sociales (provincias) del país, basándose en convenios preestablecidos. Este desarrollo se enmarcó dentro de un proyecto más grande y que ya estaba funcionando, por lo que la tecnología a utilizar (aplicación web con panel lateral) ya había sido definida por el área de programación debido a requerimientos técnicos.
Para el área de diseño (dos personas, una sola para ux y otra para ui), esto significaba trabajar dentro de ciertos límites al momento de diseñar la plataforma y resolver el problema. No se debían proponer, salvo estricta necesidad, animaciones o interfaces muy avanzadas. Además, el tiempo destinado para el rediseño fue limitado en relación a la magnitud del proyecto.
Un poco de contexto.
Para contextualizar el sistema, este software permite la gestión de las reciprocidades de afiliados en tránsito entre distintas obras sociales. Estas reciprocidades están basadas en convenios que se establecen entre las propias obras sociales y con su cobertura específica para cada relación. Es decir, que sin convenios no hay reciprocidad.
No había plataforma pre existente para este tipo de gestiones. Era una oportunidad de desarrollo. El equipo de programadores ya había esbozado una organización preliminar y solicitaron nuestra ayuda. Este fue el puntapié inicial para trabajar.
Esbozo inicial de los programadores. Carga y acceso de datos importantes.
Frente a esta pantalla principal, en un primer análisis a simple vista, existe una barra lateral de navegación solo indicando obras sociales y no se comprendía claramente qué acciones se podían realizar, más allá de agregar una obra social o descargar el archivo en diversos formatos. Sin embargo, las obras sociales son fijas y siempre las mismas. Por ello, se propuso que se recargaran automáticamente los datos desde la base de datos de la organización que las agrupa, ahorrando así el tiempo de carga manual de estos datos.
Esta idea inicial estaba basada en ingresar al oprimir el detalle de una obra social y a partir de allí establecer una relación con ella (crear un convenio) como se observa en la pantalla a continuación.
Es por ello que el primer rediseño se basó en la separación correcta de términos y accesos para navegar por el sistema. Para ello se plantearon opciones y se confrontó con los encargados del sistema para corroborar. Resumiendo.
1. Cambio de nombres en la barra lateral izquierda para mayor claridad de navegación.
2. Agregado por sincronización de base de datos de organización que las agrupa para ahorrar el tiempo de carga de las propias obras sociales.
Hasta ahora lo que se relató tiene que ver con un componente esencial que es la carga de datos de las Obras Sociales para luego generar la relación (convenio). Para mejorar el acceso a este apartado de convenios y por la importancia de los mismos para el sistema se propuso que tengan un lugar en la barra lateral izquierda para mejor acceso y más rápido. Se propuso en este punto dejar, según criterio de UX de agrupar elementos similares, lo que es información específica sobre las obras sociales (info general, logs de usuarios, domicilios, etc.) y por otro lado la relación con esa obra social (es decir los convenios de reciprocidad que se tenían con esa obra social). Esta accesibilidad es clave en el tema esencial de la función principal de la plataforma, sin la info de las obras ni los convenios no serían posibles las reciprocidades o registros de idos y venidos. Es por ello que están primeros y a mano en la barra lateral.
El cómo organizar los registros de personas (reciprocidades)
Una vez definido y clarificado el acceso a la información fundamental y estrictamente necesaria para que luego existan los registros de las personas en tránsito, se procedió a diagramar la información y categorías de estos registros. Para esto los programadores no tenían un esbozo inicial así que se partió de cuadros y esquemas generales para interpretar la cuestión.
Lo que sí estaba definido como condicionante era que el afiliado podía solicitar la reciprocidad en Origen o en Destino, lo que coloquialmente se les llamaba Idos y Venidos, que era más confuso aún ya que depende desde dónde este parado quien lo gestiona. Como complejidad adicional existían instituciones que no gestionaban las reciprocidades de manera automática sino manual, teniendo que aprobar una por una dichas reciprocidades.
Entendiendo la complejidad
A modo ilustrativo se agregan esquemas que representan el cómo se fue pensando las distintas situaciones y aproximaciones al problema para poder identificar la arquitectura de producto más entendible.
A través de este análisis se pudo identificar que existen solicitudes enviadas y solicitudes recibidas no necesariamente coincidían con gente que iba (idos) y gente que venia (venidos) a atenderse por la propia obra social. Para ello se trabajo con ejemplos de casos para identificar las tareas que tenían que realizar los tres actores en este caso, el afiliado, la obra social de origen, y la obra social de destino.
Descubriendo dificultades e iterando.
Curiosamente, al momento de explicar el proyecto a los otros miembros del equipo, parte de la gerencia y a los programadores
se noto que se seguían existiendo confusiones sobre el término “enviados” porque depende de dónde esté situado y también
confusión con yo envié una solicitud pero recibí una persona.
Después de múltiples iteraciones, con distintos nombres y formas de nombrar a los afiliados en tránsito, finalmente se decidió utilizar una diferenciación simple pero eficaz. Propios y ajenos. Es decir, propios de una obra social y ajenos a ella. Esto permitió separar las responsabilidades que existían sobre los propios que se acercan a mi obra social y van a viajar a otro lugar o bien los propios que solicitan desde otro lugar del país. En el caso opuesto, los externos, sería si una persona que no es afiliado de la obra social en cuestión se acerca y solicita la reciprocidad o bien la solicita desde la otra obra social pero figurará en los afiliados externos.
Luego ...
Una vez esclarecida la cuestión de las categorías y flujos se comenzó a iterar mediante wireframes donde se reflejaron varias opciones sobre cómo mostrar cierta información. Nuevamente mediante reuniones con programadores para las condicionantes se llegó a una solución mediante pestañas.
En los wireframes anteriores en la opción izquierda la aprobación o rechazo (solicitados) se podía realizar desde afuera de la pantalla y en la derecha se definió que estaría dentro de una nueva ventana la cual se activaría mediante el botón de responder solicitud.
Las solicitudes como tales pasaban por varios estadios por lo que se necesitó crear estados que los representaran.
La definitiva
Diseño de las solicitudes que requerían respuesta por parte de la obra social, agrupadas y con detalle de la cantidad de pendientes para poder indicar al usuario que necesita responderlas.
Detalle esquemático de la solicitud con los datos que vienen de parte de desarrollo, donde se permite la acción de rechazar, aceptar la solicitud o cerrar la ventana.
Lo que se aprendió
Los esquemas de arquitectura de la información resultaron muy útiles para la diversa cantidad de casos y para definir una solución. Otro aprendizaje fue que la propia semántica puede llegar a confundir sistema entero por lo que es muy importante definir correctamente los términos y asegurarse que la mayoría de gente posible entiende lo mismo.
Qué podría mejorarse
Como mejoras se podría modificar el ui de las solicitudes, estableciendo mayor claridad para destacar algunos datos.