Reducir la brecha entre diseño y desarrollo web

Ya en 2019, Marina Aisa abordó el concepto del UX Engineer en su charla para T3chFest. Ponía como ejemplo los graves problemas de comunicación que sufría Microsoft entre los equipos de diseño y desarrollo. La solución que proponía era que la mejor forma de conectar con los desarrolladores era “hablar su idioma”. El UX Engineer surge como un perfil híbrido que actúa de puente o traductor entre el diseño y el front-end. Si bien este rol es habitual en grandes compañías, su aplicación en entornos más comunes podría equivaler en un profesional de UX con conocimientos de desarrollo front-end.

Como sostiene Green (2023) en A Guide to UX Design and Development, la raíz del fracaso en los proyectos de experiencia de usuario no está en deficiencias puntuales de diseño o desarrollo, sino en un error estructural: concebir ambas disciplinas como “dos mundos aislados”.

El problema reside en el gran abismo que hay entre diseño y desarrollo.

Esta disociación genera una brecha crítica donde el diseñador, centrado en lo visual y ajeno a las implicaciones técnicas, produce soluciones que no contemplan las posibles restricciones de implementación. A su vez, el desarrollador, tradicionalmente encargado de “hacer que funcione” desde una lógica puramente técnica, trabaja desconectado de los objetivos del negocio y de las necesidades reales del usuario.

El resultado suele ser un producto sin alineación, normalmente con dos escenarios: una propuesta de UX que choca directamente con la viabilidad técnica, o una implementación robusta que no resuelve correctamente el problema del usuario. El fracaso, por tanto, no pertenece a un rol concreto, sino a un modelo de trabajo ineficiente.

Tal como plantean Kashfi et al. (2016) en A Conceptual UX-aware Model of Requirements, la raíz de numerosos problemas de UX es estructural, ya que diseño y desarrollo operan sin un marco común y los modelos vigentes rara vez se alinean de forma efectiva con los procesos de ingeniería de software.

Otra contribución relevante (y que para mí es clave para entender por qué estos conocimientos técnicos suponen una ventaja) es el marco que ofrecen para refinar requisitos UX (subjetivos) en FR + QRs (especificaciones claras y verificables). Esto podemos verlo, por ejemplo, con una afirmación como “el onboarding debe ser fácil y comprensible para un usuario nuevo”. Es una aspiración UX subjetiva. Sin embargo, si incorporamos criterios técnicos desde diseño, esa aspiración puede traducirse en requisitos concretos. Por ejemplo:

• FR (Functional Requirements): “El flujo de onboarding debe completarse en un máximo de 3 pantallas”.
• QR (Quality Requirements): “El usuario debe poder retroceder o avanzar entre pasos sin perder los datos previamente introducidos”.

Esta traducción reduce la ambigüedad y evita interpretación libre por parte de desarrollo y esto es posible cuando diseño trabaja con la tecnología en mente desde el principio.

Por otro lado, este dominio de los aspectos más técnicos es esencial para los entregables y la documentación. Normalmente nos encontrábamos con procesos de hand-off donde diseño entregaba un visual sin especificaciones y desarrollo se enfrentaba solo a su materialización, generando interpretaciones y, en muchas ocasiones, productos fallidos. Tener conocimientos de desarrollo permite al diseñador realizar una traducción terminológica de Figma a Desarrollo y una documentación exhaustiva que elimina ambigüedades y facilita un traspaso riguroso que garantice la máxima fidelidad en la implementación.

Por ello, la incorporación de criterios técnicos en fases tempranas del diseño UX/UI es determinante para garantizar la viabilidad, eficiencia y calidad de la implementación final.

En definitiva, el valor está en reducir la brecha entre diseño y desarrollo. Sin criterios técnicos desde el diseño, la UX falla, ya sea por rework, por decisiones ocultas o por interpretaciones erróneas. La calidad UX depende tanto de la intención del diseño como de la viabilidad técnica desde el primer momento.

Otras ventajas que podemos encontrar al aplicar criterios técnicos en diseño son:

• Permiten traducir un Design System en componentes reutilizables y documentados.
• Aseguran que las implementaciones sean accesibles desde su base.
• Facilitan la detección temprana de problemas técnicos en prototipos funcionales.
• Mejoran la conciencia sobre la viabilidad técnica y el coste real de las ideas de diseño.
• Entender cómo aspectos del desarrollo influyen en una pantalla: tamaños, resoluciones, OS, tecnología nativa, híbrida o web.
• Permiten comprender cómo se implementarán realmente las interacciones.

El principal problema es una relación de enfrentamiento entre desarrollo y diseño que no beneficia a nadie, las empresas y sobre todo, los usuarios, necesitan lo contrario. Esta dinámica negativa se alimenta de una falta de comunicación y de estereotipos que nos presentan incluso como rivales.

El problema es bidireccional, por un lado, los criterios de UX a menudo no se integran correctamente en los documentos de requisitos, por otro, el trabajo de diseño puede resultar un desafío enorme de implementar. Para solucionarlo, creo que los desarrolladores deberían mostrar curiosidad por el aspecto visual, mientras que los diseñadores debemos esforzarnos por conocer la tecnología.

Las empresas, por su parte, tienen un papel clave fomentando entornos colaborativos donde se trabaje en paralelo, no en cascada. La misión es clara: ofrecer al usuario una experiencia óptima que le permita alcanzar sus objetivos de la forma más satisfactoria posible. Y esto solo se logra trabajando en conjunto e implementando los procesos y metodologías adecuados.