Mi primer año diseñando

10 cosas que he aprendido durante este último año diseñando en Ironhack y mendesaltaren

Spoiler: no soy ni lead, ni head, ni vp de diseño, ni nada por el estilo. Soy un diseñador junior y estas son las cosas que he aprendido en mi primer año diseñando.

1. No hay proceso por dogma en el diseño de producto

No hay proceso mágico que funcione en todas las situaciones, ni hay un proceso que siempre de con las mejores soluciones.

Existen procesos que pueden funcionar en multitud de situaciones, como GV Design Sprint, Lean UX o Design Thinking, creados por diseñadores con años de experiencia a base de pruebas y errores. Pero incluso estos procesos pueden no funcionarte en determinadas situaciones, o pueden no darte soluciones a los problemas que tienes.

Mi consejo: coge un proceso como referencia y pruébalo. Lee la documentación y realiza los ejercicios como se propone, pero no lo conviertas en principios grabados en piedra, sé flexible. Adáptalo a tu contexto y equipo.

2. No todos los ejercicios funcionan igual en todas las situaciones

O por qué no he aplicado siempre el mismo proceso con los mismos ejercicios.

A todo esto, ¿qué es un proceso? Podemos pensar en un proceso como una serie de pasos, realizados (normalmente) de forma consecutiva, tras los que esperas obtener un resultado.

Por ejemplo: para hacer un plato de pasta, primero tienes que calentar la olla, después tienes que introducir la pasta en la olla, realizar la salsa, etc…. ¿Tiene sentido empezar el plato por el final? No mucho la verdad. No vas a echar la salsa a la pasta cruda y luego cocinarla, ¿no?

¿Estas mismas reglas aplican al Diseño de Producto Digital? ¿El proceso que tengas tiene que ser algo rígido y lineal? ¿Tienes que hacer siempre los mismos ejercicios, de la misma forma y en el mismo orden?

Yo creo que no.

Los ejercicios de diseño, como entrevistas, user journeys o prototipos, son una serie de herramientas que puedes utilizar en determinados momentos. Pero no siempre tienes que utilizar las mismas y en el mismo orden.

En HighResolution, Jared Erondu puso un ejemplo que me hizo verlo claramente, era algo parecido a: “las herramientas de diseño son como el cinturon de Batman, tiene múltiples que sirven para determinadas situaciones. Pero cuando Batman se enfrenta a un problema, ¿siempre utiliza las mismas y en el mismo orden? No, sería de locos.” Para mí, en el diseño pasa lo mismo.

Y, ¿cómo sé que herramienta puedo utilizar en cada caso?

La clave es saber contexto en el que estás (qué información tienes) y cuál es el valor que esperas obtener de un ejercicio (a dónde quieres llegar). En función de estas dos preguntas puedes buscar un ejercicio que te pueda ayude en cada caso. Sé flexible y prueba distintos ejercicios, prueba que es lo que da más o menos valor.

Por ejemplo: ¿quieres validar una posible solución a una problema? Yo realizaría un prototipo y lo validaría con User Testing. ¿Quieres validar si tienes o no un problema? Yo utilizaría cualquier método de User Research.

En Ironhack, tenemos un proceso definido horizontalmente, pero verticalmente no lo tenemos milimétricamente definido. Es decir, tenemos claros los pasos que tiene el proceso general (kickstart, research, ideación, prototipado), pero no hemos definido el ejercicio único que hay que realizar en cada fase. ¿Por qué? Porque no siempre vas a poder realizar el mismo proceso, no siempre te van a funcionar los mismos ejercicios. Por ello tenemos un Playbook (concepto de los chicos de Typeform de Playbook), en el que tenemos ejercicios que nos han funcionado en el pasado. Dependiendo del contexto en el que estemos, utilizamos un ejercicio u otro. Puedes ver el template que utilizamos para rellenar cada “jugada” aquí.

Dicho esto, tengas el proceso que tengas, no caigas en el error de convertirlo en un proceso en cascada. Si tienes que volver a alguna parte del proceso y rehacerla, hazlo. El resultado siempre será mejor que si lo terminas parcialmente para luego volver a tener que revisarlo.

No hagas que se escriba una sola línea de código en algo que sabes de sobra que no va a funcionar.

3. Diseño debe estar alineado con negocio

Esta es una de las cosas que más me ha sorprendido. Los primeros meses pensaba que el diseño consistía en crear marcos para que los usuarios creasen sus propias experiencias y que los diseñadores no teníamos que dejar que negocio u otros departamentos influyeran en eso.

Al final, todo repercute a negocio. Estás diseñando para que negocio pueda “vender” más, si haces un rediseño de un logo, la razón intrínseca es negocio.

No por llamarle usuario va a dejar de ser tu cliente.

Entonces, ¿diseño es únicamente negocio? Yo creo que no. Como diseñador tienes que encontrar el equilibrio entre lo mejor para el usuario y la visión que tiene negocio. Parte de tu trabajo es ayudar a que negocio cumpla sus objetivos. Por eso debes entender a negocio. Entender que es lo que necesitan, su visión y su misión. Sus objetivos a largo, a medio y a corto plazo.

4. No intentes leer todo lo que se publica

El contenido en internet crece exponencialmente.

En mi experiencia leer todo lo que se publica no te va a ayudar, no va a hacer “que estés a la última”, no te va a hacer mejor diseñador.

Evita ser un yonki de las noticias de última hora.

Mucho contenido que se publica hoy en día es la copia de la copia de la copia (incluso este artículo lo es, yo no he inventado nada de lo que digo, la mayoría son cosas que he aprendido de gente con la que he tenido el placer de trabajar o entrevistar en 5minutos).

Mi consejo: no intentes leerlo todo y no intentes aprender todo al mismo tiempo, sino que centres el tiro en algún tema y aprendas sobre ello. Lo más importante es lo que retengas, no cuanto leas.

En mi caso, me di cuenta de que los artículos rápidos me daban una gratificación instantánea, me leía un artículo y sentía (falsamente) que había aprendido mucho, y como me costaba tan poco leer artículos, seguía leyendo y seguía leyendo. Con la falsa premisa de que cuanto más leyera, más sabría y mejor diseñador sería. Pero luego me di cuenta de que de todo lo leía, retenía poquísimo. A partir de ahí busqué una organización que me ayudará a aprender más sobre lo que leía.

5. Aprende de las soluciones que ya están en producción

No copies simplemente lo que alguien ha hecho, intenta ver que hay detrás de esa solución, qué es lo que la ha llevado a estar en producción.

Recuerda también que no sabes hasta que punto algo puede estar funcionando o no. Por el hecho de que sea visualmente atractivo no significa que vaya a funcionar. ¿Puedes conocer todo el contexto de esa decisión? Probablemente no, por lo que tienes que tener especial cuidado al aplicar soluciones a problemas que pueden ser distintos, porque puede que sea contraproductivo.

Un buen ejercicio también es ver como podrías mejorar o empeorar ese diseño. Pregúntate: ¿Qué es lo que deberías cambiar para hacer que el diseño funcionara mejor? ¿Qué es lo que deberías hacer para romperlo y que no funcionara? Eso te ayudará a la hora de revisar tus propios diseños para mejorar lo que no funcione y ver lo que podría funcionar.

André Mendes lo explica perfectamente aquí.

6. Lo que les gusta a los diseñadores no tiene por qué ser lo mejor para tu producto

Porque este mes estén “de moda” los botones con gradientes, no significa que ese estilo de botones vaya a funcionar o convertir mejor que un botón plano.

Mi consejo: ten claro para quien diseñas, tanto la marca como sus usuarios, y si decides aplicar alguna de esas tendencias, que el motivo no sea simplemente porque “se lleva” o “es tendencia”, sino que haya una razón de peso detrás.

No hay nada de malo en que tu producto no siga las tendencias que hay ahora mismo en Dribbble.

Ojo, no todo Dribbble es igual, hay muchas pruebas de concepto que siguen las tendencias que hay para conseguir likes pero también hay muchos equipos que publican actualizaciones y decisiones que toman para avanzar su producto (como Todoist, Uber o Duckduckgo). Yo encuentro más valor en estas segundas.

David de la Iglesia explica para que utliza Dribbble aquí.

7. Producto es un equipo, no una mezcla de departamentos

El desarrollador que se sienta a tu lado es tu mejor amigo. Muchas veces se pinta como una guerra constante, en la que los diseñadores odian a los desarrolladores porque no implementan sus diseños a la perfección y los desarrolladores odian a los diseñadores porque les envían diseños imposibles.

Esto es algo en lo que yo personalmente me he pasado mucho tiempo obstinado.

Pero no es así. Todos en el equipo de producto tenéis el mismo objetivo: el producto final. Tu trabajo no es únicamente el diseño y ya está. Como Diseñador de Producto, tienes que pensar en Producto, tienes que preocuparte por crear el mejor producto posible, no únicamente el mejor diseño posible.

Tu trabajo no termina cuando subes tus diseños a [inserta el nombre de tu herramienta favorita de handoff, i.e Zeplin].

Los desarrolladores no son code monkeys, no son gente a la que le lanzas diseños para que “simplemente” los programen.

Mi consejo: involucralos desde el minuto 0 al proceso, pídeles feedback o posibles ideas para solucionar problemas que encuentres. Trabaja con todo tu equipo para crear un buen producto.

Es tu responsabilidad que lo que has diseñado esté en producción, no eches la culpa a los desarrolladores porque no sepan apreciar tu diseño. El diseño es una etapa más del proceso de producto.

Gracias Lluis, Fer y Marc por grabarme esto a fuego ❤️

8. Busca los casos complicados

Es común (y lo más fácil) diseñar para nombres como Ana López, nombres o textos con pocos caracteres que en muchos casos hacen que el diseño quede estéticamente mejor. Mejor de lo que podría quedar Genoveva González.

Mi consejo: piensa siempre en los casos extremos y detallalos. Busca a propósito los casos complicados. Siempre te va a llevar más tiempo, siempre va a ser más sufrido. Habrá casos en los que tengas que rehacer lo que hayas diseñado, pero siempre va a ser mejor que saber que algo puede salir mal y mirar a otro lado.

Preocúpate por diseñar para todos tus usuarios, no solo para el que te “facilite” el trabajo.

9. Si te dan mal feedback, mayoritariamente es tu culpa

¿Qué considero yo como mal feedback? Todo el feedback que no te va a ayudar a mejorar lo que estás haciendo.

Feedback del tipo:

• “Esto no me gusta, esto es una mierda”
• “Mira lo que hace este competidor, deberíamos hacer lo mismo, si lo hacen ellos…”
• “Esto no va a funcionar, deberíamos hacer esto otro”

Pero este feedback no suele está respaldado en datos, todo suelen ser opiniones.

Una de las razones por la que puedes recibir este feedback suele ser cómo lo pides, es decir, lo que preguntas a la hora de pedirles feedback.

Si preguntas: ¿te gusta?, ¿cómo lo ves? solo vas a encontrar problemas. Intenta evitarlas cuanto puedas.

Si aún así recibes feedback de ese tipo, no te quedes con el primer comentario, pregunta ¿por qué?. Haz que te expliquen porqué piensan eso.

No te quedes en la superficialidad, detrás de todo habrá una suposicion de un problema y de ahí vendrá el comentario.

Si la cosa no mejora, habla con la persona que te lo está dando. Explícale tu proceso, explícale como aplicas el feedback. En resumen, hazle ver que el feedback de ese tipo no os va a ayudar a mejorar el producto. Al final, todos siempre vamos a querer mejorar el producto de nuestra empresa, lo que puede generar tensiones es que cada uno creemos que para mejorarlo tenemos que hacer cosas distintas.

Por último, si hay diseñadores en tu empresa, no solo les preguntes por feedback a ellos. Habla con Tecnología, habla con Negocio, haz un workshop sobre como dar feedback que de verdad te aporte valor y te ayude a llegar a un mejor producto.

Samuel hermoso explica mejor que yo el feedback de gustos aquí.

10. Herramientas =! Diseño

Cuando empecé a diseñar, mi foco estaba únicamente en las herramientas. Pensaba que una vez supiera utilizar las herramientas que utilizaban los diseñadores, sabría diseñar.

Me obsesione con saber todos los shortcuts, tener todos los plugins (aunque luego no utilizará la mayoría de ellos), saber Sketch, Principle, Flinto, Invision y leerme todos los artículos del tipo de “10 cosas que no sabías que podías hacer con Sketch”. Pero nada de eso me enseñó a diseñar.

La mejor manera que he encontrado para aprender a diseñar ha sido diseñando, realizando proyectos. Si puedes trabajar con un equipo en proyectos reales mejor que mejor, pero sino, que eso no sea una excusa para no diseñar. Busca un briefing de internet (cómo este) o algún problema que tengas, o que veas que exista y diseña una posible solución.

Al empezar a diseñar para solucionar un problema te empezarás a dar cuenta de que la herramienta es simplemente un medio, no el fin.

Si quieres saber más sobre la relación entre las herramientas y el diseño, Manel Abella lo explica mejor que yo aquí.

Estos son mis 5 céntimos, son cosas que he aprendido en el último año trabajando en Ironhack y mendesaltaren o entrevistando a gente que sabe infinitamente más que yo en 5minutos.

Repito. No son dogmas, no son leyes, es mi propia experiencia. Espero que te aporten valor 😊

Si crees que estoy equivocado (y puede que tengas razón) mencióname y tengamos una conversación. Estoy encantado de poder conocer otros puntos de vista.

Si quieres conocer más sobre como he llegado hasta aquí, lo he intentado explicar brevemente en este hilo:

Gracias por leer ❤️