Es complicado imaginarse el rol del diseñador sin pensar en otros perfiles que intervienen en el proceso de creación de un producto o servicio. Producto, desarrollo, marketing o negocio son solo algunos de ellos.
Todos somos parte de un equipo que persigue el mismo objetivo final, y sin embargo a menudo no existe esa sensación de unidad ni de cohesión. Muchas veces ni siquiera tenemos la sensación de ser un equipo.
Es normal que a la hora de tomar decisiones todos “barramos para casa”. Cada uno quiere lo mejor (y a veces lo más fácil) desde su punto de vista. Por eso es importante que representantes de todos los perfiles que componen el equipo se sienten a hablar y a tomar decisiones en conjunto, teniendo siempre en cuenta los problemas y argumentos de cada uno. Hasta aquí la teoría que todos nos sabemos. El principal problema suele estar a la hora de llevarla a la práctica.
A lo largo de mi carrera profesional he desempeñado dos roles dentro del equipo: desarrolladora y diseñadora. A día de hoy me dedico al diseño, llevo más de dos años sin programar (profesionalmente), pero fueron casi cinco años los que pasé entre desarrollo web y programación móvil (iOS y Android).
Últimamente, una de mis “cruzadas” personales es que la gente con la que trabajo no haga comentarios como el que compartí en twitter hace unas semanas (con mi habitual estilo cariñoso):
O este que compartió hace poco Cris Busquets:
No hace falta profundizar demasiado en este tipo de comentarios para darse cuenta de que detrás de ellos hay, sobre todo, un gran desconocimiento sobre el trabajo y los procesos ajenos.
Saber vs “saber”
Existe un eterno debate en twitter sobre si los diseñadores deberíamos saber programar (y viceversa). Cada vez que me preguntan por mi opinión, mi respuesta siempre es la misma: depende de lo que entiendas por “saber programar” (o “saber diseñar”).
Hay quien dice que “saber programar” implica tener nociones básicas de maquetación y algo de Javascript. Es como decir que “saber diseñar” es crear y mover elementos en Sketch y hacer un prototipo navegable con inVision.
Obviamente, no estoy de acuerdo con ninguna de las dos afirmaciones. Reducir cualquiera de las dos disciplinas de esa forma es absurdo. A partir de esto podríamos abrir el melón de otro debate también muy habitual y que para mí está bastante relacionado: el de las formaciones cortas cada vez más en auge en nuestro sector. Nunca he estado en contra de los llamados bootcamps, pero hay quien pretende equiparar cursos de tres meses con ingenierías, diciendo que en la práctica ambas formaciones te preparan igual. Os podéis imaginar cual es mi opinión, pero tampoco es el objetivo de este artículo 😉
Tanto en diseño como en desarrollo sabemos que detrás de cualquier resultado hay un proceso, un conjunto de decisiones y, a menudo, un buen puñado de limitaciones.
Pretender aprender a hacer el trabajo de cada una de las personas que componen el equipo es poco menos que imposible. Detrás de un buen profesional hay muchas horas de formación y otras tantas de experiencia para asentar y ampliar conocimientos. Además, en nuestras profesiones no vale con el conocimiento base, si no que cada poco tiempo salen nuevas herramientas, métodos, frameworks o lenguajes de programación que requieren de buena parte de nuestro tiempo para no quedarnos atrás. Lejos de ser una desventaja, creo que es una de las cosas que más me gustan de lo que hago; seguir formándome y aprendiendo para ser mejor cada día.
Por lo tanto, entendiendo saber programar o diseñar como dedicarte a ello, conociendo al detalle los procesos, herramientas — y teniendo unos cuantos proyectos a las espaldas que te hayan dado la experiencia necesaria como para tomar decisiones bien argumentadas — , mi respuesta es que no, no necesitas saber programar para ser un buen diseñador ni necesitas saber diseñar para ser un buen programador. Ahora bien, tienes que ser capaz de encontrar un lenguaje común para comunicarte con ese compañero que no hace lo mismo que tú.
Comunicación, hay que decirlo más
Aunque parezca mentira, comunicarse con el resto del equipo es una de las cosas más complicadas de hacer, pero está directamente relacionada con gran parte del éxito o el fracaso del proyecto y del equipo.
Encontrar un lenguaje común significa aprender lo suficiente del trabajo del resto como para que seamos capaces de sentarnos a hablar, que cada uno exponga su punto de vista y no tengamos la sensación de que nos hablan en chino. Es algo que lleva tiempo y para lo que necesitaremos preguntar más de una vez. No tengamos miedo a preguntar. Mostrar nuestro interés hacia el trabajo de los demás e intentar entender de qué forma impactan nuestras decisiones sobre él, nos ayudará a llevarnos mejor con el resto del equipo y a que la comunicación sea mucho más fluida.
¿Qué podemos hacer desde cada lado para intentar acercarnos y empatizar con nuestros compañeros? ¿En qué momentos es clave que se produzca esa comunicación?
Desde el lado del diseño hay muchas cosas que podemos hacer para iniciar ese acercamiento y trabajo en equipo. Estas son algunas de ellas:
- Conocer las implicaciones técnicas de lo que estamos diseñando. Es posible que lo que para nosotros sea un cambio pequeño suponga más de un quebradero de cabeza para desarrollo. O que ese dato que queremos mostrar no haya forma de obtenerlo con las APIs que tenemos. Quizá incluso una funcionalidad ni siquiera sea viable técnicamente, o suponga un esfuerzo que en ese momento el equipo no pueda asumir. Si esperamos hasta tener los diseños definitivos para conocer los problemas quizá sea tarde para volver a evaluar posibles soluciones y haya que resolverlos mal y sin tiempo, creando inconsistencias y/o deuda de diseño.
- Saber si hay una deadline para el equipo de desarrollo. Aunque no debería ser así, muchas veces el equipo de desarrollo tiene fijado un plazo de ejecución antes de que el diseño esté cerrado. Es imprescindible saberlo para adaptar nuestro diseño en función de las posibilidades. Obviamente es una limitación para nosotros como diseñadores, pero no en todos los proyectos tendremos carta blanca para hacer las cosas como queramos (especialmente en consultoría). Creo que entender esto y adaptarnos a las circunstancias también dicen mucho de la seniority de cualquier diseñador.
- No actuar “a espaldas” del equipo de desarrollo. Enseñar al cliente algo que no ha visto el equipo puede ser muy peligroso si hacemos que se enamore de ello y luego no encaja técnicamente o en los plazos pactados. Contrastar diseños con el equipo antes de enseñarlos nos ayudará también a gestionar las expectativas del cliente. No tiremos piedras contra nuestro propio tejado por no preguntar.
- No siempre “seguro que hay una librería que hace esto”. Dile esto a un desarrollador al que quieras caerle mal. Así de fácil.
- Hacer partícipe a todo el equipo del proceso. En una clase que di hace unas semanas surgió la pregunta “¿cómo convencemos a los desarrolladores para que hagan X?”. Creo que la clave no está en convencer, sino en hacer partícipes del proceso y del razonamiento que hemos seguido. Así será más fácil que entiendan porqué la decisión que les planteamos es la mejor desde el punto de vista del diseño centrado en el usuario. Además de aprender de la parte técnica, es muy interesante que el resto del equipo entienda como trabajamos y cómo tomamos las decisiones.
Sentarnos a revisar las propuestas de diseño con el equipo de desarrollo es vital para asegurarnos de que lo que estamos diseñando es viable. Ser conscientes de los plazos y trabajar conjuntamente nos puede ayudar a tener una relación mucho mejor que repercute directamente en el éxito del proyecto.
Por supuesto, en una relación las dos partes tienen que poner su granito de arena. Algunos consejos para el equipo de desarrollo son:
- No tomar decisiones de diseño unilateralmente. Puede pasar que, incluso habiendo aprobado técnicamente los diseños, a la hora de implementar surjan problemas que impidan que se lleve a cabo el desarrollo de una funcionalidad o elemento. En ese caso es muy importante hablar con el equipo de diseño, explicarle cuales son esos problemas e incluso darle alguna alternativa que creamos que pueda encajar y que sea técnicamente viable. Con toda esa información, debe ser el equipo de diseño (o producto) quién tome la decisión final, de manera que todo el equipo esté cómodo con ella. Saltarse este diálogo puede ser percibido por el equipo de diseño como una falta de respeto a su trabajo.
- No limitarse al “esto no se puede hacer”. Para que la comunicación funcione y el equipo de diseño entienda las limitaciones con las que trabaja también es importante que se las expliquemos. A ser posible en un idioma que entiendan. Hay diseñadores con más conocimientos técnicos que otros, pero si invertimos el tiempo necesario en explicar las cosas al equipo de diseño más allá del “esto no se puede” también estaremos ayudando a que empaticen con nosotros y entiendan las implicaciones técnicas de lo que están diseñando.
- Dar feedback sobre los entregables de diseño y preguntar las dudas. A veces los diseñadores cometemos el error de pensar que todo el equipo tiene el mismo grado de conocimiento de proyecto que nosotros, y nos dejamos cosas por explicar. A veces pensamos que con un Zeplin o un prototipo se entiende de sobra lo que hay que desarrollar. A veces nos dejamos casos de error, casos cero, estados vacíos… Es muy importante que como desarrolladores demos feedback sobre lo que recibimos y expliquemos lo que necesitamos para poder hacer bien nuestro trabajo. El equipo de diseño también lo agradecerá y le ayudará a mejorar.
- No, mover ese texto no es tan fácil. Esto sería el equivalente al “seguro que eso hay una librería que lo hace”. A veces hacer un cambio en diseño no es tan fácil como parece, especialmente si un componente se usa en varios sitios o casos. Diseñar no consiste en mover elementos para ver cómo quedan mejor, como muy bien explica Cris:
Comunicar al equipo de diseño lo que necesitamos para poder desarrollar el proyecto, hacerles partícipes de los plazos que manejamos y las limitaciones técnicas que se pueden encontrar a la hora de conceptualizar, ayudará a que el diseño sea mucho más realista, tanto en tiempo como en alcance.
Egoístamente, nos interesa llevarnos bien
No hay mejor aliado para el equipo de diseño que el equipo de desarrollo. Y viceversa. Nos interesa llevarnos bien. Es mucho más fácil trabajar y hacer que el proyecto salga adelante si todos remamos en la misma dirección.
Desde el punto de vista del diseño es mucho más fácil que el equipo de desarrollo esté dispuesto a asumir cierto esfuerzo extra en un momento puntual si siempre les tenemos en cuenta a la hora de tomar nuestras decisiones. Si a veces nosotros sacrificamos cosas que no sean 100% necesarias o que supongan un verdadero quebradero de cabeza para ellos, es mucho más probable que ante algo verdaderamente importante el equipo de desarrollo ceda. Lo que en cualquier relación es “hoy por ti, mañana por mí”.
De igual manera, para el equipo de desarrollo es genial contar con un equipo de diseño que le tiene en cuenta a la hora construir el proyecto. Como desarrollador, es muy frustrante que te lleguen decisiones tomadas sobre las que tu tienes mucho que decir y que nadie te haya preguntado. A nadie le gusta sentirse el último mono del equipo, y más cuando esas decisiones pueden suponer que salgas o no a tu hora. Reclama tu turno de palabra a la hora de tomar decisiones e invierte tiempo en “evangelizar técnicamente” al equipo de diseño.
Ni los buenos son tan buenos, ni los malos son tan malos
Como dice el refrán, a veces es muy fácil ver la paja en el ojo ajeno y no ver la viga en el propio. Es muy fácil ver lo que hace mal el resto del equipo pero no siempre nos paramos a pensar qué podemos hacer nosotros para intentar mejorar los procesos o flujos de trabajo.
A veces ese diseñador puntilloso que te corrige hasta el último píxel se ha encontrado con desarrolladores descuidados que no han puesto suficiente atención al diseño y ha habido que perseguirles con mil cambios.
A veces ese desarrollador que te dice a todo que no, solo ha trabajado con diseñadores que nunca le han preguntado si lo que estaban diseñando se podía hacer hasta que ha sido demasiado tarde.
A lo largo de nuestra carrera, todos nos hemos encontrado con profesionales maravillosos de los que hemos aprendido y con los que hemos disfrutado trabajando. Pero también nos hemos encontrado con gente con la que ha sido un infierno trabajar; bien por carácter o por mediocridad y que ha provocado que (a veces inconscientemente) desconfiemos del trabajo ajeno.
Y por supuesto, como dice la gran Irene M Morgado en sus charlas, siempre hay un gilipollas. Gente con la que por mucho esfuerzo que pongamos es muy complicado trabajar, que no pone de su parte y que no quiere llevarse bien con nadie. Intentemos reducir las interacciones con esa persona al mínimo y que no estropee la dinámica con resto del equipo. Por suerte, hay más no gilipollas que gilipollas.
Que no sea por no haberlo intentado 🙂
¡Muchas gracias por leerme! ?
Si quieres podemos seguir con la conversación en Twitter o por mail. ¡Me gustaría mucho conocer tu experiencia!
Lucía Gómez 