GCBA
R.U.B.I.
Cliente
Gobierno de la Ciudad de Buenos Aires
Rol
UX Lead
Stakeholders
Dirección de Bienes, Dirección de IVC, Dirección de Concesiones, Dirección de Relocalizaciones, Escribanía, entre otros.
Tiempo
8 meses
Contexto
La aplicación RUBI (Registro Único de Bienes Inmuebles) nació en 2010 con el propósito de gestionar, supervisar y auditar las propiedades y el patrimonio del gobierno de la Ciudad Autónoma de Buenos Aires en todo el país.
Administrada por la Dirección General de Administración de Bienes, esta herramienta digital juega un papel crucial al coordinar, proponer e intervenir en las políticas, normas y procedimientos relacionados con la gestión y disposición de bienes inmuebles en la ciudad.
Usuarios principales
Los principales usuarios de RUBI son los funcionarios gubernamentales, quienes desempeñan diversas funciones y, por lo tanto, requieren diferentes niveles de acceso a la aplicación. Estos usuarios provienen de departamentos clave, como el de Bienes Inmuebles, Concesiones, Relocalizaciones y Notarial.
Desafíos y objetivos
Con el paso de los años, la aplicación heredada enfrentó desafíos significativos. La experiencia de usuario era ineficiente y carecía de enfoque centrado en el usuario, lo que resultaba en una interacción torpe y poco amigable. Además, la interfaz de usuario no reflejaba la guía de estilo del gobierno, conocida como Obelisco.
Para abordar estos problemas y mejorar la usabilidad de la aplicación, los stakeholders solicitaron un rediseño completo no solo de la interfaz de usuario, si no de toda la experiencia, inclusive a nivel ingenieria en conjunto con el desarrollo de nuevas características y funcionalidades. El objetivo era crear un producto digital amigable y transparente que optimizara el proceso de gestión de propiedades, haciendo que las tareas diarias de los usuarios fueran más fluidas y eficientes.
Estas son algunas de las capturas del sistema original de RUBI (Disculpa si las visualizás borrosas, son capturas de nuestro relevamiento)
Como se puede apreciar en las mismas, la obsolescencia a nivel técnológico y la falta de una experiencia significativa para el usuario eran sin dudas los puntos más importantes a mejorar.
En estas pantallas anteriores, el usuario realizaba consultas a través de un formulario. El mapa performaba erroneamente, muchas veces brindando otros datos, datos érroneos, o bien, errores técnicos de sistema.
En este caso, los formularios no tienen una arquitectura lógica y todos los datos estaban en las pantallas sin una lógica ni un concatenamiento en base a una estructura.
Entendiendo desde el inicio el alcance de esta herramienta
Inicialmente, llevamos a cabo una evaluación exhaustiva que abarcó reuniones con los usuarios para discutir el propósito, las funcionalidades y el alcance de la herramienta. Estos encuentros tenían como objetivo principal obtener un análisis detallado sobre la importancia, el alcance y el esfuerzo inherente a la creación de un nuevo software que evolucionara desde el RUBI 1.0 hacia un RUBI 2.0, tanto en términos funcionales como tecnológicos.
En este contexto, creamos un documento de evaluación que abordaba la situación actual (AS IS), los interesados, un relevamiento de las funcionalidades actuales, un diagnóstico de los problemas y áreas de mejora identificados, así como la transición de los procesos actuales hacia ideales. Este documento también incluyó una matriz de priorización, estándares y recomendaciones tecnológicas.
Por principios de confidencialidad, decidí recortar el archivo original, para mostrar solo una parte de este assesment.
Los puntos de dolor se contaban por montones...
Los puntos de dolor que se identificaron en la experiencia de usuario de la aplicación RUBI revelaron deficiencias significativas que afectaron la eficiencia y la usabilidad del sistema. Estos desafíos representaron obstáculos clave que se debían abordar para mejorar la experiencia del usuario y optimizar el proceso de gestión de propiedades.
- Datos/información desactualizada/incongruente: La presencia de datos desactualizados o inconsistentes dificultó la precisión y la confiabilidad de la información dentro del sistema, lo que podía generar decisiones erróneas por parte de los usuarios.
- Falta de normalización de datos y nomenclaturas: La falta de uniformidad en las nomenclaturas y la falta de alineación con el código urbanístico de la ciudad dificultaron la búsqueda y la gestión de propiedades de manera efectiva.
- Falta de alertas críticas: La ausencia de alertas que advirtieran sobre situaciones críticas podía resultar en la falta de acción o en la gestión inadecuada de problemas urgentes relacionados con las propiedades.
- Falta de integración con otros sistemas: La falta de integración con sistemas externos que contenían información relevante limitó la capacidad de los usuarios para acceder a datos necesarios para una gestión completa de propiedades.
- Limitaciones en los niveles de visualización y edición: La falta de niveles de visualización y edición según los distintos roles y perfiles dificultó la personalización y la eficiencia en la gestión de propiedades.
- Problemas con registros de "Calles Sin Nombre": La posibilidad de registrar un inmueble bajo "calle sin nombre" condujo a errores de identificación cuando varios registros compartían el mismo número de casa, lo que afectaba la precisión de los datos.
- Necesidad de actualizaciones masivas de datos: La falta de herramientas para realizar actualizaciones masivas de datos de manera eficiente resultó en un proceso manual y tedioso que consumió tiempo y recursos.
- Falta de información de Concesiones y Relocalizaciones: La ausencia de información relevante sobre concesiones y relocalizaciones limitó la comprensión completa de la situación de las propiedades.
Nuestro equipo estaba listo para afrontar un nuevo desafío
Después de que el cliente revisara el análisis y diera su aprobación para trabajar con nosotros a través del área comercial, estábamos preparados para comenzar de inmediato y avanzar con la priorización de las historias de usuario.
Acordamos dividir el proyecto en tres fases distintas:
- La primera fase se enfocó en implementar funcionalidades básicas como el inicio de sesión, la página de inicio y la creación de propiedades.
- La segunda fase, de carácter evolutivo, se centró en el núcleo de funcionalidades, como el módulo de seguridad, administración y búsqueda, junto con otros complementos.
- La tercera fase, también evolutiva, consistió en la incorporación de características secundarias que enriquecieron la experiencia del usuario.
Después de priorizar las tareas con el propietario del producto, procedimos a planificar los sprints y los trimestres, dando prioridad a todo el backlog de productos que habíamos cargado en Jira.
Con todos los detalles organizados, nos dispusimos a realizar un mapeo exhaustivo del sistema.
Nuestro equipo listo y preparado para el desafío
Comenzar por el final...la imagen completa del sistema
Utilizando un artefacto de mapeo como herramienta principal, el equipo se embarcó en la tarea de trazar meticulosamente cada uno de los caminos que los usuarios seguirían a lo largo del sistema.
Desde el momento del inicio de sesión y los posibles casos de uso hasta la exploración completa del sistema, cada conexión fue minuciosamente documentada. El desafío estaba claro: diseñar una experiencia fluida que permitiera a los usuarios llegar a su destino con no más de tres clics desde el punto de partida.
Una vez que este mapa de navegación fue elaborado y validado por los stakeholders clave, nos sumergimos de lleno en el desarrollo de las historias de usuario previamente priorizadas. Este enfoque nos permitió centrarnos en las áreas de mayor importancia y garantizar que cada aspecto del sistema estuviera alineado con las necesidades y expectativas de los usuarios finales.
Trabajar ordenados, la prioridad número uno.
Trabajar ordenados, con una estructura de artefactos para mi es vital. Si bien, en los distintos workspaces de cada designer, dejo el espacio a la creatividad y a proponer nuevas cosas, considero que tener una estructura de artefactos fué una de las cosas por las cuales trabajé en mi pasado, optimamente.
Para ello, mi estrategia con el equipo fué simple:
- Para artefactos de entendimiento, prototipado y todo lo que se genere desde la ideación y prototipado por cada sprint, deberían ir ubicados en archivos denominados SP_01/02/03/sucesivamente. Allí unicamente tendriamos toda la montaña de ideas. El archivo debería contener, una portada, y un indice con las historias de usuarios que se tomaron en ese período. A su vez, que cada historia tuviera una distribución por pages de figma.
- Master de prototipos: Una vez validados los prototipos, colocarlos en un archivo central, llamado Master. Desde allí, todas las personas involucradas en el proyecto podrían consultar el mismo. Al igual que los archivos borradores, el master debía contener una portada, un indice, y posteriormente todas las historias o flujos implicados.
- UI KIT: En caso de que se tuviera que realizar un UI KIT desde cero, generar el archivo y nomenclarlo oportunamente, agregando además la documentación correspondiente de uso y condicionales a la hora de aplicarlo. En este proyecto en particular, el design system estaba ya construido por parte del cliente, con todas sus especificaciones.
Aportando más valor al producto diseñando accesiblemente desde su inicio
Además de trabajar ordenados, un diferencial importante era que todos los usuarios pudieran utilizar esta herramienta, indistintamente de sus condiciones permanentes, parciales o temporales. Es por ello, que con el equipo pactamos tener muy en cuenta y tomarnos muy enserio el diseño desde su concepción hasta su validación, siempre tener presente la accesibilidad. Si bien, por términos comerciales y prioridades no pudimos aplicar todo lo que teniamos pensado desde un comienzo proponer como mejoras (Lectores de voz, altos contrastes, etc.) pudimos aplicar gran parte de técnicas a nuestros diseños, tales como auditorías a través de plugins de figma que nos permitieron analizar, buscar gaps e iterar en consecuencia. Además, utilizamos una calculadora de ratio de contraste para evaluar todas las capas del diseño. También, en conjunto con desarrollo, fomentamos la identación del código a través de parámetros ALT, para que permitiera en un futuro a las personas poder leer más alla de una herramienta integrada de lectura o no.
Llegamos al MVP acordado
En este punto, no había mucho que destacar aparte de la excelente capacidad de nuestro equipo para cumplir con los plazos establecidos. Logramos completar con éxito la primera fase de este proyecto, entregando la experiencia solicitada según lo previsto.
Sin embargo, ¿realmente nuestro trabajo había finalizado después de una demostración con los usuarios? Aquí es donde comenzaba una etapa crucial en la evolución del proyecto. Aunque la primera fase se hubiera completado, siempre había espacio para la mejora continua y la optimización. La retroalimentación de los usuarios en la demostración podía revelar áreas de oportunidad y necesidades adicionales que debíamos abordar en las siguientes fases del proyecto. Por lo tanto, era importante mantener un enfoque proactivo y estar preparados para adaptarnos y ajustar nuestro trabajo en función de las necesidades emergentes.
Fase dos ongoing
Nuestro avance a la etapa dos se iba a consolidar con la presentación a los interesados del producto mínimo viable que habiamos construido en la fase 1. Con la confirmación del cliente para continuar trabajando con nosotros, nos embarcamos en una nueva etapa.
El proceso se repitió siguiendo una secuencia bien establecida:
Primero, nos reunimos con el product owner para priorizar las historias de usuario, asegurándonos de enfocarnos en las funcionalidades y características más críticas, que aportaran valor para el éxito del proyecto. Esta fase fue crucial para alinear nuestras prioridades con las expectativas del cliente y garantizar que nuestro trabajo agregara el máximo valor posible.
Luego, elaboramos un roadmap detallado que trazaba el curso del proyecto en los próximos pasos. Esto implicaba planificar cuidadosamente los hitos, asignar los talentos elegidos para este proyecto (Continuaban desde la fase 1) y establecer plazos realistas para cada fase del desarrollo. El roadmap no solo proporcionaba una guía clara para nuestro equipo, sino que también servía como una herramienta de comunicación efectiva para mantener informados a todos los interesados sobre el progreso del proyecto.
Finalmente, una vez que todo estuvo en su lugar, nos lanzamos de lleno a la acción. Con un plan sólido en su lugar y el compromiso renovado de nuestro equipo, estábamos listos para abordar los desafíos por delante y llevar el proyecto hacia adelante con confianza y determinación.
Todo marchaba bien hasta que...
Todo marchaba sobre rieles; nuestro equipo había estado colaborando durante más de cuatro meses. Desde el principio, no solo logramos un rendimiento óptimo, sino que también cultivamos una identidad cohesionada. A través de diversas actividades como sesiones de team building, Jams UX y críticas de UX, conseguimos forjar la sinergia necesaria para este ambicioso proyecto.
Sin embargo, durante la fase inicial del proyecto, identificamos que una parte del sistema podía presentar desafíos significativos: los formularios. Como si fuera una premonición, así sucedió. Cuando llegamos a la sección de los formularios, el equipo se encontró bloqueado. Además, nos llevó tiempo alinear las expectativas del propietario del producto respecto a la funcionalidad de los formularios, lo que provocó retrasos en el proyecto.
En ese momento, entré en acción. Con un equipo ansioso por resolver el desafío de visualizar hasta tres niveles de formularios en uno solo, la tarea era titánica. Comenzamos abordando preguntas clave: ¿Cómo debería funcionar? ¿Cuál es el resultado ideal? ¿Quiénes son los usuarios y cuáles son sus necesidades? ¿Cuánto tiempo tenemos disponible? ¿Qué otras soluciones existen en el mercado? Este enfoque nos permitió tener una comprensión holística de la funcionalidad de los formularios.
Con toda esta información sobre la mesa, nos sumergimos en el análisis de los distintos escenarios mediante userflows y cuadros de doble entrada. Esto nos permitió desglosar la información en un nivel de detalle muy específico.
Finalmente, el diseño resultó ser una consecuencia natural de este proceso colaborativo. La reacción positiva del propietario del producto en las reuniones de validación fue una prueba del éxito de nuestro enfoque. Logramos resolver un problema que había estado afectando al equipo no solo en términos de cumplimiento, sino también en relación con los ajustados plazos del proyecto y la importancia estratégica del cliente para la empresa.
Codearse con desarrolladores es lo mejor que le puede pasar a un diseñador
En muchas ocasiones, los diseñadores y los desarrolladores no suelen estar en la misma sintonía. Aunque no puedo explicar exactamente por qué ocurre esto, es una tendencia común en la industria que ambos equipos trabajen de manera independiente. Sin embargo, tener una relación cercana entre el equipo de diseño y el de desarrollo puede ser una ventaja estratégica que no se debe subestimar.
Desde el principio, me propuse trabajar en estrecha colaboración con el equipo de desarrollo. Este desafío no fue fácil, especialmente porque los diseñadores no tenían experiencia previa trabajando directamente con los desarrolladores; de hecho, habían tenido malas experiencias en sus trabajos anteriores con ellos.
Para superar esta brecha, tuve que idear una estrategia efectiva. Después de una cuidadosa planificación, implementé una serie de prácticas que resultaron ser clave:
- Organizamos reuniones semanales de una hora con el equipo de desarrollo, donde ambos equipos podían plantear dudas y consultas, fomentando así la comunicación abierta y el intercambio de ideas.
- Implementamos un proceso de handoff técnico para todas las historias de usuario validadas por el propietario del producto. Esto incluyó la creación de documentación técnica y visual detallada, así como reuniones a solicitud para discutir cualquier aspecto relevante.
- Habilitamos canales de comunicación en Slack dedicados a discutir la viabilidad y factibilidad de componentes o interacciones específicas, permitiendo un diálogo continuo entre los equipos de diseño y desarrollo.
Estas simples prácticas fueron fundamentales para fortalecer nuestras relaciones y alinear nuestros objetivos. Desde entonces y hasta el final del proyecto, nuestros equipos trabajaron como uno solo, con un único objetivo en mente: satisfacer las necesidades del cliente, tanto en términos de desarrollo como de experiencia del usuario.
ValidUX, una palabra que refleja un gran trabajo
En mis experiencias anteriores, a menudo nos encontrábamos probando el desarrollo en los entornos para asegurarnos de que todo funcionara según lo planeado en la experiencia prototipada. Sin embargo, esta tarea solía ser simplemente una revisión rápida, sin ser una actividad formal dentro del proceso.
Decidí cambiar esto y formalizar esta tarea para que mi equipo pudiera llevarla a cabo de manera más sistemática, siempre respetando la planificación establecida y encontrando momentos adecuados para ello dentro de la rutina diaria.
Antes de comenzar, acordamos con el equipo de Control de Calidad (QA) llevar a cabo una revisión visual e interactiva, y coordinamos con el equipo de desarrollo para abordar cualquier problema detectado posteriormente. Una vez establecidos los procedimientos, pusimos manos a la obra.
Utilizando una hoja de cálculo, comenzamos a registrar todas las inconsistencias funcionales y visuales que encontramos, categorizándolas y proporcionando soluciones claras para corregirlas.
Al finalizar este proceso y realizar las correcciones necesarias, el valor del producto se hizo evidente. Cada detalle, desde un simple ícono hasta un título o un campo de entrada, fue examinado y rectificado. Esta atención meticulosa a la calidad se reflejó en la percepción del producto, que resultó ser excepcionalmente positiva durante la demostración al cliente, quien, por cierto, era exigente en cuanto a los detalles. El trabajo en equipo había dado sus frutos y el producto final destacaba por su calidad y atención al detalle.
Culminando la herramienta
satisfactoriamente todas sus horas asignadas. A pesar de los pequeños contratiempos relacionados con el entendimiento y diseño de los formularios de RUBI (más de 10 en total), el equipo demostró una gran capacidad para aprovechar los momentos más tranquilos y enfocarse en las historias menos complejas, gracias al coaching que les proporcioné. Esto nos permitió mantenernos en curso y cumplir con los plazos establecidos.
Al finalizar el proyecto, todo el trabajo realizado se había diseñado y documentado de manera exhaustiva. Cada detalle había sido registrado y analizado, garantizando que el producto final cumpliera con los estándares de calidad y los requisitos del cliente. El equipo pudo enfrentar los desafíos con determinación y, gracias a su esfuerzo y dedicación, logramos alcanzar nuestros objetivos con éxito.
El detalle final para este proyecto (Spoiler: Hay parte dos en proceso)
Para culminar con el proyecto, y en base a que nos sobraron un par de horas de la planificación, decidimos con el equipo darle el broche de oro a este proyecto.
Para ello, fuera de los sprint (Nuestra participación había finalizado recientemente), y con un capacity reducido, afrontamos minimizar el manual de usuario en una guía rápida de inducción, para que todos los usuarios pudieran adentrarse al producto de forma rápida.
Por otro lado, un breve video promocional y de onboarding que permitiera a los usuarios poder ingresar rápidamente al producto y reconocer todas sus funcionalidades.
Algunos números de nuestro paso por el proyecto
Tiempo de Desarrollo: Esta métrica evalúa el tiempo total dedicado al desarrollo del proyecto, desde el inicio hasta la entrega. Puede desglosarse en fases específicas del proyecto para identificar áreas de mejora en términos de eficiencia y productividad.
Eficiencia del Equipo: Esta métrica evalúa la productividad del equipo de desarrollo en términos de la cantidad de trabajo realizado en relación con los recursos y el tiempo invertido. Puede medirse utilizando puntos de historia completados por iteración o sprint.
Calidad del Código: Se puede utilizar una variedad de métricas técnicas para evaluar la calidad del código, como la cobertura de pruebas, la complejidad ciclomática, el número de errores encontrados durante las pruebas, entre otros. Estas métricas proporcionan una visión más profunda de la salud y la mantenibilidad del código.
Satisfacción del Cliente: Esta métrica puede obtenerse a través de encuestas de satisfacción del cliente o retroalimentación directa del cliente. Evalúa la percepción del cliente sobre la calidad del producto final, la comunicación durante el proyecto y la capacidad del equipo para satisfacer sus necesidades y expectativas.
Cumplimiento de Requisitos: Esta métrica evalúa en qué medida se cumplieron los requisitos del cliente y del proyecto. Puede medirse utilizando una matriz de trazabilidad de requisitos para rastrear cada requisito desde su concepción hasta su implementación y verificación.
Adopción del Usuario: Esta métrica evalúa la rapidez con la que los usuarios finales comienzan a utilizar y adoptar el producto después de su lanzamiento. Puede medirse mediante el seguimiento de métricas como el número de usuarios activos, la frecuencia de uso y la retención de usuarios.
Feedback del Usuario: Esta métrica se refiere a la retroalimentación directa de los usuarios finales sobre su experiencia con el producto. Puede obtenerse a través de encuestas de satisfacción del usuario, análisis de comentarios en redes sociales o plataformas de revisión de productos.
+50% Aumento de productividad
Los usuarios reportaron un aumento de un 50% de productividad, comparando con el anterior sistema.
Satisfacción del cliente
En base al trabajo realizado, al momento estamos en fases de estimación para nuevos features.
Aumento de la utilidad del producto
En base a la nueva experiencia, más usuarios de distintas áreas pueden utilizar el sistema para la carga de datos.
NPS 4 de 5
Anteriormente, los usuarios dejaron inclusive de utilizar este sistema debido a su obsolescencia tecnológica como a nivel experiencia. Actualmente calificaron al sistema con un 4 de 5 respecto a la experiencia.
+50% Reducción en tiempos de ejecución de tareas
Anteriormente los usuarios demoraban en promedio, alrededor de 2 minutos, desde el ingreso de información, hasta la finalización de las tareas generales. Con la nueva experiencia, los usuarios demoran tan solo un minuto.
Conclusión
Como líder del equipo de diseño en este proyecto, mi conclusión sería que hemos logrado un éxito notable al enfrentar los desafíos con determinación y compromiso. Hemos demostrado que la colaboración entre los equipos de diseño y desarrollo es fundamental para el éxito de cualquier proyecto de UX. A lo largo del proceso, hemos aprendido valiosas lecciones que nos ayudarán en proyectos futuros.
Lecciones aprendidas
Comunicación y colaboración: La estrecha colaboración entre los equipos de diseño y desarrollo ha demostrado ser fundamental para superar obstáculos y alcanzar nuestros objetivos. Mantener canales de comunicación abiertos y fomentar un ambiente de trabajo colaborativo nos permitió abordar los desafíos de manera efectiva y lograr resultados excepcionales.
Atención al detalle: Nuestra dedicación a la calidad y la atención meticulosa a cada detalle, desde el diseño de la interfaz hasta la revisión del producto final, fueron aspectos fundamentales para garantizar la satisfacción del cliente y la excelencia en la experiencia del usuario. Nunca subestimamos la importancia de cuidar cada aspecto del diseño, por pequeño que parezca.
Adaptabilidad y resiliencia: A lo largo del proyecto, nos enfrentamos a desafíos inesperados y cambios en el camino. Sin embargo, nuestra capacidad para adaptarnos a las circunstancias y mantenernos resilientes nos permitió superar los obstáculos y seguir avanzando hacia nuestros objetivos. Esta experiencia nos ha enseñado la importancia de ser flexibles y estar preparados para ajustarnos a las necesidades cambiantes del proyecto.
¡Muchas gracias por leer!
Trabajemos juntos🚀
Me apasionan los nuevos desafíos. Si te gustaría reunirte y conocer más sobre mi trabajo, no dudes en escribirme por email. Te responderé a la brevedad.