6 problemas típicos en proyectos UX — parte 5: Brecha entre diseño y desarrollo

2b2c965

Éste es el quinto capítulo de la serie sobre los 6 problemas típicos en proyectos UX que hemos encontrado en Continuum.

Al igual que el problema #4 (investigación deficiente), éste es un problema que, al menos parcialmente, es responsabilidad de los diseñadores a la hora de desarrollar productos digitales en equipo. En Continuum nos hemos dado cuenta una y otra vez que la separación entre equipos de diseño y equipos de desarrollo fractura los productos, vuelve tediosos los proyectos y genera mucha más fricción que la necesaria. Veamos por qué.

Trabajar en silos, como si estuviéramos armando autos

Henry Ford es conocido por haber desarrollado el automóvil moderno. Sin embargo, hizo otra contribución igualmente trascendental para la industria moderna: la línea de ensamblaje. Hasta entonces, las fábricas e industrias tendían a estar organizadas en torno a la figura del artesano, dominador de su oficio y capaz de crear un producto de principio a fin.

La innovación de Ford fue crear un proceso lineal compuesto de varios operarios, cada cual especializado en una tarea puntual sobre el producto y encargado de entregárselo al siguiente. Un silo ensambla el motor, otro pone la carrocería, otro los asientos, otro lo pinta. El proceso demostró ser mucho más eficiente y requerir menor mano de obra calificada. Nadie es irremplazable, dado que todos sólo hacen una parte del trabajo. Lo realmente central pasa a ser el proceso productivo. Los automóviles se fabrican de esa forma hasta el día de hoy.

La idea de que la línea de ensamblaje mejoraba la eficiencia industrial fue tan trascendente que impregnó toda la cultura empresarial, incluyendo la de procesos que no necesariamente se beneficiarían de la división de roles. El término “fábrica de software” tiene que ver precisamente con esta cultura: tienes un silo de analistas funcionales, otro de arquitectos de software, otro de programadores back-end, luego de front-end, otro de Quality Assurance y otro de DevOps. Cada uno se va pasando el software, en un orden lineal, como si estuvieran armando un automóvil.

Cuando le tocó a las empresas asumir la necesidad de integrar la Experiencia de Usuario a sus productos digitales (estamos hablando del 2005 para las empresas pioneras y del 2019 para las más rezagadas), sus gerentes de TI vieron que la solución era sencilla y constaba de dos pasos:

  • Incorporar a los expertos de UX al principio del proceso, en el silo del análisis funcional. De esta forma, los UXers procesarían los requerimientos y generarían un conjunto de especificaciones que luego pasarían a manos de los arquitectos de software, y de alguna forma validarían con sus conocimientos e investigación el trabajo de los analistas funcionales.
  • Potenciar el silo de front-end con diseñadores que tuviesen conocimientos de usabilidad. Así, el producto tendría una mejor usabilidad, se vería más moderno e integraría efectos visuales que lo harían más atractivo.

Todo esto suena maravilloso… en teoría. En la práctica, ha resultado pésimo.

Jugando al teléfono (malogrado)

El approach que les acabo de describir tiene las siguientes fallas estructurales:

  • Asume que el software pasa limpiamente de un silo al siguiente. Nuevamente hay que recordar que este proceso fue pensado para producir autos; funciona bien cuando trabajas sobre objetos físicos. El software no es un objeto físico, y en el mundo de lo abstracto, el concepto de “una buena experiencia de usuario” es una de las que se degrada más rápidamente. Cuando el estratega de UX entrega sus diseños y no vuelve a saber del producto hasta que ha sido lanzado, el ruido que provoca el hand-off se va amplificando de silo en silo.
  • Como lo anterior nunca resulta cierto, se cubre la brecha con documentación. Un montón de documentación. OK, tenemos el problema de que el producto digital se va degradando a medida que pasa de mano en mano. ¿Cuál es el problema aquí? Para el mindset de la línea de producción, la respuesta es simple: es porque el producto no se ha especificado lo suficiente. Si la documentación es clara y exhaustiva, nadie tendrá por qué malinterpretar nada. Y así, amigos, es como surgieron las documentaciones técnicas de tomos y tomos que toman meses en escribirse y meses en leerse (cuando son leídos).
  • Asume que sólo una parte del equipo es la responsable de la experiencia de usuario. Y ésta es sin duda la falla más grave. Asumiendo que los desarrolladores de software son más productivos cuando trabajan en un entorno aséptico, se los aísla totalmente del contacto con usuarios y se les pide optimizar en torno a la robustez y la performance como única meta. El contenido, realmente, no importa. Y es así como llegamos a mensajes de error como el siguiente:

User-friendly.

Y en este punto es donde empieza la pelea entre diseñadores y desarrolladores. Los diseñadores sienten que los desarrolladores no escuchan sus requerimientos y no entienden lo que significa una buena experiencia de usuario, y éstos a su vez piensan que los diseñadores no entienden el costo de implementar sus sugerencias, y no le ven sentido a agregar “adornos” que retrasan el proyecto.

Ambos tienen la razón

La división entre diseñadores y desarrolladores es artificial y dañina. Ambos son parte clave del mismo producto. Es el diseñador quien planifica e idea una experiencia de usuario, pero es el desarrollador el encargado de hacerla realidad.Desde el punto de vista del usuario, ambas partes son indistinguibles en la forma en cómo lo experimenta. Ningún usuario final piensa “este producto está bien diseñado, pero mal implementado” o “este producto tiene súper buena performance, pero le faltó diseño”. Simplemente piensa “este producto está mal hecho”.

Esto implica que cada parte debe aprender algo sobre la otra:

  • Los diseñadores necesitan entender que sus decisiones tienen costos de implementación y un potencial impacto en la performance. Es responsabilidad de un diseñador conocer su soporte. Independiente de si el diseñador sabe o no de programación, es su deber entender cómo funciona el medio en el cual está diseñando. Más al respecto en este artículo.
  • Los desarrolladores necesitan entender que el código que construyen será usado por seres humanos, y que lo que hagan determinará la experiencia final. No es necesario que el desarrollador “sepa diseñar” ni que se sepa al dedillo los patrones de interacción; pero sí es primordial que esté tan conectado con los usuarios finales como lo está el diseñador.

Diseñadores y desarrolladores necesitan un lenguaje unificado. Y esto, a su vez, requiere que ambos trabajen juntos y cooperen en tiempo real. Es por esto que, desde la primera reunión de nuestros procesos de Lean UX, pedimos a los desarrolladores que sean parte de la mesa de trabajo y participen en definir la propuesta de valor y en conocer las necesidades de usuario.

Hay un valor enorme en que el equipo desarrollador sea partícipe del feedback de los usuarios tempranamente. Súbitamente, lo que hace ya no se va a una caja negra en medio de la nada; va dirigido a otras personas, que lo experimentarán, lo usarán y opinarán sobre él. Sentir que estamos haciendo algo importante para otros es potente para la motivación, sin importar el tipo de trabajo.

Con un cliente en particular, un jefe de desarrollo nos preguntó:

¿Qué saco con estar presente en estas reuniones? Son de diseño, no de desarrollo. Lo que a mí me compete es que las cosas queden bien hechas, que logren alta disponibilidad y que sean robustas. Estar acá me hace perder tiempo valioso.

Como imaginarán, este desarrollador nació y fue criado en la mentalidad de silos. Nuestra respuesta fue la siguiente:

Si estás presente, podrás en primer lugar tener voz y voto sobre las cosas que luego tú mismo tendrás que desarrollar. Si no estás, corremos el riesgo de tomar decisiones de diseño que impacten directamente los tiempos de desarrollo de tu equipo. En segundo lugar, serás partícipe de las necesidades de usuario que hacen surgir este producto, y eso te permitirá trabajar con más autonomía, porque entenderás mejor lo que necesitan los usuarios, y por ende el diseñador deberá intervenir menos. Y por último, ayudarás a crear un mejor producto, que te hará sentir más orgulloso y que recibirá menos tickets de soporte por fallas de usabilidad.

Al parecer la respuesta lo convenció, porque continuó yendo al resto de las reuniones.

Agile UX: La UX es responsabilidad de todos

En Continuum es requerimiento que los diseñadores de UX sepamos además escribir código, como mínimo HTML/CSS/JS (hemos tenido que dejar fuera UXers talentosísimos sólo por esta razón). Esto no sólo es para hablar un lenguaje común con los desarrolladores, sino para actuar directamente como uno de ellos en la parte front-end.

De eso se trata Agile UX: de compartir la responsabilidad a la hora de la implementación. La mezcla de que ambos lados entiendan el trabajo del otro, y que a su vez cada uno pueda concentrarse en lo que es más eficiente, trae como resultado velocidades altas y un equipo sumamente satisfecho y que requiere mucha menos documentación y gestión.

Personalmente me gusta mucho programar en Ruby on Rails, y el poder estar metido directamente entre modelos, vistas y controladores me permite asegurarme que la experiencia de usuario final es exactamente la diseñada. Lo mismo ocurre con JavaScript y la interactividad que le agrega a los productos Web. Y lo mismo ocurre con entender las implicancias de performance de los dispositivos móviles, así como sus capacidades.

Los profesionales de UX que se quedan demasiado pegados en las tareas más proyectuales y no meten las manos a la implementación de aquello que diseñan le hacen un flaco favor a sus productos. En primer lugar, hacen necesaria toda la burocracia de documentación y papeleos que ralentiza el proyecto y desgasta al equipo, y en segundo lugar pierden contacto con el producto final, aquel que realmente experimentan los usuarios.

La gente no usa wireframes ni usa prototipos clickeables: usa productos reales. En la medida que estemos más integrados con la manera en la que se hacen los productos reales y finales, tendremos mejores experiencias para nuestros usuarios, y una experiencia más rica de trabajo para nosotros mismos y para el equipo.

¡No te desconectes!

Próximo capítulo y final: Waterfall UX.

2 comentarios en “6 problemas típicos en proyectos UX — parte 5: Brecha entre diseño y desarrollo

  1. Sole Moris

    Excelente artículo. Mi párrafo favorito:
    “Los profesionales de UX que se quedan demasiado pegados en las tareas más proyectuales y no meten las manos a la implementación de aquello que diseñan le hacen un flaco favor a sus productos. En primer lugar, hacen necesaria toda la burocracia de documentación y papeleos que ralentiza el proyecto y desgasta al equipo, y en segundo lugar pierden contacto con el producto final, aquel que realmente experimentan los usuarios”.
    Mi único comentario negativo es que cuando se usan mucho términos como “approach”, “scope”, etc. es similar a cuando comiste estupendo, pero al rato se te repite el postre.
    ¡Saludos! 🙂

    Responder

Agregar un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *