🤘🏻 ¿Buscas libros de diseño UI/UX, tipografía, research...? Haz clic aquí para ver mis favoritos :)

Cómo trabajar con desarrolladores

Escrito por Cris Busquets. Publicado en Diseño UI

Cómo trabajar con desarrolladores

Si eres diseñador/a en cualquier empresa que tenga una vertiente más o menos tecnológica, seguro que en algún momento has tenido que hablar con el equipo de desarrollo…

… y me juego lo que quieras que más de una vez ha resultado ser una conversación más o menos tensa en la que todo el mundo tenía razón y nadie lograba crear un consenso.

Estas situaciones se dan cuando se entiende “diseño” y “desarrollo” como dos procesos distintos dentro de la creación de un producto.

Considerar que primero va uno (diseño, incluyendo UX) y después desarrollo solo puede llevar a resultados mediocres.

¿Por qué? Pues sencillamente porque los desarrolladores tienen que lidiar con el código heredado (legacy code), una infraestructura y unos tiempos que a menudo dificultan implementar correctamente la propuesta de diseño.

A esto hay que añadirle que no todos los desarrolladores tienen conocimientos de diseño UI y lo que para un diseñador es obvio que está mal implementado, un desarrollador puede no verlo.

Aunque obviamente no es solo culpa de los desarrolladores: desde diseño a menudo se envían propuestas a medias o que no tienen para nada en cuenta el tiempo de desarrollo, las limitaciones de la tecnología o los recursos actuales del equipo.

6 buenas prácticas entre diseño y desarrollo

Como diseñadores/as está en nuestra mano solucionar una parte del problema, o por lo menos tratar de que no haya problemas tan a menudo.

A lo largo de los años he llegado a estas “buenas prácticas” que, aunque no siempre puedo aplicarlas, me han ayudado a mejorar la relación entre diseño y desarrollo.

1. Enseña todo el diseño

Y cuando digo todo, es todo.

Al igual que otros implicados en el producto, la persona que se encarga de su desarrollo debe hacerse un “mapa mental” de cómo está estructurado todo: qué sucede cuando el usuario hace clic en un botón concreto, cómo se navega hasta determinada página y cómo se vuelve atrás…

¿Cómo solucionarlo?
En este caso es fácil: basta con hacer un buen prototipo interactivo y, si es necesario, adjuntar un user journey en el que se aprecie el “mapa” de toda la web o aplicación.

2. Diseña TODOS los estados

Reconozco que este punto a veces se me olvida. Cuando diseñamos una aplicación a menudo nos quedamos con el “estado normal” y nos olvidamos de cómo es el hover de los distintos enlaces y botones, qué mostramos cuando el sistema está cargando, qué pasa cuando el usuario hace clic en un input, cómo y dónde se muestran los errores, etc.

No definir este aspecto implica que el equipo de desarrollo va a tener que “inventárselo” para salir del paso. Probablemente tengan que tirar de un framework ya existente o de sus estados predefinidos. Obviamente no será con mala fe, pero son estados que hay que definir por algún lado.

¿Cómo solucionarlo?
Llegados a este punto lo ideal sería preparar bien el UI Kit (o Sistema de diseño, guía de estilo…) en el que se contemplan todas estas opciones.

Estados de botones en UI

Diseño por Paul Hatch.

3. Diseña con datos reales y no uses “Lorem ipsum”

A veces, por las prisas, se envía a desarrollo un diseño que está acabado pero al que le faltan los textos.

Y cuando ya están desarrollando el diseño, aparecen. Esto suele provocar que la propuesta vuelva al equipo de diseño, ya que prácticamente siempre los textos que se tienen que incluir son más largos de lo que el diseño soporta.

Así que hay que volver a diseñar, con la consiguiente pérdida de tiempo que esto supone.

¿Cómo solucionarlo?
En Holaluz estamos consiguiendo mejorar el workflow con el siguiente proceso:

  1. Hacemos lo wireframes, que ya dan una idea aproximada de qué contenido va dónde y qué límite de caracteres tiene.
  2. Se hace un Google Spreadsheet (mejor que un Excel convencional) en el que adjuntamos una captura del wireframe y creamos celdas para cada bloque de texto. El truco aquí es que al lado escribimos el límite de caracteres y los caracteres que ya están ocupando. De este modo, quien redacta los textos ya ve que se ha pasado y los reescribe.
  3. En paralelo, avanzamos con el diseño propiamente dicho. Y cuando los textos están aprobados, los añadimos y hacemos los ajustes necesarios.

Solapando ambos procesos con equipos distintos conseguimos no dilatar demasiado en el tiempo la fase de diseño y, de rebote, que a desarrollo llegue todo como debe ser 🙂

4. Sé consistente con colores, espaciados…

Va ligado al segundo punto. En desarrollo probablemente crearán variables con los colores y espaciados que reutilizarán a lo largo del proyecto para asegurar la consistencia e ir más rápido.

Si en el diseño hay tonos de azul “que son iguales pero no” y espaciados inconsistentes (a veces múltiplos de 8, a veces de 7, etc.) se ralentizará el proceso de desarrollo y el diseño final implementado no tendrá consistencia (ni técnica ni para el usuario).

¿Cómo solucionarlo?
Hace un tiempo escribí un artículo sobre Consistencia en UI. Allí encontrarás todos los trucos y recursos necesarios para mantenerla 🙂

5. Respeto mútuo y sentido de equipo

Personalmente no puedo trabajar en un equipo en el que ambas partes no se respeten. Y no lo digo en el sentido de ir diciendo “eh, yo te respeto”, sino que hay que demostrarlo.

Cada persona que pertenece a un equipo de trabajo tiene unas habilidades y fortalezas distintas. El respeto nace de ser capaces de “soltar” nuestra parte del trabajo y dársela a otro miembro del equipo para que continúe y se lo haga suyo (lo que los ingleses llaman ownership)… sin dudar de si él o ella lo resolverá “bien”.

Cuando hablo de “sentido de equipo” me refiero a que no es un “yo ya he hecho mi parte y me desentiendo”, sino de remar todos. En el fondo estamos en el mismo barco y, llámame loca, es mejor si remamos todos juntos que no si solo rema una parte del barco.

Si sucede, acabaremos dando vueltas en círculos enfadados unos con otros. Y obviamente, el resultado que obtendremos será bastante mediocre.

¿Cómo solucionarlo?
Este punto no fácil. Si estás trabajando con un desarrollador como freelance, debes verlo como un miembro de tu equipo (aunque sea temporal) y comunicarte con él/ella para ir alineados y trabajar junt@s.

Si estás en un equipo, hay que buscar que todo el mundo sea proactivo y fomentar un buen ambiente de trabajo que sea colaborativo y de respeto. Para esto suelen haber figuras como los Agile Coach y Scrum Masters, que ayudan a promover estas dinámicas.

6. Entrega del diseño

O lo que los ingleses llaman design handoff, que no es más que el propio proceso de “dar el diseño a los desarrolladores”.

Entregables de diseño a desarrollo - Zeplin

Actualmente hay muchas herramientas para hacerlo: Zeplin, Avocode, plugins de Sketch como Sketch Mesure, etc.

Aquí se trata de entregar a los desarrolladores todo lo que necesitan para empezar a trabajar:

  • Los assets exportados: iconos en svg, imágenes optimizadas, etc.
  • Tipografías, si no las tienen
  • Prototipo funcional
  • UI Kit, Sistema de diseño o guía de estilo
  • Otras especificaciones técnicas, como media queries, enlaces a ejemplos de otras páginas web (si queremos enseñar algún comportamiento o algún plugin), etc.

Y esto es todo 🙂

Como habrás deducido a estas alturas, se trata de un camino de doble sentido: tanto los diseñadores como los desarrolladores debemos trabajar juntos, entendiendo el proceso como un “todo” en el que debemos trabajar mano a mano como un equipo.

Te dejo con esta charla que dio Marina Aísa en el T3chfest, en la que habla de la relación entre desarrolladores y diseño y de cómo podemos colaborar mejor entre nosotros:

Si no logramos lo máximo que alcanzaremos es malestar en el trabajo y que tanto el equipo como el resultado final se resientan a causa de ello.

Y nadie quiere que su trabajo caiga en saco roto, ¿verdad? 🙂


Deja tu opinión

  1. Suena muy bonito todo, pero en la realidad es que hay ingenieros de software que son unos genios en su trabajo pero simplemente no tienen la habilidad de comunicarse con nadie y mucho menos empatizar y entender motivos y razones de un diseñador o de alguien de marketing, y generalmente estos tienen poder dentro de la empresa. hay que hacer un trabajo de cambio de mentalidad dentro de la empresa con respecto al diseño, en hispanoamerica.

    1. Querido Ernesto,

      No hay ingenieros de software que sean «unos genios en su trabajo pero simplemente no tienen la habilidad de comunicarse con nadie».

      La comunicación es iuna habilidad mprescindible en un ingeniero de software.

      Un ingeniero de software sin habilidad para comunicarse es, como mucho, un mediocre ingeniero de software que se cree un genio, de esos he conocido bastantes.

  2. Tere

    ¿Alguien más trabaja con desarrolladores que solo utilizan Photoshop y no saben ni qué es Sketch? Me estoy encontrando con diferentes proyectos que los planteo en Sketch y cuando llega la hora de pasarlos me los piden en Photoshop y tengo que rehacerlo todo.

    La verdad es que la velocidad con la que se trabaja en Sketch está muy por delante de del tiempo que se necesita para hacer lo mismo en Photoshop. Es un atraso total.

    ¿Alguien más? XD

    1. chimi

      ufff! Creo que eso está un poco a nivel de entregar un logo en Word.

      Con Figma directamente les paso una URL con el proyecto compartido para que puedan ver y toquetear.

Contesta a Laia Cancelar respuesta

Tu email no será publicado. Los campos con asterisco son obligatorios.

Únete a +1,400 diseñador@s y recibe los mejores contenidos para crecer.


No te enviaré spam. Recibirás un correo semanal y descuentos promocionales. Podrás darte de baja cuando quieras.