No hay duda acerca del impacto que ha tenido el desarrollo de herramientas de software para la creación de proyectos de diseño desde los años 80, aquellas que el historiador y teórico Lev Manovich agrupa bajo el término software de medios: programas que permiten crear, publicar, compartir y remezclar imágenes, diseños en 3D, texto, vídeos, elementos interactivos y un largo etcétera. Manovich incluso define nuestra sociedad actual como una sociedad del software y la cultura contemporánea como cultura del software, en cuanto éste influye directamente en la creación de los productos que dan forma a lo que denominamos “cultura.” El historiador incide también en que el software suele ser ignorado en los análisis de la cultura contemporánea, mientras que es de hecho lo que define lo que se puede hacer al trabajar en un proyecto creativo con un ordenador.

En su libro El software toma el mando (UOC Press. Comunicación #29. Barcelona : Editorial UOC, 2013), Manovich señala que los medios simulados por medio del software (fotografías digitales, vídeos, simulaciones en 3D, etc) se basan en dos elementos principales: una estructura de datos y una serie de algoritmos. El software “interpreta” los datos contenidos en un archivo por medio de una serie de algoritmos que hacen posible manipular una foto digital o combinar fotos y texto en un programa de diseño gráfico. Pero también determinan si es posible o no abrir un dibujo de vectores en un programa de edición de fotografías, o manipular las propiedades de un tipo de letra.

El código de programación es lo que da forma al software y en consecuencia determina qué pueden hacer los diseñadores con los programas que emplean a diario. A lo largo de las últimas décadas, las innovaciones que han introducido las empresas desarrolladoras de software en sus productos han tenido una fuerte influencia en las tendencias de diseño, puesto que han hecho posibles nuevas maneras de crear composiciones de diseño gráfico, objetos de consumo o interfaces de usuario. A fin de superar esta dependencia del software, se plantea una cuestión que viene debatiéndose durante los últimos años: ¿los diseñadores deben saber programar?

Según el ingeniero y diseñador John Maeda, uno de los principales promotores del “creative coding” o programación creativa, saber programar es un conocimiento imprescindible para los diseñadores del siglo XXI. Maeda afirma que el rol del diseñador está cambiando y que ya no se trata sólo de conocer o anticipar las necesidades del usuario, sino también de tener la capacidad de programar y trabajar con diseño generativo, machine learning u otras tecnologías de Inteligencia Artificial. En las recientes ediciones del Design in Tech Report, Maeda y su equipo plantean la comparación entre el diseñador “clásico,” que crea objetos para un conjunto limitado de personas (como ocurre en el diseño gráfico, diseño de producto o diseño de mobiliario) y el diseñador computacional, que trabaja con productos en constante evolución. Maeda define el diseñadores computacional como un profesional que entiende la computación (tiene un conocimiento de los lenguajes de programación y sabe qué se puede hacer con ellos), reflexiona de forma crítica sobre la tecnología (considerando los aspectos positivos y negativos en relación al proyecto) y aprende acerca de las últimas innovaciones tecnológicas, tales como los avances en Inteligencia Artificial.

Si bien Maeda daría una respuesta categóricamente afirmativa a la pregunta que encabeza este texto, y tiene argumentos para defender su postura, cabe considerar otros puntos de vista. En una serie de artículos publicados en la plataforma Medium, el diseñador de software Alan Cooper, creador del entorno de programación Visual BASIC y pionero en el campo del diseño de interacción, plantea las razones por las cuales los diseñadores no deben saber programar.

De entrada, Cooper plantea una serie de razones por las cuales no hay que imponer a los diseñadores la necesidad de aprender a programar:

• Es posible saber cómo se hace algo sin hacerlo directamente. Muchos profesionales (directores, coreógrafos, entrenadores, etc) dirigen a otros sin hacer su trabajo, pero sabiendo cómo debe hacerse.
• Hacer algo no supone automáticamente conocer sus implicaciones. Saber programar no implica entender los efectos del código que se ha creado en el producto final o en la organización que lo emplea.
• La separación entre “diseñadores” y “desarrolladores” es simplista y no refleja la complejidad de ambos roles ni cómo estos interactúan. En este sentido, Cooper indica que si bien puede ser bueno que los diseñadores dediquen un tiempo a programar, los programadores también deberían dedicar un tiempo a diseñar, es decir a participar en el proceso de diseño que incluye conocer las necesidades de los usuarios.
• Hay pocos buenos programadores y diseñadores. Por tanto, para Cooper “es absurdo y un desperdicio obligarles a trabajar en un ámbito ajeno a sus especiales habilidades.”

Alan Cooper culpa de esta división entre diseño y programación a la propia industria del software, que se rige por los beneficios económicos y un ritmo de producción que impide que el 80% de los proyectos llegue a materializarse:

“Hemos creado sistemas de software cutres durante décadas, y al parecer no somos capaces de encontrar la manera de hacerlo de forma efectiva. La mayoría de los proyectos no ven la luz del día. Los que lo logran son a menudo versiones patéticamente débiles que carecen de fuerza y flexibilidad.”

Los programas y plataformas que se han ido desarrollando en la última década, muchos de ellos en código abierto, contribuyen a resolver este problema, si bien sigue existiendo la brecha entre diseñadores y programadores. Para salvar esta distancia, en lo que coinciden Cooper y Maeda es en que los diseñadores deben conocer el potencial de los lenguajes de programación y lo que supone trabajar con ellos. De esta manera, pueden colaborar más efectivamente con los programadores y saber qué pedirle en función de las necesidades del proyecto. Esto también es beneficioso para el programador, puesto que su trabajo vincula el ordenador con el usuario, pero como indica Cooper, nunca trata con el usuario, sólo con el ordenador. El diseñador, cuyo trabajo se centra en entender las necesidades del usuario, puede aportar esta parte al programador sabiendo qué puede pedirle y qué no, aunque no sepa programar, si entiende las capacidades y limitaciones del código.