Diseñando interfaces web en posición absoluta

De dónde venimos y la situación actual

Empecé a diseñar para web en 2011 y a trabajar en 2013. Uno de mis primeros trabajos fué en Microsoft como becaria en el equipo de diseño, en Helsinki. Por aquel entonces la mayoría de recursos para UI estaban hechos en Photoshop. Sí, Photoshop, una herramienta para editar fotos, era la misma con la que se diseñaban páginas web. Con ello podía exportar imágenes que luego se las pasaba a desarrollo y ellas harían la magia para programarlo. Y siempre, no lo programaban como yo esperaba que lo hicieran. El diseño no se ajustaba nunca con exactitud a lo que realmente había diseñado y ello me frustraba, y mucho. No lo entiendía, así que decidí aprender a programar, para entender cual era el problema y conseguir resolverlo.

Un tiempo después, empecé a programar HTML y CSS y poco después ya escribía código en producción en otra empresa más pequeña. Eso sí, sin dejar de lado el diseño. Es entonces cuando me empecé a dar cuenta de que había algo que no cuadraba. ¿Por qué diseñábamos imágenes estáticas cuando la web no lo era? ¿Por qué no podía diseñar un botón que se ajustara a su contenido en vez de ir ajustando sus márgenes manualmente como hacía en la web? ¿Por qué mis diseños no se adaptaban al ancho de la pantalla con estilos relativos como pasaba cuando programaba? ¿Por qué parecía que diseñaba en "position: absolute;"?

Y no solo era esto, mientras las diseñadoras estábamos haciendo obras artesanales, en desarrollo utilizaban Git como control de versiones, trabajando en equipo y de forma totalmente segura y ordenada gracias a ello.

Hasta que un día apareció Sketch. Me acuerdo que empecé a utilizarlo a finales de 2014. Parecía la revolución, seguro que las diseñadoras que me estéis leyendo afirmaréis que mejoró nuestra calidad de vida. ¡Por fin un programa únicamente para diseñar UI! ¡La salvación! Un programa donde no había mil botones que no necesitabas, donde no solo se podían exportar imágenes, ¡sino que se podían exportar también SVGs! Y todo era mucho más rápido y fácil que con Adobe. Además tenía plugins que parecían super poderes al lado del antiguo Photoshop. Lo realmente maravilloso llegó con los símbolos, por fin podíamos guardarnos diseños, reutilizarlos y sincronizarlos a través de toda la app, era genial.

También aparecieron programas como Zeplin que facilitaban a las desarrolladoras (que no tuvieran Sketch) implementar nuestros diseños. Pero no nos engañemos, el CSS que genera Sketch o Zeplin pocas veces acaba en producción o tiene relevancia. Alguna cosita como colores, espaciados o sombras, pero nada más. Ni siquiera utilizamos "CSS" a pelo en los proyectos de frontend, sino que utilizamos preprocesadores de CSS como SCSS.

Un tiempo después, en el 2017, apareció Figma el cual ha conseguido mucho protagonismo por estas razones frente a Sketch:

• Funcionar en la web y tener un plan gratuito de iniciación.
• Colaboración en tiempo real en un mismo archivo.
• Historial de versiones (que no control de versiones)
• API web con la que poder extraer información del archivo de Figma.
• Plugins, seguramente la feature más fuerte de Figma en este momento. Aunque Sketch ya tiene plugins, gracias a la API web que he mencionado antes, los plugins de Figma tienen mucha más fuerza.

Creo que tanto la colaboración en tiempo real como el historial de versiones es un gran paso, aunque a mí me gustaría un control de versiones independiente al programa y preferiblemente alojado donde esté el código, para centralizar los recursos. Lo que tiene que mejorar aún mucho más es su API, donde los resultados que devuelve siguen siendo muy escasos, sobre todo lo relacionado con componentes y estilos, lo que hace imposible conectar frontend y diseño, uno de mis deseos para esta API.

Seguimos sin solucionar los problemas clave

Sí, Sketch o Figma son mucho mejor que Photoshop y la industria continua evolucionando constantemente, pero seguimos sin solucionar los problemas clave:

• Diseñamos e implementamos lo mismo 2 veces y encima ¡hay diferencias entre sí! ¿Cuánto tiempo hemos perdido diseñando los espaciados de x píxeles y luego en desarrollo no se ha implementado así o ni siquiera hemos podido aplicar esa regla en todos los elementos del diseño? No es culpa de las desarrolladoras, ni es culpa de las diseñadoras, la culpa ha sido del medio, de la herramienta de diseño. La diferencia entre lo diseñado y lo desarrollado siempre existirá mientras estén separados paralelamente.

• Las herramientas actuales no nos permiten diseñar de forma responsive. Ojalá poder hacer posiciones relativas en diseño. Ojalá tener CSS media queries para estructurar el contenido en función de su ancho. No soporto tener que diseñar la misma pantalla 3 veces porque no se puede diseñar de forma que se ajuste a su ancho. Pérdida de tiempo. Ineficacia. Al final, como UX Engineer (diseño y front) acabo no diseñando las versiones en otros dispositivos porque las diseño de forma modular en un solo ancho de pantalla y yo misma las adapto de forma responsive en la implementación.

• La web no es plana, no es un lienzo en blanco. Estamos acostrumbradas a crear dibujos estáticos que no representan la realidad en su totalidad: la web no son imágenes ni vectores, no es plana, tiene interactividad. La web también tiene estados (hover, active, focus, visited...), pero ¿cómo se representan en el mundo plano del diseño? Repitiendo diseños. Diseñamos ese mismo elemento 4 veces diferentes para representar de forma irreal esos estados pero no vemos como queda el resultado real hasta que se ha implementado.

• Trabajar sin control de versiones hace que no podamos trabajar en equipo en un mismo archivo de forma totalmente ordenada. Sí, Figma tiene la colaboración en tiempo real e historial de versiones pero seguimos estando a años luz de poder documentar y crear diferentes versiones del proyecto para luego compararlas y unirlas como hacemos con los controles de versiones en código. Y no, las herramientas como Abstract para Sketch no me parecen suficientes, ya que no están basadas en código web y no podemos comparar las diferencias objetivas desde su mismo medio.

• Los bugs visuales acaban en producción porque no tenemos tests de aceptación en el diseño. Cuando hablo de test, hablo test técnicos de aceptación, no de usuario. Imagina tener una forma de comprobar que todos los colores usados en el diseño son los colores oficiales. O por ejemplo, que todas las medidas utilizadas son múltiplos de 8 como se ha definido en el sistema de diseño. ¿Sería muy útil, verdad? En el lado de desarrollo están muy acostumbrados a pisar en firme con tests que les permiten minimizar posible errores en su trabajo, los diseñadores no tenemos esto al diseñar y esto lleva a que los bugs visuales acaben en producción.

¿Por qué pasa esto?

Muchas diseñadoras de UI siguen arrastrando el pensamiento de diseño gráfico, como si diseñar para web fuera lo mismo que para offline pero con diferentes medidas o reglas. No, no es así. El medio del producto es totalmente diferente y nuestras herramientas tienen que cambiar en función a ello.

Por ello creo que las herramientas con las que diseñamos para web tampoco deberían de ser las mismas con las que diseñamos apps móviles nativas. No funcionan igual, no se desarrollan igual, no tienen las mismas interacciones y no se deberían diseñar igual. SwiftUI ha dado el paso de poder diseñar con el mismo código con el que se desarrolla la app en producción, haciendo que sea la herramienta más indicada para diseñar apps para iOS.

El problema principal está en separar concepto de implementación. ¿Realmente necesitamos separarlo? ¿Por qué? Lo único que conseguimos es trabajar el doble con unos bocetos idealizados que no se ajustan a la realidad y generar fustración entre la brecha diseño-desarrollo. A diferencia de otras modalidades de diseño, en el diseño web tenemos el privilegio y la gran suerte de poder utilizar el mismo medio donde se implementa para conceptualizar ese diseño. Pero las actuales herramientas de diseño están alejadas de cómo funciona la web, arrastran el pensamiento de separar el concepto de la implementación como se hace en todas las otras modalidades de diseño. No se puede diseñar edificios en su mismo medio, utilizando esos mismos edificios. Pero sí que podemos hacerlo con la web, ya que su material (HTML, CSS y JS) es lo suficientemente flexible, a través de una herramienta gráfica, como para permitirnos conceptualizar con la misma rapidez y fluidez que con una herramienta basada en vectores como es Sketch.

Como muy bien menciona Colm Tuite en su artículo: "Design tools shouldn’t need to resemble or reflect the web and its nuances — they should just BE the web."

Sistemas de diseño

Nuestro tema preferido, los sistemas de diseño. Pero poco mencionamos lo increíblemente difícil que es mantener dos sistemas de diseño. El primero, el de diseño y el segundo, el de frontend. Y cuando se tienen dos proyectos diferentes con tecnologías diferentes y mantenidos por diferentes personas, nunca, jamás, van a tener una consistencia total. Y ahí está el problema, la dualidad.

Me canso de ver sistemas de diseño muy bien pensados pero que cuando vas a inspeccionar su código te das cuenta que están implementados de forma diferente a como se han diseñado. Lo cual es una tontería, porque ¿para qué tener un sistema de diseño definido si tu equipo de frontend lo ignora o no lo puede implementar? Un concepto que no se desarrolla o no se implementa bien no sirve para nada. ¿No sería mejor poder tener un único sistema de diseño? Una sola fuente de verdad.

¿Qué necesitamos para cambiar esto?

Yo imagino la herramienta de diseño perfecta como un Storybook donde las diseñadoras tuviéramos los componentes de un sistema de diseño escritos en código, los mismos que utiliza frontend en producción, por lo que no necesitaríamos mantener dos sistemas de diseño, solo tendríamos uno. Al arrastrar podríamos combinar esos componentes para crear organismos donde aplicar CSS desde una interfaz gráfica que reflejara las propiedades reales de la web, como son las medidas relativas, media queries, flexbox, CSS Grid... Lo mismo pasaría con las animaciones, podríamos animar esos elementos web con animaciones CSS. Y lo más importante, nuestros diseños dejarían de ser JPGs para ser HTMLs. Accesibles, responsive y sobre todo, reales.

Además solucionaríamos el problema del control de versiones y la creación de tests de aceptación. Al ser una herramienta basada en código web no habría problemas con crear ese control de versiones. Se podría previsualizar comparando de forma gráfica los archivos HTMLs visualizados por el browser y eligiendo con qué versión te quedas además de ver objetivamente el código web que ha cambiado. Tampoco existiría ningún problema al crear un tests de aceptación ya que el código lo permitiría.

Por suerte hay ya algunos programas que trabajan así y aunque no respondan a todas las necesidades, van por el buen camino.

• Framer X: el hype en 2018 fue tremendo con el anuncio de que sus diseños podrían ser exportados a React o se podría diseñar mediante componentes programados previamente en React. Aunque es un gran paso, después descubrimos que el código no está pensado para acabar en producción sino para asemejarse lo máximo posible a React. Y aquí están los problemas: encerrarse en un framework como React y separar diseño y desarrollo al no crear código con el fin de acabar en producción. Realmente sería genial si Framer no se limitara a React, sino que se ajustara a los estándares web como son HTML y CSS. Utilizar React, Vue o Angular debería de ser una capa por encima de la maquetación como framework de JS que controla la reactividad de la webapp y delegarse al equipo de frontend.

• Webflow: es una gran y muy madura opción y cumple con la gran mayoría de los puntos. El principal problema es que el código que genera lo guarda en su propio hosting y parece imposible editarlo fuera de ese propio editor.

• Modulz: cae en el mismo problema que Framer X al exportar código sólo en un framework como React, pero en esta ocasión también darán soporte a otros frameworks de frontend populares. La ventaja principal es que exporta código preparado para ser utilizado en producción y utiliza propiedades de CSS para los estilos del diseño como flexbox y estados nativos.

• Hadron: aunque aún está en la versión 0.14, va en muy buena dirección. En su web podemos ver cómo resuelven todos los problemas planteados en este artículo incluso el diseño responsive con mediaqueries o grids hechos con CSS Grid. Aunque tardaremos en ver el resultado final, creo que promete mucho.

• Handoff: en su página de inicio podemos leer cómo también resuelve todos los problemas y frustraciones mencionados en este artículo. Me parece muy impresionante y prometedor. Veamos si podemos probar esta herramienta pronto, en la web ponen que se lanzará entre el cuarto trimestre de 2019 y el primer trimestre de 2020.

• Alva: es la única herramienta open source que he encontrado. Cae en el mismo problema de depender de componentes hechos en React en vez de web nativa. Y el código que exporta no está pensado para producción.

Por último, no voy a entrar en el "debate" de si las diseñadoras de UI deberían de saber "programar" (¡qué término más amplio!) porque creo que no debería de haber ni siquiera tal debate. Ser diseñadora de UI y conocer cómo funciona la web y por tanto HTML y CSS, que son lenguajes puramente declarativos, es tan básico como saber física siendo arquitecta. Las herramientas de diseño nos tienen que ayudar a través de interfaces gráficas que nos proporcionen más rapidez frente a los editores de código pero la implementación debería de ser la misma.

Seguir leyendo sobre el tema

• Design tools are holding us back de Tom Johnson
• Design tools are running out of track de Colm Tuite

¿Cómo lo ves tú?

Y tú, ¿qué opinas de las herramientas de diseño actuales? Ya has leído mi opinión al respecto, me encantaría que me contarás cual es la tuya en Twitter @marinaaisa