La forza dell’Atomic Design
Cambiare la logica dei prodotti digitali, cambiando la metafora con cui li concepiamo.
Da anni ci occupiamo di progettare e sviluppare prodotti digitali, che si tratti di siti web, app o portali aziendali.
Un po’ per la natura evolutiva di questo tipo di prodotto, un po’ per la propensione esplorativa del nostro team, ci piace sperimentare continuamente con nuovi strumenti e metodi per affinare il processo progettuale, riuscendo da un lato a gestire meglio i tempi, gli attori coinvolti e la produzione e dall’altro a migliorare la qualità del prodotto finale.
In particolare con questo articolo vogliamo raccontare il metodo che abbiamo testato (e di cui ci siamo appassionati subito) su una fase specifica del processo progettuale: la messa a terra del prodotto, nonché la sua costruzione vera e propria.
(A proposito, se doveste chiedervi perché parliamo in prima persona plurale, il motivo è che l’articolo è stato scritto a 4 mani, di cui 2 sono di Nicola Gubernale)
Quali erano gli obiettivi a cui puntavamo?
Quello che stavamo cercando era un modo per rispondere a 3 esigenze chiave che caratterizzano la maggior parte dei prodotti digitali:
Solidità e opportunità di sviluppi futuri
Creare prodotti destinati a durare nel tempo, predisposti a evolvere e crescere adattandosi alle esigenze con facilità, senza la necessità di rework o adattamenti onerosi.Efficienza e allineamento
Per far sì che un progetto evolva velocemente è necessario che i diversi attori coinvolti (per esempio designer e sviluppatori) possano lavorare per task in contemporanea, su un terreno comune e parlando la stessa lingua.Collaborazione
Agevolare il team creando le condizioni giuste perché possa essere flessibile, ovvero facilitando l’ingresso di collaboratori anche a progetto iniziato, senza compromettere la coerenza — quindi l’usabilità — del prodotto.
L’atomic design
Già da tempo si sente parlare di Design System e online si trovano molti materiali a supporto, come articoli, semilavorati, esempi famosi (fra questi Material Design, Polaris, Atlassian), ma ciò che serviva a noi era soprattutto una metodologia semplice per costruirne uno da zero.
E così, un po’ perché ci piaceva la metafora, un po’ perché ci piaceva l’approccio, siamo stati attratti come dei piccoli elettroni dall’atomic design, teorizzato da Brad Frost nel 2013.
Si tratta di un metodo progettuale che facilita la creazione di un Design System grazie all’applicazione di un modello di ordinamento derivato dalla chimica e basato sull’individuazione di atomi, molecole e organismi come elementi base costitutivi di un’interfaccia.
Il concetto che sta alla base di questo ordinamento è quello della modularità object-based: l’interfaccia viene scomposta nelle sue parti più piccole (atomi) che vanno poi a ricomporsi in livelli di complessità crescenti per formare prima molecole (componenti) e organismi (macro-componenti) e poi le “pagine” (gruppi di componenti organizzati secondo uno specifico template).
“Questa operazione facilita la progettazione perché tende ad individuare i piccoli singoli problemi che si nascondono nei sottoproblemi. Risolti i piccoli problemi uno alla volta […] si ricompongono in modo coerente secondo tutte le caratteristiche funzionali per ogni singola parte e funzionali tra loro…“
Bruno Munari, Da cosa nasce cosa
Uno dei vantaggi principali dell’applicazione di questo metodo è il superamento della metafora della pagina per come la conoscevamo. L’idea che il web fosse composto da “pagine” è stata utilissima nei primi decenni di vita degli oggetti digitali: era facile e immediata, tutti avevano dimestichezza con l’idea di pagina.
Nel tempo però il supporto attraverso il quale accediamo al web è cambiato: se agli albori di internet i contenuti erano veicolati unicamente attraverso lo schermo del computer, oggi la varietà dei supporti con cui accediamo alla rete è pressoché sconfinata e questa metafora inizia ad essere limitante per i designer e per gli sviluppatori.
L’Atomic Design ci offre un’alternativa al concetto statico di pagina. Infatti, partendo dalla progettazione degli elementi più piccoli per arrivare a quelli più complessi, riusciamo a trattare ogni parte dell’interfaccia come se fosse viva e a definirne non solo l’aspetto, ma anche anche il comportamento che avrà a seconda delle esigenze, per esempio come si trasformerà se la fruisco da un portatile 15 pollici, oppure da uno smartphone, oppure da un altro modello di smartphone, e così via.
Questo ci garantisce da un lato la coerenza e la solidità dell’interfaccia in tutte le possibili configurazioni e dall’altro agevola l’interazione tra designer e developer, dal momento che negli ultimi anni anche il mondo del front-end developing si è spostato su logiche object-based per sfruttare a pieno la possibilità del riutilizzo, risparmiando tempo e mettendosi al riparo da eventuali bug.
La nostra esperienza con mentorXchange
Nel 2019 abbiamo avuto l’opportunità di supportare una startup inglese, mentorXchange, che ci ha permesso di mettere in campo le teorie apprese dall’atomic design. Infatti, in quanto startup, una delle sue necessità fondamentali era quella di ottenere velocemente un prodotto funzionante da mostrare ai propri utenti e ai potenziali clienti, con la duplice finalità di validare l’idea di business e poterla sviluppare ulteriormente.
Attraverso una piattaforma web, mentorXchange promuove la cultura della collaborazione e della crescita personale all’interno delle aziende. Questo prodotto abilita la creazione di connessioni tra i colleghi di una stessa azienda con lo scopo di scambiarsi esperienze e conoscenze su temi specifici: gli utenti possono pianificare degli incontri, dare e ricevere feedback, accedere a contenuti di ispirazione e tracciare i propri progressi.
Come è andata?
Dopo aver co-progettato con mentorXchange il concept, il business model e le macro-funzionalità della piattaforma, le premesse per affrontare il design dell’esperienza e dell’interfaccia (UX e UI) erano le seguenti:
- tempi stretti;
- dovevamo definire contemporaneamente le funzionalità di dettaglio, elaborare la UX e la UI e portare avanti lo sviluppo;
- ciò che stavamo realizzando era solo il cuore di un prodotto più complesso, che successivamente avremmo lasciato nelle loro mani o comunque in quelle di altri collaboratori, per ulteriori sviluppi.
Viste le evidenti esigenze di velocità, flessibilità e modularità richieste da questo progetto abbiamo subito visto nell’Atomic Design l’approccio ideale. Nei prossimi paragrafi descriveremo passo passo il procedimento che abbiamo seguito.
Prima della scomposizione…
1 • L’identità prima di tutto: il branding
Prima di partire con la progettazione del design system, ci siamo dedicati alla fase di branding per definire l’identità del prodotto: design del logo, creazione della palette colore, definizione degli stili di testo, scelta del tone of voice e così via.
A meno che il cliente non disponga già di un brand manual, questa attività è essenziale perché costituisce la base da cui derivare gli elementi del nostro design system.
2 • Wireframe come mappa comune
Parallelamente al design del brand abbiamo iniziato a delineare i primi wireframe, sulla base della lista di funzionalità che era emersa nelle prime fasi di ricerca e co-design con il cliente.
Il wireframe è stato il nostro mezzo principale per descrivere il flusso di esperienza dell’utente, il funzionamento delle micro-feature, l’architettura delle informazioni, la struttura dei template e i breakpoint secondo i quali l’interfaccia si sarebbe riconfigurata conformemente con il supporto di fruizione.
Il livello di profondità dei wireframe può essere diverso a seconda del tipo di progetto o di fase progettuale. Nel nostro caso, trattandosi di una piattaforma con molte interazioni, abbiamo scelto di addentrarci in ogni dettaglio dell’esperienza, lasciando fuori da questa visualizzazione solo la veste grafica.
Per mentorXchange abbiamo disegnato oltre 130 wireframe e questo ci ha permesso di condividere e validare ogni ragionamento con gli sviluppatori del nostro team e con il cliente senza dover continuamente curare l’aspetto e la coerenza estetica delle schermate e risparmiando quindi molto tempo.
…La scomposizione…
3 • L’analisi delle particelle
Una volta che il disegno dei wireframe era giunto a un livello tale da consentirci di avere un’idea chiara dell’esperienza utente e una volta ottenute le prime approvazioni da parte del cliente, abbiamo iniziato ad impostare il lavoro sul Design System partendo dall’analisi particellare dell’esperienza, ovvero abbiamo analizzato gli elementi presenti nei wireframe per individuare e stilare un elenco di atomi, molecole e organismi.
L’ingrediente segreto di questa attività è stata la collaborazione sinergica tra designer e sviluppatori: infatti, perché sia efficace, la lista di componenti dovrà corrispondere sia alla struttura del file di lavoro di design (es. il file .sketch) sia alle logiche di costruzione del codice.
Una piccola parentesi per i più tecnici:
Metodologie come OOCSS, SMACSS e BEM si caratterizzano sostanzialmente per essere tecniche di naming per gli ID delle classi. Nella prassi comune il rischio è che se vengono assegnati nomi generici a diversi elementi e successivamente, utilizzando CSS, viene scritta una regola di stile per uno di essi, la nuova regola rischia di agire anche su elementi di cui non era prevista la modifica. La metodologia BEM per esempio dice: diamo un ID a un componente, tipo “header”, e poi tutte le cose che appartengono a HEADER devono avere il nome HEADER all’inizio, seguito da __ (doppio underscore) e poi il nome dell’elemento (es. logo) → header__logo. In questo modo non si generano conflitti e c’è un grado maggiore di controllo sulle modifiche. Ecco perché è essenziale destinare alle prime fasi di definizione del nostro sistema un tempo adeguato e la giusta perizia.
…La composizione
A questo punto siamo arrivati al nostra fase preferita, quella di ricomposizione dell’interfaccia, nonché di progettazione vera e propria della UI.
4 • Partire dal piccolo: il design delle particelle
Guidati dalle teorie di Frost, siamo partiti dal design degli atomi, molecole e organismi. Nel frattempo abbiamo costruito la style guide (stili dei font e palette colori) e perfezionato i breakpoint e le griglie dei template.
5 • La dimostrazione scientifica: testare continuamente
Questo processo naturalmente non è stato lineare, soprattutto all’inizio della progettazione. Infatti, man mano che i componenti erano pronti, li componevamo per ottenere esempi di “pagine” con contenuti realistici, in modo da valutarne velocemente l’efficacia ed eventualmente migliorarli.
Perché ci è piaciuto lavorare così e vorremmo farlo sempre?
I vantaggi che abbiamo riscontrato nell’utilizzare questo metodo hanno toccato diversi aspetti del prodotto e della gestione del progetto e sono stati preziosi per tutto il team coinvolto: designer, PM, sviluppatori, cliente.
Scalabilità del prodotto
Anche se abusato e a volte usato a sproposito, “scalabile” è in questo caso l’aggettivo che meglio descrive il tipo di prodotto che si riesce ad ottenere lavorando con l’atomic design.
Questa caratteristica permette di ottimizzare gli sviluppi futuri di un prodotto e si sposa perfettamente con un approccio incrementale che parte da un MVP per andare velocemente sul mercato e per comprendere il prima possibile i reali bisogni degli utenti, in modo da basare su di essi le fasi successive.
Solidità versatile
Investire nell’analisi e scomposizione dell’interfaccia in atomi, molecole e organismi ci ha permesso di creare un sistema solido, ma versatile, in cui tutte le parti sono guidate da un’unica logica. Ciò si è tradotto in un processo progettuale dove, man mano che si procedeva con lo sviluppo, riuscivamo ad ottenere in modo quasi naturale:
- Maggiore possibilità di riutilizzo dei componenti
- Riduzione notevole di bug
- UI e UX coerenti
- Velocità nell’accogliere nuovi requirements e modificare funzionalità già implementate
Team compatto e aperto
Per utilizzare questo metodo è stato indispensabile che tutto il team di lavoro — in particolare designer e sviluppatori — impostasse il proprio lavoro (linguaggio di programmazione e file grafici) utilizzando una logica orientata agli oggetti.
Stabilito questo linguaggio comune, è stato semplice collaborare fin da subito per definire insieme la granularità dei vari componenti e quindi le fondamenta del prodotto.
Ed è proprio grazie a queste regole condivise che siamo riusciti ad agevolare le interazioni all’interno del team (anche facilitando l’ingresso di nuovi componenti nei momenti più intensi) e generare un output coerente con le aspettative del cliente e con quelle di tutto il team di lavoro.
Scalabilità, versatilità, velocità e team allineati sono gli ingredienti essenziali per la sopravvivenza di una startup, ma — considerando il contesto di innovazione continua nel quale siamo immersi — sono diventati gli ingredienti essenziali per lo sviluppo di qualsiasi prodotto digitale ed è per questo che l’atomic design è un metodo che può interessare tutti i tipi di azienda.
Se vuoi saperne di più o scambiare con noi qualche pensiero, scrivici a
✉️ innovation@h-farm.com
