Los desarrolladores son de Marte. Los diseñadores de Venus. (Parte 1 de 2)

Aquel libro tan conocido sobre si unos éramos de marte y otros de Venus podría ser aplicable a nuestro sector como: "Los desarrolladores son de Marte. Los diseñadores son de Venus"

Espero que nadie se sienta ofendido, pero si eres diseñador o desarrollador probablemente sepas de lo que hablo. ¿Por qué cuesta a veces tanto que estos dos perfiles se entiendan o se alineen a la hora de trabajar?"

Hoy quiero compartir contigo dos motivos que yo creo que son la causa, y unas claves que te ayudarán a que tanto diseñadores como desarrolladores os entendáis en vuestro próximo proyecto.

Notas del episodio

Enlaces mencionados en el podcast

Aquí está la lista de recursos mencionados en el episodio de número 49:

  • Project Notes: Para agregar títulos, notas al pie y notas adhesivas a los artboards en Figma. 
  • Sticky notes: Para crear notas adhesivas (como post-its) en los wireframes, mockups y diseños que hagas con Figma. 
  • Notepad: plugin en Figma para crear un lugar donde poner las notas en los archivos. 

Accede a la plantilla gratuita de control de presupuesto en los proyectos

Subscríbete a la newsletter y accede gratuitamente a la visualización y resto de material de los episodios exclusivo para los miembros de la comunidad Lecciones UI para Creativos.

¿Eres de los que prefieren leer?

Transcripción del podcast por si lo tuyo es leer a tu rollo con una buena taza de te/café/mate...

El otro día leí unos mensajes del grupo de padres del colegio de mis hijos que me hicieron pensar en la “in-comunicación” entre diseñadores y desarrolladores. Os paso aquí un trocito de la conversación para explicarme mejor:

  • Madre delegada: Hola a todos, empezamos el curso y hay que elegir delegada de padres de la clase. Yo fuí el año pasado. Animaros que no es mucho trabajo.
  • Madre X: La extraescolar de Inglés qué día la hacen?
  • Delegada: Aún no se sabe porque antes hay que abrir grupo.
    Apúntalo 🙂
  • X: Qué día lo hacen?
  • Delegada: No se sabe, X.
  • X: Si lo hacen los martes, sí.
  • Delegada: Antes hay que abrir grupo, y para eso hay que apuntarse. BTW, nadie se presenta de delegad@? En serio, no es mucho trabajo.
  • X: Pero antes era los martes, no?
  • Delegada: No sé cuándo lo hacían el año pasado. Cada año cambian.
  • X: Vale

Parece un diálogo de besugos, con una clara tendencia a cada uno estar por su tema ¿verdad?. Entre creativos y desarrolladores suele pasar algo parecido.

Por eso, hoy quiero compartir contigo los obstáculos que hacen la comunicación y coordinación tan complicada entre los dos equipos; y también qué puedes hacer como diseñador para superarlos.

¿Empezamos?

La realidad se debe aceptar. En este caso la realidad es que la comunicación y coordinación entre diseñadores y desarrolladores suele ser peliaguda. Empieza con buenas intenciones, pero a menudo acaba teniendo malentendidos y discusiones en algún momento (o varios).

Intentar cambiar a los desarrolladores es un objetivo inalcanzable y fuera de nuestro círculo de influencia. Además, puede ser también un ataque de arrogancia por nuestra parte, pues igual el problema no son ellos, sino nosotros… ¿o puede que un poco de ambas partes?

Lo mejor será otra estrategia viable para nosotros y mucho más humilde: vamos a ver lo que sí podemos hacer nosotros. Creo que para ello lo más efectivo es entender el otro lado, a los desarrolladores.

Para hablar de ello he dividido el episodio de hoy en 2 partes:

  1. La forma de pensar y analizar de diseñadores y desarrolladores. Una breve explicación basada en algunos artículos que he leído, y  lo que he vivido desde mi experiencia como “diseñarrolladora”.
  2. En la segunda parte veremos 8 claves que te serán de gran utilidad a la hora de entenderte con los desarrolladores, trabajar más a gusto haciendo equipo con ellos, y consiguiendo en conjunto mejores resultados en el proyecto.

¿Qué dificulta la comunicación entre diseñadores y desarrolladores?

Los motivos que yo he detectado que dificultan la comunicación entre el equipo creativo y el de desarrollo son los siguientes:

Motivo 1

Éste primero es muy obvio y fácil de detectar: cada equipo mira y se preocupa por sus propios intereses y problemas.

Los desarrolladores tienen la mirada en:

  • ¿Cómo vamos a implementar el diseño dado? ¿Es un diseño viable tecnológicamente?
  • ¿Cómo lo haremos para no cargar el sistema y que tenga una buena velocidad de carga?
  • ¿Cómo haremos las llamadas a las bases de datos lo más eficiente y mínimas posible?
  • ¿Cómo testearemos la app o la web?
  • También mirarán otros temas como: crear un código limpio, reutilizable, fácil de entender; generar una buena documentación, etc.

Y pensarán en todo ello en torno al deadline. El éxito del proyecto se basa en que consigan todo lo anterior cumpliendo a la vez el deadline con el cliente.

Por otro lado, el equipo creativo está enfocado en:

  • Crear un concepto disruptivo que será la base para el resto de diseño. Se trata de la idea entorno a la cual se construirá el proyecto. Debe ir de acuerdo con la marca y conseguir diferenciarla del resto.
  • Cómo aplicar y transmitir la marca y sus valores en el proyecto.
  • Cómo conseguir y asegurar en la medida de lo posible que el diseño realizado cubra todas las necesidades: diseño de todas las pantallas y páginas acordadas con el cliente consiguiendo qeu cada una de ellas cumpla con el objetivo (los usuarios compren un producto fácilmente, contacten con el cliente, pidan una demostración de un producto, etc).
  • Cómo transmitir el concepto al cliente, pues no siempre es fácil conseguir que un cliente abandone la línea que ha llevado hasta ahora, pese a que no le ha funcionado. Y es mucho más difícil aún si el equipo creativo presenta un concepto y proyecto que rompe moldes en el sector.
  • Además de otros temas como por ejemplo:Cómo conseguir una correcta adaptación del diseño a otros dispositivos, si se trata de una app o de una web (responsive design); Crear un prototipo del diseño interactivo a poder ser y comprensible por el cliente; etc.

Así pues, cada uno tiene el enfoque en aspectos y necesidades muy diferentes del proyecto.

Esto provoca que a la hora de comunicarse pueda darse la situación que os presentaba del whatsapp. Mientras el equipo creativo está preocupado en los aspectos de diseño y comunicación del proyecto, el equipo de IT está discurriendo sobre los aspectos técnicos.

Parece obvio, pero a veces se nos olvida, y diseñamos como si no hubiera limitaciones técnicas, o no entendemos cómo el equipo de IT se salta aspectos estilísticos básicos o del branding. Se nos olvida pues, que ellos tienen la mirada en esos otros aspectos técnicos.

Motivo 2

El segundo motivo se trata del hecho de que el pensamiento y el proceso mental de trabajo para analizar, decidir y actuar suele ser distinto según si se trata de un equipo creativo o de desarrollo.

Yo he oído a desarrolladores hablar de diseñadores como si estos últimos fueran seres irracionales completamente. Acusación que me pareció completamente errónea. Desde mi punto de vista, esos diseñadores sólo pensaban de diferente manera y usaban el cerebro de otra manera que los desarrolladores que los criticaban. Ni mejor ni peor. Y mucho menos irracional o sin sentido.

Hasta hace unos años habríamos explicado esta diferencia en el pensamiento basándonos en el descubrimiento del psicobiólogo y ganador del Premio Nobel Roger W. Sperry en los años 60.

Los dos cerebros
Cerebro

Según Sperry, y explicado de forma muy genérica, el cerebro se divide en el hemisferio izquierdo y el derecho.

  • Hemisferio izquierdo: más verbal, analítico y ordenado que el derecho. Por eso se creía que era más conveniente para leer, escribir y hacer cálculos.
  • Hemisferio derecho: más visual e intuitivo, por lo su forma de pensar es más creativa y menos organizada.

Basándose en esta hipótesis que separaba tan claramente dónde se realizaban las funciones en el cerebro, se pensó que el cerebro izquierdo era el que estaba conectado a la lógica, la secuenciación, pensamiento lineal, matemáticas, pensamiento verbal, etc. Mientras que el cerebro derecho se asoció a la imaginación, pensamiento holístico, artes, intuición, visualización de ideas, etc.

Según esta teoría, hay un hemisferio predominante en cada uno de nosotros. En el caso de los desarrolladores, el hemisferio predominante por norma general sería el izquierdo, mientras que en los diseñadores sería el derecho.

¿Realmente hay un cerebro predominante?

Años después del descubrimiento de los dos cerebros, un equipo de neurocientíficos quiso comprobar la premisa. Durante 2 años hicieron resonancias magnéticas a 1000 personas. La conclusión fue que el cerebro humano no favorece a un hemisferio sobre el otro, ni las redes de un lado suelen ser más fuertes que las del otro.

Lo que sí se ha comprobado es que los dos hemisferios están unidos por fibras nerviosas creando una autopista de información entre ellos. De esta manera, cada hemisferio trabaja de manera diferente pero juntos, compartiendo información a través de esa autopista.

Por tanto, tanto si realizas una función lógica como una creativa, ambos hemisferios están trabajando y aportando información. P.e.: Al hemisferio izquierdo se le atribuye el lenguaje, sin embargo es el cerebro derecho el que te ayuda a comprender el contexto y el tono.

Si no trabajan ambos hemisferios conjuntamente, tu habilidad de comunicación no funcionaría correctamente.

Así pues, tanto el diseñador como el desarrollador acaban usando las dos partes del cerebro a la vez. En otras palabras, podemos olvidarnos de la idea simplista de que si eres programador/ingeniero predomina el hemisferio izquierdo, y si eres diseñador@ usas más el derecho.

Pero entonces… ¿Los diseñadores y los desarrolladores pensamos igual o no?

Os explicaré mi experiencia aquí para compartir cómo yo respondo a esta pregunta. Yo he detectado que diseñadores y desarrolladores no piensan igual.

No puedo afirmar que sea porque biológicamente sean diferentes.Lo que sí que puedo afirmar es que durante su formación, a los desarrolladores se les trabaja mucho las tareas que tradicionalmente se creían del hemisferio izquierdo, mientras que a los diseñadores se les trabaja las tareas que se creían de hemisferio derecho.

Es decir, a los desarrolladores y a los ingenieros en general se les enseña a clasificar, categorizar y organizar basándose en el conocimiento o los datos para que la asimilación del proyecto a realizar o tareas sea más sencilla. Yo he conocido personas que de entrada eran despistadas y desorganizadas y después de la ingeniería habían dejado de serlo, por lo menos en su trabajo, en su vida personal su esencia se relajaba y el caos salía a flote.

En cambio, a los diseñadores se nos enseña a procesar la información de otra manera, se realza más la importancia de mantenerse abiertos.

El análisis en la formación como diseñador@

Análisis de negocio

Recuerdo hablando con unos diseñadores con los que que trabajé que hablaban de su problemas en el estudio que habían creado. Intenté echarles un cable y empecé a analizar los clientes que tenían, a clasificarlos según su importancia social, influencia económica para el estudio, la recurrencia de sus pedidos, etc.

El objetivo era poder encontrar el cliente ideal para poder tenerlo bien definido. Ese era el primer paso básico para poder luego determinar qué acciones se requerían para poder conseguir más del mismo tipo.

Se quedaron sorprendidos del análisis. No se les había ocurrido este tipo de pensamiento ni de forma de plantearse los clientes. No es que yo fuera la crac número uno del mundo. En realidad sólo apliqué lo que me habían enseñado a hacer en la carrera y en el primer trabajo que tuve como ingeniera.

En cambio, los diseñadores a los que me dirigía, en toda su formación como diseñadores, nunca nadie les había comentado este tipo de análisis.

Yo misma he estudiado una ingeniería y luego estudié diseño. Mientras en la ingeniería no parábamos de hacer este tipo de análisis para los proyectos, mirando sus fortalezas, debilidades, viabilidad, etc. antes de determinar soluciones, durante mi formación en diseño nunca hablamos ni de que existía este tipo de análisis.

Puede, y espero, que esto esté cambiando, y que en los estudios de diseño cada vez se incluya más el análisis (desde el punto de vista de marketing, empresa y proyecto). Pero durante misi años de formación en universidades y centros docentes, no se daba.

Formación diferente, enfoque distintos

Esto lleva a que luego los equipos de IT tengan un enfoque muy analítico, organizado y paso a paso, siguiendo la norma. Mientras que muchos creativos traten incluso de huir de la norma para mantenerse abiertos, y ser mucho menos analíticos y planificadores.

Atención, esto lo digo como esencia muy general. Hay muchos diseñadores brillantes que tienen un método muy planificado y estructurado.

En fin, como decía, esto lo digo desde mi experiencia personal como diseñadora y programadora.

3 claves para mejorar la comunicación y colaboración con los desarrolladores

1. Involucra a los desarrolladores desde el principio

Diseñadores y desarrolladoes trabajando juntos

En muchos proyectos web y app se trabaja de la siguiente manera: un diseñador o equipo de diseño crea los diseños del producto. Cuando ya están todos hechos se muestran al equipo de IT para tener su valoración de la comlejidad de implementación del diseño. Algunos diseñador@s llegan incluso a validar los diseños con el cliente y luego los muestra al equipo técnico.

Este sistema es muy arriesgado porque puede resultar que el equipo IT te informe entonces de que el diseño no es viable; o que unos componentes no pueden funcionar tal y como están definidos en el diseño, etc. 

Es más conveniente considerar el diseño como una tarea de co-creación junto con los desarrolladores. Si les mostramos unas primeras pantallas, o unos wireframes iniciales, ya podemos empezar a detectar is hay funcionalidades o parte del diseño a modificar o eliminar.

Esta forma de trabajar te permitirá incluso enriquecer y asegurar más el resultado de tu trabajo.
De esta manera evitarás la horrible situación en la que cuando ya está todo diseñado resulta que tienes que dedicar más horas o recursos humanos al proyecto porque ciertas funcionalidades del proyecto requieren complicaciones técnicas innecesarias; o que funcionarían diferente de como lo habías pensado.

El peor escenario se da cuando incluso el cliente ya ha aprobado los diseños que luego IT no puede implementar. Para el cliente es frustrante tener que dedicar el doble de tiempo en la revisión del proyecto. Y encima se lleva una imagen muy pobre del equipo en conjunto (diseño e IT).

2. Anotaciones para las interacciones

Cuando diseñas en Sketch o Figma, por ejemplo, una app o un web, visualizas todo lo máximo que puedes. Sin embargo, algunos aspectos quedan en tu cabeza pero no se plasman en el diseño.

Estoy hablando de interacciones o animaciones como por ejemplo la animación que debe usarse para que aparezca el contenido; cuándo debe mostrarse un spinner; cuántos resultados deben mostrarse en la búsqueda; etc.

No cometas el error de asumir que son obvias y que por tanto el desarrollador va a tener lo mismo en mente que tú.

La solución es sencilla: utiliza notas en tus diseños para indicar las interacciones e interacciones que esperas.

En Figma puedes utilizar uno de estos plugins para hacerlo:

  • Project Notes: Para agregar títulos, notas al pie y notas adhesivas a los artboards en Figma. 
  • Sticky notes: Para crear notas adhesivas (como post-its) en los wireframes, mockups y diseños que hagas con Figma. 
  • Notepad: plugin en Figma para crear un lugar donde poner las notas en los archivos. 

Yo aún estoy probándolos, así que no puedo recomendar ninguno todavía. Sin embargo sí que quiero compartir que por ahora Project notes me ha ido muy bien.

Si aún no utilizas este recurso, verás cuando lo hagas que añadir estas notas en los diseños es crucial tanto para poder indicar bien las interacciones o especificaciones que no puedas reflejar en el diseño, como para indicar cambios de última hora por pequeños que sean.

Por cierto, en Figma existen los comentarios para poder dejar notas también asociadas a los elementos de los artboards. Sin embargo, para mí es más cómodo usar project notes o un plugin de notas para especificaciones de diseño, y los comentarios para recoger feedback y discutir sobre aspectos del diseño.

3. Utiliza prototipos para transmitir ideas

Si no eres muy amigo de las notas, puedes llegar a reemplazarlas haciendo un prototipo.

Con Figma es bastante sencillo. El equipo de IT, así como el cliente y posibles stakeholders, podrán ver de forma más real y clara qué estás proponiendo.

Los prototipos son una forma de asegurar que todos hablamos de los mismo, o como dicen los ingleses “we are on the same page”. La siguiente ilustración (no es mía pero tampoco he conseguido saber de quién es 🙁 ) , aunque no me parece de un gran estilo gráfico,  resulta muy clara sobre el problema típico de que cada uno entiende las cosas como las entiende:

Al principio las tres personas hablan sobre un tema y llegan a la conclusión de que están todas de acuerdo. Sin embargo, no es así. Una está pensando en un cuadrado azul, la otra en un círculo rojo y la tercera en un triángulo amarillo. Cuando por fin lo plasman en una pizarra se quedan en shock al darse cuenta de que cada uno lo ha entendido completamente distinto. Entonces empiezan a trabajarlo en la pizarra hasta que llegan a una forma común. En la siguiente viñeta se ve a las 3 mismas personas que ahora sí que tienen la misma imagen en mente.

Con los diseños se llega en muchos aspectos a que todos hablemos de lo mismo. Sin embargo, en algunos puntos como por ejemplo las interacciones nos quedamos en la primera viñeta. Explicamos como debe ser pero un programador entiende un cuadrado azul, otro un triángulo amarillo, y tú mientras tanto sigues con el círculo rojo en la cabeza.

Si no puedes hacer un prototipo por el motivo que sea, asegúrate con notas todo lo que puedas, tal y como veíamos en el punto 2.

¿Y las otras 5  claves?

Vayamos poco a poco, y buena letra (como se suele decir). Hoy te he presentado las 3 primeras claves para mejorar tu comunicación y coordinación con los desarrolladores. Puedes ponerlas ya en práctica y adaptarlas a tu sistema como mejor te convenga. En el siguiente episodio te presentaré las otras 5. Te doy mi palabra 😉

Conclusiones

En mi experiencia profesional he trabajado tanto de desarrolladora como de diseñadora, y aún sigo intercalando a menudo los dos roles. Esto me ha llevado a trabajar en los dos equipos (IT y diseño). A veces ha sido incluso sorprenderme cómo ante un mismo problema, el enfoque y la manera de solucionarlo era tan diferente dependiendo de si estaba en el equipo de desarrollo o el de diseño.

Entender a qué se puede deber esta diferencia en la mentalidad y cómo trabaja el otro, te ayuda a entenderle mucho mejor. El entendimiento es clave para la coordinación en los proyectos, y para detectar las fortalezas y debilidades del otro y poder trabajar de forma más efectiva y productiva.

Espero que las primeras 3 claves que hemos visto en el episodio de hoy para trabajar con desarrolladores te sean muy útiles. 

Si te ha gustado el episodio de hoy, te animo a compartirlo en tus redes sociales para extender este mensaje por la comunidad UX/UI, y así ayudar a más diseñadores como tú.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Descubre cómo aumentar tu productividad y eficiencia en tu negocio con Lecciones UI para creativos

Breves podcast semanales en las que comparto contigo cómo mejorar los procesos tanto de gestión como de producción UI.

Lecciones UI
para Creativos

Subscríbete para descargar los contenidos. Si ya estás suscrito, puedes acceder a ellos a través del enlace que recibiste en el email de bienvenida.

Términos y condiciones

Puedes cambiar de opinión en cualquier momento haciendo clic en el enlace "dar de baja" que hay en el pie de página de cualquier correo electrónico que recibas de nuestra parte, o poniéndote en contacto conmigo en info@maria-pascual.es Trataré tu información con sumo respeto y cuidado. Para obtener más información acerca de nuestras prácticas de privacidad, visita nuestro sitio web.