Soy un impostor por partida doble.

Si el síndrome del impostor hace que dudes de tu competencia profesional a pesar de la experiencia o los logros que acumules, yo tengo el dudoso mérito de poder ser un fraude en, al menos, dos disciplinas: el diseño de interfaces (vamos a llamarlo así por ahora) y el desarrollo de software.

Me cuesta considerarme un diseñador porque, a pesar de tener un máster en diseño de interfaces cuyo trabajo final fue una herramienta de soporte al diseño, publicar algún artículo sobre el tema o haber desarrollado varios proyectos de prototipado y evaluación, no me emociono con los diagramas de UX, ni creo que el design thinking sea la solución a todos los problemas de la humanidad, ni considero que cosas como el diseño colaborativo sean tan positivas, ni tengo una obsesión compulsiva hacia los post-its.

Aunque tampoco debo de ser un desarrollador como Dios manda porque no soy un enamorado de la línea de comandos, ni proclamo a gritos lo maravilloso que es Git, y supongo que voy camino de la ceguera porque no he memorizado la combinación de teclas para poner cualquier editor con el fondo oscuro. Y eso que, cuando peina canas, uno ya tiene en la mochila casi de todo: desde el diseño de modelos de datos, SQL y stored procedures, hasta algunas experiencias con los últimos frameworks JavaScript, pasando por Java, .NET o PHP.

Pero… veamos el lado positivo: tener un pie a cada lado de la frontera hace que veas las cosas con cierta perspectiva, que puedas comparar hábitos y maneras de trabajar, e incluso que puedas proponer cómo unos y otros pueden beneficiarse mutuamente de buenas prácticas y aprender de errores ajenos (que siempre es más práctico que hacerlo de los propios).

Metodologías y “metodologías”

Si consideramos que una metodología es una combinación de técnicas (o métodos), herramientas para desarrollarlas y alguna guía que ayude a elegir cuándo y como hacerlo, no cabe duda de que los desarrolladores llevan mucha ventaja a los diseñadores. Desde las metodologías en cascada hasta las ágiles, en general podemos decir que las de desarrollo de software están bastante bien estudiadas y definidas: sus pasos, sus herramientas, las diferencias entre ellas, etc. Eso hace que, en general, podemos determinar si un proceso concreto sigue una metodología u otra.

Por otro lado, en los foros del diseño de interfaces se sigue discutiendo sobre qué es UX, qué es diseño centrado en el usuario, qué es design thinking; y por qué es una herejía digna de excomunión confundirlos o mezclarlos. Eso sí, cuando uno intenta hacer una comparación mínimamente rigurosa entre ellos se encuentra con que, en la práctica, no existe una definición formal de ninguno de ellos, ni de los pasos o técnicas concretas que incluyen. Son, en el mejor caso, una serie de principios generales y buenas prácticas que además son, ¡oh, sorpresa!, muy similares entre ellos. Mientras un programador puede perfectamente decir que no está usando Scrum, es difícil que algún diseñador afirme que no “hace UX”, o que no está centrado en el usuario; prueba de que, en el fondo, no significan prácticamente nada (si nos inspiramos en la falsabilidad de Popper).

Creo firmemente que sería positivo que los diseñadores de interfaces dispusieran de metodologías más y mejor definidas, que les guiaran en el proceso de diseño y a la hora de decidir qué técnicas aplicar en cada momento y cómo (sobre lo que hice un humildísimo intento). Eso sí, siempre recordando que usar una metodología en un proceso creativo no quiere decir limitar la creatividad, sino encauzarla hacia el objetivo final.

En definitiva, en este aspecto los diseñadores podrían parecerse un poco más a los desarrolladores, pero sin llegar a perder de vista (como a veces les ocurre a  estos últimos) que la metodología es un medio, no un fin en sí mismo. El objetivo final es construir mejor software o mejores diseños, no elaborar mejores entregables o poder presumir de que se ha seguido la metodología al pie de la letra.

Lo que nos lleva al siguiente punto.

Herramientas (y el amor por ellas)

Los desarrolladores se enamoran con preocupante frecuencia de sus herramientas (y que nadie saque la frase de contexto). Todavía me sorprende la pasión casi “hooliganiana” con la que muchos de ellos defienden la superioridad de su lenguaje de programación o del framework que usan sobre los demás. Que yo sepa, los fontaneros no llevan camisetas con su llave inglesa preferida, ni los electricistas hacen congresos para gritar lo avanzados que son los destornilladores de estrella comparados con los de pala. Personalmente tengo más una relación de amor/odio con ellas; son herramientas, las eliges en función de tu objetivo, y cuando las conoces acabas conociendo y amando sus virtudes, y odiando sus defectos.

¿De dónde viene entonces ese “fanboyismo” (tan poco profesional, me atrevería a decir)?. Probablemente daría para una tesis en psicología, pero puede que la receta tenga (además de nuestra tendencia a seguir las modas) un poco de Síndrome de Estocolmo, algo de disonancia cognitiva y una pizca de falacia del coste hundido. En resumen: cuando uno ha invertido mucho tiempo y esfuerzo en dominar una tecnología, racionaliza que esa tecnología tiene que ser buena por necesidad y hace que sea poco probable que la abandone en favor de otra.

El resultado es que, en ocasiones, los programadores dedican más tiempo y esfuerzo a conseguir que las herramientas funcionen (cof… cof… Git… cof… cof… node.js … cof… cof… Webpack… cof… cof…) que en realizar su verdadero trabajo. Como decía Kathy Sierra, ese tipo de tareas secundarias deberían automatizarse en la medida de lo posible para que los desarrolladores puedan concentrarse en las tareas creativas de su trabajo, que bastante difíciles son ya de por sí.

Entre los diseñadores, en cambio, mi sensación es que ese efecto es mucho menos acusado. Por supuesto, cada uno tiene sus herramientas de prototipado o editores gráficos favoritos, pero no me parece que estén tan atados a ellas como los desarrolladores, ni que el uso de una u otra despierte tantas pasiones. Parece que en el diseño se tiene más presente que el verdadero objetivo es el trabajo realizado (un diseño adecuado) e, idealmente, la satisfacción del usuario, y que las herramientas utilizadas son un aspecto secundario. Diría que, en ese sentido, los desarrolladores deberían tomar buena nota.

Mientras tanto…

… podemos seguir discutiendo sobre cómo se llama lo que hacemos, o si los diseñadores deberían saber programar, o cuánto deberían saber los desarrolladores de diseño, o qué ponemos en nuestro perfil de LinkedIn. Las discusiones semánticas tienen su utilidad, pero corremos el riesgo de quedarnos varados en ellas y que se conviertan en argumentaciones sobre el sexo de los ángeles, sin ningún resultado práctico.

Yo, por ahora, seguiré actuando como si supiera lo que hago (hasta que me descubran).