El otro día encontré un post en LinkedIn que hacía una analogía entre «realidad vs expectativa» y la viñeta iba sobre un Figma vs la realidad.
Creo que fue la primera vez que intervine realmente en un comentario. Mi participación últimamente es autopropaganda de este blog. Que por cierto no sé quién lee, no tengo nada de medición por que quiero ser cookieless y además sin comentarios.
Pues bien, bajo mi criterio es un error que en los equipos de diseño no exista una figura de CSS artisan y que el entregable, en vez de componentes en Figma, muy bien documentado, no se entregue eso mismo pero en componentes HTML. Precisamente por esto escribí hace tiempo sobre el diseño sobre navegador, por los beneficios que implica.
CSS artisan
Perfil híbrido que sabe diseñar y conoce como y traducir esa propuesta en componentes HTML/CSS listos para producción, garantizando fidelidad visual, rendimiento y accesibilidad.
Los límites del diseño y la interfaz
Como diseñadores es imprescindible conocer los límites del diseño.
Eso te hará tener más control sobre el dispositivo y la interfaz, que van a ser claves para ofrecer una buena experiencia. De hecho en los primeros capítulos de un curso de UX muy recomendable que realicé con la gente de Designgraduate conocí el diagrama de la tarea. Con estos se puede visualizar de forma muy rápida cuales van a ser los principales stoppers y puntos críticos. Evidentemente, no es lo mismo realizar una interacción en un móvil que en un reloj inteligente, hay que diseñar de forma diferente.
Si diseñas un APP móvil con algún Framework lo ideal es que te adentres en sus entrañas y sepas como realmente funciona para que te ponga límites.
El problema de los mockups perfectos
Y es que el problema no es Figma. Está muy bien para lo que está diseñado. El problema es que hemos convertido los ficheros .fig en el final del proceso de diseño cuando debería ser solo el principio.
Resulta que diseñas un componente precioso en Figma, con sus sombras perfectas, sus estados hover que parecen sacados de un anuncio de Apple. Lo entregas al desarrollador y…
¿Por qué pasa esto? Porque entre el diseñador que sabe hacer cosas bonitas y usables y el desarrollador front que sabe hacer que las cosas funcionen, hay un abismo de conocimiento que nadie está cubriendo.
Y luego existe otro problema, proyectos que se encargan a agencias incomunicadas. Diseño por un sitio y a desarrollo por otro y nadie acaba validando nada, a menos qué, en la empresa de desarrollo exista algún CSS artisan.
La figura que falta en los equipos
En cualquier equipo de diseño que se precie debería haber alguien que entienda profundamente de CSS. No me refiero a alguien que sepa poner display: flex y ya está, sino alguien que entienda las limitaciones del medio, las posibilidades reales, y que sepa traducir las ideas del diseñador a código que realmente funcione.
Este perfil, al que llamo CSS artisan, sería el puente entre el diseño y el desarrollo. Alguien que puede coger el mockup de Figma y convertirlo en un componente HTML/CSS funcional que el desarrollador puede integrar directamente.
Y sobre JavaScript, tampoco hace falta ser senior. Con que sepa acoplarse a un elemento del DOM y hacer un toggleClass o hacer un append con datos dummy sería más que suficiente para la mayoría de interacciones básicas que necesitan los componentes y explicarlos al equipo de desarrollo.
El guardián de la accesibilidad
Pero luego habría que hablar también sobre accesibilidad, y esa figura sería la que lo controlase. Porque resulta que la accesibilidad no es algo que se añade al final, es algo que se diseña desde el principio. Y no es solo poner alt en las imágenes.
Es entender que un dropdown necesita aria-expanded, que ese botón con icono necesita aria-label, ¡y ojo!, no te olvides de aria-live="polite" cuando vayas a abrir ese componente reactivo; que la navegación por teclado tiene que funcionar de manera lógica. Es saber que esos colores tan modernos igual no tienen suficiente contraste, que esa animación igual le da mareos a alguien.
Un CSS artisan que entienda de accesibilidad puede entregar componentes que no solo se ven bien y funcionan bien, sino que son usables por todo el mundo. No como ahora, que la accesibilidad se convierte en una tarea de «ya lo arreglaremos después» que nunca llega.
¿Deberían ser los entregables un HTML?
Imagínate un mundo donde en lugar de entregar un .fig con anotaciones, entregas un .html con su CSS correspondiente. El desarrollador se lo descarga, lo mira en el navegador, y dice: «Ah, vale, ya entiendo cómo funciona esto».
Los beneficios son evidentes:
Para el diseñador: Ve inmediatamente si su diseño funciona en el mundo real. Si ese botón se ve bien en móvil, si esa tipografía se lee correctamente, si esa animación no ralentiza la página…
Para el desarrollador: No tiene que interpretar nada. No tiene que adivinar cómo se comporta ese dropdown o cuántos píxeles tiene realmente ese margin. Todo está ahí, funcionando.
Para el proyecto: Se reduce dramáticamente el tiempo de implementación y las idas y venidas entre diseño y desarrollo.
Diseñar en el medio final, no en un prototipo
Cuando diseñas directamente en el navegador, te das cuenta inmediatamente de las limitaciones reales del medio. Esa sombra que quedaba preciosa en Figma igual resulta que consume demasiados recursos. Ese layout que parecía perfecto igual se rompe en cuanto cambias el tamaño de la letra del dispositivo.
Pero sobre todo, cuando diseñas en navegador, diseñas para usuarios reales usando dispositivos reales.
Recuerdo hace unos 10-15 años, el diseño de mi primera APP, su implementación fue desastrosamente inconsistente. Acabó llena de botones redondeados que era la imagen del prototipo que les envié, eran tiempos donde no existía Figma y empezaba a sonar Sketch, sólo para los usuarios de MAC.
El problema real era que yo no conocía las limitaciones del Framework que había por detrás, con el que se estaba desarrollando.
A los años, se rediseñó y solicité entrar y ver. Tras una pequeña formación comprendí algunos de los límites que tenía, los componentes y ese sistema de marcado tipo XML, que me recordaban a lo que ya conocía.
Se iba a programar con el antecesor de MAUI, y fue enriquecedor conocer bien las limitaciones que teníamos para poder ofrecer una experiencia buena con un diseño decente y por fin con unos buenos bordes redondeados nativos que escalaban correctamente según el ancho del dispositivo.
Mobile first, ¿de verdad se puede hacer sólo con Figma?
Y ya que hablamos de dispositivos reales, una coña: todo el mundo va de mobile first, pero ¿cómo probáis «first» vuestro diseño en Figma? ¿Achicando la ventana del navegador para ver cómo queda el frame de 375px?
Porque resulta que mobile first no es hacer el diseño más pequeño, es entender cómo se comporta realmente en un dispositivo móvil. Con dedos gordos, con conexiones lentas, con interrupciones constantes. Y eso, por mucho que lo hagas responsive en Figma, no lo vas a saber hasta que no lo pruebes en un móvil real.
La resistencia del sector
¿Por qué no se hace esto más? Porque requiere que los equipos inviertan en perfiles híbridos que son más caros.
Al final es una cuestión de entender que el diseño de interfaz no termina en Figma. El diseño termina en el la tarea que van a ejecutar personas reales con dispositivos y conexiones de verdad, las que se estudian previamente en investigación UX y en la que el «medio y parte del contexto», a veces, no están presente en el proceso de diseño.
Hasta que no asumamos eso, seguiremos teniendo «Figma vs Realidad».