# Diseñadores vs Desarrolladores: Que lo que el Producto une no lo separe Nada 🦄

Hablaremos de los topicazos mentales a la hora de hablar de diseñadores y desarrolladores, cuáles son las diferencias más comunes -ejemplos concretos de peleas de alcoba- y cómo solucionarlas. Hablaremos de ego, de disciplina, de procesos de trabajo y, sobre todo, de producto: ese hijo de ambos que nos une y a la vez nos separa.

## 1) ¿Qué es UX, UI y FE?
- Los diseñadores: esos bichos raros
- Los programadores: esos bichos raros
## 2) Todos somos bisagras
- Simplificar la visión de lo que hacemos: Sistema de información. Datos que llevo a la pantalla o de la pantalla a la base de datos

## 3) Problemas de Alcoba

### Unleashed Creativity :art:

**PROBLEMA:**

El diseñador no conoce la API ni la DDBB. Diseña pantallas con datos que la API no provee.

**SOLUCIONES:**

- Si la app está naciendo, el proceso de diseño de DDBB tiene que estar unido al diseño de interfaces (sobre todo cuando hay mucha visualización de datos, gráficos, etc)
- El diseñador tiene que saber qué tiene la DDBB y qué provee la API cuando diseña interfaces. La documentación es fundamental para este fin. Tiene que haber información actualizada. No está mal que el diseñador pueda ver las tripas del producto con autonomía.
- El super Front End Developer.

:::danger
Este problema se resuelve con **DISCIPLINA**
:::

### A Matter of Style :japanese_castle:

https://css-tricks.com/the-benefits-of-structuring-css-around-appearance-and-layout/

**PROBLEMA:**

Estilos globales vs. estilos en componentes. A los desarrolladores puros, pegaditos del front tienden a hacer dos cosas: pelearse por React o Vue y pensar en componentes (todo en su cajita, a lo Marie Kondo). Así, los estilos van en el componente sí o sí, ¿verdad?.

Pues, os sorprendería la cantidad de diseñadores/maquetadores que prefieren estilos globales.

Pero esos diseñadores viejuners, arcaicos con sus mega stylesheets no siempre están equivocados. Cuando creamos estilos de layout en componentes, luego padecemos enormemente sobreescribiendo a hijos que heredan de padres, abuelos y tatarabuelos. Cuando creamos estilos que tienen que ver con la apariencia, soy más proclive a escribirlos en el componente. Generalizar es de cobardes, pero ahí va un tip.

**SOLUCIONES:**
- Alinear filosofías
- Establecer jerarquías de información y, por ende, de componentes(UX)
- Dar responsabilidades específicas a cada elemento de la app, intentando no olvidarse de 'información hacia el usuario e información desde el usuario'

:::success
Este problema se resuelve _killing the **EGO**_
:::

### Flaw of Perfection 🔫

**PROBLEMA:**

Los diseñadores se curran un montón diseños para que queden teóricamente perfectos (el TOC del pixel-perfect). Luego viene un desarrollador y le cambia el border-radius, el tamaño a los componentes, los márgenes, etc.

Lo que el diseñador no sabe es que puso un botón de 102 px de ancho (¿qué medida loca es esa?) y que el margen no queda bien en soportes muy angostos. Y el desarrollador también trata de subsistir y llegar a la demo vivo.

**SOLUCIONES:**

- Entender cómo se traduce en realidad el diseño en producto
- Recordar que todo lo que se diseña son prototipos
- El buen programador debe intentar respetar el diseño (sí, pegarse con el CSS hasta más no poder)
- Mobile-first & Desktop-first. Depende del proyecto. Pero diseñar en los soportes en los que va a existir el producto (los soportes más pequeños deben venir primero porque tenemos menos espacio para poner cosas)

:::warning
Este problema se resuelve con **RESPETO**
:::

### Gimme your money now! :money_with_wings:

**PROBLEMA:**

La transferencia de archivos, diseños, vistas, imágenes, iconografía es siempre tema de polémica (es el _quién lava los platos_ del producto).

**SOLUCIONES:**

- Diseño y desarrollo iterativo
- Mantener diseños actualizados
- Nunca enviar los diseños en PDF
- Zeplin + SketchApp / Adobe + InVision
- Figma :heart:

:::info
Este problema se solucioa con **COMUNICACION**
:::

OUTLINE:

Cómo llegué al diseño. Vengo del cable y blah blah y Ironhack UX Design. Con qué se come eso?

Emociones:
- Surprise
- Joy
- Fear - We might not qualify for the work
- Disgust - Mistakes
- Anger
- Sadness

(Inside Out)

We are passionate about the work. And if you're not, find something to be passionate about. So in a wau, it is personal. Fall inlove with your project includes falling in love with your colleagues work.
'Ama lo que haces no hagas lo que amas'. Yo no lo entendía, pero si te enfocas en aprender del trabajo del otro, finalmente te ayuda a ti. Somos bisagras
Involucrate no solo con el código o el diseño, sino con el negocio, con los diferentes stakeholders. No tienes que tener toda la idea de todo, pero aumenta el enfoque lo máximo que puedas

Las mejores soluciones son de sinergias totalmente random.
Una hora de concepto. No más de eso
Plan features together
Agrupar features y momentos de producción/diseño