Hoy vamos con un tema denso así que siéntate porque este post no es sencillo. Quiero poner encima de la mesa la gestión de ecosistemas de aplicaciones con legacy.
Precisamente la gestión de ecosistemas de aplicaciones con un legacy importante supone uno de los retos más complejos de abordar en diseño UX.
Os pongo en contexto. Hace un par de semanas, en una reunión con un cliente, pudimos comprobar lo que ya sabíamos, pero esta vez de manera muy clara, con muchos matices, y con nombres y apellidos: nos encontramos un panorama en el que había múltiples focos de desarrollo de software, muchas plataformas, y un buen montón de aplicaciones construidas a lo largo de años con criterios de diseño dispares. La tormenta perfecta.
El problema de la fragmentación
Lo que en algunas ocasiones hemos podido identificar es un patrón recurrente en organizaciones, ojo, con un cierto nivel razonable de madurez: aplicaciones desarrolladas sobre diferentes plataformas y lenguajes de programación y sistemas legacy que pueden haber cumplido 20 años tranquilamente. Cada una con su propio look and feel, y cada una respondiendo a las decisiones de diseño de diferentes equipos, modas y momentos temporales. El resultado es un ecosistema inconsistente en el que la coherencia visual y de experiencia de usuario brillan por su ausencia.
Este no es un problema menor, o como diría el otro, esto es un problema grande. Estamos hablando de aplicaciones que en la mayoría de las ocasiones son muy relevantes para el negocio, que son utilizadas todos los días por usuarios que trabajan con ellas, y de las que esperan una experiencia consistente, independientemente de la plataforma sobre la que estén desarrolladas, ya que en muchas ocasiones ni saben lo que hay debajo, ni tampoco les interesa saberlo.
Sistemas de diseño como infraestructura
Yo suelo decir que aquí es donde está el mundo de los mayores. Ese contexto en donde los artefactos, las metodologías y el buen hacer se juegan el prestigio. Aquí es, por tanto, donde los sistemas de diseño demuestran su valor real, más allá del branding, las modas, el hype o la estética. Un sistema de diseño tiene que comportarse como una infraestructura agnóstica a la plataforma de implementación, y así sucesivamente. Los componentes, patrones y principios deben poder desplegarse en cualquier tecnología del stack de la urbanización.
La clave desde mi punto de vista, y desde mi experiencia, está en entender que un sistema de diseño tiene dos niveles de abstracción:
El primero es a nivel conceptual: estamos hablando de los principios de usabilidad, los criterios de accesibilidad (WCAG 2.1 nivel AA), los patrones de interacción y la arquitectura de información. Este nivel es completamente agnóstico a la tecnología. Y de no ser así, la sostenibilidad estará ya entre la de juicio.
El segundo tiene que ver con el nivel de implementación: estamos hablando de las especificaciones técnicas, los design tokens, las bibliotecas de componentes, las hojas de estilo CSS y las plantillas. Este nivel tiene necesariamente que adaptarse a cada plataforma.
El valor del Playbook UX
Esto es café para los muy cafeteros, y soy consciente de que no todas las organizaciones tienen la capacidad para trabajar con una herramienta o un artefacto de este tipo. En todo caso, la experiencia me hace recomendarlo como estrategia, ya sea para escalar, ya sea para profesionalizarse o ya sea para atacar problemas de comunicación entre departamentos.
La propuesta de un Playbook de experiencia de usuario y accesibilidad responde, en líneas generales, a una cierta necesidad de estandarización. No es un tema que se circunscriba a la documentación estética, sino más bien se trata de un marco de referencia técnico que los equipos de desarrollo puedan consultar y aplicar.
Un Playbook UX que sirva para su objetivo debería incluir como mínimo:
- Checklist exhaustivos de accesibilidad basados en WCAG
- Principios de usabilidad fundamentados en heurísticas reconocidas (Nielsen)
- Especificaciones de componentes con variantes según plataforma
- Arquitectura de design tokens escalable
- Guías de implementación específicas para cada tecnología del stack
- Criterios de calidad y procesos de validación
Plataformas low-code como base del ecosistema
Las plataformas low-code presentan por su parte problemáticas particulares. Pero también nos las encontramos en muchas organizaciones. Conceptualmente están muy bien y son muy cómodas porque permiten que los equipos desarrollen rápidamente aunque con limitaciones en cuanto a personalización visual. Aquí es donde alguien ha tenido que tomar una decisión estratégica vinculada con la arquitectura: trabajar dentro de las capacidades nativas de la plataforma o implementar capas de personalización mediante CSS global. Ya os digo yo, que mi opción es siempre intervenir desde el ámbito de diseño en esta decisión con criterio.
El primer enfoque es más conservador y el más sostenible a largo plazo. Trabajamos con los design tokens que la plataforma permite modificar de manera nativa y adaptamos el sistema de diseño a estas restricciones. Es mucho menos personalizable pero pon otra parte es cierto que requiere un mantenimiento mínimo.
El segundo enfoque permite una coherencia visual total con el resto del ecosistema a través de la utilización de hojas de estilo personalizadas. Aquí gozamos de máxima flexibilidad pero introduce ciertas dependencias con la evolución de la plataforma. Cada actualización de la plataforma o la herramienta sobre la que estamos construyendo, podría potencialmente romper estas personalizaciones, organizando un follón importante y obligándonos a tirar de recursos extraordinarios para asegurar el mantenimiento.
¿Cómo resolver esta cuestión? Pues no existe una respuesta correcta ni universal. La decisión lógicamente va a depender de los objetivos estratégicos de la organización, su capacidad de mantenimiento técnico, y el valor que le dé a la coherencia visual absoluta frente a la estabilidad operativa.
El perfil de desarrollador como usuario
Uno de los aspectos más importantes en este tipo de proyectos es reconocer que los desarrolladores son usuarios primarios del sistema de diseño. Su experiencia trabajando con la documentación, implementando componentes y consultando especificaciones técnicas es fundamental para el éxito del sistema. Obviamente no hay que dejar de lado que también tienen su peso específico en la organización, más allá de cuestiones técnicas. La convivencia organizacional también es un factor que tenemos que considerar, especialmente cuando tenemos el rol de liderazgo en diseño.
Dicho todo lo cual, es el momento de decir que un sistema de diseño con alta fiabilidad desde la perspectiva de ingeniería tiene definitivamente que facilitar el trabajo de los equipos de desarrollo. Esto implica:
- Especificaciones técnicas precisas y completas
- Ejemplos de código funcionales y testeados
- Documentación de casos extremos y estados de error
- APIs de componentes definidas
- Procesos de actualización y versionado
Cuando los desarrolladores encuentran valor en el sistema de diseño, y especialmente cuando les simplifica el trabajo en lugar de complicarlo, encontramos ese momento mágico en el que la adopción ocurre de manera orgánica. El sistema de diseño deja de ser una imposición, deja de ser una cosa de diseñadores y de estética, y se convierte en una herramienta que facilita el trabajo del día a día.
Migración progresiva y deuda técnica
Habrá quien piense que todo esto está muy bien y tiene razón: el papel o, en este caso, un post de un blog personal lo aguantan todo. Es muy sencillo decirlo y otra cosa es llevarlo a la práctica. La realidad es que no se puede reconstruir todo un ecosistema de aplicaciones de la noche a la mañana. Expresaría una estrategia que tiene que venir definida por un amplio consenso. Y además de eso, la estrategia tiene que contemplar dos frentes a la vez:
Aplicaciones nuevas
Se arranca la construcción desde el inicio siguiendo el Playbook UX. Aquí no hay excusas, todo (o casi todo) es posible, y por eso todo desarrollo nuevo tiene que cumplir los estándares establecidos.
Aplicaciones existentes
Aquí estamos ante un escenario, donde hay que diseñar y desplegar una estrategia de refactorización progresiva. Estamos hablando de establecer una priorización que esté basada en el impacto al usuario, la criticidad del negocio, y por supuesto La viabilidad técnica. Algunas aplicaciones legacy simplemente no justifican la inversión que implica la actualización y, en algunas ocasiones, no les quedará más remedio que coexistir de la mejor manera posible con el ecosistema hasta su desaparición.
Esta gestión de la deuda técnica de UX necesita inexorablemente de dos cosas: criterio y pragmatismo. No todo necesita estar perfecto, pero sí necesita haber un plan y una dirección clara. Una vez más, principio de realidad.
Conclusión
El diseño de experiencia de usuario en ecosistemas tecnológicos que tienen un alto componente de heterogeneidad y que además cuentan con componentes legacy no es tanto un problema estético sino sobre todo un problema de arquitectura. Requiere sistemas de diseño solventes, además de documentación técnica que sea precisa, y por comprensión de las plataformas de implementación.
El objetivo no es necesariamente uniformidad visual, sino que exista una innegable coherencia a nivel de experiencia de usuario, que respete las capacidades y limitaciones de cada tecnología mientras mantiene los principios de usabilidad y accesibilidad. Es un trabajo exigente e importante de ingeniería tanto como de diseño, donde el rigor técnico y la visión de usuario tienen necesariamente que converger en soluciones que sean pragmáticas y sostenibles.
No es fácil.
Muy de acuerdo con el enfoque del post, especialmente con la idea de los sistemas de diseño como infraestructura y la necesidad de playbooks y procesos sólidos en entornos heterogéneos y con legacy.
El problema que veo a menudo no es tanto definir estos sistemas, procesos y artefactos, sino sostenerlos en el tiempo. Mantener un sistema de diseño, su documentación, los tokens, las guías de implementación y los procesos de validación tiene un coste real y recurrente (tiempo, foco y capacidad organizativa). Para que eso funcione, se necesita un cierto nivel de madurez… pero también agencia.
Cuando los equipos trabajan con objetivos muy cortoplacistas o con poca autonomía, nadie quiere asumir el rol de “policía de la coherencia”. El resultado es que los procesos se relajan, la documentación deja de actualizarse, el sistema de diseño resulta incómodo de usar y los equipos, incluido el de diseño, buscan atajos para avanzar. A largo plazo, eso genera deuda de UX.
A este fenómeno suelo llamarlo “oxidación”: el sistema de diseño ideal y lo que realmente acaba llegando a producción divergen poco a poco hasta casi no reconocerse entre sí. Pasa lo mismo con la documentación: capturas de pantalla desactualizadas, procesos que describen pasos que ya no existen, reglas que se ignoran porque son demasiado costosas de seguir.
Cuando a esto se suman incentivos perversos de corto plazo y una baja cultura de producto y diseño, la degradación se vuelve visible en el propio producto. Y cuando esa pérdida de calidad en UX empieza a aparecer incluso en las fases de venta como argumento en contra, normalmente ya es demasiado tarde.
Bastante de acuerdo con lo que dices, Javier. Tanto la oxidación como la degradación son dos conceptos que suelen tener como origen agentes tanto externos como internos. Los externos dependen al 100% del nivel de madurez de la organización y es complicado combatirlos. Los internos, sin embargo, pasan por el presupuesto, por la excelencia estratégica, el liderazgo en diseño y, desde luego, la voluntad de mantener un nivel de servicio.
Pero insisto en el final del artículo: no es fácil.