Smashing Podcast Episode 9 con Stephanie Walter: come posso lavorare con i framework dell'interfaccia utente?

In qualità di sviluppatore, una delle cose che mi piacciono dei framework dell'interfaccia utente è che spesso hanno uno stile predefinito, ma è qualcosa su cui dovremmo fare affidamento nei progetti? Semplicemente usando lo stile predefinito e fidandoti che chiunque abbia prodotto il framework abbia fatto un ottimo lavoro nella progettazione di quei componenti? Unisciti a me per l'episodio del podcast di oggi in cui parlo con la UX Designer Stephanie Walter delle cose che dovremmo considerare quando costruiamo su un framework dell'interfaccia utente.

Mostra note

• Il sito di Stefania
• Stefania su Twitter

Aggiornamento settimanale

• "Come creare un gioco di abbinamento di carte utilizzando Angular e RxJS" di Anna Prenzel
• "Come creare un sito WordPress senza testa su JAMstack" di Sarah Drasner
• "Magic Flip Cards: Risolvere un problema di dimensionamento comune" di Dan Halliday
• "Aspetti salienti di Django: modelli utente e autenticazione (parte 1)" di Philip Kiely
• "Come creare mappe con React And Leaflet" di Shajia Abidi

Trascrizione

Drew McLellan: È una designer incentrata sull'utente ed esperta di esperienza mobile, che ha incrociato prodotti e interfacce deliziosi con un'attenzione particolare alle prestazioni. Ha lavorato a progetti per clienti come l'Università del Lussemburgo, la Banca Europea per gli Investimenti, BMW e Microsoft solo per citarne alcuni, e aiuta quei clienti a fornire progetti di successo al loro pubblico dalla strategia al prodotto finale. È una Google Developer esperta nella progettazione di prodotti e un'insegnante appassionata che condivide le sue conoscenze in numerosi post di blog, articoli, workshop e presentazioni di conferenze. Quindi sappiamo che è un'esperta designer dell'esperienza utente, ma lo sapevi che una volta ha avuto un lavoro per montare i tappeti con Sir Elton John? I miei amici Smashing, per favore, date il benvenuto a Stephanie Walter. Ciao Stefania, come stai?

Stephanie Walter: Ciao, sono fantastica e ho adorato l'introduzione.

Drew: Quindi oggi volevo parlarti di un problema particolare e questo è l'argomento dell'uso di framework di interfaccia utente standard. Ora sei un designer di esperienze utente e lavori con molti clienti diversi e il tuo compito è aiutare quei clienti a creare le migliori esperienze utente possibili attraverso la creazione di interfacce utente altamente utilizzabili. Quindi l'idea di poterlo fare con un set di strumenti standard mi sembra un po' forzata. L'uso del framework dell'interfaccia utente è qualcosa che vedi molto durante il tuo lavoro?

Stephanie: Sì, è qualcosa che ho visto molto, soprattutto negli ultimi anni perché ho iniziato a lavorare con un'agenzia e ora lavoro all'interno dell'azienda. Quindi in quei super grandi team di tecnologia IT e sì, al momento ci sono molte UI di framework come quella che ho visto di più è Material-UI, in pratica il design dei materiali è un tipo di linee guida e cose di design di Google, e il materiale -UI è il team di Angular, ma anche il team di React. Hanno creato la propria struttura utilizzando l'aspetto grafico del design dei materiali di Google. Ma non ha più nulla a che fare con Google. È proprio come loro, non lo so, penso che gli sia piaciuto l'aspetto grafico. Quindi, al momento, questi sono i due framework principali dell'interfaccia utente con cui lavoro. E c'è anche qualcosa chiamato Ant Design, che è diventato abbastanza popolare.

Stephanie: È un framework React. Non so se hanno anche Angular. Penso che sia stato realizzato da un team in Cina. Ed è interessante perché non solo fornisce i componenti, tutto in React, ma se vai sul loro sito Web otterrai anche i file scratch, il che in realtà è piuttosto interessante perché in qualche modo motiva o aiuta il designer a costruire o modellare l'interfaccia nei componenti dell'interfaccia utente utilizzati da quel framework. Quindi sì, è qualcosa che ho visto molto, specialmente nei grandi team IT perché la maggior parte delle volte quelli non hanno un designer. Al momento sono fondamentalmente un team UX di uno in un piccolo team presso una banca d'investimento europea. Quindi sono io come designer UX. Lavoro con un team di sviluppatori, analisti aziendali, tutte brave persone, ma sono comunque un designer per l'intero progetto.

Stephanie: Fino al mio arrivo non c'era nessun designer. Quindi è una sorta di soluzione implementata in molte aziende, in particolare sui prodotti interni, ad esempio. Dove di solito dicono, va bene, non abbiamo davvero bisogno di un designer per quello. Abbiamo solo bisogno di qualcosa che funzioni per i nostri utenti interni e usiamo solo un framework perché è conveniente per gli sviluppatori. La maggior parte dei componenti sono già presenti e poiché non hanno designer nel team, si tratta di sostituire, per così dire, il ruolo di un designer dell'interfaccia utente. Sì, il problema è che, ok, allora hai i componenti, ma il ruolo del designer dell'interfaccia utente non è solo quello di decidere se il pulsante deve essere rosso, verde, arancione, blu, qualunque cosa. Di solito il ruolo del designer dell'interfaccia utente è l'architettura dell'informazione, la comprensione delle esigenze degli utenti. Quindi tutto ciò che va oltre l'interfaccia. Quindi, anche se hai questo tipo di framework, questo si prende cura dell'intera interfaccia utente, quindi visivamente ciò che vedi sullo schermo.

Stephanie: Ad un certo punto hai ancora bisogno di qualcuno che faccia il lavoro per capire cosa mettiamo sullo schermo, come si comporterà? Cosa succede quando clicchiamo qui? In che modo l'utente raggiunge il proprio obiettivo? Come si va dal punto A al punto B? Poiché possiamo usare un modello, possiamo usare le schede, possiamo usare tutti i componenti. Ecco perché è sempre un po' complesso e complicato.

Drew: È possibile, pensi di essere in grado di creare un'interfaccia utente utilizzabile utilizzando un framework dell'interfaccia utente standard o sarà sempre un po' un compromesso?

Stephanie: In un certo senso lo spero. In un certo senso lo spero perché altrimenti sto costruendo interfacce non utilizzabili. Quindi questa risposta è totalmente parziale, ma sì, penso che lo sia, ma dipende anche dal livello di compromesso che sei disposto a fare e ci sono compromessi da entrambe le parti. Al momento sto compromettendo molti pulsanti, ad esempio, perché hai alcuni pulsanti davvero specifici nell'interfaccia utente dei materiali e non mi piace molto l'effetto a catena sul pulsante. Penso che funzioni alla grande sui dispositivi mobili perché sui dispositivi mobili è necessario un tipo di feedback importante quando l'utente fa clic o tocca il pulsante. Ma poi i passaggi sono una specie di effetto a catena che va fino in fondo sul pulsante. È un po' eccessivo, specialmente quando ci sono molti pulsanti. Ma continueremo comunque a mantenere questo effetto a catena perché sarebbe super complesso rimuoverlo perché è stato integrato nel framework React. E per avere un altro effetto al passaggio del mouse su questo pulsante, qualcosa di più sottile che non sarà questo genere di cose sibilanti qui. Sarebbe super complesso.

Stephanie: Quindi questo è il tipo di compromessi che fai. Ma nel frattempo, non scendo a compromessi su cose specifiche che sono i componenti personalizzati. Dove lavoravo prima, attuale cliente di una compagnia di viaggi e compagnie aeree. E la compagnia aerea ha delle esigenze davvero, davvero super specifiche. Il calendario per la compagnia aerea, ad esempio, vuoi inserire i prezzi, vuoi mettere... se non viaggi verso questa destinazione in una data specifica, non sai quando metterlo, hai questa partenza e questo arrivo e il calendario di base della maggior parte di quei framework dell'interfaccia utente non fornisce questo tipo di cose. Quindi a un certo punto puoi dire, ok, useremo semplicemente il calendario che hanno. E questo è tutto. Devi andare oltre. Quindi la maggior parte dei compromessi sono fondamentalmente basati su, usiamo il componente di base? Ne creiamo uno personalizzato che soddisfi le esigenze dell'utente? O facciamo un mix dei due? Nel caso del calendario, ad esempio, utilizziamo la griglia del calendario, quindi utilizziamo il componente di base e poi lo abbiamo migliorato con la personalizzazione. Quindi c'è stato molto sviluppo di React per quello.

Stephanie: E sì, quindi di solito fai molti compromessi.

Drew: Quindi sembra che l'utilizzo di un framework per l'interfaccia utente possa portarti un po' in là, ma per avere davvero una buona interfaccia utente come risultato, devi fare un po' di personalizzazione in cima?

Stefania: Di solito. Sì.

Drew: Questa personalizzazione va oltre i temi?

Stephanie: Sì, il mio sviluppatore desiderava che non andasse oltre i temi. Eugenio Se mi ascolti. Penso che sarebbe super felice se cambiassimo solo alcuni colori su tutto. Ma sì, a un certo punto devi andare oltre la personalizzazione perché prima, come i framework dell'interfaccia utente sono come gli strumenti Lego, è una specie di cassetta degli attrezzi. Quindi hai molti componenti diversi nella scatola, ma questo non crea una pagina. Hai ancora bisogno di un'intestazione, hai ancora bisogno di un piè di pagina. Hai ancora bisogno di contenuti extra che non erano nel framework. Quindi a volte puoi modificare un componente in ciò di cui hai bisogno. Da quello che ho capito, stiamo usando il componente card per costruire una finestra modale, ma la cosa con le finestre modali è che non si comporta davvero come una carta.

Stephanie: Stai andando un po' oltre. Hai bisogno di uno sfondo con oscuramento. Devi attivarlo al clic mentre di solito la tua carta è già lì nell'interfaccia. Quindi stiamo usando questo componente della carta perché ha molte delle cose di cui abbiamo bisogno come lo sfondo, un'intestazione e un titolo in alto, alcuni pulsanti in basso. Quindi abbiamo la struttura e poi la modifichiamo un po'. Ma a volte finiamo con qualche conflitto sulla semantica e anche sull'HTML. Perché, ad esempio, volevo avere pulsanti che non avessero forme di pulsanti, quindi proprio come il pulsante di collegamento e lo sviluppatore ha detto: "Ok, quindi utilizziamo un collegamento come il tuo link href". Ho detto: "No, questo non è un collegamento. È un pulsante. Quando fanno clic su di esso, non si apre una nuova pagina. Cancella tutto ciò che è nella forma.

Stephanie: Quindi dovrebbe essere tecnicamente da un punto di vista semantico, dovrebbe essere un pulsante. "Sì. Ma non esiste nel quadro”. Dico "Allora va bene, lo so quindi cosa facciamo?" Quindi di solito inizi a discutere di queste piccole cose e poiché sto davvero infastidendo i miei sviluppatori anche con l'accessibilità, questo è un altro livello in più per cercare di assicurarci di avere i componenti di base con cui funzionano bene. Ma anche che sono semanticamente come se non volessi avere pulsanti con gif all'interno di gif all'interno di gif. Altrimenti avremo problemi alla fine.

Drew: Immagino che iniziando un nuovo progetto che utilizzerà un framework dell'interfaccia utente, probabilmente dovrai iniziare con una sorta di ricerca sugli utenti.

Stefania: Sì.

Drew: È giusto?

Stefania: Dovresti. Devi. Quindi sì, di solito puoi avere tutti i componenti che desideri. Hai ancora bisogno di sapere di cosa hanno bisogno i tuoi utenti sulle pagine, come navigheranno? Devi creare un flusso. Quindi di solito anche prima di decidere un framework, quello che facciamo è andare dai nostri utenti, parlare con loro, cercare di capire le loro esigenze. Quindi al momento sono abbastanza fortunato perché gli utenti sono internamente alla banca. Quindi facciamo molti workshop con loro e devi immaginare che sia un'interfaccia super complessa. Stiamo migrando da qualcosa che è stato costruito, non lo so, penso 10 o anche 15 anni fa a qualcosa di tutto nuovo brillante usando Material-UI React. Quindi è un cambiamento piuttosto grande e devi capire che durante quei 15 anni, tutti coloro che volevano qualcosa potevano andare al supporto e poi chiedere al team IT di implementarlo. Quindi al momento la mia interfaccia è come 400 pagine con tabelle, all'interno di tabelle, all'interno di tabelle, con altre tabelle e cose che non dovrebbero nemmeno essere nelle tabelle.

Stephanie: Come se avessimo un sacco di cose che sono solo valore chiave, valore chiave, valore chiave. Quindi costruiscono la tabella con due colonne. Sono tipo "No, forse possiamo fare qualcosa di meglio con quello". Quindi al momento quello che stiamo facendo è fare alcune ricerche sugli utenti per capire i diversi obiettivi degli utenti. Quindi quello che abbiamo identificato è che quello che fanno con l'interfaccia, hanno alcuni obiettivi di pianificazione. Hanno bisogno di pianificare il loro lavoro. Quindi voglio sapere che questa operazione andrà a questo incontro, quindi ne ho bisogno in quel programma, cose del genere. Vogliono monitorare una cosa, vogliono riportare i dati. Quindi monitorare è proprio come guardare i dati e assicurarsi che tutto vada bene. Il reporting è essere in grado di sfruttare i dati, di farne qualcosa che vogliono condividere e di collaborare in qualche modo con i colleghi e tutto ciò che abbiamo scoperto discutendo direttamente con gli utenti.

Stephanie: E quello che abbiamo scoperto è che in realtà alcune delle cose che stavamo pianificando di migrare alla fine sono alcune delle cose più importanti su base giornaliera per l'utente. Quindi l'obiettivo dell'utente della pianificazione è uno dei più grandi al momento. Quindi ci stiamo davvero, davvero lavorando. Quindi sì, utilizziamo l'intervista e ora siamo nella fase in cui al momento siamo di altissimo livello dicendo che va bene, dobbiamo costruire la shell, dobbiamo capire la navigazione. Ma al momento non abbiamo esaminato tutti i dati e ora è quello che faremo. Ed è interessante perché abbiamo molti tavoli e abbiamo detto che possiamo o andare in un modo non intelligente e semplicemente inserire i tavoli nella nuova interfaccia e abbiamo finito, oppure possiamo dire, ok, proviamo a capire cosa quelle tabelle sono, per cosa usano i nostri utenti questa tabella?

Stephanie: E poi forse alcune delle tabelle potrebbero essere visualizzate come visualizzazione dei dati e quindi per farlo è necessario comprendere l'intera attività in modo che i dati abbiano un senso. Quindi, se hai un bel framework e dici, ok, usiamo questo grafico ... penso si chiami framework JS del grafico. Hai un sacco di cose, puoi avere istogramma, grafici a torta e grafici e tutto il resto, ma a un certo punto hai ancora bisogno di un designer che ti aiuti a decidere. Ok, questi dati, hanno senso se li mostriamo in un grafico o ha più senso mostrarli come una torta perché vogliamo mostrare parte del tutto, o vogliamo confrontare l'evoluzione di un paese negli ultimi 10 anni, allora un istogramma è più interessante. Quindi, in base a ciò che l'utente vuole fare con i dati, li visualizzerai in un modo completamente diverso.

Stephanie: E di solito non è un lavoro di sviluppatore farlo. Il nostro sviluppatore è un ragazzo super intelligente. Mi dispiace, ma onestamente lavoro con sviluppatori di ragazzi, vorrei avere delle donne, ma no. Nessuno di loro sono donne. Ragazzi così super intelligenti ma non sono super qualificati per dire, ok, questi dati dovrebbero essere visualizzati così, così, così e così. Quindi alla fine hai ancora bisogno che alcuni designer vadano a parlare con gli utenti, capiscano cosa puoi fare con i dati e questo va ben oltre il semplice dire, ok, questa dovrebbe essere una barra delle schede o questa dovrebbe essere una navigazione a sinistra.

Drew: E dopo aver preso quel tipo di decisioni basate sul parlare con gli utenti. In genere riporteresti i prototipi o i progetti risultanti agli utenti per testarli di nuovo per vedere se capiscono, ad esempio, il tipo di grafico scelto?

Stephanie: Sì, in realtà l'abbiamo fatto molto, il che è davvero bello perché poi non sviluppi qualcosa finché non sai che sarà utile e utilizzabile. Quindi dipende. Se è più veloce sviluppare effettivamente la cosa perché hanno già la maggior parte dei componenti, quello che faccio di solito è fare una prototipazione su carta molto veloce e poi sviluppiamo la cosa perché è veloce, anche senza i dati. Se è qualcosa di complesso, qualcosa di veramente, davvero nuovo che richiederà molto tempo per essere sviluppato, allora diciamo, ok, progettiamo alcuni schermi e facciamo dei test direttamente sullo schermo. Quindi abbiamo uno strumento chiamato InVision, in cui fondamentalmente metti tutto il tuo design, puoi creare collegamenti tra le diverse parti. Il fatto è che dipende anche da cosa vuoi testare. Ad esempio, se vuoi testare i telefoni, è un incubo testarli in InVision perché le persone non possono davvero sentirli e soprattutto sul telefono cellulare, ad esempio.

Stephanie: Quindi è sempre un po' essere intelligente. Qual è il modo più veloce ed economico? È più veloce ed economico testare solo i progetti. È abbastanza? Per i moduli di solito, non proprio perché hai il completamento automatico di tutto il lavoro pesante che hai inserito nel front-end che in realtà ha l'utente a compilare un modulo, quindi per i moduli, forse è più efficiente creare effettivamente un modulo e testarlo. Ma per le cose nuove, sì, facciamo molti progetti. Passiamo agli utenti. Quindi al momento o facciamo uno contro uno, ma i miei utenti sono persone davvero impegnate. È una banca d'investimento europea, quindi non hanno molto tempo. Quindi quello che di solito facciamo è che se arriviamo a uno contro uno con gli utenti, facciamo alcune piccole riunioni, come più come focus group. Ed è anche interessante perché a volte hai una specie di confronto. Alcune persone dicono: "Sì, penso che funzioni per me perché lavoro così e così", e poi ci saranno altre persone che dicono, "Oh, lavori così? In realtà no, lo faccio così e così.

Stephanie: Quindi è anche interessante avere un po' di persone nella stanza e ascoltare solo la conversazione, prendere appunti e dire: "Oh forse allora potremmo farlo" e "Questo componente sarebbe meglio basandomi su ciò che sentito." E cose così.

Drew: Se stai lavorando con un pubblico più generale per il tuo prodotto. Quindi forse non gli utenti interni come te, ma più il pubblico in generale, ci sono modi economici in cui i designer possono ottenere quell'uso della ricerca? Ci sono modi più semplici se non sai direttamente chi saranno i tuoi utenti?

Stephanie: Dovresti sapere chi saranno, altrimenti fa il lavoro degli addetti al marketing prima di creare il prodotto. Ma sì, ad esempio, abbiamo eseguito alcuni test utente di guerriglia, ad esempio puoi ancora utilizzare InVision. Quindi puoi costruire alcuni prototipi in InVision e quindi reclutare utenti attraverso i social media, ad esempio. Stavo lavorando per un prodotto che aiutava, come si chiama, i meccanici delle concessionarie automobilistiche che riparano le cose e poi informano anche il cliente di riparazioni extra, cose del genere. Quindi avevamo già una comunità in crescita su LinkedIn e Facebook. Quindi quello che puoi fare è reclutare quelle persone. Puoi eseguire test a distanza, come se stessimo conversando in uno strumento come uno strumento online. Puoi fare un po' di condivisione dello schermo. Quindi lo abbiamo fatto anche per qualche progetto.

Stephanie: Vorrei solo darti un consiglio è testare lo strumento prima, perché stavo usando, si chiamava compare.in. Ma penso che abbiano cambiato il nome in Whereby o qualcosa del genere, ma è davvero nel browser che ho detto, va bene, è bello perché gli utenti non hanno bisogno di installare nulla ma gli utenti non erano su un vero computer. Erano in VM, in un Citrix e non avevano microfoni, quindi quello che abbiamo finito per fare è stato come se avessero usato il mio strumento per condividere lo schermo. Stavano cliccando sul prototipo e allo stesso tempo li avevo al telefono, come un telefono fisso, per parlare con loro direttamente. Quindi c'è sempre, questo è stato abbastanza economico perché è stata una giornata meravigliosa di reclutamento, penso che avessimo 10 utenti o qualcosa del genere. Sì, puoi fare molte cose anche se non puoi andare faccia a faccia, ho fatto molti test di usabilità direttamente su Skype o cose del genere. Quindi ci sono sempre dei modi economici per farlo.

Drew: Quando si tratta di scegliere un framework dell'interfaccia utente con cui lavorare, se questa è la strada che stai seguendo, è qualcosa che lasceresti solo agli sviluppatori o è qualcosa in cui dovrebbero essere coinvolti anche i designer?

Stephanie: Per me dovresti coinvolgere l'intero team. Come i designer, gli sviluppatori, forse anche gli architetti se ne hai alcuni, perché anche il modo in cui è costruito il framework potrebbe influenzare questo genere di cose. Sfortunatamente, la maggior parte delle volte quando arrivano sul progetto, il quadro era già deciso. No, in realtà è divertente, o è già deciso o mi chiedono di convalidare la loro scelta del framework, ma non ho fatto recensioni o ricerche. Non ho assolutamente idea di cosa ci sia nel progetto perché non mi hanno nemmeno mostrato i loro schermi. Dicono: "Sì, fai le tue cose. Possiamo usare questa struttura”. Non lo so. Bene, abbiamo uno schermo? Quindi hanno finito per mostrarti alcune schermate, che era un'app nativa di Windows che volevano migrare nel cloud. Hanno detto: "Sì, abbiamo solo bisogno dei pulsanti e soprattutto come forme e cose del genere".

Stephanie: Ma è davvero difficile dire: "Sì, scegli questo framework, abbiamo tutti i componenti di cui abbiamo bisogno". O come "Non andare se non hai un'idea approssimativa di quali saranno i tuoi contenuti, qual è la navigazione". Quindi penso che dovresti comunque avere una sorta di panoramica globale prima di scegliere i tuoi framework a meno che tu non sia sicuro al 100% di avere tutti i componenti. Ma ho la sensazione che la maggior parte delle volte la scelta del framework sia fondamentalmente basata su quali tecnologie piacciono agli sviluppatori al momento, hanno esperienza con un framework precedente? Abbiamo usato Ant in alcuni progetti solo perché alcuni sviluppatori avevano esperienza con questo e gli è piaciuto molto ed erano piuttosto efficienti nell'usare Ant. E per l'interfaccia utente di Material React è lo stesso. È come se lo sviluppatore lo avesse già utilizzato in progetti precedenti, quindi sono efficienti con esso.

Drew: Quindi deve esserci davvero un equilibrio tra ciò con cui gli sviluppatori si sentono a proprio agio, ciò che sanno, ciò che funzionerà con il loro stack tecnologico e quindi quali sono i requisiti del prodotto in termini di creazione di una buona interfaccia utente. E in qualche modo devi bilanciare i due per trovare la struttura ideale per questo.

Stefania: Sì. Ho una sorta di requisito specifico per alcuni progetti, che è... sono in Lussemburgo, abbiamo molte istituzioni europee e cose del genere, quindi abbiamo un requisito di accessibilità extra per alcuni di questi. E di solito quando è stato deciso il framework, non hanno verificato l'accessibilità del loro framework e poi tornano alcuni mesi dopo l'inizio del progetto dicendo: "Oh, ci abbiamo appena detto che c'è questa nuova legge e dovremmo essere accessibile ma non sappiamo come farlo”. Come sì, è un po' troppo tardi. Quindi per me, per scegliere un framework devi conoscere davvero tutti i vincoli all'inizio del progetto e se l'accessibilità è uno di questi devi testare i tuoi componenti e assicurarti che siano accessibili. Ma non sono uno sviluppatore React o Angular, ma sono abbastanza sicuro che sia super complesso trasformare un framework dell'interfaccia utente non accessibile in qualcosa di accessibile. Immagino che potrebbe essere un po' complesso ricostruire tutti i componenti, quindi cose del genere.

Drew: Se ti ritrovi a lavorare su un progetto in cui quel processo non ha avuto luogo ed è già stato scelto un framework dell'interfaccia utente, c'è il pericolo che l'interfaccia utente possa iniziare a essere influenzata dai componenti che già esistono all'interno di quel framework piuttosto che essere guidato dalle esigenze dell'utente?

Stephanie: Davvero, onestamente, la maggior parte dei progetti su cui ho lavorato, alla fine finisci per avere molti compromessi, anche se provi davvero a spingere. Quindi si tratta principalmente di equilibrio e discussione con gli sviluppatori. Quindi di solito quello che faccio è fare dei telai di filo, anche veloci telai di filo di carta, dì ok, in questa pagina avremo bisogno di quello e quello e quel componente, la prima cosa che faccio è chiedere allo sviluppatore se lo abbiamo nel nostro quadro in questo momento? Che cosa sembra? E poi decidiamo insieme, va bene, questo è un componente che farebbe il lavoro o va bene questo non farà il lavoro. Lo modifichiamo? Ad esempio, manteniamo ancora il componente ma lo cambiamo un po' in modo che faccia il suo lavoro, o costruiamo qualcosa da zero?

Stephanie: E alla fine della giornata, ovviamente, dipenderà dal budget. Quindi hai finito per fare dei compromessi. Ad esempio, andrebbe bene per piccoli componenti che non vengono quasi mai utilizzati se non sono perfetti e ci sono alcuni problemi. Ma per la navigazione principale, la struttura principale, le cose che vedi continuamente sullo schermo, ad esempio, questo deve davvero funzionare. Le esigenze dell'utente di capire come funzionano in modo efficiente e sì, è, come hai detto, trovare un equilibrio tra l'esperienza ideale che vorresti avere se non avessi alcun framework e quello che hai a portata di mano e il budget e anche il tempismo. Se diciamo, va bene, per questi sprint, la funzione deve essere completata alla fine di questo sprint, e poi dicono, va bene, ma se vuoi i tuoi componenti non finiremo mai la funzione alla fine di questo sprint, allora tu inizia a discutere, ok, finiamo questa funzione nella schermata successiva, ci prendiamo più tempo per farlo correttamente? E di solito dipende davvero.

Stephanie: La cosa che mi frustra di più è quando so che usiamo un componente di correzione del ritaglio e mi dicono tipo, Oh no, non preoccuparti. Lo sistemeremo più tardi. E sapevo che l'ultimo, purtroppo, non sarebbe mai potuto accadere. Quindi dipende dalla squadra. Ma dopo un po' hai l'esperienza e sai, questo arriverà dopo e o no? Sì, si tratta di compromessi. Quando lavori con questo tipo di strumenti.

Drew: In qualità di sviluppatore, una delle cose che mi piacciono dei framework dell'interfaccia utente è che spesso hanno uno stile predefinito. Quindi ciò significa che non ho necessariamente bisogno di un designer che forse mi aiuti con l'aspetto grafico di tutti i componenti. È qualcosa su cui dovremmo fare affidamento nei progetti? Solo lo stile predefinito e la fiducia che chiunque abbia prodotto il framework abbia fatto davvero un buon lavoro nella progettazione di quei componenti? O modelleresti tu stesso quei componenti?

Stephanie: Penso che dipenda davvero. Il problema, ad esempio, con Material-UI è che l'aspetto della tua app Web sarà fondamentalmente i prodotti Google configurati. Quindi, se in realtà non cambi il carattere, cambi alcuni colori e in qualche modo porti la tua identità di marca e lo fai, avrai un prodotto che assomiglierà a qualsiasi prodotto Google, il che potrebbe essere una buona cosa perché se i tuoi utenti sono abituati ai prodotti Google, potrebbe aiutarli a capirlo. Quindi di solito se non hai un designer nel team, hai qualche scelta? Come molti altri lavori che ho visto, sono dotati di temi personalizzati, quindi almeno puoi cambiare i colori. Penso che tu possa cambiare anche i caratteri abbastanza facilmente. Ma ancora una volta, come se cambi i colori e non sei molto bravo nel design o addirittura nell'accessibilità, forse i colori che utilizzerai si scontreranno, potrebbero avere problemi di contrasto.

Stephanie: Ad esempio, adoro l'arancione, ma è uno dei colori più fastidiosi con cui lavorare perché per avere un vero arancione accessibile, ad esempio, come pulsante con testo bianco, sembra quasi brunastro. E se vuoi avere questo arancione davvero brillante, hai bisogno di un testo scuro sopra per renderlo leggibile ma fa sembrare la tua interfaccia come Halloween alla fine della giornata. Sì, ti vedo ridere. Ma è vero. Quindi si tratta sempre di questo tipo di compromessi e dì che se sei uno sviluppatore e vuoi usare il framework così com'è e non hai un designer, penso che sia comunque meglio che non avere nulla e costruirlo da zero e allora è super complesso da usare. Ma il fatto è che solo perché hai i componenti non significa che creerai un'ottima interfaccia. È come i mattoncini Lego. Se hai i mattoncini Lego, va bene, va bene, ma puoi fare una bella navicella spaziale o puoi fare qualcosa che non tiene insieme e andrà in pezzi perché non avevi davvero un piano.

Stephanie: Quindi il design è qualcosa di più di questo. Il design consiste nel capire davvero cosa apparirà sullo schermo, come funzionerà. E conosco alcuni sviluppatori che hanno effettivamente la capacità di farlo. Quindi sono davvero bravi con le linee guida sull'usabilità e capiscono molte regole di progettazione, ad esempio. Quindi, quando si tratta di scegliere i componenti, sono davvero bravi in ​​questo. E conosco sviluppatori che non hanno idea di quali componenti scegliere e scelgono il primo che fa il lavoro. Ma dopo un po' non funziona più. Come le schede, ad esempio, avevamo un'interfaccia in cui alcuni sviluppatori sceglievano le schede. Penso che all'inizio abbia senso quando hai solo tre elementi. Ma poi c'erano 12 elementi sullo schermo e poi hai le schede che sono tre righe di schede, e tutte sono le stesse schede di livello uno, e ci sono schede all'interno delle schede. Quindi avevano il componente, sembrava carino perché usano il framework, ma non era davvero utilizzabile.

Stephanie: E ho avuto lo stesso con una finestra modale per esempio. Dove costruiscono i progetti senza un designer e dopo un po' penso che il cliente abbia chiesto sempre più cose in questo modale. Quindi sono finiti con una schermata con una tabella e quando fai clic su aggiungi una riga, apri un modale e in questo modale hai due schede, e poi in una di quelle schede hai anche un'altra tabella e poi hanno voluto aggiungi qualcosa in più, ero tipo, ok, forse possiamo mettere un modale sopra un modale. E ad un certo punto il designer risponderebbe, ok, se hai così tanto contenuto nel modale, non dovrebbe essere una finestra modale. Dovrebbe essere una pagina. Quindi, anche se hai il componente, hai comunque bisogno di un tipo di architetto per fare il piano e assicurarti che tutti quei componenti funzionino bene insieme.

Drew: Quindi, se come designer ti viene chiesto di cambiare lo stile di alcuni componenti, proveresti a cambiare tutto lo stile? Personalizzeresti tutto o ci sono alcune aree su cui ti concentreresti?

Stephanie: I colori Penso perché è la prima cosa che vedi, i colori possono effettivamente darti identità. Se hai una forte identità di marca, avere almeno i colori del tuo prodotto sui pulsanti o le icone e cose del genere, ti aiuta già a personalizzare il framework. Caratteri perché penso che sia facile, se il framework è ben costruito, di solito si cambia l'intera famiglia di caratteri da qualche parte e quindi dovrebbe essere una sorta di cascata sul resto del sito. Quindi colori e caratteri sono due semplici modi per personalizzare rapidamente il framework. Le icone sono un altro bel modo per conferire personalità, ma potrebbe essere difficile perché da quello che ho visto, la maggior parte del framework viene fornito con icone personalizzate o Font Awesome o come una libreria già integrata. Quindi, per sostituirle, è necessario prima un molte icone se vuoi sostituirle tutte. Quindi potrebbe essere un po' complesso. Ho anche visto framework che ti permettono di scegliere quale icon pack vuoi usare. come Font Awesome, Glyphicons e alcuni degli altri. Quindi questo è il tipo di cose che puoi personalizzare abbastanza facilmente.

Stephanie: E poi si tratta di aspetto grafico, ad esempio l'intestazione, di solito hai diversi tipi di intestazioni, piè di pagina. Come navighi in cose del genere. Quindi c'è già un sacco di piccole personalizzazioni che puoi portare in modo che non sembri Material-UI-ish, assomigli di più al tuo marchio e quindi puoi giocare con i raggi di confine, ad esempio. Sia che tu voglia pulsanti completamente arrotondati, sia che tu voglia pulsanti quadrati o desideri anche qualcosa nel mezzo come le ombre. Quindi alcune piccole cose che di solito sono facili da personalizzare perché la maggior parte di quei framework li ha nelle variabili CSS. Questo è il tipo di piccole cose che puoi personalizzare senza pensare a molti sforzi, ad eccezione di questi effetti a catena. Odio che. Lo combatterò. Spero che prima o poi lo cambino.

Drew: I guess things like that, that might seem obvious might seem just like a surface level effect, Do you think that would be easy to change and in this case it turns out it wasn't easy to change? Is that just a case of speaking to your developers to find out what's going to be easy to customize and what's not going to be easy?

Stephanie: Yeah, usually, especially if they're used to work with the framework, they know what's easy to change on it. It depends on the developer, I had discussion with one developer and I asked him if we can not have like uppercase buttons, because they are kind of a little bit hard to read, especially in the font we were using, he went into the documentation and say, I don't know if we can customize it because I can't see it in the API. I was like, what API? It's like CSS class, CSS definition. You remove the uppercase from the CSS and it's done. So he was like looking for an API to change just the font, how does the font look like. And I was like, yeah, but if there's no API for that, I think you can change it in CSS.

Stephanie: But then it's complex because if you have to change this in like all of the CSS line. So it's usually kind of a big discussion. It was the same… was like drop downs. So Material-UI, the React version we use, has some customized drop downs. So when you have a select box like form element, the select it opens these custom components and I don't know why but we have a big problem with that on Internet Explorer. We are going to migrate to windows 10 and Edge. I'm looking forward to it, but we are still Internet Explorer 11 at the moment. And what's happened is whenever you use or you open one of those components, it freezes the screen behind it and you have a scroll bar, so it kind of jumps around whenever you want to use one of those.

Stephanie: And at some point we discuss with the developer, is the customizing of that worth the screen jumping around whenever users click on that. And it's like, honestly for me, no, I prefer it not to jump and we use the select in the browser, then it will not look the same if our users have Edge and, no not Edge, IE. Or if some users are using Firefox, okay? So it will not look the same but it will be the native one and it will not make the page jump around every time someone clicks. So it's this kind of discussion also, do we want to customize it but then it's kind of clumsy or do we say, okay we are not going to customize it. We had the same debate with a scroll bar because we had another project we had drop-downs and they were 100 elements at some point in the drop downs. So there's an auto complete but you can still scroll inside the drop down. And the developer said, yeah but this is looking really ugly on IE, the default scroll bar.

Stephanie: And they investigated, they found JavaScript library that would let us have this really small little a scroll down you have on Mac and have it everywhere. Then we said, okay, is it worth investigating? We need to investigate, test it, put it everywhere, test all of the browsers. So we said we are going to do it, but only if it doesn't damage the performance and if he doesn't damage the rest of your experience, otherwise it's perfectly normal that the browser element don't look the same on any browsers. So at the end, don't customize everything.

Drew: I guess it's a collaborative team effort, then? Everyone needs to discuss and balance up again all the different performance factors, ease of customization and where that customization happens. So once you've got your UI framework in place, you've got all your components specified and built out and customized and styled to how you want them. I guess you need to document that in some way to maintain consistency?

Stephanie: So at some point as a designer what we usually do, we already document them in our sketch files. So we have the working files with every single screen and everything. And in the sketch files we have really specific art boards where we put all of the different components. So that if another designer works on the project, they know that the components already exist and they can just drag and drop it in a new page and reuse it afterwards. So we have this system where we document the components also we document the use, like when do you use this component? When do you use that one? Where is this one working better? So all of the different states for instance, like inputs, we have I think 10 of those, like a focus with a placeholder, without a place holder, with content like arrows and things like that. So again, we bring consistency and then the development parts, it really depends on the kind of maturity of the communication of the team. So what we are currently building is basically a library of components and we are also building the tool around it.

Stephanie: So my developer is currently building that and the idea is to build the component first in our kind of a sandbox, document it. Also he builds things where you can change the colors and if have a button for instance, you can change the icon, you can change the text to see if it will still work with longer text, smaller text, things like that. So we are building this sandbox and in the sandbox, you have a 'Read me' tab where you have documentation for how should this look, how should this component be used, when, how is it supposed to behave? Like auto complete for instance, seems to be something really, really easy, But if you start actually designing the flow of the auto complete, what happens when you put the focus in the field? Do you start auto completing or offering suggestion after one character after two, after three? If it's after three, what happens in the meantime?

Stephanie: So there's a lot of different questions about that that we also document, which is really going super deep into that so that if this auto complete gets implemented on another project or gets used by another team, they know exactly how it's supposed to work as well. So we kind of do the same. The two of us, so designers are documenting into the design tools and usually in the design tool we document the colors and shadows and gradients so that the developer don't have to look around and try to remember exactly what the hexadecimal code for this button was and things like that. So in the end it's kind of you have this UI framework that was super generic and you customized it, you made sure that the components you use are actually the ones that are going to help your user accomplish their goals.

Stephanie: Everything you've customized is kind of starting to become your own little design system. So at the end you're building a design system, but instead of building it from scratch, you're basically building it using React, Material or, what was the other one? Ant or something like that. So it's the same constraints.

Drew: Would you go back to user testing at this point after things have actually been built? Would you go back and test things with users again?

Stephanie: We have tests, like real people testing, like regression testing and making sure that everything works. Like when you click it works, when you hover it works, stuff like that. But yes in the end, especially if we didn't do a prototype, if we did the user testing in mockups, we want sometimes to test it again with the real users who have a feeling that everything is still working. So yeah, sometimes we go again into user testing at the end. We do that usually at the end of a few sprints where the features were implemented. So usually what happens is like we do the research, we design the feature into design tools, we do quick testing at the beginning, then it's implemented, we do tests to make sure it works. And then again we go back to the users.

Stephanie: And it's also interesting because we are building a community with the users. So they're actually quite eager to see that. The first testing was a little bit kind of a sneak peek, like, Oh, this is what it might look like. And then they are super curious about how it works and how it looks like at the end. So we go back usually in one-on-one testing for that or if we don't have the time, we do just like panels and also we deploy it. So sometimes we do AB testing also sometimes if we don't have time for the user testing one-on-ones, we deployed it and then we say, okay, it was deployed. If you have any feedback, please come back to us. Also if you see bugs, because sometimes we compete, the team missed a bug or something, so if we don't have time for re testing it, we still try to find and manage to find some ways to gather feedback even after it's deployed.

Drew: And over time, one of the things that might be a concern probably from a technical point of view is that you've built on top of a UI framework and then a new version of that framework comes out and things have changed. Is that a situation that you've experienced where a new version has come, your developers want to update but it might have implications on the design?

Stephanie: Yeah. The thing is we have test environments, so they're really quick and easy thing to do is like, okay, let's put in your version in one of those secure environment and see what is broken. So from when designers most of the time when they do a new version they tell developers, is it going to break? Like is this new version something completely new and it's not compatible with the old version? Or is this new version something that is just an announcement and you might not break that many things. So yeah, obviously sometimes when you put a new version it completely breaks, but this is again, then you have like testing stories and like technical investigation stories to decide if we are going to migrate or not. Also like from what I understand in some of the environment I worked on, they kind of encapsulated those in web components.

Stephanie: So they're already has kind of two different version of Angulars on some components, it was using one version on the other ones it was using the other one and from what I understood it works because then you only encapsulate what you need. So this apparently is also a solution is then you can use whatever version you want, but I'm not a developer but I feel at some point you'll be like, okay, this component is using that version of Angular and this one, this and this maybe kind of becomes super hard to maintain. Do you know?

Drew: Yup.

Stephanie: It does. Bene. So yeah, you make sure it still works, but I don't have the feeling that Material-UI are like those frameworks, even bootstrap for instance, they don't have any new version every year or something. It's a long lifecycle and in the case of my tool, I think this tool will be here for the next year, so we have eventually to update. But if you're building kind of a online tool, more like a B to B product. Most of the time you revise every three years or something. And usually there is a new technology. I was talking to a friend and they're currently working on a project where they're rebuilding and riffing on React. The first version was built three years ago with another technology. I really don't remember the technology, but they say, okay, we are three years later, they're already rebuilding it. And I think in like three years, they will re-rebuild it. So at some points if you're in like in B to C products, I even wonder if you update your framework or if you are going to change the design and rebuild it anyway in a few years from scratch.

Drew: Is there anything else that we should be considering when building on a UI framework?

Stephanie: I feel we covered a lot of things. Well, the thing is like, there's always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don't design or build in a silo and try to have other people at least look at what you've created to make sure that the components as a developer, that you used as a developer I really do wonder are going to do the job. And don't ask the designer to put paint on top of the framework at the end of the project because it's kind of already too late to do big infrastructure on changes. It might not work.

Drew: So at Smashing, we have books, we have conferences, and of course, we have Smashing Magazine, a website with loads of articles. We're all about learning. So what is it that you've been learning lately?

Stephanie: I've been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stephanie: Last lesson was actually super interesting. We were talking about visual illusions and how they work with your brain. So it's really super complex and there's… Apparently not everyone agrees on the explanation of most of those illusions, but it's interesting because I had a small psychology lesson, like I read books on cognitive sciences and things like that. So I already knew kind of the basics, but it's interesting to see like all the different aspects of psychology. So the interesting part of this course is it's an introduction but it explains to you kind have all the branches from say child development psychology to trauma psychology to intercultural psychology. So and then illusions and I think this week it's actually about cognitive psychology and how to apply psychology to interfaces. So all of those really, really interesting topics. And it's nice because it's an online class, so I'm basically learning stuff on my couch with some tea, and yeah, that's really, really cool.

Drew: Oh, that's super interesting. If you, dear listener, would like to hear more from Stephanie. You can follow her on Twitter where she's @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stephanie. Do you have any parting words for us?

Stephanie: Thanks for having me. It was a smashing experience.