Insights
Figma para desarrolladores: cómo preparar ficheros para mejorar la conexión con el equipo de desarrollo
Los prototipos web no solo sirven para comunicarnos con nuestros clientes, sino que además son una importante herramienta de comunicación interna entre equipos, ya que una vez aprobados por los clientes, pasan del diseñador al desarrollador, que es quien se encargará de hacerlos realidad. ¿Así que por qué no optimizar estos prototipos para facilitar al máximo este traspaso entre diseñadores y desarrolladores? No solo conseguirás mejorar los tiempos y la relación entre equipos, sino que además el producto final será más sólido y estará siempre a la altura de las expectativas que el cliente se ha formado durante la fase de diseño.
Como norma general, ponerse en la piel del otro siempre nos ayuda a ser mejores en la vida. También en el caso concreto que nos ocupa en este artículo. Nos referimos a que, a la hora de hacer un diseño web, como diseñadores una parte importante de nuestra labor es ser conscientes de que en algún momento nuestro documento de trabajo (en nuestro caso un documento de Figma) va a abandonar nuestras manos y va a ser la referencia con la que un desarrollador va a tener que construir un site: toda la información tiene que quedar reflejada claramente en él, ya que nada de lo que no esté en el documento (o sea confuso) será implementado. Esto es especialmente importante en empresas en las que los equipos de diseño y desarrollo están físicamente distantes (en plantas separadas, o en edificios distintos, o incluso en países diferentes).
En este sentido ayuda bastante (aunque no es estrictamente necesario) que los diseñadores tengan nociones de desarrollo. Esto nos servirá para saber qué va a necesitar exactamente el desarrollador. Pero además nos permitirá estimar qué se puede y qué no se puede hacer en el diseño y valorar si lo diseñado se va a poder realizar dentro de los plazos y el presupuesto del cliente, dos puntos que hay que tener muy en cuenta y que nunca podemos dejar que se conviertan en un problema para el equipo de desarrollo por una mala previsión. Por eso, aunque en OKB Interactive Studio tenemos distintas áreas de especialización, siempre hemos apostado por perfiles multitarea, que nos permitan aportar una perspectiva completa a todos nuestros proyectos, desde la concepción a la entrega.
Pero independientemente de esto, lo aconsejable es que el equipo de diseño y el de desarrollo estén cerca, algo que generalmente hemos visto que no se suele cumplir. Y cuando decimos cerca, no quiere decir necesariamente que sea físicamente cerca: gracias a las funcionalidades de Figma que vamos a ver en este artículo, podemos conseguir que los proyectos de diseño sean accesibles durante su elaboración al equipo de desarrollo y tener así su punto de vista y conseguir que estén más familiarizados con el proyecto cuando este llegue a sus manos, pudiendo resolverles dudas a lo largo del proceso en lugar de solo al final. Y una vez listo el documento, existen mejores prácticas que nos permiten preparar correctamente archivos para conseguir que el traspaso con los desarrolladores sea lo más efectivo posible. Vamos a verlas…
Cómo organizar tus proyectos en Figma
Como ya henos dicho más de una vez en este blog, no existe una forma ‘oficial’ de organizar proyectos en Figma. Lo que hace realmente interesante a esta herramienta es que ofrece una gran flexibilidad, así que existen muchas maneras en las que se pueden estructurar los proyectos: la mejor será aquella que se adapte a las necesidades específicas de tu empresa, de tu equipo y de tu producto. Ahora bien, escojáis el enfoque que escojáis para ordenar vuestros proyectos, es importante seguir unas pautas.
La primera de ellas es emplear siempre la misma estructura en todos tus proyectos. Eso ayudará a que los desarrolladores (u otros diseñadores) sepan dónde pueden encontrar lo que buscan.
Otro consejo es dividir el proyecto en partes más manejables (archivos). Porque aunque a veces sea tentador incluir todo el diseño de un proyecto en un solo archivo, lo cierto es que -salvo en contadas ocasiones y para productos muy simples- este enfoque se traduce en documentos excesivamente grandes y complejos, donde se hace muy difícil encontrar algo.
Dentro de los archivos podemos crear páginas con el mismo propósito: separar el trabajo para evitar espacios la acumulación de excesivos frames. Esta estructura de páginas puede estar formada por la portada (con la miniatura con la información básica del archivo para que sea reconocible en la vista de explorador de archivos), el research (moodboard para almacenar ideas que pueden servir como inspiración), la documentación del cliente (contenido que nos comparten para el proyecto), la zona de experimentación (donde se empiezan a desarrollar las primeras ideas), el work in progress (donde se empieza a montar el diseño afinando los detalles y utilizando componentes y variables), el prototipo final (con las páginas que ya han sido validadas por el cliente para que los desarrolladores lo puedan localizar e integrar).
Sigue en Figma la misma metodología para diseñar que para desarrollar
Que diseñadores y desarrolladores sigan la misma metodología de trabajo es tan útil como que hablen el mismo idioma. Por ejemplo, la mayoría de los desarrolladores (como es el caso de OKB Interactive Studio) trabajan habitualmente siguiendo una metodología atomic design, que disecciona una página en elementos repetibles más pequeños que se combinan de diferentes modos para crear nuevos elementos. Sus herramientas de trabajo básicas son los tokens y los componentes, así que les resulta muy útil que los diseñadores también utilicen estos conceptos a la hora de diseñar en Figma, planeando bien el sistema de diseño para crear patrones que se repitan y que eviten que los desarrolladores tengan que aplicar clases y estilos específicos para un solo elemento, optimizando así el código y también el tiempo invertido.
Siguiendo esta misma lógica, Figma permite aplicar estilos y crear componentes y luego reutilizarlos a lo largo del diseño a modo de instancias. Cuando un desarrollador selecciona una instancia puede ir directamente al archivo que contiene su componente maestro. Por eso es muy conveniente que los diseñadores añadan junto a ellos toda la documentación que pueda resultar útil para el desarrollador, como el nombre, una breve descripción de uso, sus diferentes estados…
No pases a desarrollo sin incluir el ‘responsive’
Un diseñador nunca debería dejar a la intuición del desarrollador saber qué va a pasar con un contenido cuando la resolución de pantalla sea muy reducida, máxime cuando actualmente el 57% de las consultas que se realizan a Internet desde España se hacen a través de teléfonos móviles (frente al 40% de los ordenadores y el 3% de las tabletas). Sin embargo, todavía hoy es muy habitual que a los desarrolladores les lleguen prototipos solo con su versión para escritorio, cuando tu fichero en Figma debería incluir versiones de cada pantalla en cuatro resoluciones: mobile (para teléfonos móviles de unos 360 píxeles de ancho), tablet (para tabletas en vertical de unos 768 píxeles), laptop (para pantallas pequeñas de 1280 píxeles) y desktop (para monitores de 1920 píxeles).
¿Dónde es mejor ubicar estas versiones de resolución? Siempre hay que pensar en los flujos de trabajo. Por ejemplo, en OKB Interactive Studio, las ubicamos todas juntas en una misma página porque es más cómodo tanto para los diseñadores como también para los desarrolladores, que suelen trabajar con ellas simultáneamente. Separarlas puede obligar a saltar demasiado de una página a otra o de un archivo a otro, incomodando el trabajo.
Un prototipo debe incluir todos los estados
Al igual que sucede con hacer prototipos solo para desktop, otro vicio habitual de los diseñadores es centrarse únicamente en crear pantallas que representen el estado ideal y por defecto en el que se muestra el contenido. Por ejemplo, es muy fácil diseñar un carrusel de tarjetas cuando el texto de cada una de ellas es falso y está perfectamente formateado para que todos tengan la misma longitud. ¿Pero qué pasa cuando los contenidos están descompensados? ¿Se hace una ellipsis? ¿Se aumenta el tamaño de la tarjeta? Como diseñadores, también hay que dar solución a estos casos (que sin duda se producirán una vez el proyecto abandone la idílica fase de diseño) para que el desarrollador también los tenga en cuenta en su código y no tenga que improvisar nada.
También hay que planificar otros supuestos, como los estados de error y éxito (que describen si una determinada tarea se ha completado con éxito, como por ejemplo rellenar los campos de un formulario), el estado de carga (que muestra cómo se visualiza una pantalla cuando se está a la espera de que se realice alguna acción o de que se cargue su contenido) o el estado en blanco (que describe el aspecto de una pantalla cuando no hay contenido que mostrar, por ejemplo tras realizar una búsqueda y no obtener ningún resultado).
Los mismo sucede con las interacciones: todo diseño en Figma debe incluir qué aspecto tienen los elementos cuando el usuario interactúa con ellos, ya sea haciendo clic o pasando el ratón por encima de ellos.
Indica a los desarrolladores los versionados y las validaciones
Como ya hemos dicho antes, el diseño de una aplicación web implica muchos cambios. Esos cambios no se suelen hacer sobre un mismo diseño, sino que se hacen a modo de versiones, ya que siempre existe la posibilidad de tener que volver a algo que se descartó previamente o incluso es habitual que algunos cambios sean solo pruebas que necesita el cliente para hacerse una idea de algo. Como resultado, al final de la fase de diseño, un proyecto en Figma puede albergar decenas de pantallas.
Por eso es muy importante que todas estas versiones no caigan a la espalda de los desarrolladores, o de lo contrario les costará identificar qué versión es la definitiva (que no tiene que ser necesariamente la última). Así que nuestro consejo desde OKB Interactive Studio es separar siempre los archivos de diseño de los de producción, como ya hemos visto al hablar de las páginas.
Además, dentro del prototipo que se comparte con el cliente, en OKB Interactive Studio incluimos un frame que sirve como control de versiones de una misma página, indicando en él qué versiones son nuevas y, en caso de existir una, qué versión es la aprobada, evitando así confusiones tanto a clientes como a desarrolladores.
Este proceso se complica si tenemos en cuenta que las fases de diseño y desarrollo no son siempre consecutivas: en muchas ocasiones se solapan la una a la otra y el equipo de desarrollo trabaja en algunas pantallas mientras el equipo de diseño termina de cerrar otras con el cliente. Por eso, resulta muy útil establecer un código que sirva para comunicar a los desarrolladores qué partes de los prototipos están listos, cuáles están pendientes de validación y en cuáles se sigue trabajando todavía, usando por ejemplo etiquetas, colores o emojis sobre los frames del archivo Figma. Cualquier código es válido siempre que sea fácil de entender y se comparta por todos los equipos involucrados.
Usa nombres descriptivos en tus prototipos Figma para desarrollo
Nombrar los distintos frames de un documento de Figma tiene varios objetivos:
- Hacerlos fácilmente localizables.
- Hacerlos innequívocos.
- Ser descriptivos para ayudar a entender lo que representan.
Puedes usar la nomenclatura que quieras, pero recuerda que un nombre sólo tiene sentido si todos los equipos lo usan.
Pero no solo hay que nombrar los frames. Nombrar los elementos de cada capa es también importante, quizás no durante la fase inicial de ideación (ya que no es necesario comunicarse con otros equipos) pero sí una vez que el diseño va consolidándose y avanza en las validaciones, y sobre todo antes de pasarlo a los desarrolladores. Así que podría valer la pena nombrar las capas Figma según las clases que usarán más tarde los desarrolladores: por ejemplo en OKB Interactive Studio usamos la metodología de nomenclatura BEM CSS (bloque, elemento y modificador) para definir las clases de los nodos HTML. Así que es una buena idea utilizar esta misma metodología a la hora de nombrar las capas en Figma: así, gracias al Dev Mode, los desarrolladores pueden obtener código HTML y CSS de los elementos que previamente se han diseñado ya con los nombres que van a utilizar, sirviéndoles como base de trabajo.
Mantén siempre un canal de contacto con los desarrolladores
A veces como diseñador puedes tener una idea muy clara de cómo debe comportarse un determinado elemento. Pero aunque para ti pueda parecer algo muy obvio, puede ser que para otra persona (como por ejemplo el desarrollador que se va a encargar de implementarlo) no lo sea tanto.
Es cierto que transmitir una idea con precisión en un diseño puede ser algo complicado, pero para ello Figma dispone de una funcionalidad de comentarios realmente útil. Con ella puedes dejar constancia de todos aquellos puntos que han surgido durante el diseño, sobre todo aquellos en los que más ha incidido el cliente y más le preocupan: que esas cuestiones no se incluyan en el desarrollo (aunque haya sido por descuido) da muy mala imagen del estudio de cara a su cliente. La clave está en explicar todo tal cual te gustaría que te lo explicaran a ti. Es mejor no dar nunca nada por supuesto…
Pero esta herramienta no es unidireccional: también sirve para que los desarrolladores puedan plantear sus dudas sobre el diseño durante el proceso de desarrollo. Dejar comentarios directamente en Figma en lugar de recurrir a emails o tickets es, en nuestra opinión, una forma más práctica de comunicarse, ya que proporcionan un contexto. Es más, Figma incluye un paso más en este sentido: el audio chat, donde diseñador y desarrollador pueden hablar directamente si una duda por escrito se está complicando demasiado.
Incluye un esquema de navegación para los desarrolladores
Finalmente, tener claro cuántas páginas integran la aplicación, cuáles son sus nombres y cómo se relacionan entre ellas le resultará muy útil al desarrollador, especialmente si la aplicación web es compleja o su número de pantallas es elevado. Incluir un árbol de navegación no llevará mucho tiempo y sin embargo facilitará mucho el trabajo.
La organización de archivos puede parecer una tarea ardua al principio. Pero hacer un buen traspaso entre los diseñadores y los desarrolladores es muy beneficioso: no solo sirve para agilizar el trabajo o asegurarnos de que los detalles importantes no se pierdan por el camino, sino que además evita las tensiones entre equipos. En este sentido, Figma es una herramienta muy útil porque tienen un espíritu colaborativo, que rompe la tradicional visión del diseño y el desarrollo como compartimentos estancos, cuando en realidad son dos piezas de un mismo proceso que no se pueden separar y que, cuanto más integradas estén, mejor resultados se obtendrán.
