Frameworkless e lo scenario delle interfacce e del design

Frameworkless e lo scenario delle interfacce e del design

N.B. Questo contenuto è stato prodotto e pubblicato la prima volta da Flowing, società che da luglio 2022 è confluita in Claranet Italia. Insieme a essa sono confluite riflessioni, temi, metodologie e spunti, ampiamente condivisi e orgogliosamente riproposti all’interno di questo blog. ©claranet

PUBBLICATO IL 19/11/2018 DA

Alessandro

Design

IN SINTESI

Francesco in un post precedente ha descritto bene come è nato il frameworkless movement, che sin da subito mi ha visto in linea con un occhio di riguardo a come questo approccio torni utile anche nel mondo delle interfacce e del design.
È vero, abbiamo scelto un nome d’impatto ma necessario per fare il giusto rumore ed emergere dalle routine e dalle mode aiutandoci anche ad innescare conversazioni e confronti costruttivi, che potete leggere sul nostro repo.

La parte che mi interessa di più delle discussioni che si sono sviluppate è quella meno tecnica, quella che tocca la decisionalità e il contesto del progetto. Mi piace quando il focus si sposta da quello che facciamo al perché lo facciamo. Sia che scriviamo codice sia che progettiamo interfacce il concetto alla base è sempre quello: il valore non è nel codice, nei flussi o nei wireframe ma nel risultato finale di quello che si produce e di quanto esso raggiunga gli obiettivi.
Ribadisco quindi che nel frameworkless movement nessuno è contro niente, ci siamo semplicemente chiesti quale sia il modo migliore per fare il nostro lavoro. Ogni software non è fine a se stesso, ma ha obiettivi strategici dettati dai business goal e che devono trovare riscontro nell’utente finale. Scrivere buon codice o fare belle interfacce è propedeutico al vero obiettivo, non è la missione del team di sviluppo ma appunto un asset.
Dunque fare bene la propria parte di lavoro (che sia scrivere codice o progettare interfacce) significa anche prendere giuste decisioni. Fare in modo che i cambiamenti siano “fisiologici” quindi veloci, poco costosi e misurabili.

In questo contesto trovo un ancoraggio tra i principi del frameworkless movement e il modo del design e delle interfacce.
Infatti nell’Interface Development i framework esistono da parecchi anni ormai. Prima sorti come toolset nelle impostazioni dei ritmi verticali e orizzontali, di tipografia e griglie poi sempre di più diventati una libreria di pattern. Qui il concetto è molto simile ai framework lato development (dato che sempre di codice si parla) anche se in un contesto più spostato verso l’interfaccia, il design e l’esperienza d’uso. In una ipotetica linea temporale di flusso di lavoro l’Interface Development si colloca tra lo User Interface Design e il Frontend/Backend Development. Non a caso i suoi primi framework furono immediatamente apprezzati dal modo dello sviluppo (perché permettevano una maggiore velocità fornendo loro più autonomia e meno dipendenza) e molto meno da quello del design (visti spesso come vincoli e freni alla creatività). Col senno di poi, potremmo dire che quel confronto era sterile. Valide ragioni esistevano da ambo le parti perché non era il framework a fare la differenza ma la decisione presa su perché e quale usare.

Ma è nel design (Interaction Design e User Interface Design) che la questione assume una grana ancora diversa. Non si parla più di codice ma di interazione, usabilità, abitudini e percezione cognitiva dell’utente in un contesto soggetto a variabili che a volte devono essere persino delineate.
Nell’Interaction Design c’è già una posizione priva di bias e pregiudizi per la natura del suo outcome. Non si è influenzati dalla tentazione di dover dimostrare la “qualità” o di dover convincere per la sua “bellezza” o perché “well written”. La progettazione dell’interazione tiene conto dei parametri di funzionalità con una visione innata più sistemica che locale. Viene progettata per un motivo e il come viene progettata non rischia mai di diventare troppo ingombrante. Non esistono (ancora) veri e propri framework in questa fase di lavoro, anche se si sta iniziando a cercare di automatizzare alcuni parametri che ricorrono in determinate situazioni già mappate. La questione è ancora molto aperta ma è qui che si innesca la domanda chiave del frameworkless movement nel chiederci cosa effettivamente ci fa comodo sia “già pronto” e quali risposte siano immuni da variabili che cambiano in base al contesto e agli obiettivi di progetto. Per tutto il resto degli assets dell’Interaction Design subentrano i design pattern, dove Christof Alexander ci insegna che è legittimo prenderne spunto per risolvere un problema che è già stato risolto con successo. Da ricordare che il contesto temporale non vale all’infinito ma finché non cambiano alcune condizioni chiave. È dunque introdotto un concetto di sensibilità che spazia dall’evoluzione tecnologica passando per le abitudini degli utenti e l’etnografia.
Nella fase di User Interface Design le cose cambiano di nuovo. Il lavoro è inevitabilmente influenzato e/o influenzerà la parte di interazione e quella di sviluppo. Framework di Interface Development e di Frontend/Backend Development possono diventare vincoli o risorse della UI e il confine è molto labile. Da un lato quindi le decisioni altrui che si ripercuotono su questa fase contaminandola e dall’altro lato le decisioni proprie date da soluzioni già pronte e framework che agiscono su due livelli: un livello locale e uno globale. A livello locale possiamo elencare più che altro tool, automatizzazioni matematiche tipografiche e di layout e modelli iconografici più o meno delineati. Anche qui lo spunto del frameworkless movement riporta la giusta saggezza nello scegliere bene soluzioni in cui studi già fatti dimostrano l’efficacia e la dignità del riuso senza cadere nella scelta per la mera velocizzazione del delivery. Lato globale il discorso è di nuovo ancora aperto. Probabilmente è la necessità di punta che si avverte ad oggi nel mondo dei team cross-funzionali, dove il design deve trovare l’equilibrio tra coerenza e malleabilità. Il Design System è un framework lato design di tipo globale per creare una cornice di lavoro che sia utile a tutto il team per i suoi principi di condivisione e linguaggio comune, che protegga l’esperienza utente con la sua coerenza e che mantenga il focus sugli obiettivi di business grazie all’ancoraggio ai business goal.

Chiudendo il cerchio quindi, per ogni fase e per ogni professionalità esistono framework in cui ha senso chiedersi se sia il caso di usarli e, se sì, quali. In ogni ambito professionale vengono fatte scelte ma i criteri su cui scegliere devono essere condivisi per impedire che si faccia la migliore scelta per il proprio lavoro e non per gli obiettivi del progetto.
Capire come funziona e agisce la nostra cornice di lavoro ci aiuta a maturare quella sensibilità necessaria per valutare il contesto e la scelta, e quanto più questo momento si poggia su principi condivisi da tutti tanto più la scelta sarà il frutto della massima espressione di tutto il team.


Rimani in contatto con noi

...saremo "né troppo vicini, né troppo lontani" :)