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.
