El libro Atomic Design de Brad Frost fue publicado en su primera edición en 2013. Desde entonces, se ha convertido en un libro de referencia para la creación de sistemas de diseño.
Este post no pretender resumir el contenido del libro. Hay otros que lo han hecho muy bien. Por ejemplo, el mismo Brad Frost en su blog.
Lo que pretendo en este artículo es pasar a limpio las principales enseñanzas o reflexiones que a mí me ha aportado la lectura del libro. A modo de recordatorio para el futuro. En consecuencia, se trata de un escrito completamente subjetivo y basado en mi know how previo.
Lo primero que quiero decir, es que me parece un libro de lectura muy recomendable para todos aquellos que estéis interesados en desarrollar sistemas de diseño, interfaces de usuario, guías de estilo, patrones de diseño, etc.
El autor ha sido muy generoso con la comunidad y el libro se puede leer completo online. Además de comprarlo en formato papel y/o ebook.
Además, está escrito de manera que su lectura resulta muy amena y es relativamente breve. En su versión en papel tiene unas 190 páginas.
Evaluar funcionalidades y componentes, no páginas
El trabajo que supone desarrollar un proyecto se determina mucho mejor mediante sus funcionalidades y componentes que por el número de páginas que contiene.
El concepto “página” es una metáfora útil y familiar que nos ayuda a comunicarnos, pero no resulta relevante a la hora de computar esfuerzo de desarrollo.
Modulariza el contenido
Prepara el contenido como si fuera a estar en cualquier sitio porque podrá estar en cualquier sitio.
Para ayudarte a modularizar la arquitectura de tu CSS existen metodologías como OOCSS, SMACSS y BEM.
Las primeras aproximaciones visuales al diseño de un interfaz deben ser de porciones pequeñas del mismo. No de páginas completas que proporcionen un diseño con falsa apariencia de diseño final.
Bootstrap sí o no
Los tan populares frameworks de UI como Bootstrap o Foundation resultan útiles para el desarrollo rápido de interfaces.
Proporcionan una colección de componentes bien comprobados y consistentes. Pero, como todo, le ve algunos serios inconvenientes:
- Uniformidad en el diseño. Todas las webs desarrolladas con estos frameworks “son iguales”.
- Cargas el proyecto con código que no vas a usar.
- Te impone un naming.
Estoy de acuerdo en el tema del naming, pero no del todo en los dos primeros.
La uniformidad en el diseño se puede evitar si se personaliza suficientemente el framework. Aunque lógicamente esto supone un importante trabajo de diseño y codificación.
La carga de código que no vas a usar también se puede evitar (o paliar al menos) configurando correctamente el framework y compilando sólo el CSS y el JavaScript que realmente necesitamos en nuestro proyecto.
Guía de estilo, la base del sistema de diseño
La guía de estilo (style guide) es la base de un buen sistema de diseño (design system). Documenta y organiza los componentes y proporciona instrucciones sobre su uso.
Las guías de estilo reciben varios nombres alternativos: pattern libraries, UI libraries, component libraries.
Las guías de estilo son herramientas que ayudan a prevenir el caos.
Qué es una guía de estilo
Una guía de estilo es una colección de componentes y reglas que el equipo de desarrollo debe seguir para asegurarse de que las partes separadas de una aplicación sean consistentes y proporcionen una experiencia coherente al usuario.
Una buena guía de estilo cuenta, al menos, con las siguientes funcionalidades:
- Proporciona descripciones de los componentes que incluye.
- Facilita el código HTML, CSS y JavaScript de cada componente.
- Permite visualizar los componentes a distintas resoluciones de monitor.
- Proporciona mecanismos para visualizar las distintas variantes de un componente.
- Proporciona contenidos reales de ejemplo para las distintas plantillas.
- Proporciona información contextual sobre el uso adecuado de los componentes.
Principales beneficios de disponer de una guía de estilo
- Promueve la consistencia y cohesión de todos los interfaces y aplicaciones.
- Incrementa la productividad de los desarrolladores. Ahorrando tiempo y dinero.
- Facilita un flujo de trabajo colaborativo entre las distintas disciplinas implicadas en los proyectos de desarrollo (jefes de proyecto, diseñadores, desarrolladores front-end, desarrolladores back-end, etc.)
- Establece un vocabulario común para todas las partes implicadas en el desarrollo. Incluyendo proveedores externos.
- Proporciona documentación útil para ayudar a formar a todas las partes implicadas en el desarrollo. Incluyendo proveedores externos.
- Facilita el testeo en distintos navegadores y dispositivos.
- Constituye una base sólida que se puede extender y mejorar con el tiempo.
A las guías de estilo hay que dedicarles tiempo
El desarrollo de una guía de estilo requiere de una importante dedicación en tiempo y recursos.
Si bien, una vez que se ha desarrollado, incrementa la velocidad y productividad de los desarrolladores.
Las guías de estilo no deben ser tratadas como un proyecto auxiliar
Son la base de un sistema de diseño y el sistema de diseño debe considerarse la base de todo proyecto de desarrollo de interfaces.
Las guías de estilo tienen que resultar un recurso útil para cualquier miembro de la organización
Deben ser atractivas, visibles, claras y fáciles de usar.
Deben proporcionar información sobre cuándo, cómo y dónde usar cada componente.
Un ejemplo de guía de estilo que proporciona información muy completa sobre cómo, cuándo y dónde utilizar cada componente es Material design.
Una estrategia de mantenimiento y actualización es crítica para la supervivencia de una guía de estilo
No hay que considerar un sistema de diseño como un proyecto con un alcance limitado. Debe ser considerado como parte del producto. Y como tal. crecer y evolucionar de manera ilimitada.
En el momento en el que una guía de estilo deja de reflejar la realidad del producto, está obsoleta. Para evitarlo hay que disponer de un workflow que actualice la guía de estilo antes que los interfaces de usuario finales.
Para desarrollar una guía de estilo sostenible en el tiempo, aconseja:
- Hacerla oficial. Asignando tiempo, dinero y recursos al sistema de diseño.
- Hacerla adaptable. Estableciendo una estrategia de actualización clara.
- Hacerla fácil de mantener. Técnicamente fácil de mantener y con un sistema para comunicar los cambios a todas las partes implicadas.
- Hacerla interdisciplinar. Toda la organización participa de su desarrollo y evolución.
- Hacerla atractiva. Clara y fácil de usar.
- Hacerla visible. Dentro de la organización. Evangelizarla.
- Hacerla más grande. Incluyendo, poco a poco, otras guías que no se refieran sólo a la parte visual: guías sobre cómo redactar los textos, cómo escribir el código, cómo tratar con el cliente, etc.
- Hacerla agnóstica. Nombrando a los patrones de acuerdo a su estructura y no a su contexto o contenido.
- Hacerla contextual. Proporcionando información sobre cuándo, cómo y dónde usar cada componente.
- Tenerla actualizada. En el momento en el que una guía de estilo deja de reflejar la realidad del producto, está obsoleta.
Atomic Design no es un proceso lineal
Aunque la metáfora de los átomos, las moléculas, los organismos, etc. pueda dar a entender que se trata de un proceso de construcción lineal, es crucial entender que no es así.
No tendría sentido diseñar botones y otros elementos de forma aislada y luego cruzar los dedos para que se cohesionen correctamente con el resto de elementos del interfaz.
Debemos pensar que Atomic Design es un modelo que nos permite crear al mismo tiempo los interfaces finales y sus componentes subyacentes.
El contenido condiciona el sistema de diseño
Más que condicionarlo, incluso podríamos decir que lo define.
El contenido real que vayan a albergar los distintos componentes del interfaz condiciona las características del propio componente.
La metáfora química no es lo relevante
La metáfora, basada en la química básica (átomos, moléculas, organismos), ayuda a entender que la construcción de los componentes de un sistema de diseño implica jerarquía.
Pero si esta metáfora no funciona en tú organización, el autor no ve problema en que la cambies. Atomic Design no es un dogma rígido.
Pattern Lab, una herramienta muy útil
Con la colaboración de varios colegas, Brad Frost ha desarrollado una herramienta que facilita construir una guía de estilo respetando los principios del Atomic Design. La han llamado Pattern Lab y es open source.
En su estructura, Pattern Lab utiliza la metáfora de la química, pero fácilmente se puede utilizar otra estructura o metáfora. De hecho, en el libro se invita a establecer el naming y la categorización que resulte más efectiva para nuestro proyecto.
Pattern Lab para el testeo de casos extremos
Una de las funcionalidades que, a mi juicio, resulta más interesante de esta herramienta son las pattern variations. Las cuales permiten testar variantes de un mismo componente con contenidos de distintas características.
Por ejemplo, ¿qué ocurre si el usuario añade 87 productos al carrito de la compra?, ¿qué ocurre si el título del post es de 400 caracteres?, etc.
Pattern Lab para el testeo de distintas resoluciones
Los desarrolladores front-end están acostumbrados a utilizar herramientas que permiten probar con facilidad distintas resoluciones de pantalla. Sin embargo, otros stakeholders del proyecto puede que no. Pattern Lab incorpora una herramienta para el cambio de resoluciones que puede resultar muy útil para hacer entender a ciertos stakeholders las propiedades responsive de un sistema de diseño.
El “secreto” para el éxito de un sistema de diseño: la colaboración y la comunicación
El “secreto” para desarrollar un sistema de diseño realmente efectivo no es otro que el que exista una auténtica colaboración y comunicación entre todas las partes implicadas.
Un ejercicio para favorecer la colaboración y comunicación al inicio del proyecto: la auditoría de componentes
Realizar en equipo una auditoría de los componentes actuales de un interfaz de usuario es una excelente manera de evidenciar sus inconsistencias y demostrar a los stakeholders la necesidad de un sistema de diseño.
En el libro se detalla la técnica para llevar a cabo este ejercicio.
Tres imágenes muy útiles para hacer comprender la complejidad del entorno web
Nuestro trabajo es proporcionar una buena experiencia de uso para una gran diversidad de dispositivos, tamaños de pantalla, velocidades de conexión, capacidades del dispositivo, funcionalidades del navegador, etc.
El libro incluye tres imágenes que al autor le han resultado muy útiles para hacer entender la complejidad del entorno web a los clientes, colegas, etc.
Considerar el rendimiento como un principio esencial del diseño
El rendimiento o velocidad de carga de un interfaz debe ser considerado como un requisito esencial de la experiencia de usuario.
La metodología de desarrollo en cascada no es válida para el mundo digital
La metodología de desarrollo en cascada tiene sentido en el mundo físico (imprenta, arquitectura, manufactura, etc.) porque los cambios suponen un coste muchas veces inasumible. Sin embargo, esto no es así en el mundo digital.
Para crear un sistema de diseño hay que hacer comprender claramente este punto a todas las partes implicadas y hacerlas trabajar de manera colaborativa, iterativa e incremental.
Hay que incluir a los desarrolladores front-end en el proceso de diseño
En libro distingue fundamentalmente tres roles implicados en el desarrollo de un sistema de diseño:
- UX designer
- Visual designer
- Front-end developer
Defiende (y estoy completamente de acuerdo) que es crucial que los desarrolladores front-end formen parte del core del proceso de diseño. No puede existir ningún tipo de división entre diseñadores y desarrolladores front-end.
La metáfora de la escultura
Para ilustrar el proceso de creación de un sistema de diseño Brad Frost utiliza una, en mi opinión, acertada y bonita metáfora.
Desarrollar un sistema de diseño es un proceso iterativo similar a esculpir una escultura.
Es clave que los stakeholders se sientan cómodos y sepan revisar el sistema de diseño cuando aún está en curso de desarrollo.
Papel de los UX designers
Los UX designers (también conocidos como information designers, information architects, interaction designers…) son los responsables de sintetizar toda la información vital del proyecto y trasladarla a los interfaces de usuario para que cumplan con los objetivos del usuario y del negocio.
Dentro de este proceso, es mejor comenzar con wireframes mobile first de baja fidelidad, en lugar de documentos de alta fidelidad.
Utilizar la aproximación mobile first nos fuerza a poner el foco en el contenido más importante y realizar una correcta jerarquización del mismo. Te puedes preguntar: ¿tiene esta página el contenido adecuado?, ¿está en el orden correcto?
El test visual de los 20 segundos
Una técnica que sirve para capturar en fases tempranas del proyecto los gustos visuales de los stakeholders.
Style tiles
Una técnica que permite a los diseñadores visuales explorar aspectos de color, tipografía, textura, iconos, etc. sin tener que avanzar en el diseño de la estructura del interfaz.
Sabemos que diseñar componentes y pantallas finales en fases demasiado tempranas del proyecto y sin la necesaria participación de los desarrolladores front-end nos llevará a realizar asunciones técnicas poco realistas.
Los style tiles sirven también para educar a los stakeholders en que piensen en términos de “sistema”, en lugar de en términos de “páginas”.
Collages de elementos
Es una técnica que permite avanzar algo más en el diseño que los style tiles, pero sin llegar aún a diseñar los componentes finales.
Tareas iniciales de cada rol de desarrollo
Durante los primeros días del desarrollo de un sistema de diseño, los roles implicados en el mismo pueden llevar a cabo tareas iniciales en paralelo:
- UX designers: pueden crear los wireframes de baja fidelidad para establecer la arquitectura de la información y anticipar algunos patrones de interfaz.
- Visual designers: pueden capturar las preferencias estéticas de los stakeholders mediante el test de los 20 segundos y plasmarlas en style tiles y collages de elementos.
- Desarrolladores front-end: pueden establecer las dependencias técnicas del proyecto, trabajar en las plantillas básicas, etc.
Estas tareas pueden llevarse a cabo en paralelo, pero no de manera aislada.
Iteraciones en el navegador
Diseñar los componentes finales requiere de mucho trabajo. Es por ese motivo que previamente se utilizan técnicas de aproximación para establecer la dirección del trabajo a realizar.
Si el feedback que obtenemos de los stakeholders cuando presentemos el diseño de los componentes finales es del tipo “¿podemos aumentar el tamaño de esta imagen?” o “¿podríamos cambiar este formulario de posición?” es que vamos por el buen camino. Estos ajustes de poco calado deberíamos realizarlos ya sobre el navegador.
Hasta que los componentes diseñados no se transfieren al navegador, debemos considerarlos como hipótesis de trabajo. Es el comportamiento en el navegador quien los valida definitivamente.
Trabajando en el navegador se pueden probar:
- Distintas resoluciones de pantalla.
- Distintas longitudes de los literales.
- Distintos tamaños de las imágenes.
- La interacción y las animaciones.
- El rendimiento.
Técnica para compartir el CSS y el JavaScript del front-end
Marcelo Somers escribió un post en el que compara diversas técnicas para compartir y coordinar librerías de componentes.
Una de las técnicas más sencillas de implementar es la de proporcionar URLs con las versiones de los archivos CSS y JavaScript del front-end.
Ejemplo: http://mycdn.com/1.3.5/styles.css
Los nombres de los componentes deben ser independientes del contexto
Por ejemplo “carrusel” en lugar de “carrusel home”. Así podrá ser utilizado en cualquier página. No solo en el home.
Por ejemplo “panel” en lugar de “panel de producto”. Así podrá ser utilizado para contener productos, pero también promociones, localizaciones de tiendas, etc.
En resumen, si los nombres de los componentes son agnósticos del contexto, serán más portables, reusables y versátiles.