Este post es una continuación de YesISO: más intuitiva y moderna, en el que describíamos el proceso de diseño y mejora del diseño de yesISO, en este post abandonamos el Figma y nos metemos de lleno en el código y, más concretamente, en los pasos que seguimos para implementar y desplegar este diseño en producción de la manera menos molesta tanto para los usuarios como para un negocio que no puede parar de desplegar nuevas funcionalidades.
A continuación, algunas cifras de yesISO para tener en cuenta la magnitud del cambio:
- 1600 vistas en el proyecto.
- 22 módulos funcionales.
- 30 tenants.
Veremos como lo logramos usando un layout (diseño maestro) temporal que muestra el nuevo diseño sobre la tecnología existente en la web: desplegamos el diseño actualizado de una sola vez y con cambios mínimos en el código de la aplicación, pudiendo hacer después los cambios en usabilidad y patrones de uso. Concentrando el "shock" del cambio de diseño en un solo momento y sin parar los despliegues de funcionalidades y correcciones.
El objetivo de implementar y desplegar el nuevo diseño tenía múltiples condicionantes:
- El cambio en el UX debería ser "transaccional", es decir, no deberíamos tener partes con la estética nueva y otras con la antigua.
- La web estaba implementada con librerías de front ya obsoletas, por lo que no bastaba con cambiar únicamente las hojas de estilo: además de los cambios en estilos y clases, necesitábamos hacer cambios en la estructura de las vistas para soportar las librerías de front y los nuevos patrones de uso. Esto implicaba modificar gran parte de los listados.
- Si usáramos una rama en el repositorio para la migración completa al nuevo diseño, su tamaño haría que los merges del código serian muy proclives a errores.
- No se podía "parar" el desarrollo durante el tiempo que nos llevara hacer el cambio estético/de funcionalidad. En yesISO seguimos una estrategia de despliegues muy frecuentes tanto para entregar nuevas funcionalidades como para corregir los errores. El hecho de tener que cambiar un porcentaje muy alto de la aplicación hacía que un despliegue total fuera muy problemático, aunque fuera únicamente por la dificultad de realizar pruebas en todas las pantallas de la aplicación.
Desde un principio descartamos hacer un "todo o nada". No podíamos garantizar la calidad de lo desplegado en un cambio que afectara de golpe a toda la aplicación, por lo que ideamos una estrategia por fases:
- Estimamos que, pese a la importancia de los cambios en usabilidad, el impacto más visible en el usuario vendría dado por el cambio de disposición de los elementos generales de la pantalla (sobre todo la localización de los menús), de los colores y de los estilos generales de la web.
- Ese cambio estético debería hacerse de forma completa y de una sola vez, anunciando a los usuarios ese cambio e informándolos de dónde se situarán los elementos comunes.
- Los cambios de usabilidad "profunda" de las pantallas podrían hacerse de forma escalonada, ya que no los consideramos tan traumáticos.
Los pasos que seguimos fueron los siguientes:
- Implementamos el nuevo diseño utilizando las librerías existentes, dejando los aspectos de usabilidad "profunda" para más adelante; esto nos permitiría implementar los cambios estéticos sin tener que realizar cambios (o de forma muy mínima) en las pantallas de la aplicación. Como la aplicación está desarrollada en MVC, creamos un layout intermedio con las librerías antiguas y el look & feel moderno..
- Creamos un selector de diseño en base al usuario de tal forma que los dos equipos trabajaban sobre la misma rama de código y el nuevo layout se desplegaba en producción junto con la aplicación y podríamos activarlo de forma discrecional para determinados usuarios o tenants.
- Una vez finalizada la creación del layout intermedio y pasadas las pruebas, comunicación y formación a usuarios, etc., lo activamos para todos los usuarios. Habíamos realizado despliegue del nuevo diseño sin tener que realizar los cambios más profundos en la aplicación y sin parar el despliegue de nuevas funcionalidades.
- El equipo que creó el layout intermedio con el diseño nuevo y las librerías antiguas, creó entonces el layout definitivo: con las librerías y el diseño actualizado, que sería el definitivo.
- De forma escalonada, y ya sin presiones de tiempo o de parar desarrollos nuevos, se fueron adaptando pantallas: dado que la aplicación puede tener varios layouts y usarlos en función de la página, podíamos hacer cambios muy atómicos que afectaran a un solo listado o pantalla de edición usando ramas efímeras en GIT que no suponen problemas de merges masivos, por lo que no afectaba al despliegue de nuevas funcionalidades o correcciones de bugs. En este paso también tuvimos que implementar algunos elementos comunes que se usaban en vistas antiguas y no eran compatibles con las nuevas (por ejemplo: buscadores genéricos).
- Una vez finalizada la migración al nuevo front, eliminamos los layouts no utilizados, hojas de estilo antiguas y elementos de uso común antiguos.
Con esta estrategia pudimos desplegar de forma muy segura un cambio masivo en todas las pantallas sin afectar al ritmo de evolución y corrección de incidencias del cliente.
Este cambio de diseño no solo ha modernizado la interfaz de yesISO, sino que también refuerza la solidez técnica de la plataforma desarrollada por Res-novae.