Nella realtà rispondono a delle domande sul rapporto che hanno sia tra di loro come colleghi sia in relazione alla UX.
Come cambia un progetto:
Differenze tra quando è presente uno UX designer e quando non c’è.
Davide: In base alla mia esperienza lavorativa ritengo che la presenza di uno UX designer all’interno di un team di sviluppo sia essenziale. Si tende spesso a credere che per sviluppare un’applicazione web sia sufficiente trasporre in digitale una procedura manuale eseguita dall’utente. In molti casi lo sviluppo si limita ad una riscrittura di un software obsoleto con una nuova tecnologia e una UI moderna. In entrambi questi scenari la figura dello UX designer non viene utilizzata e il risultato nel migliore dei casi è sufficiente ma spesso l’utente lamenta inefficienza nel lavoro e non vede alcun vantaggio nel nuovo software. La presenza di uno UX designer permette di esplorare nuove strade, ridefinire workflow, cambiare punto di vista e approccio al problema. Solitamente questo porta ad un prodotto efficiente che migliora l’operativa di chi usa il software.
Quando sai che ti confronti con un team di sviluppo e quando, invece, è solo un progetto di design.
Andrea: Quando parliamo di un progetto di solo design possiamo dire di avere più libertà ma minor controllo su quello che poi sarà davvero il prodotto finito, e una grande incognita sulla quale possa essere l’effort tecnico rispetto alle soluzioni presentate. Può essere la migliore esperienza per l’utente mai realizzata ma quanto è complicato realizzarla? Quali sono i tempi di realizzazione? Con un team di sviluppo si ha il vantaggio di potere definire dei confini con i quali controllare eventuali leak in termini di tempo e costi oppure, allo stesso tempo, capire quali nuovi paradigmi possano essere messi in gioco per ottimizzare i nuovi flussi. Quello che non cambia in entrambi i casi è la necessità di capire, insieme al cliente quale sia la richiesta e come trasformare l’idea in qualcosa di utilizzabile.
Lavoro interattivo: non solo schermate consegnate ma confronto costante.
Che cosa ti piace di questo approccio? Cosa funziona e cosa non funziona.
Davide: All’interno di un team di sviluppo il confronto è fondamentale. La possibilità di confrontarsi costantemente con uno UX designer ha molti vantaggi in tutte le fasi del progetto:
- durante l’analisi e la progettazione di nuove funzionalità permette di verificare costi e fattibilità delle diverse soluzioni possibili;
- in fase di sviluppo permette di chiarire eventuali dubbi implementativi;
- nella fase di bugfixing o di modifiche richieste dal cliente permette di trovare soluzioni a basso impatto per limitare costi e tempi realizzativi. Come in tutte le relazioni ci possono essere alti e bassi ma nel nostro team la collaborazione solitamente funziona molto bene.
Cosa comporta in relazione con lo sviluppo (effetto cantiere)?
Andrea: Esattamente, la relazione con lo sviluppo aiuta a disinnescare dubbi tecnici e, sulla base della tecnologia utilizzata, modificare alcuni pattern o behaviour per ottimizzare funzionamento, tempi di realizzazione e costi. L’aggiornamento continuo dell’output, grazie anche al confronto costante con il team di sviluppo, è necessario a tenere aggiornate le due facce dell’applicazione per avere due binari sempre paralleli e ottimizzati. Apprezzo molto anche il lavoro in parallelo su eventuali change request dove io e Davide abbiamo fatto co-design direttamente su Figma e successivamente abbiamo verificato nel codice che le modifiche fossero implementabili.
Rapporto con il cliente: come cambia la gestione del cliente con uno ux designer nel team.
Davide: Il primo vantaggio che vedo nella gestione del cliente è la semplificazione delle comunicazioni: noi developer tendiamo spesso a dilungarci con tecnicismi che in molti casi possono confondere il cliente. La presenza di uno UX designer riesce a sintetizzare meglio i discorsi portando la conversazione su argomenti più confortevoli per il cliente. Il secondo vantaggio riguarda la raccolta dei requisiti che il software deve soddisfare. Molti clienti tendono a richiedere la soluzione che credono sia ottimale anziché raccontare le esigenze che li spingono ad acquistare un software. Lo UX designer riesce spesso ad incanalare il discorso su altri binari portando il cliente a descrivere scopi e obiettivi che vuole perseguire: questo solitamente porta ad una progettazione ottimale delle interazioni. L’ultimo vantaggio riguarda la validazione del prodotto da consegnare: l’occhio del progettista è ben allenato ad individuare eventuali bug presenti nel software da consegnare. Questo permette di anticipare i tempi di risoluzione dei problemi.
Andrea: Si aggiunge la possibilità di avere un layer che aiuti il team di sviluppo a definire al meglio le richieste sulla base degli obiettivi e delle priorità. Non è più il cliente che chiede un software ma sono cliente e CodicePlastico a iniziare un dialogo volto alla realizzazione del miglior prodotto possibile sulla base di tempistiche e budget. Spesso lo UX designer può accompagnare il cliente nella scelta di quelle che sono le feature obbligatorie per la messa in produzione dell’applicazione o comprendere al meglio gli obiettivi di business che portano valore. Dall’altro lato la possibilità del designer di condividere con lo sviluppo queste considerazioni porta un grosso vantaggio competitivo: la mediazione tra necessità e tempi e criticità di sviluppo è palese e chiara anche al cliente che può scegliere come procedere senza lati oscuri.
Strumenti e documentazione:
Manna o dannazione?
Davide: La questione strumenti e documentazione è forse la più spinosa. Negli anni abbiamo fatto molti passi avanti: sono lontani i tempi in cui si cercava di sviluppare un frontend partendo da un file psd. Strumenti come Sketch, Figma, Zepplin, Invision hanno semplificato le operazioni ma non sempre sono sufficienti: se da un lato semplificano le operazioni di misurazione, estrazione degli assets e di individuazione di font e colori dall’altro non riescono a mostrare in maniera semplice le interazioni possibili e i diversi stati che la UI potrà assumere. In CodicePlastico cerchiamo di sopperire a queste mancanze con una documentazione che descriva i flussi applicativi: per far questo ci affidiamo a semplici note o ad una documentazione più complessa su Notion. In molti casi serve comunque un confronto diretto per dirimere le interazioni meno comprensibili. E’ anche per questo motivo che ritengo un grosso valore il fatto di avere UX designer all’interno del team perché questo permette un confronto continuo e riduce i tempi dei feedback.
Muoversi tra librerie e modi di scambiarsi le informazioni.
Andrea: Consegnare un design system, tutte le schermate di un’applicazione, i flussi o le interazioni con le relative animazioni è sicuramente l’output migliore per tutti gli attori in gioco, sia per i designer che mettono in chiaro il dove si sia arrivati, sia per i developer che hanno un punto di partenza dal quale partire con lo sviluppo e soprattutto per il cliente che ha sottomano non solo delle immagini ma un prototipo. Per quanto Figma e gli altri tool di design possano aiutare i developer a confrontarsi con i designer anche in asincrono, non siamo ancora riusciti a avere una singola sorgente di informazioni che, al momento, viene affiancata da altri strumenti come meeting notes o Notion (per documentazioni più complesse) che completano il range di informazioni necessarie ad avere una visione d’insieme.
Ti viene in mente altro sul tema?
Davide: Come già scritto in precedenza, ritengo che la presenza di un team di UX all’interno della nostra azienda sia un vero plus sia per noi sviluppatori che per i nostri clienti. Dobbiamo ancora affinare la comunicazione e soprattutto trovare dei tool che possano migliorare l’interazione ma siamo già sulla buona strada.
Andrea: Credo che UX/UI e DEV siano inscindibili e, per quanto ci sia ancora un po’ di strada da fare per essere a regime, penso che questo lavoro di condivisione tra team stia già portando vantaggi a CodicePlastico in termini sia lavorativi che di crescita personale.
