Immagina di dover passare un progetto a un collega perché hai completato la tua parte. Quindi, un Handoff in questo contesto sarebbe quando tu prendi il progetto e lo passi fisicamente o digitalmente al tuo collega, in modo che possa continuare a lavorarci. Quindi, un Handoff non è altro che un “passaggio”. Ed è qui il dilemma: come si fa un Handoff per bene senza fallire nell’intento?
Problema
Per iniziare, direi che non è solo “passare” o “condividere” il file ad un’altra persona, soprattutto nel caso dei UX Designer. Quello che si pratica in Italia, almeno, è che quando si completa un lavoro, lo si passa a uno sviluppatore e poi non si sa cosa accade o come continuare il percorso.
Uno dei primi problemi per me è il fraintendimento tra noi, UX Designer, e gli Sviluppatori. Per illustrare la mia frustrazione, ti racconto un episodio. Ricevetti una notifica che diceva così: ‘Hai 1 min. per me?’. Questo è tutto, nulla di più. Immediatamente scatta l’ansia! Non si sa di cosa si tratti. Immagina di essere impegnato in un altro progetto e quel dubbio, che per uno sviluppatore rappresenta un minuto, per me significa dover abbandonare tutto, cercare di ricordare a quale progetto si riferisce, fare memoria sul tipo di cliente o progetto, accettare un’ennesima interruzione per risolvere al volo un dubbio che potrebbe essere stato presentato in modo poco chiaro e che richiede molto più tempo di quanto inizialmente immaginato. Devo poi fornire una soluzione ‘miracolosa’ per non interrompere il suo sprint di lavoro.
Un altro “piccolo” problema sono i silenzi, quei vuoti cosmici che si creano dopo aver portato a termine un progetto UI, dove praticamente si sa meno di zero. Quindi, rimanendo in tema, ricevi un altro messaggio sui canali dove ci ritroviamo tutti, tipo l’immancabile “General”, che lancia la perla: “Hey, hai visto l’App? Hanno pubblicato!” e poi ci delizia con un epico “Auguri a tutti”.
E arrivo all’ultimo, ma non meno importante, dilemma. Partiamo da questa immagine.
Immagina queste due schermate apparentemente complete. Si tratta di un flusso di schermate nel quale rappresentano cosa dovrebbe accadere: quando si fa lo scroll e l’immagine supera una certa distanza, appare l’header o la testata diversa che rimarrà fissata per tutta la lunghezza della pagina. Quindi dal punto di vista del design, sembrano contenere tutto il necessario affinché uno sviluppatore possa iniziare il lavoro, vero? Ahimè purtroppo, la realtà è ben diversa.
La percezione può essere ingannevole quando si considera solo la parte di design delle schermate, poiché sembrano complete e sufficienti per gli sviluppatori. In altre parole, pensare in questo modo, ossia “sembrano complete per gli sviluppatori“, o il classico “è palese che si capisce se uno fa lo scroll poi…”, è la prima cosa/regola che dobbiamo correggere o applicare se vogliamo che l’handoff sia preciso.
E arrivo al punto. Gli sviluppatori non sono Designer e non devono “coinvolgersi” più di quanto necessario. La loro attività rimane più schematica, quasi sempre da sprint (indipendentemente dalla sua durata), dove tutto ciò che devono sviluppare deve essere molto chiaro, e non solo. L’idea stessa di aver fatto le prime revisioni con loro, non implica necessariamente che siano molto bravi a ricordare ciò che deve fare un evento o le cose in cui hanno dato per scontato in maniera superflua “tanto ci vuole niente per farlo”, perché nel momento dello sviluppo ciò che conta è ciò che hanno davanti per realizzare. Vai a dire o sottolineare poi “Ma se mi hai detto che non ci voleva niente”.
Per noi, designer, è chiaro come ci aspettiamo che debba essere una transizione, ma immaginare non equivale a trasmettere questo conoscimento agli altri. Per chi dovrà lavorare con queste schermate, l’unica cosa che vede è che a un certo punto appare un header, ma non sa né cosa deve fare né come deve apparire. Ecco perché, proprio in questo caso, accade la peggiore cosa possibile: lo sviluppatore si trova ad › i m p r o v v i s a r e ! ! ! ! !
E se non bastasse, credi che lo sviluppatore, vedendo che non sa cosa deve fare, verrà da te a chiedere? Questo accade solo nei film. E se dovesse accadere, non sarebbe così positivo, poiché proprio queste piccole incertezze possono generare caos e INTERRUZIONI. Ma stai tranquillo, nel caso dei Dev, non accade quasi mai, anche se non si può mai dire mai.
Soluzione
Sì, ovviamente c’è una soluzione! Nei casi già testati in progetti precedenti, la pratica migliore da seguire come un mantra è l’allineamento, cercando di allinearsi il più possibile. Ad esempio, appena si ha una bozza o uno schizzo appena abbozzato del progetto da realizzare, si fa una foto, si mette in FigJam o Miro e si dialoga con gli interessati, soprattutto con i Dev, per chiarire e discutere. Non è tanto importante avere qualcosa di definito a livello di UI, bensì avere qualcosa di abbastanza concreto da poter discutere, in modo da individuare tempestivamente eventuali problemi o punti da rivedere per risolverli.
Attenzione però, l’allineamento non è una cosa monouso, del tipo “lo fai una volta e poi lo dimentichi”. Si tratta, come ho detto prima, di un mantra o rituale da seguire e rispettare in maniera quasi disciplinare e metodica, ovvero allinearsi spesso. Crearsi una vera e propria regola, organizzando incontri periodici per rivedere il lavoro svolto, discutere e individuare tempestivamente eventuali disallineamenti.
Non creare tutte le schermate solo per far comprendere un’interazione con un elemento. Se ci sono vuoti, come nell’immagine sopra, dove non è chiaro il comportamento desiderato dell’header dopo lo scroll, realizza un prototipo su Figma, Marvel o Principle per comunicare chiaramente il risultato finale desiderato. Per il resto, si redige una documentazione con le specifiche degli elementi. Personalmente, la produco su Figma perché è più comodo per me perché rimane tutto in un unico file, e facilita anche chi deve interagire con il progetto, compresi gli sviluppatori, per comprendere eventuali lacune che possono emergere durante lo sviluppo.
Ad esempio, nei casi in cui una schermata presenta diverse varianti di un elemento specifico, non è necessario duplicare molte volte la stessa schermata per apportare piccole modifiche. Questo approccio non aiuta gli sviluppatori poiché devono cercare di capire cosa è cambiato in un cumulo di informazioni, colori e testi. Invece, risulta più pratico isolare il componente specifico e collocarlo accanto con tutte le sue varianti.
L’ordine per gli sviluppatori è una cosa che apprezzano enormemente, e non solo. Si tratta di perfezionare al massimo il flusso lasciando nella consegna, appunto Handoff, solo ciò che è indispensabile sia per lo sprint che per il progetto nella sua interezza. Organizzare i flussi di schermate in modo molto chiaro, evitando l’uso di termini in inglese o di terminologie alla moda che possano risultare confusi. È importante descrivere il processo fino all’ultima schermata, ad esempio se si tratta di un flusso di registrazione, includere anche le schermate superficiali di successo, come quelle che appaiono quando l’utente riceve un’email di conferma e deve cliccare sul tasto per attivare l’account.
Dopodiché, sotto ogni schermata, allegare un documento con le specifiche riguardanti solo quei componenti che ritieni debbano essere necessariamente sviluppati o presi in considerazione. Questo può includere gli stati degli stili, i colori, le forme e, soprattutto, come già menzionato prima, le possibili varianti.
L’idea della documentazione con le specifiche si basa sugli step classici, fornendo dettagli essenziali. Non si tratta di creare una documentazione mastodontica, bensì di concentrarsi su ciò che è strettamente necessario. Esempio:
Step 1) Quando l’utente accede alla pagina, visualizza il tasto per registrarsi. Il tasto ha i seguenti stati: Default, Hover, Pressed e Disabled.
Step 2) Se l’utente clicca sul tasto “Registra” e il form è compilato correttamente, lo spinner di attivazione deve essere visualizzato in questo modo.
E così via, dettagliando ogni azione e stato previsto nel flusso dell’utente. Questo approccio fornisce una guida chiara per gli sviluppatori, delineando con precisione cosa aspettarsi e come comportarsi in diverse situazioni durante lo sviluppo del progetto.
Un’approccio che trovo particolarmente interessante è l’osservazione attiva. Quando hai l’opportunità, sia in presenza che a distanza con lo schermo condiviso, coinvolgi gli sviluppatori in brevi interazioni o perché no anche dei piccoli “test”. È impresionante cosa puoi imparare dal tuo lavoro. Non si tratta solo di rimanere in silenzio, senza fornire giustificazioni, ma di comprendere come affrontano il progetto quando viene passato dal lato del design. Questo tipo di osservazione può offrire preziose insights sulle sfide che possono emergere e sul modo in cui gli sviluppatori interagiscono con il lavoro proposto. Tale approccio può aiutare a ottimizzare la collaborazione tra il team di design e quello di sviluppo.
