Hace ya algún tiempo escribía sobre la experiencia de tener un perfil mixto entre diseñador UX y desarrollador y cómo, a pesar de provocar cierta indefinición personal, podía aprovecharse para aplicar de manera cruzada buenas prácticas y evitar errores comunes de una disciplina en la otra. Podría decirse que se trataba de una quimera en su doble acepción, tanto en la de ser híbrido mitológico como en la de situación imaginaria (ya que parecía no ser un perfil que se demandara realmente en las organizaciones).

Por supuesto, estamos hablando de UX y de diseño de experiencia de usuario como proceso que incluye investigación de usuarios, prototipado, evaluación, etc., y no únicamente como la habilidad de “hacer pantallas bonitas”.

Pensaba que me encontraba en un territorio un tanto inexplorado, pero poco después me topé con el artículo ‘Why we have user experience developers at Shopify‘ en el que no sólo se habla de esos seres híbridos que llama UX developers, sino que se dan razones para contratarlos en tu empresa (como ellos hacen):

The UX and engineering teams are not a part of each other’s process. These teams struggle to speak the same language, and handover slows each team’s understanding, making it harder to challenge the other.

UX developers bridge this gap.

El punto de vista del artículo encajaba con mi experiencia: los equipos de diseño y los de programación suelen estar relativamente separados en las organizaciones, e incluyen especialistas que habitualmente:

• tienen perfiles y habilidades muy diferentes
• raramente utilizan las mismas herramientas
• hablan lenguajes diferentes

Precisamente esa discontinuidad, esa brecha en el proceso de desarrollo puede suponer un problema importante a la hora de convertir las necesidades de los usuarios en una aplicación usable, justo ahora que estamos llegando a la conclusión de que dicho proceso tiene que ser iterativo, ágil e integrado.

¿Puede implementarse una metodología ágil o un desarrollo iterativo cuando la comunicación entre diseño y desarrollo es unidireccional y basada en capturas de Photoshop, sin un método de feedback establecido? Eso es algo más propio de una metodología en cascada clásica, donde las especificaciones vienen dictadas “desde arriba”, son inmutables y prácticamente no existe comunicación en el otro sentido.

Justo ahí es donde esos UX developers, personas con conocimientos y experiencia tanto en el campo del desarrollo como en el del diseño, pueden (podemos) actuar como puentes, salvando esa brecha entre disciplinas y facilitando la comunicación en ambos sentidos: por un lado, aportando contexto y limitaciones técnicas a las decisiones de diseño; por otro, incluyendo un punto de vista y una empatía hacia el usuario final en el equipo de programación.

Tomando como punto de partida ese artículo he pensado que se puede concretar más en qué aspectos los UX developers podrían aportar valor en el proceso de desarrollo. Y se me ocurren dos ejemplos:

• en herramientas tan en boca de todos como los design systems
• en un aspecto tan crucial (y, en mi opinión, un tanto descuidado) como la UX de los desarrolladores.

Design systems: quién le pone el cascabel al gato

De un tiempo a esta parte da la sensación de que no eres una organización que se precie si no tienes tu propio ‘design system‘. Más allá de discusiones sobre si es realmente un concepto nuevo o si se trata simplemente de una evolución natural en el proceso de diseño, podemos probablemente acordar que un requisito fundamental en un sistema de diseño es que funcione como repositorio único de estilos, de componentes, de principios, etc. para todos los involucrados en el proceso de desarrollo: fundamentalmente diseñadores y programadores.

Hasta ahora un equipo de diseño podía, por ejemplo, proporcionar una guía de estilos a los desarrolladores y dejar que la integraran en sus interfaces en función de las posibilidades de la arquitectura; por otro lado, los programadores podían tener su propia librería de componentes software para implementar los diseños, librería a la que los diseñadores probablemente no tenían acceso.

Actualmente, para evolucionar hacia un verdadero design system todos esos elementos tienen que formar parte de un único repositorio compartido e integrado. Y como tal, ese repositorio no puede ser creado ni impuesto por una de las partes involucradas, sino que debe ser acordado y puesto en común por todas ellas. Las intenciones son indudablemente buenas, pero ¿quién puede llevar a cabo esa tarea?

Es precisamente ahí donde la figura del UX developer puede jugar un papel fundamental en un design system, tanto a la hora de definir las características y necesidades del sistema y desarrollarlo (detectando puntos en común y posibles fricciones) como para actuar como mediador entre las partes involucradas, al conocer cada una de ellas y hablar su lenguaje propio. Cualquier intento de crear un design system impuesto por un solo departamento teniendo en cuenta únicamente sus propias necesidades tendrá todos los números de terminar en fracaso.

La ‘developer experience’, o los programadores también son personas

En un artículo anterior hablaba de la necesidad de mejorar la experiencia de usuario de los desarrolladores. Cada vez más el proceso de desarrollar una aplicación requiere conocimientos variados, desde el uso de multitud de librerías y herramientas de terceros (frameworks JS, npm, Git, …), hasta el seguimiento de determinados procesos y metodologías (Scrum, Agile, TDD, …). Conceptos como el de full-stack o el de devops pueden dar la falsa sensación de que los profesionales de perfil técnico pueden asumir toda esa sobrecarga de información sin ningún coste. Y no es así: ni siquiera los programadores pueden saberlo todo sobre todo.

“Fullstack” developer. pic.twitter.com/yfymQmJJgq

— Brian Holt (@holtbt) March 24, 2018

Usar interfaces muy claras, hacer las herramientas más fáciles de usar, reducir la necesidad de memorizar datos, automatizar las tareas más repetitivas, … Todos esos propósitos básicos de UX habitualmente referidos a los usuarios finales se pueden (y se deberían) aplicar también a los propios programadores. Reducir la carga cognitiva necesaria para manejar sus herramientas y procesos hará que estos se puedan concentrar en la tarea más complicada y creativa: desarrollar.

Y no se me ocurre nadie mejor que un UX developer para llevar a cabo esa tarea de mejorar la experiencia de los programadores. ¿Por qué no aplicar una evaluación de usabilidad a las herramientas que usan los desarrolladores para ver qué procesos se pueden mejorar? ¿Por qué no hacer un test de usuario con programadores para detectar qué problemas tienen y mejorar su experiencia? Estoy convencido que cualquier recurso dedicado a facilitar el trabajo de los desarrolladores se compensa muy sobradamente con software de mejor calidad.

Ponga un UX developer en su vida

Siendo consciente del peligroso “obligocentrismo” de pensar que el trabajo propio es el más importante y necesario de la galaxia, sinceramente estoy convencido que la figura del UX developer como alguien que pueda moverse a ambos lados de la frontera entre el diseño y el desarrollo tiene muchísimo que aportar en las organizaciones software, y no me extrañaría que fuera un perfil que empezara a demandarse cada vez más en el mundo laboral.

Ahora que a los programadores se les pide en las ofertas de trabajo experiencia y conocimientos en muchos ámbitos (full stack, devops, …) y en tecnologías concretas (“5 años en Angular 2”, “Git”, …) que un buen profesional con experiencia puede aprender en poco tiempo, considero que un desarrollador con experiencia en tareas de UX puede resultar muy valioso, ya que esas habilidades requieren más tiempo y dedicación y, por otro lado, tendrán un tiempo de vida útil mucho más largo que un lenguaje o framework concretos.

Y quizás en algún momento un UX developer siga siendo una quimera como ser híbrido, pero ya no como situación imaginaria.