Il linguaggio del design modulare

Mentre molti di noi smettono di progettare pagine per progettare sistemi, continua a saltare fuori un concetto: la modularità. Sentiamo spesso parlare dei benefici di un approccio modulare: i moduli sono scalabili, sostituibili, riutilizzabili, facili da testare, rapidi da mettere insieme… “Sono proprio come il LEGO!”

Sulle prime, la modularità potrebbe sembrare un concetto semplice, ma farla funzionare per il vostro team richiede degli sforzi e un impegno significativi.

Le sfide più grandi poste dalla modularità sono tutte le decisioni che devono essere prese: quando riutilizzare un modulo e quando progettarne uno nuovo, come rendere i moduli sufficientemente distinti, come combinarli, come evitare duplicati con i moduli che altri designer e team creano e così via. Quando si rende modulare un design esistente o se ne crea uno nuovo, non è sempre chiaro da dove cominciare.

Cominciate dal linguaggio#section1

Il linguaggio è fondamentale per collaborare. Nel suo libro How to Make Sense of Any Mess, Abby Covert dice che l’ostacolo più grande che un team si trova ad affrontare è la mancanza di un linguaggio condiviso. Per aiutare a stabilire quel linguaggio condiviso, suggerisce di discutere, esaminare e documentare le nostre decisioni ontologiche sotto forma di “vocabolari controllati”.

In breve, dovremmo cominciare dal linguaggio, non dalle interfacce.

Da circa un anno ormai, il nostro team in FutureLearn, una piattaforma di open education, sta sperimentando con l’approccio modulare. Vorrei condividere alcuni modi che abbiamo provato per perfezionare un linguaggio condiviso per aiutare il nostro team a passare al design modulare.

Create una pattern library come team#section2

Uno dei primi esperimenti con la modularità è stato un tentativo di redesign della nostra homepage. Un visual designer ha creato delle parti modulari, poi noi abbiamo fatto un workshop in cui abbiamo cercato di organizzare i moduli in comp. Questo è quello che pensavamo (forse ingenuamente) fosse un “processo di design modulare”.

Uno dei nostri primi esperimenti con la modularità.

Alla fine avevamo tre design che sarebbero diventati prototipi completamente funzionanti, ma anche se è stato un esercizio utile, il risultato non è stato davvero modulare:

• i moduli non erano chiaramente definiti;
• non avevano funzioni chiare: le differenze tra loro spesso erano semplicemente estetiche;
• non li abbiamo standardizzati e non gli abbiamo dato un nome;
• non abbiamo ragionato molto sul modo in cui sarebbero stati riutilizzati.

In definitiva, abbiamo deciso di non usare i design risultanti. Questi esperimenti sono stati utili per spingerci in una forma mentale modulare, ma lo step di definizione che ci avrebbe portato a pensare modularmente stava passando attraverso il processo di creazione di una pattern library come team, che ha occupato vari mesi (e che è ancora in corso).

La metodologia dell’atomic design sperimentata per primo da Brad Frost è stata la nostra base. In quel momento abbiamo cominciato ad osservare la UI, a smontare l’interfaccia, a fare degli inventari e a definire gli elementi principali e i pattern che abbiamo usato per creare nuove pagine.

Una volta avuta una library, eravamo preparati meglio per pensare al design in termini di componenti distinte e riutilizzabili. Fino ad allora, anche dopo tutti i nostri esperimenti, stavamo ancora pensando in termini di pagine.

Assegnate in maniera collaborativa i nomi alle cose, basandovi sulla loro funzione di alto livello#section3

Una volta che avete le basi, è importante creare su queste facendo evolvere il linguaggio come team. Una parte importante di questo processo è dare un nome alle cose che create.

Immaginatevi di avere un semplice componente la cui funzione è di persuadere le persone a fare uno specifico corso online. Come lo chiamereste?

Componente UI che promuove un corso online su FutureLearn.

Il nome dipende dalla funzione del componente e dal modo e dalla posizione in cui appare nell’interfaccia. Alcune persone, per esempio, potrebbero chiamarlo “image header” o “course promo”.

James Britton, un insegnante britannico molto noto, spiega in Language and Learning che conferendo nomi agli oggetti, ci impegniamo in un “processo in cui li portiamo in vita”, proprio come i bambini utilizzano il linguaggio per “portare in vita, per togliere dalla non esistenza” il mondo che li circonda. In maniera simile, se un oggetto nell’interfaccia non ha un nome, un nome che abbia senso per il vostro team e che è conosciuto ed usato dalle persone del vostro team, allora non esiste come modulo concreto su cui agire e con cui lavorare.

Una volta che avrete dato un nome a un oggetto, gli avrete dato un futuro. Per esempio, se gli date un nome “presentational”, il suo futuro sarà limitato perché sarà attinente solo ai suoi stili. Un nome funzionale potrebbe andare meglio, ma i nomi funzionali richiedono più ragionamento ed è più difficile arrivarci, perché la funzione potrebbe essere relativa. Per esempio, abbiamo quasi chiamato il componente di cui sopra “course poster” perché aveva un’immagine di sfondo del co

Nel processo di assegnazione di un nome a un elemento, si elabora tutti insieme come gruppo la funzione e si raggiunge un accordo. Non è tanto dare un grande nome a qualcosa (anche se, ovviamente, è un ideale a cui aspirare), quanto essere d’accordo sul nome. Questo determina il modo in cui sarà usato l’elemento e contribuisce ad assicurare che venga usato da tutti in maniera consistente.

rso e la sua funzione era quella di promuovere il corso. Non era un nome sbagliato (in effetti era quasi funzionale), ma era anche limitante.

Più o meno allo stesso momento, per un altro progetto, un designer diverso aveva introdotto un componente che sembrava (salvo alcune variazioni minori nel layout e nella tipografia) piuttosto simile al nostro “course poster”.

Componente UI che invita gli studenti a prendere parte a una discussione.

La funzione del nuovo componente era quella di invitare le persone a prendere parte a una discussione. Quindi, il primo pensiero che c’è venuto in mente è stato di chiamarla “discussion”. Sulle prime, nessuno aveva creato una connessione con “course poster”, perché il suo nome l’aveva limitata ad una specifica funzione – promuovere corsi – e la funzione di “discussion” aveva poco a che fare con essa.

Se avessimo dato a quelle componenti i nomi a cui avevamo inizialmente pensato (“course poster” e “discussion”), saremmo finiti con due moduli con nomi diversi ma praticamente identici e non riutilizzabili. Certe sviste possono portare a dei duplicati e a delle inconsistenze, che minano la modularità.

Sebbene la loro funzione possa apparire diversa sulle prime, se guardate ai vari usi di queste componenti nel conteso o se addirittura immaginate i potenziali casi d’uso, è più semplice vedere che entrambe fanno cose analoghe: fungono da parti che attraggono l’attenzione. Comandano le call to action principali su quelle pagine. In altre parole: la loro funzione ad alto livello consiste nel focalizzare l’attenzione degli utenti sull’azione più importante.

Una componente billboard in uso.

Alla fine, abbiamo creato una singola componente chiamata “billboard”. I billboard non sono vincolati dalla loro posizione sulla pagina o dal loro contenuto o dal loro aspetto. Possono apparire o con un’immagine come sfondo o come parte del contenuto. La cosa importante è la loro funzione ad alto livello e che tale funzione ad alto livello sia compresa allo stesso modo da diverse persone nel team.

Esempio di una componente billboard con un’immagine come parte del contenuto.

Nel processo di assegnazione di un nome a un elemento, si elabora tutti insieme come gruppo la funzione e si raggiunge un accordo. Non è tanto dare un grande nome a qualcosa (anche se, ovviamente, è un ideale a cui aspirare), quanto essere d’accordo sul nome. Questo determina il modo in cui sarà usato l’elemento e contribuisce ad assicurare che venga usato da tutti in maniera consistente.

Rendete il linguaggio del design parte della cultura quotidiana#section4

Assegnare dei nomi alle cose in questo modo potrebbe richiedere più tempo, almeno inizialmente, perché non è ancora un’abitudine. Rendere il processo più familiare richiede uno sforzo e un impegno in più da parte dell’intero team.

Un modo per far sì che avvengano le discussioni sul linguaggio consiste nel creare uno spazio fisico per queste all’interno dell’ufficio.

Uno spazio del nostro ufficio in cui spesso si fanno discussioni sul linguaggio.

Le funzioni ad alto livello sono più semplici da definire se avete stampato l’intera UI e se è comprensibile a colpo d’occhio. In questo modo, è anche molto più facile trovare duplicati ed inconsistenze.

Anche Slack o altri client sono un una strada percorribile per fare queste discussioni. Per esempio, può essere utile postare dei nuovi elementi che avete appena introdotto o quelli esistenti che sospettate siano inconsistenti o potenzialmente dei duplicati, e poi provare a trovarne la funzione e un nome adatto. Quando pensate ai nomi, aiuta avere un punto di riferimento comune: il nostro team prende spesso in prestito dei termini da altri settori quali l’editoria o l’architettura, per trarne delle idee.

Una tipica discussione sui nomi su Slack.

Tenere vivo il linguaggio del design rendendolo parte delle nostre conversazioni quotidiane, sia di persona sia da remoto, gioca un ruolo fondamentale nel mantenere la modularità all’interno del nostro team.

Definite l’architettura del CSS nella fase di design#section5

Non c’è bisogno di dirlo, ma raggiungere il consenso può essere difficile. Per esempio, potremmo non essere d’accordo sul fatto se riutilizzare o meno un modulo esistente, personalizzarlo per un contesto specifico o creare un nuovo componente.

Sono stati scritti molti articoli sull’assegnamento di stili ai componenti UI basandosi sul contesto, ma Harry Roberts ha suggerito che “dover cambiare l’estetica di una componente in un certo contesto è Design Smell”, un segnale che il vostro design sta fallendo. Come possiamo evitare che accada?

Ci può aiutare cercare di standardizzare gli elementi nella fase di design, prima di realizzarli. In altre parole, cominciando dal linguaggio del design. Questo significa che gli sviluppatori devono capire perché le cose siano progettate in un certo modo e i designer devono sapere in che modo i moduli verranno costruiti, così che possano migliorarli senza dover creare una versione diversa del modulo.

Prima di scrivere il CSS è utile che designer e developer capiscano lo scopo di ogni elemento che creano. Potrebbero cominciare col fare moltissime domande: “Questo modulo sarà sempre a larghezza piena? Perché? Ci saranno sempre questi pulsanti? È possibile che la tipografia cambi? L’immagine di background è critica per il design? Le righe orizzontali fanno parte della molecola?”

Rispondere a queste domande aiuta ad essere sicuri che le componenti completino lo scopo del design. Per eesmpio, potreste scegliere di specificare alcuni stili a livello atomico, invece che a livello di organismo, per rendere più semplice cambiare quelle proprietà senza cambiare il modulo stesso.

Coinvolgete gli utenti nel processo di design#section6

Un alto aspetto critico nello stabilire una comprensione condivisa è coinvolgere fin da subito persone di discipline diverse, così come gli utenti, nel processo di design. Quando si fa un brainstorm e si fanno le bozze assieme, non si può evitare di parlare degli elementi di design, quindi inevitabilmente si prendono decisioni ontologiche che contribuiscono a rafforzare ed evolvere il linguaggio del design.

Passare presto alla fase di test è importante, anche se i moduli vengono presentati semplicemente su carta. Testare le idee su carta è molto diverso dal processo solito, in cui si ha una lista di task e scenari attraverso i quali conduciamo gli utenti. Qui, i partecipanti possono scegliere, spostare, discutere e scarabocchiare sulle card, diventando parte attiva del processo di design. Questo ci dà la possibilità di testare le nostre scelte di linguaggio e di essere sicuri che le funzioni che abbiamo definito abbiano senso per i nostri utenti.

User testing e design partecipativo con gli studenti.

Per concludere#section7

Le fondamenta costituite da un linguaggio ben definito sono uno strumento potente che permette ai team di sintetizzare i propri sforzi attorno all’implementazione del design modulare. Ma il modo in cui si evolve un linguaggio del design condiviso è un processo da fare passo a passo, graduale ed organico. Ogni persona del team ha un ruolo per renderlo più coerente. Passare attraverso il processo di creazione di una pattern library come team è un modo efficace per stabilire le fondamenta del linguaggio. Utilizzare una metodologia solida, come l’atomic design, può accelerare il processo.

È utile che il vostro team sviluppi l’abitudine di assegnare insieme i nomi alle cose, perché mentre si cerca di dare a qualcosa un nome che abbia senso, se ne definisce la funzione e, ancora più importante, si raggiunge il consenso. Il nome concordato determina il modo in cui l’elemento sarà creato e incoraggia un uso consistente in tutto il team. Come scrive Abby Coverts, “Se non c’è accordo prima di cominciare, preparatevi a dover lavorare di più dopo”.

Sforzatevi di far riferimento agli elementi con il nome che avete concordato, indipendentemente da quanto possa suonare strano nelle conversazioni di ogni giorno. Ci vuole più sforzo all’inizio per chiamare qualcosa “box dei sussurri” (sì, abbiamo un elemento chiamato “box dei sussurri”) piuttosto che “quella cosa con le righe e un’icona nel mezzo”, ma finché non comincerete a far riferimento a un elemento con il suo nome proprio, non esisterà nel vostro sistema modulare come blocco solido su cui poter intervenire. Ogni volta che usate il nome concordato, rafforzate l’elemento che state chiamando ed evolvete il vostro linguaggio del design.

Mettete alla prova il vostro linguaggio al di fuori del vostro team usandolo all’interno dell’azienda, con altri team e con gli utenti. È sempre interessante vedere cosa rimane. È davvero incoraggiante quando anche qualcuno al di fuori del team di prodotto comincia ad usare quel nome.

Infine, ricordatevi che nessun linguaggio (salvo alcune eccezioni) esiste isolatamente. Evolvendo e rafforzando il vostro linguaggio del design, avete un’opportunità per contribuire linguaggio più ampio del web e per contribuire a renderlo più consistente e coerente per tutti.

Illustrazioni: {carlok}