Il futuro della progettazione dell'interfaccia utente: strumenti dell'interfaccia utente di nuova generazione

Pubblicato: 2022-03-11

Gli strumenti di progettazione dell'interfaccia utente hanno fatto molta strada dalla prima generazione di Adobe Photoshop, un programma destinato alla modifica delle foto, non alla creazione di interfacce utente dinamiche. L'attuale generazione di strumenti, come Adobe XD, Figma e Sketch, ha reso i nostri lavori più facili e veloci.

Tuttavia, le inefficienze nei nostri flussi di lavoro quotidiani abbondano e stiamo sprecando tempo e risorse preziose quando potremmo progettare prodotti che le persone vogliono utilizzare. I programmi di progettazione disponibili oggi sono superiori a quelli con cui abbiamo iniziato, ma non riescono a capitalizzare la tecnologia attuale e ci impediscono di realizzare il nostro pieno potenziale come designer dell'interfaccia utente.

È tempo di una nuova generazione di strumenti dell'interfaccia utente.

Integrazione di design e codice

I futuri strumenti dell'interfaccia utente uniranno design e codice per fornire un'esperienza più fluida a progettisti e sviluppatori. I nostri strumenti attuali non ci stanno aiutando a progettare interfacce utente web; ci stanno aiutando a progettare rappresentazioni astratte delle interfacce utente web. I mock-up realizzati in Figma e Sketch sono disconnessi dal codice sorgente.

Oggi molti designer conoscono le basi di HTML e CSS. Alcuni intransigenti progettano nel codice, ma non è efficace per progetti complessi; i designer hanno bisogno della capacità di esplorare rapidamente un proof of concept prima di impegnarsi in esso.

Gli sviluppatori di software dispongono di Visual Studio Code, uno strumento che unisce la modifica e lo sviluppo del codice e consente agli ingegneri di creare, testare ed eseguire il debug del codice nello stesso ambiente. Allo stesso modo, i progettisti hanno bisogno di un ambiente di sviluppo visivo che fornisca funzionalità di progettazione complete ma generi anche codice pronto per la produzione.

Ecco cosa riserva il futuro.

La creazione parallela sostituirà gli handoff di designer/sviluppatori

C'è troppo avanti e indietro tra designer e sviluppatori, specialmente durante la fase di trasferimento. In alcuni casi, il trasferimento è così dispendioso in termini di tempo ed estenuante che la qualità del lavoro ne risente. Con gli strumenti di progettazione di nuova generazione che si interfacciano con il codice sorgente, gli sviluppatori non saranno più gli unici responsabili della creazione di interfacce utente. Saranno invece in grado di concentrarsi sullo sviluppo dell'architettura logica che collega l'interfaccia utente di un prodotto al suo back-end e lo fa funzionare correttamente.

I progettisti getteranno le basi delle interfacce utente con il codice integrato e gli sviluppatori si baseranno su questo codice per dare vita ai prodotti. I designer non dovranno più importunare gli sviluppatori con richieste come "Aggiungi 16 px di riempimento invece di 8 px, come mostrato nel mock-up". E gli sviluppatori non dovranno fermarsi a porre domande di progettazione come "In che modo questo componente dovrebbe scalare tra punti di interruzione tablet e desktop?"

Invece, designer e sviluppatori collaboreranno su questioni più importanti, come se un approccio di progettazione è fattibile in base al tempo e al budget o se sono stati affrontati tutti gli stati di un componente dell'interfaccia utente.

Gli strumenti dell'interfaccia utente di progettazione e il software per sviluppatori si allineeranno

Gli strumenti attuali si basano su modelli di programmazione su misura per generare componenti di progettazione. Questi modelli generalmente non sono robusti come i CSS e non consentono ai progettisti di vedere il codice generato automaticamente alla base dei loro file di progettazione, codice che alla fine deve essere esportato in HTML, CSS o JavaScript. Sarebbe molto più semplice se i nostri strumenti utilizzassero HTML e CSS in modo nativo.

Ad esempio, CSS utilizza il modello box, che richiede di posizionare gli elementi HTML su ogni pagina all'interno di un box codificato per definirne altezza, larghezza, bordo e riempimento. Figma si avvicina a fornire questa capacità con la sua funzione di layout automatico. Ma se Figma utilizzasse il modello box che già alimenta la maggior parte delle interfacce utente web, gli sviluppatori dovrebbero tradurre ed esportare meno.

Lo stesso vale per l'ereditarietà dello stile, che controlla cosa succede quando non viene specificato uno stile per un elemento specifico, simile a un valore predefinito. CSS lo utilizza, ma la maggior parte degli strumenti di progettazione, che non sono stati creati per essere specifici per il Web, non lo fanno.

Abbiamo bisogno dei nostri strumenti per produrre visualizzazioni Web, non tavole da disegno statiche o modelli. Non abbiamo bisogno di simulatori HTML e CSS. Abbiamo bisogno di HTML e CSS.

Due cerchi blu sovrapposti. Il cerchio sinistro è etichettato UI Designer. Il cerchio di destra è etichettato come Front End Developer. Nel cerchio di sinistra si legge "Strumento di progettazione di nuova generazione" e in quello di destra si legge "Logica complessa (Javascript)". Al centro in blu scuro, dove si intersecano, si legge "Layout (HTML)," "Styling (CSS)" "Simple logic (JavaScript)".
Gli strumenti di progettazione di nuova generazione si interfacciano direttamente con il codice sorgente, eliminando i deliverable usa e getta e consentendo a designer e sviluppatori di collaborare sullo stesso deliverable: il codice sorgente.

I mock-up diventeranno obsoleti

Invece di modellini usa e getta, lanciamo modelli fuori dalla porta.

I mock-up lasciano troppe domande senza risposta. Non è possibile progettarne uno per ogni ambiente digitale. Oggi i progettisti creano layout per larghezze dello schermo di 320 px, 834 px e 1440 px; ma cosa succede se parte del layout si interrompe su un viewport di 1220 px? E perché non ottimizzare per 375 px, una dimensione comune per i telefoni più grandi di oggi?

La creazione di una tavola da disegno per ogni scenario non è pratica, soprattutto se si considerano tutti i punti di interruzione e le viste, per non parlare dei temi oscuri. La progettazione per tutte queste variabili aumenta il numero di tavole da disegno oltre ogni ragionevolezza.

Anche i mock-up sono uno spreco di risorse. La loro costruzione richiede molto tempo e sono diventati meno importanti nella progettazione di prodotti digitali. Webflow ha eliminato i modelli e sostiene invece prototipi reattivi e interattivi. (Sfortunatamente, Webflow è limitato a soluzioni basate sul Web e si rivolge a semplici siti Web). E mentre i risultati finali usa e getta potrebbero avere senso durante l'ideazione, sono uno spreco durante la fase di soluzione.

Tutti gli stati del sistema verranno contabilizzati

Tutti i prodotti digitali hanno stati che corrispondono a ciò che stanno facendo in un dato momento, ad esempio, bloccarsi durante il caricamento o visualizzare un messaggio di errore.

Ogni stato deve essere considerato, ma gli attuali strumenti dell'interfaccia utente lasciano questo compito ai progettisti, costringendoli a creare numerose varianti di un singolo componente. Gli strumenti di sviluppo React e Vue.js consentono agli sviluppatori di adattarsi facilmente a tutti i possibili stati di un componente. Gli strumenti di progettazione devono seguire l'esempio e incoraggiare i progettisti, persino assillarli, a garantire che tutti gli stati dei componenti siano progettati per.

Screenshot da Storybook.js. Sulla sinistra c'è un menu e la prima intestazione è Libreria. Sotto c'è la parola "grafici" e sotto c'è "istogramma". Il livello successivo elenca tre stati. Il primo, "predefinito", è evidenziato. Nella parte principale della pagina c'è un grafico a barre con l'intestazione "distribuzione della latenza". Sotto c'è un elenco di controlli.
Storybook.js funge da enciclopedia dei componenti dell'interfaccia utente di un repository. La modifica dei controlli mostra un componente in tutti i possibili stati. Gli strumenti di progettazione devono muoversi in questa direzione, invece di essere silos isolati che sono disconnessi dalla base di codice di un prodotto.

I dati reali sostituiranno i contenuti segnaposto

Proprio come i progettisti creano componenti per più stati, progettano anche per un'ampia varietà di dati. I progettisti dell'interfaccia utente devono essere in grado di testare i loro componenti con l'input effettivo (copia, immagini, date, nomi, titoli e altro) che alla fine popoleranno i componenti nei loro progetti. Attualmente, i progettisti possono simulare i dati solo copiandoli e incollandoli manualmente nelle tavole da disegno, un'operazione estremamente noiosa. Esistono plugin che possono aiutare ad automatizzare questo processo, ma sono ingombranti.

Anche chiedere agli sviluppatori di valutare come i componenti gestiscono i dati non è la risposta. Con il tempo che i componenti arrivano ai test, è troppo dispendioso in termini di tempo riprogettarli. E se i progettisti non possono testare e iterare i componenti con dati reali, come faranno a sapere se una scheda funziona con un titolo lungo o nessun titolo? Come scopriranno che un font non supporta i caratteri arabi o che un sito non supporta le lingue che si leggono da destra a sinistra?

Un componente "titolo pagina" di Google Material Design. Il lato sinistro mostra come funziona il componente se il titolo viene letto da sinistra a destra. Una colonna sotto l'immagine mostra informazioni sulla quantità di riempimento dell'icona dal bordo dello schermo, distanza del titolo dal bordo dello schermo, riempimento sotto il titolo, altezza della barra di navigazione e riempimento del menu di overflow. Sul lato destro mostra lo stesso componente del titolo di pagina in arabo per dimostrare come funziona il componente per una lingua letta da destra a sinistra. Una colonna sotto l'immagine mostra informazioni sul riempimento delle icone dal bordo dello schermo, la distanza del titolo dal bordo dello schermo, il riempimento sotto il titolo, l'altezza della barra di navigazione e il riempimento del menu di overflow.
Material Design supporta la bidirezionalità per impostazione predefinita.

I test sui casi limite diventeranno più semplici

Quando gli strumenti dell'interfaccia utente finalmente soddisferanno tutti gli stati e consentiranno il test dei dati reali, i progettisti saranno in grado di anticipare meglio i casi limite. Una volta che un componente è stato creato, i progettisti sottoporranno a stress test i suoi vari stati, facendolo esplodere con dati diversi per vedere come si comporta in diversi scenari. In questo modo, l'interfaccia utente diventerà il dominio del progettista, consentendo agli sviluppatori di concentrarsi su attività come la correzione di JavaScript o il test delle API.

Due blocchi di testo dimostrano la differenza di quanti pixel richiedono le diverse lingue. Il blocco in alto recita "Ripeti password". In rosso sopra si legge "210 pixel di larghezza in inglese". Il secondo blocco di testo recita "Wiederholen Sie das Kennwort". In rosso sopra si legge "380 pixel di larghezza in tedesco".
Il tuo componente dell'interfaccia utente può soddisfare un cambio di lingua? L'unico modo per scoprirlo è testarlo con dati diversi.

Si aprirà un mondo di strumenti per sviluppatori ed estensioni del browser di terze parti

Una volta che il nostro lavoro vive in HTML e CSS, durante la fase di progettazione sarà disponibile un intero ecosistema di estensioni, come l'indispensabile Lighthouse per gli audit di prestazioni, SEO e accessibilità, o i vari strumenti di sviluppo del browser che simulano i breakpoint dei dispositivi e le basse velocità di rete. Il set di strumenti del browser è molto più prezioso per la creazione e il test di interfacce utente pronte per la produzione rispetto a qualsiasi plug-in in Figma, Sketch o Adobe XD.

Designer e sviluppatori lavoreranno in parallelo

Paragono lo stato attuale dello sviluppo del prodotto a una cucina in cui uno chef sta cercando di cucinare un piatto dettando a un altro cosa fare: potrebbe funzionare, ma richiederà molto più tempo e sarà molto meno efficiente. Esistono aziende che sviluppano strumenti di progettazione basati su codice: Hadron, Modulz e Relate hanno prodotti in versione beta. L'adozione diffusa di questi strumenti segnerà l'inizio di una rivoluzione nella creazione di prodotti digitali.

Segnalirà anche un cambiamento radicale nel rapporto progettista-sviluppatore. Con le due parti che lavorano in parallelo, i team di prodotto diventeranno esponenzialmente più efficienti. Gli sviluppatori saranno liberi di affrontare la complessa logica dell'architettura dell'interfaccia utente invece di perdere tempo a interpretare modelli o farsi impantanare dai designer che chiedono loro di spingere i pixel alla perfezione. E i designer saranno più preziosi per i loro team e aziende man mano che diventeranno co-costruttori di prodotti digitali di successo.