Insights
Cómo preparar prototipos en Figma para el equipo de desarrollo
La rivalidad entre diseñadores y desarrolladores no tiene ningún sentido y es enormemente contraproducente, porque ambas partes son indispensables para crear un buen producto. Así que si trabajas en un entorno donde los desarrolladores creen que todos los diseñadores son un puñado de creativos con egos insufribles que siempre están imaginando la forma de torturarlos, y los diseñadores piensan que los desarrolladores son personas sin alma que solo saben de unos y ceros y que se molestan cada vez que se les pide hacer algo distinto, entonces puede ser que tengáis un problema serio con los prototipos. Porque en la mayoría de los casos, estos problemas surgen porque el handoff entre las fases de diseño a producción no se hace correctamente.
Solemos ver los prototipos web como una herramienta para acordar con el cliente una idea cerrada de un producto digital (tanto de su aspecto como de sus funcionalidades) sin tener que escribir una sola línea de código, momento en el cual el proceso se vuelve más costoso y los cambios de dirección son difíciles de manejar. Pero algo que a veces se pasa por alto es que, además de para eso, los prototipos web son también una importante herramienta de comunicación interna entre los distintos equipos que participan en el proceso. Porque una vez que han sido aprobados por los clientes, esos mismos prototipos pasan del diseñador al desarrollador, que es quien se encargará de hacerlos realidad.
Por eso, un prototipo puede marcar la diferencia entre una fase de desarrollo ágil u otra llena de sorpresas indeseadas. O, lo que es lo mismo, entre unos equipos de diseño y desarrollo que se entienden y trabajan juntos o unos equipos en los que las tensiones surgen con demasiada frecuencia.
Los prototipos no son tuyos, son de todos
A la hora de preparar un prototipo web hay que ser conscientes de que en algún momento este 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 o una aplicación. Así que es importante que tu trabajo no se convierta en un jeroglífico indescifrable que dé rienda suelta a la libre interpretación de quien lo reciba.
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. Lo interesante es que este proceso de organización se establezca conjuntamente entre todos los equipos. Ahora bien, escojáis el enfoque que escojáis para ordenar vuestros proyectos, es importante no olvidar unas pautas.
La primera de ellas es emplear siempre la misma estructura en todos los 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 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) y el prototipo final (con las páginas que ya han sido validadas por el cliente para que los desarrolladores lo puedan localizar e integrar).
Prepara prototipos pensando en el desarrollador
Ponerse en la piel del otro siempre nos ayuda a ser mejores en la vida. También en nuestro trabajo. Por eso, que un desarrollador sea capaz de pensar como un diseñador (y a la inversa) resulta sumamente útil para un proyecto. No es estrictamente necesario que los diseñadores sean también desarrolladores, pero sí que tengan nociones de desarrollo; tanto como que los desarrolladores estén familiarizados también con los prototipos y conozcan conceptos esenciales de diseño y usabilidad.
Aplicado a la elaboración de prototipos, este principio se puede conseguir aplicando en el diseño la misma metodología de trabajo que en el desarrollo. Que diseñadores y desarrolladores sigan la misma metodología de trabajo es tan útil en términos de agilidad de trabajo como que hablen el mismo idioma. La mayoría de los desarrolladores trabajan habitualmente siguiendo una metodología atomic design, que consiste en diseccionar una página en elementos repetibles más pequeños que se combinan de diferentes modos para crear nuevos elementos. Esa es por ejemplo la forma de trabajar que seguimos en OKB Interactive Studio. Por lo tanto, las herramientas básicas de trabajo de todo desarrollador son los tokens y los componentes, así que si los diseñadores también utilizan estos conceptos a la hora de diseñar sus prototipos en Figma, en desarrollo se optimizará el código y también el tiempo invertido.
¿Y cómo se hace todo esto? Figma permite 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…
En este sentido, nombrar correctamente cada elemento de capa en Figma 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 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.
Nunca pases a desarrollo un prototipo que no está completo
Un buen prototipo nunca debería dejar a la intuición del desarrollador qué es lo que va a pasar con el diseño en determinadas circunstancias, como cuando la resolución de pantalla sea muy reducida o cuando se produzca alguna interacción con el contenido. En algunos proyectos, este tipo de situaciones son tan frecuentes que el diseñador suele omitirlas para simplificar su trabajo. Y esto es lo que ocasiona problemas…
El caso más habitual de prototipos incompletos se suele producir con el responsive. El prever cómo se van a comportar los elementos de una página cuando la resolución de pantalla sea muy reducida es parte del trabajo de todo diseñador. Y una parte importante, ya que actualmente el 57% de las visitas web en España se hacen a través de teléfonos móviles, frente al 40% de los ordenadores y el 3% de las tabletas. Pese a eso, todavía hoy es muy habitual que a los desarrolladores les lleguen prototipos solo con su versión para escritorio, lo que suele generar problemas y retrasos en las entregas. Así que todo prototipo en Figma debería incluir versiones de cada una de las pantallas a distintas resoluciones. Ahora bien, qué resoluciones incluir y dónde hacerlo es algo que siempre ocasiona algún debate.
Para saber cuántas vistas de cada pantalla hay que incluir, lo ideal es basarse en los puntos de ruptura que se vayan a aplicar en el desarrollo. Por lo general serán cuatro resoluciones: mobile (de unos 360 píxeles de ancho), tablet (unos 768 píxeles), laptop (1280 píxeles) y desktop (1680 píxeles). En cuanto a la ubicación de estas vistas en el archivo de Figma, nuestra conclusión es que lo mejor es hacerlo pensando en los flujos de trabajo: por ejemplo, en OKB Interactive Studio ubicamos todas las vistas de cada pantalla en una misma página porque habitualmente, tanto diseñadores como desarrolladores, suelen trabajar con ellas simultáneamente, así que es mucho más cómodo tenerlas todas juntas.
El responsive es solo un ejemplo de lo incompletos que pueden estar algunos prototipos cuando llegan a desarrollo, pero desde luego no el único. Otro punto de conflicto entre diseñadores y desarrolladores se produce cuando los diseñadores se centran únicamente en crear pantallas que representan el estado ideal y por defecto en el que se muestra el contenido: por ejemplo un carrusel de tarjetas en las que 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? Un buen prototipo que facilite el trabajo siempre tiene 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.
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). Y lo 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.
Los prototipos siempre deben estar accesibles
Lo aconsejable es que el equipo de diseño y el de desarrollo estén siempre cerca. Y cuando decimos cerca, no quiere decir físicamente cerca. Según el tamaño de la empresa, hay veces que los equipos de diseño y desarrollo están en plantas separadas, en edificios distintos, o hasta en ciudades o países diferentes. Pero incluso en esas circunstancias pueden estar próximas si ambas partes se implican en el trabajo de la otra. Por eso, los prototipos siempre deben estar accesibles durante la fase de diseño para que el equipo de desarrollo se vaya familiarizando con el proyecto y puedan aportar también su perspectiva.
Los prototipos deben ser lo suficientemente completos como para explicarse por sí solos, pero es cierto que, conforme más compleja se vuelve una aplicación web, más difícil se hace transmitir con precisión en el prototipo algunas de sus funcionalidades o comportamientos. Incluso lo que a veces como diseñador puede resultar evidente, para otra persona que no ha estado tan implicada en la fase de diseño no lo sea tanto. Por eso es muy importante documentar bien todo.
Para ello Figma dispone de una funcionalidad de comentarios realmente útil. Con ella se pueden 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 todas esas cuestiones no se incluyan en el desarrollo (porque no hayan quedado claras o porque se hayan omitido por descuido) da muy mala imagen de cara al cliente.
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.
Deja claro qué versión de prototipo es la correcta
Durante la fase de diseño de una aplicación web, los cambios suelen ser constantes. Esos cambios no se suelen hacer sobre un mismo diseño, sino que se añaden 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… Todo esto hace que, como resultado, al final de la fase de diseño, el prototipo en Figma albergue 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 generará dudas 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, algo que hacemos en OKB Interactive Studio y que creemos que resulta muy útil, es incluir 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.
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.
