Atomic Design para dummies
Recientemente en Interactius hicimos un proyecto interno que consistía en estudiar la viabilidad de incorporar un design system en nuestra metodología de trabajo. La intención era agilizar el proceso de diseño y preparar unos entregables que faciliten la maquetación del front-end. Hicimos una investigación conjunta entre Alexandre Cuadrado y Aleix Martí, y los resultados nos parecieron suficientemente interesantes como para compartirlos aquí. Hemos decidido dividirlo en 2 partes: en esta primera haremos una introducción a los design systems y Atomic Design; en la segunda parte, que publicaremos próximamente, explicaremos cómo implantar la metodología y una forma de facilitar el paso del diseño a la implementación front-end.
Design Systems
Un design system es un conjunto de componentes que se pueden reutilizar en diferentes combinaciones, permitiendo escalar fácilmente el diseño de una interfaz digital.
Los design systems no son nada nuevo, de hecho están muy integrados en nuestro día a día. Veamos un par de ejemplos:
LEGO©: con sólo 6 piezas de 4x2 del mismo color se pueden crear nada más y nada menos que 915,103,765 combinaciones distintas. Si un pack viene con varias piezas de distintas formas y colores, imaginad la cantidad de formas distintas que pueden crearse.
Pizza al gusto: muchas pizzerías, además de tener las pizzas de la carta, también permiten crear tu propia pizza: mezclando distintos tamaños de masa (pequeña/media/familiar) y todo tipo de ingredientes, pueden salir innumerables combinaciones.
¿Entonces, de qué estamos hablando? La novedad no son los Design Systems en sí, sino la forma de aplicarlos en el diseño de productos digitales: sitios web, aplicaciones, etc. Esto nos da una serie de ventajas a tener en cuenta a la hora de diseñar.
Escalabilidad: si se está diseñando un producto con, digamos 200 pantallas, ¿se van a diseñar todas desde cero? ¿No sería mejor poder reaprovechar algunas partes a medida que el proyecto vaya creciendo? Un Design System permite hacerlo de forma fácil.
Consistencia: sigamos con el ejemplo anterior. A medida que el proyecto va creciendo puede resultar fácil llegar a inconsistencias y tener varios tipos de botón que hacen lo mismo, pero con estilos completamente distintos. Un Design System ayuda a mantener la consistencia de los elementos.
Eficiencia: si se tiene una guía unificada donde todos los implicados (desde los diseñadores UI/UX hasta los desarrolladores front-end) pueden consultar los estilos, el trabajo es más rápido y eficiente.
Trabajo en equipo: todos los implicados aportan su parte a la hora de crear un Design System, por lo que se consigue un trabajo en equipo que en otras circunstancias sería complicado que se diera.
Pero más vale una imagen que mil palabras. O en este caso, 4 ejemplos de Design Systems que lo “están petando”.
- El Material Design de Google. Todo el diseño actual de Google está basado en este Design System.
- Atlassian Design Language: de los creadores de Jira y Confluence, entre otros.
- Polaris es otro bastante famoso; se trata del Design System de Shopify.
- IBM Design Language, creado por IBM (¿os suena de algo?).
Tanto en IBM como en Atlassian, no le llaman Design System, sino Design Language, pero el concepto es el mismo. Esos son sólo unos ejemplos, pero hay muchísimos más. En Design Systems Repo se pueden consultar.
Atomic Design
Muy bien: ya sabemos qué es un Design System. Pero, ¿qué es exactamente Atomic Design? ¿Es otro Design System? ¿Es un pájaro? ¿Es un avión? No.
Atomic Design es una metodología ideada por Brad Frost que explica cómo aplicar un modelo mental para crear un Design System de forma eficiente.
La idea viene, según nos cuenta el propio Brad en su libro, de una mezcla de varios conceptos. Veamos cuatro de ellos muy representativos:
Uno de ellos es la famosa cadena de montaje de coches que ideó Henry Ford. Desglosó los coches en piezas y separó la fabricación en módulos, en lugar de fabricar sólo un coche desde cero cada vez.
Otro concepto, este ya más digital y seguramente más familiar, son los UI Frameworks (Bootstrap, Foundation, etc). Básicamente consisten en librerías de elementos preensamblados que proporcionan una base sólida para empezar un diseño o un desarrollo. Aumentan la productividad pero al final todos los productos acaban pareciéndose si no se modifican un poco. Y para modificarlos se puede llegar a invertir mucho tiempo.
También están las guías de estilo. Como indica su nombre, son una guías donde poder consultar todos los elementos visuales del diseño: fuentes, tamaños, colores, paddings… todo lo que se os ocurra. Son indispensables para los desarrolladores front-end, pero también para los diseñadores. Si el proyecto está vivo y va creciendo, es el lugar de consulta para poder mantener la consistencia visual y tener un listado de todas las herramientas que tiene la aplicación.
Finalmente fijémonos en el nombre: Atomic Design. Atomic … átomo … ¿Química? ¡Pues sí! Como veremos a continuación, el nombre se basa ni más ni menos en los átomos, elementos minúsculos que se combinan entre ellos para formar moléculas. ¿Pero en serio hay que estudiar química para entender Atomic Design? No, tranquilos. Pero la analogía se entiende muy bien. En seguida lo veremos.
Aquí vemos la famosa tabla periódica con todos los elementos químicos conocidos. Hasta aquí nada nuevo.
Veamos ahora esta tabla creada por Josh Duck que contiene todos los elementos HTML agrupados según tipos de funcionalidad. Con esta aproximación al mundo digital, la cosa ya empieza a tener un poco más de sentido. Sigamos.
La base de Atomic Design, es la modularidad. Eso nos permite crear estructuras muy diversas combinando y reaprovechando varios elementos de distintas formas. Se trata de reducir los elementos a su expresión mínima e ir combinándolos para ir creando nuevas estructuras más complejas.
Repasemos unos conceptos básicos de química: átomos, moléculas y organismos.
Átomos: son las estructuras funcionales más pequeñas. Cada uno de ellos tiene distintas propiedades y se pueden combinar entre ellos.
Moléculas: átomos unidos por distintos enlaces químicos, obteniendo propiedades únicas y convirtiéndose en elementos más funcionales.
Organismos: conjuntos de moléculas funcionando como una sola unidad (pueden ser desde organismos unicelulares hasta organismos más complejos, como plantas, animales o humanos).
Pues justamente esa es la base de Atomic Design: se trata de una metodología compuesta de cinco etapas distintas (átomos, moléculas, organismos, templates y páginas) que trabajan conjuntamente para crear sistemas de diseño de interfaces de forma estructurada y jerárquica. No se trata de un proceso lineal, sino de un modelo mental que nos ayuda a entender toda la UI como un sistema de partes que interactúan entre ellas.
Así pues, en la ideación de nuestro propio design system, hemos decidido incorporar un elemento nuevo de aún más bajo nivel: los protones.
Veamos en detalle estas etapas. Hemos decidido ilustrarlo con LEGO© porque la analogía se entiende bastante bien.
De izquierda a derecha vemos la evolución de pasar de tener el concepto abstracto de una pieza a tener construida una réplica de la ciudad de Springfield de Los Simpsons.
Protones
No figuran en la teoría de Brad Frost pero se trata de las propiedades que hasta que no convergen no se pueden ver. Para explicarlo de forma sencilla, una forma sin color o un color sin forma. Se entenderá mejor en la seguna parte, cuando expliquemos la aplicación práctica.
Átomos
Los átomos son elementos que no pueden desglosarse en otros sin dejar de ser funcionales, pero cada uno tiene su función básica. Incluyen elementos HTML básicos, como pueden ser:
<label>, <input>, <button>, …
Moléculas
La moléculas son grupos relativamente sencillos de elementos UI que actúan como una unidad. Varios átomos unidos componen una unidad funcional. Podría ser, por ejemplo, un buscador compuesto por una etiqueta o un icono, un campo de entrada y un botón.
Organismos
Los organismos son componentes UI relativamente complejos formados por grupos de moléculas y/o átomos u otros organismos. Éstos forman distintas secciones de una interfaz. Podría ser un header, compuesto por un logo, un menú y un buscador, o un grid de productos de un e-commerce.
Templates
Las templates son objetos a nivel de página, sitúan los componentes en un layout. Se centran más en la estructura de la página que en el contenido final. Son útiles para contrastar tamaños de imágenes (aunque no sean las finales), o para comprobar la longitud de los títulos o los textos. Al trabajar con templates, debe tenerse en cuenta que el contenido puede ser dinámico, emulando el comportamiento final.
Páginas
Las páginas son instancias específicas de un template. Muestran cómo sería la UI final con el contenido real. Es la fase más concreta de Atomic Design, ya que es lo que deberían ver los usuarios finales cuando interactúen con el sistema. Puede contemplarse la posibilidad de mostrar distintas variantes de un template, como contenido para usuarios y administradores, o un listado de actividad reciente según si el usuario es la primera que entra o si ya tiene actividad registrada.
Finalmente podemos ver toda la evolución, ahora ya sin la analogía con LEGO©, aplicado al diseño de una interfaz digital.
En resumen, el objetivo es crear una librería de pequeños elementos reutilizables y combinables entre ellos para tener un sistema de diseño rápido, uniforme, modular y escalable.
Y por el momento lo dejaremos aquí. Hemos visto qué son los Design Systems y qué es Atomic Design (con un pequeño añadido). En la segunda parte veremos cómo aplicarlo utilizando Sketch por la parte UI y BEM CSS para la maquetación del front-end. ¡Estad atentos!
Sígueme!
Si te ha gustado el artículo, recuerda que puedes dar hasta 50 aplausos en menos de 10 segundos. Y en los comentarios puedes dejar dudas, sugerencias o simplemente saludar.
