Alineación de los perfiles UX+FE en un equipo de producto
Tags: uxdesign, designsprint, teamwork, peakteam
Published: 2021-10-27 19:11:41

Si alguna vez como diseñador de experiencia de usuario (UX) has pensado algo como: **y esos dos píxeles.. ¿cómo han acabado ahí, no ha visto que está desalineado?** o si eres desarrollador _front-end_ (FE) algo como: **¿de verdad no voy a poder reutilizar un componente por dos píxeles de _padding_?** creemos que te va a interesar esto que vamos a contarte.

Y.. ¡sí! decimos “vamos”, porque tanto el diseño como el desarrollo de la solución, pasa en primer lugar muy de cerca para dos perfiles: UX y FE .  Vamos a contarte juntos **de primera mano cómo trabajar en colaboración sin que ninguna de las partes acabe frustrada**. Ambos perfiles deben convertirse en una alianza clave para ahorrar tiempo, anticipar dificultades, aumentar el compromiso y trabajar de una forma ágil y dinámica. En definitiva, **un trabajo paralelo y colaborativo.** 

En este artículo encontrarás **herramientas y dinámicas** a tener en cuenta para conseguir la alineación y comunicación adecuada en cada fase del proyecto:


* **Discovery track (fase de exploración):** El análisis con usuarios del problema/oportunidad tendrá al perfil de FE como partícipe. Será así como podrá vincular con casos reales el porqué de las propuestas  y así proponer iniciativas desde una perspectiva técnica en la definición de la solución.  

* **Delivery track (fase de producción):** El desarrollo de la solución tendrá como partícipe al perfil de UX. Será así como entenderá el porqué de las limitaciones y así aportar la flexibilidad en la iteración de las mismas para poder ajustar tiempos en la entrega de valor al usuario. 



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/79dzs3gy4vvtzkshcq6q.png) 
 
 


##Primera barrera a eliminar

Un **error común** en equipos de producto es pensar que el objetivo del rol de UX es realizar el mejor entregable para desarrollo y que el objetivo del rol de desarrollo es recogerlo y llevar a la realidad una copia idéntica de ese pixel-perfect, como una carrera de relevos y por tanto, un trabajo independiente, en cascada.  

Esta regla no escrita es la primera barrera que debemos eliminar de nuestras mentes para poder proseguir con la implantación de la metodología que venimos a contarte: **un trabajo en equipo de principio a fin.**

El **proceso de diseño no puede ser un misterio para el desarrollador** hasta que éste recibe el entregable, al igual que **el proceso de desarrollo tampoco puede estar en la sombra para el diseñador** hasta que éste lo ve en producción. **Es necesario trabajar la visibilidad en ambos sentidos.**


A través de este método de trabajo que vamos a explicarte, **FE se convertirá en un evangelizador de problemas del usuario** tras empatizar con ellos gracias a participar en el discovery, mientras que **UX se transformará en un predicador de las limitaciones y estándares a seguir por parte de desarrollo** gracias a entender las bases del desarrollo. 

El objetivo es **conseguir una atmósfera de tolerancia recíproca**. 



##Contexto del problema: Investigación de campo

Una vez se planifiquen acciones de discovery, como por ejemplo unas entrevistas o un test de usabilidad, éstas no tendrán por qué estar limitadas a perfiles directamente relacionados con producto o negocio (Product Owner, UX Designer o Data), **es importante que se extienda la invitación y se involucre a los perfiles de desarrollo**, ya que no suelen sentirse partícipes de la toma de decisiones de producto pero su aportación puede ser clave para llegar a una mejor solución, ¿por qué no darles la oportunidad de formar parte en el contacto directo con el usuario?

De esta forma **aumentaremos el compromiso por parte del equipo en alcanzar la solución planteada y disminuiremos los tiempos de alineamiento**.  Los desarrolladores empatizarán con los pains del usuario y entenderán el objetivo que se persigue desde producto y UX de primera mano.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5zk57uzprb3kjzgus4i6.png)
 


**Tip:** Al terminar las investigaciones durante la fase de exploración, repasad en grupo los insights obtenidos, ya que por naturaleza de los roles unos enriquecerán a otros y juntos se complementarán para obtener los requisitos de diseño a cumplir para esa solución.  Una herramienta útil para clasificar estos insights y ponerlos en común es el mapearlos en: must, nice-to-have y delighter. Esto ayudará a entender mejor la prioridad de cada uno en el momento de definir una primera versión o MVP (Minimum Viable Product).




##Wireframing: Reutilización de componentes

Las conclusiones de la fase de exploración convergen en requisitos de diseño a cumplir y reflejar en la solución final. Durante la anterior recopilación de estos criterios a cumplir, gracias a haber visto los problemas de usuario en primera persona, **inconscientemente cada perfil ha imaginado ya posibles soluciones desde su perspectiva.**

En este punto de partida es importante **alinear expectativas** compartiendo todas esas posibles soluciones a través de un workshop de co-creación. Será una sesión que ayudará al equipo a **converger en una propuesta** donde desarrollo será partícipe desde el momento inicial. 

En Adevinta, tanto UX como FE, trabajamos con una librería de componentes open source en React: [SUI Components](https://sui-components.vercel.app/). Esta librería, al tener recursos fáciles de usar e iterar, permite desarrollar proyectos haciendo uso de una gran variedad de componentes ya analizados, definidos y desarrollados.

Una de las conversaciones más importantes que tiene que tener lugar en este punto entre UX y FE es aquella en la que se ponga sobre la mesa los componentes que se van a reutilizar, iterar o crear para llevar a cabo esa propuesta. **El desarrollador deberá aportar las limitaciones y el diseñador deberá valorar las afectaciones en la experiencia. El objetivo es encontrar un punto de equilibrio** entre la reutilización de componentes y la experiencia de usuario con la intención de que ésta última no salga perjudicada. 

Reutilizar y estandarizar no solamente **ayuda al usuario a tener una mejor experiencia y a reducir su curva de aprendizaje** desde el punto de vista de diseño, sino que desde desarrollo **se consigue que el servicio sea más escalable y fácil de mantener**. Los componentes nos permiten un **desarrollo ágil, ordenado y con una arquitectura mantenible** gracias a que trabajan de manera independiente, siendo muy sencillo utilizarlos. 


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/84jioqnfwwuunajmb3kr.png)
 


**Tip:** En esta sesión de co-creación se deben llegar a cumplir los requisitos de diseño acordados con producto y a marcar qué componentes formarán el wireframe inicial. Utilizad desde un papel A3 a una pizarra física o digital (Miro, Figjam, Freehand..) para este ejercicio, al más puro estilo draft. 




##Adiós a los deadlines en el diseño

El entregable que recoge las especificaciones de diseño para FE, **el _pixel-perfect_ no debe ser el testigo de una carrera de relevos que va pasando de un rol a otro una vez terminado**. Tampoco lo serán las primeras maquetaciones por parte de desarrollo. 

**FE tiene que poder contar con la flexibilidad de UX para poder levantar la mano en el momento que percibe que el coste incrementa**. Pivotad e iterad colaborativamente para adaptar la solución en conjunto y llegar así a un consenso. 

Es importante trabajar en **un ambiente de transparencia**, donde no haya miedo a compartir ideas o problemas. **Las propuestas de diseño _WIP_ son clave para obtener _feedback_** por parte de FE y **adelantarnos a posibles limitaciones de componentes o funcionalidades (incluso es importante obtenerlo antes de las _design reviews_ para poder aportar datos técnicos si aparecen dudas).  Al igual que también es clave adelantarnos y ver la maquetación en un entorno de pruebas para llegar al momento de QA con soluciones más maduras**, ahorrando así tiempo en las correcciones o _bugs_. 


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5mku43c9y9rx7afp7o35.png)
 

**Tip:** Pequeñas alineaciones entre UX y FE durante el proceso pueden conseguir dar luz verde a ideas que desde UX se valoraban de alto coste y por tanto iban a ser descartadas. Anticiparse será otro beneficio, prever posibles obstáculos ahorrará tiempos de desarrollo y reducirá riesgos en la entrega. 



##Testea, testea y testea. 

Tenemos el desarrollo en el entorno de preproducción listo para ser visto por el resto del equipo y a un solo paso para subir a producción. Testea, testea y testea. **El trabajo para crear la solución ha sido colaborativo** desde un principio. Ambos perfiles saben en qué punto está la propuesta creada. No hay sorpresas ni expectativas distintas, por lo que **el feedback podrá venir detallado y sin miedo a ser un juicio al trabajo realizado.** 

Resolver en preproducción todos los escenarios será en gran parte una tarea que completa el trabajo de UX, que tras diseñarlo es quien conoce la propuesta a la _pixel-perfección_. Esta revisión dará lugar a un conjunto de capturas de las diferencias con el diseño y a un listado de ajustes. Es el momento de crear un documento visual que recoja de forma explícita ese resultado del QA.  Para FE será un acelerador en el momento de atacar el problema. Un paso más allá será resaltar en el documento aquellos que deberían ser un must a resolver previo a la salida a producción. 


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ka8vun04gostii0pz7ac.png) 



**Tip:** La herramienta que recomendamos en este post para crear este entregable es aquella en la que el diseñador sea más ágil y pueda llevarla de forma paralela durante su testeo. Por ejemplo, una herramienta de diseño como Figma o Sketch, donde ya se contemplan los diseños finales. En nuestros archivos por flujo de usuario añadimos una página donde recopilamos todos los casos encontrados, destacamos los errores y comparamos las siete diferencias con el diseño final. 

Ahora que ya conoces nuestro _way-of-working_ basado en la transparencia, en compartir y trabajar de la mano, **¿crees que encajaría en tu equipo?** Si es así, ¡ya sabes cómo ponerte en marcha!