Indice articolo

Il Design Atomico è una metodologia di design introdotta da Brad Frost circa 6 anni fa,  questo metodo però nasce ancora molto prima in altri ambiti come l’architettura e il design industriale, ma in questo articolo ci fermiamo al design applicato alle interfacce web e al vantaggio che ci può portare questo approccio.

Il designer statunitense Brad Frost per spiegare questa metodologia  prende spunto dalla chimica e si basa sul concetto di scomposizione, ogni materia è scomponibile in atomi che a loro volta si uniscono per formare le molecole e poi organismi più complessi. 

Nelle interface web questo significa la “rottura” di un layout nelle sue parti più piccole che puoi vengono riutilizzate. Vediamolo più nello specifico.

Questo metodo si basa su 5 livelli distinti:

Atomi

In natura gli atomi sono i mattoni fondamentali della materia. Applicati alle interfacce Web sono gli elementi più astratti come palette di colori, caratteri, un campo da input, pulsanti ecc.

Questi elementi da soli sono abbastanza inutili, diventano utili come riferimento nel contesto di una libreria.

Molecole

Le molecole sono gruppi di atomi legati insieme, nel nostro caso sono i componenti che conosciamo (un campo di input con un pulsante forma una form). Anche questi elementi spesso da soli sono inutili ma soltanto assemblandoli  possiamo effettivamente fare qualcosa.

Organismi

Combinandole insieme le molecole creano i cosiddetti organismi. Gli organismi sono gruppi di molecole uniti per formare una sezione relativamente complessa e distinta di un’interfaccia. Può essere un esempio la header bar:

Pattern

I template o Pattern , sono costituiti principalmente da gruppi di organismi assemblati insieme per formare delle pagine. Sono più concreti e forniscono un contesto a tutte queste molecole e organismi relativamente astratti. Corrispondo a quelli che noi conosciamo come “wireframe”, quindi dei layout abbozzati che ci aiutano a capire la disposizione degli elementi all’interno della pagina.

Pagine

Le pagine sono istanze specifiche di Pattern . I placeholder vengono sostituiti con contenuti reali per fornire una rappresentazione accurata di ciò che un utente vedrà in definitiva. Corrispondono quindi ai mockup, rappresentano il design definitivo e il risultato che si intende ottenere.

Perchè Atomic Design?

Abbiamo visto in grandi linee le 5 fasi del design atomico. In sintesi, questo approccio ci permette di passare da un concetto astratto ad uno concreto. Si basa sulla scomposizione dell’interfaccia nella sua unità più piccola.

Questa  metodologia è particolarmente  adatta ad un sistema modulare. Un sistema modulare è composto da parti (pattern) riutilizzabili e intercambiabili e si adatta in particolare ai prodotti su larga scala come siti web di e-commerce siti di finanza ecc,  a differenza di un un sistema integrato che è focalizzato su un unico contesto (sono i prodotti che hanno pochissime parti ripetitive, ad esempio campagne di marketing, portafogli o blog personali).

Come può essere applicato a Sme.UP ?

In realtà, questo approccio la stiamo già applicando con i componenti (riutilizziamo gli stessi componenti per la creazione di schede diverse).  Tutto ciò però non ci permette ancora di ottenere un sistema coerente  in tutte le sue parti.  Il risultato è che abbiamo un comportamento ed un’esperienza di uso diversa per ogni UPP.

*Esempio di esperienza di uso simile:  Microsoft Office, il modo di salvare un documento in Word o in Power Point è lo stesso. Questo vuol dire che l’utente che sa usare Excel ha anche le basi per usare Power Point,  anche se sono due prodotti molto diversi tra loro dal punto di vista del risultato che si vuole raggiungere.

L’obiettivo è quello di costruire un sistema di design basato sui pattern  che possano costituire la base nella creazione della UI di una UPP. Questo significa scomporre la UPP in “pagine”  e creare dei layout astratti che possono essere riutilizzate da UPP diverse.

esempio di sistema di componenti e sistema di pattern (layout astratti creati combinando i vari componenti):

Esempio dello stesso Pattern con più varianti:

Pattern 1 dashboard oggetto – variante 1.1 (se l’oggetto ha l’immagine ); variante 1.2 (quando l’oggetto non ha l’immagine); variante 1.3 (quando si devono mostrare dati importanti e/o il nome dell’oggetto occupa molto spazio).

Pattern 2 dashboard UPP – variante 2.1 (navigazione a tab); variante 2.2 (dashboard divisa in macro categorie)…ecc

Pattern 3 Modalità modifica

Pattern 4 Azioni di un oggetto

ecc

Esempio Pratico: Use Case

Assemblando i diversi pattern, possiamo creare degli use case, in pratica uno use case è una sequenza di pattern che realizzano uno specifico percorso di navigazione.

Abbiamo provato a creare due use case diversi di UPP diverse utilizzando gli stessi pattern:

USE CASE UPP dei Ticket – modifica di un Ticket

USE CASE UPP Formazione – modifica di un corso

Tabella di consultazione dei use case

Per la consultazione dei pattern  abbiamo pensato alla creazione di una serie di use case come quello mostrato sopra che servono da esempio per l’utilizzo.

La tabella potrebbe essere costruita in questo modo:

Conclusioni

L’obiettivo di questo progetto (ancora in fase di sviluppo)  è  di  aiutare  chi conosce la parte di processi gestionali nella costruzione della UI mettendo a disposizione una serie di modelli già pronti come esempio.