7 minuti di lettura
Iniziai a scrivere questo articolo davvero molto tempo fa e nel frattempo ho letto sempre più articoli come “I 10 passi per condividere il design agli sviluppatori” o “Le N° cose da fare e le cose da fare quando lavori con un developer“.
Credo riscuotano molto successo tra il pubblico di designer in cerca di guide prima di eseguire alcune delle loro attività quotidiane.
La maggior parte di queste guide include suggerimenti tattici su come etichettare i file di progettazione, organizzare le cartelle o esempi di documentazione che hanno dimostrato di funzionare per 10 team su 10.
MA
Le guide su come distribuire i condividere i propri progetti agli sviluppatori sono tanto facili da seguire, quanto limitate nel tempo. Siamo sicuri che tali consigli possano essere sempre validi anche nel futuro?
La verità è che ci sono mille modi diversi di organizzare i file, etichettare le cartelle o gestire il “controllo delle versioni”.
Indicare un modo giusto di farlo può portare alla visione miope che ogni team abbia le stesse esigenze o che ogni azienda e operi allo stesso modo.
Gli strumenti che utilizziamo cambiano ogni giorno.
I designer lavorano in aziende di ogni forma e dimensione, ognuno con il proprio metodo, il quale influenza notevolmente il flusso di lavoro, gli strumenti e i processi. Anche all’interno della stessa organizzazione, le tempistiche e le configurazioni del team possono apparire completamente diverse tra un progetto e l’altro.
Una grande collaborazione si basa sui princìpi, non sulle tattiche
In questi anni, il modo in cui designer e sviluppatori collaborano è cambiato molte volte. Alcuni metodi hanno funzionato meglio di altri – e in molti casi, un metodo che ha funzionato bene con un progetto ha finito per essere un disastro con il progetto seguente.
Se dovessi scrivere linee guida specifiche, dovrebbero essere riscritte ogni poche settimane, quindi preferirei concentrarmi sui princìpi, che non solo durano più a lungo, ma tendono anche a rendere più agile il processo per i team di progettazione di tutte le forme e dimensioni.
L’elenco che segue delinea i princìpi di come i designer dovrebbero investe almeno un terzo della loro giornata lavorando con sviluppatori su iterazioni e implementazioni.
1. Lo sviluppatore è il tuo utente
Che cosa succederebbe se curassimo i file che inviamo agli sviluppatori relativi ai nostri progetti (e eventuale documentazione) come se fossero per i nostri utenti finali?
Come designer, teniamo sempre a mente le esigenze e i punti deboli dei nostri utenti quando immaginiamo l’esperienza di un prodotto.
L’utente finale non interagirà mai con i nostri progetti: interagiranno con il prodotto finale, creato dagli sviluppatori, sulla base della nostra documentazione.
Ciò significa che i veri utenti di ciò che stiamo offrendo in quella fase del progetto sono gli sviluppatori.
Una volta incorporata questa nozione nella nostra pratica, ogni singola decisione sul nostro flusso di lavoro inizia con gli sviluppatori al centro.
Analogamente al modo in cui conduciamo ricerche con gli utenti finali, possiamo avviare sessioni di intervista con il team di sviluppo all’inizio di un progetto per comprendere le loro preferenze, il loro viaggio, i loro punti deboli e trovare un modello di lavoro che soddisfi le loro esigenze.
In che modo gli sviluppatori vogliono ricevere documentazione? Quante volte? Attraverso quali canali?
Quanti dettagli sono troppi dettagli?
Qual è il giusto equilibrio tra documentazione scritta e visiva?
Qual è il modo più efficiente per quel particolare gruppo di sviluppatori di consultare le regole non visive di come dovrebbe funzionare l’intero sistema?
Come si allinea con altre parti del prodotto e altri gruppi all’interno dell’organizzazione?
Il team potrebbe voler creare una wiki per il progetto; forse la tua documentazione è in realtà un incontro che si svolge due volte a settimana e funziona più come una sessione di domande e risposte. Alcuni team non inizieranno lo sviluppo pratico fino a quando tutti i casi d’uso non saranno documentati; altri team sono più flessibili nel definire le regole attraverso iterazione e sperimentazione.
Allo stesso modo in cui adattiamo le nostre soluzioni di progettazione alle esigenze degli utenti, dovremmo adattare il nostro flusso di lavoro di progettazione per soddisfare le esigenze dei nostri partner di sviluppo.
2. L’unica certezza è il cambiamento
I designer devono essere flessibili.
Non solo dobbiamo modificare il nostro processo di lavoro per adattarci alle diverse configurazioni del team, ma anche adattare il nostro flusso di lavoro man mano che il progetto si svolge.
Con pochissime eccezioni, dovremo adattare la nostra documentazione e il nostro flusso di lavoro ogni volta che iniziamo un nuovo progetto.
Man mano si acquisiscono nuove esperienze e impariamo a produrre documentazione in modi differenti (il che potrebbe funzionare bene in un determinato contesto ma non necessariamente in un altro).
Non esiste un modo per gestire la documentazione del progetto e collaborazione che funzioni in ogni team.
L’altro aspetto è la personalità dello sviluppatore individuale. Potremmo lavorare con uno sviluppatore che apprezza davvero quando un designer si avvicina alla propria scrivania, in modo che possano lavorare insieme, letteralmente fianco a fianco, per affrontare sfide specifiche e un altro tipo sviluppatore, che fa parte della stessa squadra, ma potrebbe preferire tenere le cuffie accese per mantenere il flusso, e fare in modo che le domande vengano affrontate tramite messaggi Slack o commenti su post-it.
Non tutto è sotto il controllo dei designer. L’unica certezza è il cambiamento.
Ma su ogni progetto, è possibile prevedere cambiamenti che possono influire sul lavoro: nuovi stakeholder che si uniscono al team, bruschi cambiamenti nelle date di rilascio, vincoli tecnologici, e molto altro.
Imparare a identificare le meccaniche di collaborazione invisibili all’interno di un team e prepararsi ad adattare rapidamente il flusso di lavoro non solo eviterà le frustrazioni a breve termine, ma ti renderà un collaboratore migliore a lungo termine.
3. Un progetto non è mai concluso
Quando abbiamo completato tutte le task di un progetto, abbiamo svolto solo metà del lavoro.
Soprattutto nei progetti più grossi – ma anche in quelli più agili – c’è questo “malinteso comune” che il lavoro di un designer sia finito non appena tutte view sono state progettate.
Dopo aver completato gli “elementi tangibili”, come ad esempio i prototipi di design, è possibile creare la falsa illusione che le responsabilità del progettista siano state adempiute.
La realtà è che dovremmo pensare di meno agli schermi e di più alle funzionalità – e le funzionalità si verificano principalmente dietro lo schermo.
La vera sfida inizia quando gli sviluppatori iniziano a frugare e a porre domande sui nostri progetti.
Più vincoli e regole vengono aggiunti, più è difficile soddisfare i nuovi requisiti preservando la semplicità e la chiarezza dell’esperienza.
Questo è il momento della verità: il punto in cui la maggior parte dei team è in grado di tracciare il confine tra bravi e grandi designer.
Se l’esperienza finale non è stata implementata come previsto, questa è la nostra responsabilità quanto quella di chiunque altro.
Il nostro ruolo è quello di creare esperienze intelligenti e facili da usare, non solamente modelli che siano belli da vedere.
Ciò significa che siamo responsabili del prodotto finale che viene implementato dai nostri team, tanto quanto chi lo realizza.
4. Meno, ma meglio
Invece di sentirsi frustrati quando i responsabili riducono le funzionalità del prodotto per ottenere un MVP, i designer potrebbero trasformare ciò in un’opportunità per aumentare la qualità dell’esperienza all’interno del set di funzionalità che stiamo offrendo.
Il visionario designer tedesco Dieter Rams è diventato uno dei designer più riconosciuti e influenti del XX secolo.
Un convinto sostenitore del funzionalismo, la sua visione razionale del design è riassunta dalla sua famosa frase: “Less, but better”.
Mentre all’epoca si riferiva ovviamente al design industriale, il concetto è ancora valido applicato a prodotti e servizi digitali che stiamo creando al giorno d’oggi.
Man mano che il design si evolve, i product manager iniziano a dare la priorità alle funzionalità e i progettisti vedono molto del loro lavoro – la loro visione iniziale del prodotto e la dell’esperienza – “ridursi” ad un MVP, il che può essere frustrante. I migliori designer che conosco sono in grado di trasformare quella frustrazione in un’opportunità. Capiscono che va benissimo offrire meno funzioni, purché siano offerte meglio concentrandosi sulla qualità dell’esperienza.
Per noi designer, meno funzioni da progettare significano:
- Più tempo per documentare tutto correttamente: transizioni, stati, animazioni, ecc.
- Lavorare in stretta collaborazione con gli sviluppatori per assicurarci di comunicare correttamente la nostra visione originale.
5. La passione è contagiosa
In alcune aziende, gli sviluppatori non sono coinvolti nelle prime fasi di ideazione, esplorazioni del design e discussioni strategiche sui prodotti.
Come possiamo aiutare a colmare questa lacuna e aiutarli a capire il quadro più ampio di ciò a cui stanno contribuendo/contribuiranno?
Mentre gli sviluppatori hanno una certa comprensione del contesto aziendale in cui viene sviluppato il prodotto, potrebbero non cogliere tutte le diverse prospettive che abbiamo come designer.
I designer rappresentano la voce degli utenti nel team, ma spesso diamo per scontata la nostra naturale capacità di metterci nei panni dei nostri utenti e dimentichiamo che possiamo avere un ruolo importante nel diffondere tale sentimento all’interno del nostro team.
La nostra empatia, la nostra attenzione agli utenti e la nostra passione, sono risorse preziose che possiamo usare per ispirare gli sviluppatori e aiutarli a capire non solo come una determinata funzionalità dovrebbe funzionare, ma come avrà un impatto sulla vita delle persone e perché no, sull’agenzia stessa.
Il design è uno sport di squadra
Il vecchio stereotipo del “designer rockstar” sta (per fortuna) scomparendo . Man mano che i team digitali crescono e i progetti diventano più complessi, i designer vengono apprezzati per le loro capacità di collaborazione e abilitazione del team piuttosto che per risultati specifici. Definire i principi di come vogliamo gestire la collaborazione all’interno dei nostri team è il primo passo per essere più produttivi nei processi di lavoro.
