Atomic Design al revés: la pantalla es el yacimiento, no el plano

Artículo original en inglés: Entering Atomic Design from the screen, de Sepeda Rafael en UX Collective.

Hay dos formas de entender un edificio. La del arquitecto, que parte de un solar vacío, dibuja cimientos, levanta pilares y acaba poniendo el tejado. Y la del arqueólogo, que llega al yacimiento con el edificio ya construido (y a menudo medio derruido) y tiene que deducir, capa a capa, por qué cada piedra está donde está. Atomic Design, la metodología que Brad Frost popularizó en 2013, se ha enseñado siempre como arquitectura: átomos, moléculas, organismos, plantillas, páginas. En ese orden. Con esa pulcritud. El problema es que casi nadie trabaja así.

El manual dice “de abajo arriba”; la realidad dice “ya tenemos cuarenta pantallas”

Sepeda Rafael parte de una observación que cualquiera que haya trabajado en un producto con más de dos años de vida reconocerá: el sistema de diseño no se funda, se excava. Llegas a un equipo y la aplicación ya existe. Hay tablas de administración, filtros, pestañas, paginadores y tooltips repartidos por decenas de vistas. Nadie va a borrar todo eso para empezar por el botón primario. Y sin embargo, la literatura de sistemas de diseño sigue insistiendo en que primero se definen los tokens, luego los componentes básicos y, al final, las pantallas.

El autor recuerda algo que se ha olvidado por el camino: Frost nunca planteó sus cinco niveles como una secuencia. Eran un modelo mental para ver el todo y las partes a la vez. La linealidad se la hemos añadido nosotros, probablemente porque los esquemas de cinco pasos quedan muy bien en una presentación. La práctica, en cambio, es circular, sucia y empieza siempre por lo que hay delante: la pantalla.

El inventario te dice qué hay; no te dice por qué

La herramienta clásica para abordar un producto existente es el inventario de interfaz, también de Frost, o el taller de recorte de componentes de Nathan Curtis. Capturas pantallas, las despiezas, agrupas los pedazos parecidos y obtienes un catálogo. Es un buen comienzo y un pésimo final. Un inventario te dice que hay catorce variantes de botón, pero no explica qué conecta a cada uno con los datos que mueve.

Aquí el artículo introduce su idea más útil: el alcance. Antes de catalogar nada, pregúntate qué puede hacer el usuario en esa pantalla y qué cambia con cada acción. Un botón de ordenar vive en la cabecera de una columna, pero reordena el conjunto entero de datos. Un filtro ocupa un rincón de la barra de herramientas, pero decide qué registros existen para el resto de la vista. La posición engaña; el alcance no. Los elementos se relacionan por lo que afectan, no por dónde están sentados.

El arqueólogo no clasifica las piedras por su tamaño. Las clasifica por la función que cumplían en el edificio que ya no está.

Cada regla tiene un dueño (y casi nunca es el componente)

Una vez identificado el alcance de cada acción, toca decidir dónde vive la lógica. Y aquí Rafael propone una higiene que a muchos equipos les vendría bien: los componentes reutilizables deben seguir siendo presentacionales, tontos en el buen sentido, sin conocimiento del contexto. Las reglas que conectan zonas y se repiten entre pantallas (al cambiar un filtro se reinicia la paginación, por ejemplo) pertenecen a la plantilla. Las reglas específicas de una sola pantalla y de sus datos pertenecen a la página.

Esto convierte la plantilla, el nivel más despreciado de la jerarquía de Frost, en el protagonista. Deja de ser un esqueleto de maquetación y pasa a comportarse como un envoltorio inteligente: define zonas, sus conexiones, el estado compartido y las reglas de contexto. La misma plantilla (cabecera, zona de acción principal, navegación, barra de herramientas, área de contenido) puede servir para la vista de Miembros, la de Proyectos y la de Facturas. Cambia el contenido; la estructura y las reglas de convivencia se mantienen.

El aviso que acompaña a esta idea es importante: una plantilla que sabe demasiado de una pantalla concreta deja de ser reutilizable. Es la misma tentación que lleva a adaptar un componente genérico a un caso particular “solo por esta vez”. Tres veces después, tienes cuatro componentes casi iguales y ningún sistema.

Lo que se rompe te está enseñando algo

Me gusta especialmente la fase final del método: someter el despiece a contenido real. Resultados vacíos, estados de carga, pantallas pequeñas, textos larguísimos. Si algo se rompe, casi siempre es porque hay un estado sin dueño, una regla que nadie asignó a ningún nivel. En arqueología, las grietas del muro revelan dónde estaba la puerta tapiada. En diseño de producto, el estado vacío que nadie diseñó revela el componente que nadie pensó.

El autor también es honesto con los límites. Para una landing, una pantalla de login o un formulario de ajustes sencillo, este análisis de alcance es matar moscas a cañonazos: un inventario tradicional llega al mismo sitio en la mitad de tiempo. El método brilla en productos existentes con muchas pantallas parecidas (paneles de administración, dashboards, zonas de configuración) y en equipos que llevan meses discutiendo dónde acaba un componente y dónde empieza el siguiente.

Por qué esto importa más a los equipos pequeños

La enseñanza de Atomic Design como arquitectura ha favorecido, sin querer, a las grandes organizaciones. Son las únicas que pueden permitirse un equipo de sistema de diseño dedicado, con tiempo para fundar tokens y construir desde cero. Un estudio de cinco personas o un equipo de producto que hereda una aplicación no tiene ese lujo. Tiene pantallas. Y tiene que extraer de ellas un sistema sin parar la producción.

Entrar en Atomic Design desde la pantalla legitima lo que estos equipos ya hacen a escondidas, con mala conciencia, como si estuvieran incumpliendo el manual. No lo incumplen: lo están leyendo en el único orden posible para alguien que llega tarde. Y llegar tarde es la condición normal de casi todo el mundo que trabaja en software.

Si Frost dibujó el plano, Rafael entrega la paleta y el pincel. Ambas cosas sirven para entender un edificio. Pero solo una de ellas funciona si el edificio ya está habitado y hay gente dentro trabajando.