Il mondo del design è davvero open e accessibile?
Allo stato delle cose, il mondo del design è lontano dall’essere open e accessibile al 100% , vincolato ai tool e ai file proprietario.
Collaborando con diversi team, startup e altre realtà mi sono trovato a dover condividere file, dati e informazioni sia con designer che con altre figure professionali che non provenivano dal mio mondo.
Comunicare è un lavoro di traduzione e trasformazione con la minor perdita di informazioni possibile: passare da un mondo all’altro, che sia dal design al development, ma anche da me a te, comporta una codificazione dei contenuti che si hanno in testa importante.
Far comprendere a un altro sistema quello che sta accadendo nel nostro non è facile e la domanda che mi chiedo di continuo è: «Come posso far capire la cosa X alla persona B?»
Un’interfaccia, a esempio è allo stesso tempo una e tre cose diverse per un designer, uno sviluppatore e un imprenditore:
- per il designer, ci saranno livelli e simboli, vettoriali e path;
- lo sviluppatore penserà all’implementazione dei materiali forniti, penserà per framework e architetture;
- un imprenditore vedrà la faccia di un business, penserà in termini di investimento, conversioni e prodotto.
In un simile processo, ho visto emergere una domanda fastidiosa per i designers:
Il mondo del design è davvero open e accessibile?
Un paragone con gli sviluppatori
Lavorando braccio a braccio con i dev e approfondendo molti aspetti di back-end e front-end per migliorare il mio design work-flow e arricchire il mio know-how, ho notato l’accessibilità intrinseca nel mondo dev.
I tool per sviluppare sono molti e vari (Atom, TextWrangler, SublimeText, XCode solo per citarne alcuni) come per i designer (SketchApp, Figma, Framer, InVision, Adobe XD, Axure e via discorrendo).
I dev, però, che usino un tool o l’altro, se producono un file JSON con XCode possono leggerlo e modificarlo con tutti gli altri tool, senza import di alcun tipo.
E i designer?
È un circo.
Spesso i team decidono di adottare come standard un set di tool da usare e lo impongono ai membri e questa impostazione comporta un altissimo numero di vincoli:
- Formazione: designer che passano da anni di utilizzo di un tool devono imparare a usare quello nuovo, con notevole dispendio di tempo ed energie;
- Continuità mancata: l’importanza di un tool fluttua nel tempo e può capitare che un tool diventi il nuovo standard e ciò comporta dover adeguare i file prodotti con quelli precedenti;
- Integrazione difficile: non tutti i tool funzionano con altri servizi;
- Comunicazione fallace: spesso, condividere file e deliverables è altamente complesso perchè spesso ci si trova a scambiare documentazioni con persone che fanno uso di altri standard.
Ma qual è la causa principale alla base di tutto ciò?
I file proprietario.
La maledizione dei designer
I designer spesso sembra che indossino dei paraocchi e quei paraocchi sono i loro tool.
Il tool-centrismo è forte e lo si nota dal fatto che nessuno lo nota.
Uno sviluppatore crea un file JSON con Atom ed è uguale al file JSON che producono TextWrangler o XCode.
Se condivido quel file di codice, produco un file standard che tutti possono leggere con tool capaci di interpretare quel documento e su cui tutti potenzialmente possono lavorare.
Se vado su GitHub, anche se non sono un esperto di codice possono visionare i contenuti dei file e provare a lavorarci sopra.
I designer, invece, progettano tutti la stessa cosa ma producono un Carnevale di file.
Quante volte vi siete infastiditi quando vi hanno inviato un’interfaccia fatta cono Sketch e voi avete un Windows e usate Adobe XD?
Certo, potete caricare le schermate su InVision ma ciò comporta una fase di traduzione (come quando comunicate con qualcuno di diverso da voi, ricordate?) e, anche se ad altissima fedeltà, non state mettendo mano al file originale.
E ciò porta perdita di dati e di qualità.
E se d’improvviso tutti smettessero di usare Sketch e iniziassero a usare un altro tool? Che fine fanno tutte quelle interfacce che avete fatto? Le esportate in PNG ma se le volete modificare?
Non è tanto astratto come discorso — fra poco, InVision distribuirà il suo InVision Studio al pubblico e, se manterranno tutte le promesse fatte, è probabile che quel tool diventi il nuovo standard. L’hype, d’altronde, è alto.
Scavando sempre più alla base, però, qual è il motore di tutto?
Gli standard.
Ai designer mancano standard
I designer standardizzano tutto: UX frameworks e procedure di analisi dei dati, step per la progettazione di un sito, check-list, design sprint.
Standard su standard.
Perchè i designer sono ossessionati dal far uscire il loro lavoro dal reame magico dell’ispirazione artistica.
Quando si parla di strumenti, però, gli standard saltano.
E rendere un tool lo standard non è creare uno standard.
I tool sono basati su tecnologie in continua evoluzione e trasformazione — come in passato si usavano i martelli per fare i tavoli e ora ci sono macchinari industriali super-potenti che fanno quel lavoro lì, così adesso abbiamo tool che ci permettono di creare interfacce ma in futuro, e anche in un futuro prossimo, ce ne saranno altri e di migliori.
E se ci si basa sui tool e basta, è un continuo cercare di importare ed esportare, trasformare e convertire e i dati si perdono.
Gli sviluppatori hanno come output documenti in formato standard su cui possono lavorare con le loro tecniche.
I designer no.
È vero che se controllate, i file di Sketch sono zip fatti di JSON e PNG, ma tali formati non permettono al designer di applicare le sue tecniche e lavorare con tutti gli standard che conosce.
E dunque?
Ho fatto tanta polemica ma la polemica non è costruttiva se non seguita da proposte effettive e procedurali.
Nella mia mente, se penso a un file grafico manipolabile ad alta prestazione che è pure standard penso a un SVG.
Gli SVG sono standard, molto flessibili e modificabili e tutti i tool riescono ad aprirli senza far perdere le loro caratteristiche (o almeno, mantenendone un’elevata quantità: trasparenze e gradienti sono gestiti, a esempio).
Avere librerie e interfacce in file SVG permette di renderle condivisibili e accessibili al 100%, nonchè modificabili.
Volete i simboli reiterabili con le vostre proprietà?
Importate la libreria in SVG e trasformate i componenti in simboli col tool di interesse.
È un nuovo tipo di workflow e spesso richiede uno sforzo maggiore o passaggi ulteriori, ma è alla base di uno shift di mentalità importante puntano a un design sempre più open.
