UX Design non serve a nulla e rallenta lo sviluppo

Aggiungere le attività di design a un processo di sviluppo software non è semplice. Per questo abbiamo deciso di condividere il nostro approccio.

Autore

Luca D'Incà

30 ott 2020

“Le attività di design ci rallentano”, “Non abbiamo tempo di fare ricerca utente, dobbiamo mandare in produzione la funzione”, “Ci penseremo più avanti”. Ci capita di sentirlo spesso, sia dal nostro team di sviluppo sia da team esterni con cui collaboriamo. Perché?

Perché aggiungere le attività di design a un processo Agile è complicato. Spesso è frustrante sia per i developer, che per i designer e sfocia in prodotti mal progettati e malumori nel team.

Per questo, dopo tanti progetti, ci siamo resi conto di dover migliorare. Abbiamo iniziato analizzando il nostro processo e i problemi dei team coinvolti.

La soluzione che abbiamo trovato è composta da tre cambiamenti:

  1. Il team di design ha iniziato a lavorare a Sprint, come faceva già il team di sviluppo
  2. Abbiamo esteso la pianificazione delle attività di design e il suo anticipo rispetto al team di sviluppo
  3. Abbiamo introdotto un breve confronto giornaliero tra i membri dei team per condividere lo stato del progetto

Ma come ci siamo arrivati? Cos’è cambiato nel nostro modo di lavoro dopo questi cambiamenti? Te lo racconto.

Da dove siamo partiti

I progetti di cui parlo in questo articolo coinvolgono tutto il team e hanno una durata di almeno sei mesi, o più.

Il team è composto da:

  • design team di Belka
  • il nostro team di sviluppatori o quello del nostro cliente o ibrido

Il product team lavora verso degli obiettivi e non su una specifica definita a priori. Questo approccio ci permette di lavorare verso una direzione concreta, misurabile e di valore. Ma soprattutto di canalizzare il team verso un traguardo chiaro.

Di contro questo approccio lascia spazio ad una naturale incertezza sulle attività. Per affrontare questo problema utilizziamo i principi della metodologia Agile, cercando di adattarla alle nostre esigenze e alle realtà con cui collaboriamo.

Agile si adatta bene alle attività di sviluppo — è nato per questo. Tuttavia aggiungere al processo anche il team di design non è stato altrettanto facile.

Aggiungere al processo Agile anche il team di design non è facile

Con l’introduzione delle retrospettive, ci siamo accorti di come il lavoro del team di design non venisse capito. Gli obiettivi e le cause che avevano portato ai mockup non erano compresi e il materiale veniva trattato come un mero output grafico.

Che succede? Indaghiamo 🕵️‍♀️

Per inquadrare meglio la situazione abbiamo deciso di applicare le metodologie della progettazione (quelle che usiamo anche nel design di prodotti digitali) ai nostri processi di design e sviluppo. Ci siamo focalizzati su come individuare i problemi e su come evitare la classica sindrome da Design VS Sviluppo.

Per cominciare ci siamo lanciati in una fase di interviste a tutti i partecipanti coinvolti.

Intervista ad un membro del team

Feedback dagli sviluppatori

Come primo passo abbiamo intervistato gli sviluppatori. Questo è quello che ci hanno detto:

🤔 Non capiamo cosa fanno i designer
Non c’è visibilità sulle attività. L’unico output sono mockup e documentazione. Non vediamo molto del loro lavoro e non capiamo cosa fanno.

📅 La pianificazione dei passi successivi è scarsa
Costruire una base tecnologica robusta richiede pianificazione e uno sguardo che va oltre la sprint di sviluppo corrente.

🙆‍♂️ Le sprint hanno parti di design incomplete
Il team di design non riesce a rispettare sempre le tempistiche e quindi il lavoro dello sviluppo è penalizzato.

Feedback dal team di design

Per chiudere il cerchio abbiamo intervistato anche la controparte, cioè i designer. I problemi per loro sono:

💔 Le user story sono incomplete
In Belka i designer scrivono le user story e spesso, durante lo sviluppo, emergono corner case non considerati durante la fase di design. È impossibile che non succeda mai, ma va comunque gestito.

🚨 Non riusciamo a pianificare i passi successivi perché stiamo rincorrendo le emergenze
Le storie incomplete obbligano il design a correre ai ripari per la sprint corrente invece che a pianificare il lavoro successivo.

🕵️‍♂️ Le attività di ricerca sono bloccate a causa dei punti precedenti
Il team lavora solo in emergenza. Il risultato è che si accumula debito di design e si aumenta il divario tra design e sviluppo.

Possibili soluzioni

Per prima cosa mi sono documentato. Il rapporto tra sviluppo e design non è un argomento nuovo. Medium, libri e talk (riferimenti a fine articolo) sono un ottimo materiale per iniziare ad approfondire l’argomento.

La lettura migliore che ho trovato su questo argomento è il report Effective Agile UX Product Development 3rd Edition. Il report raccoglie numerose ricerche e interviste fatte dal Nielsen Norman Group ad aziende e team con problemi molto simili. Te lo consiglio!✌️

Le aree da migliorare

Dopo le interviste ho raggruppato i problemi. Li ho divisi in due categorie:

📢 Problemi di comunicazione I team non si capiscono tra loro. Non capiscono le reciproche attività e questo danneggia tutti.

⚙️ Problemi di processo La gestione dei punti poco chiari delle user story è costoso e influisce negativamente sulle attività di pianificazione del design.

Per affrontare i problemi ho deciso di introdurre alcune modifiche graduali. Proprio come durante una progettazione iterativa, il processo è stato suddiviso in 4 stati

  1. Introdurre un cambiamento piccolo ma con un reale impatto sul processo
  2. Testare con un solo team
  3. Raccogliere feedback
  4. Se l’esperimento funziona provare ad estenderlo ad altri team, altrimenti lasciar perdere

Processo iterativo

Daily Stand-up

Il primo esperimento è stato sui problemi di comunicazione. Per migliorare abbiamo deciso di introdurre i product designer al daily stand-up.

⏲ Cos’è il daily stand-up

Ogni mattina il team di prodotto dedica 15 minuti a discutere le cose fatte il giorno prima e confrontarsi sui punti che bloccano il lavoro. Questa pratica è chiamata Daily Stand-up ed molto diffusa nel mondo Agile.

Questo primo esperimento è stato subito recepito positivamente da tutto il team. I cambiamenti non si sono fatti attendere:

  • Il team ha iniziato a riconoscere e risolvere subito le situazioni bloccanti causate dalla progettazione
  • Tutti sono più aggiornati rispetto alle attività del team di design, soprattutto per le fasi di ricerca utente
  • È aumentata la consapevolezza delle attività svolte da parte di tutti

Gradualmente, dopo aver raccolto i primi feedback, ho integrato questa pratica in tutti gli altri product team. Ho agito da facilitatore durante i primi daily stand-up per evitare gli errori più comuni. Vuoi qualche esempio?

Time timer

Come può andare storto il Daily Stand-Up, e come prevenirlo

Questi punti quando non sono gestiti possono far deragliare questo tipo di attività.

I 15 minuti devono essere 15
Se l’evento è troppo lungo perde di valore e viene visto come una perdita di tempo. Per rendere chiaro a tutti lo scorrere del tempo consiglio di utilizzare un time-timer o il semplice conto alla rovescia dello smartphone. Non abbiate paura di tagliare le conversazioni che si dilungano su argomenti poco rilevanti.

Design e sviluppo devono avere lo stesso peso
durante lo stand-up e va incentivata la comunicazione. Non si deve parlare solo di ricerca utente, ma neanche solo di problemi tecnici al backend.

Se possibile, includete membri di tutti i team, come ad esempio il customer success. Tenere customer success nel loop ha permesso al team di sviluppo di empatizzare meglio con gli utenti.

🤔 Cosa devo fare se le persone non vogliono partecipare allo stand up?

Questa situazione è successa anche a noi. Per risolverla abbiamo invitato la persona che non voleva partecipare ad uno stand-up a settimana “di prova”. Durante questo evento abbiamo chiesto al team di coinvolgere attivamente la persona per renderla partecipe. Al termine del meeting, dopo aver compreso sul campo lo scopo dell’attività, la persona ci ha chiesto di essere invitata in pianta stabile.

Non ti posso promettere che funzionerà sempre, ma è un buon espediente. Questo perché le persone tendono a supportare quello che hanno aiutato a creare.

Ci sono sicuramente altre cose che possono andare storte, ma queste sono quelle che sono successe a noi.

Ripensiamo l’organizzazione del design

Il secondo esperimento, più corposo, è stato sui problemi di processo, con l’introduzione del Dual-Track Agile.

Dual-track Agile: come funziona?

A differenza dell’Agile classico, che definisce il piano di lavoro solo del team di sviluppo, in un processo dual-track anche le attività di design sono centrali nella pianificazione.

Il dual-track è caratterizzato da un principio: il design team lavora in anticipo rispetto al team di sviluppo. Con almeno una sprint di vantaggio, il team di design può fornire materiale completo e validato con gli utenti.

⚠️ Attenzione!

Questo non significa lavorare solo in anticipo di una sprint. Il team deve sempre mantenere una chiara visione sull’intera roadmap del progetto.

Seguendo questa metodologia anche il lavoro dei designer viene organizzato in sprint. L’obiettivo di ogni sprint è produrre user story dettagliate e complete da discutere e prioritizzare con il team di sviluppo e il product owner.

Schema che rappresenta il dual-track agile

Iniziamo da un solo team

Ho scelto il team con la UX Maturity migliore per iniziare. Questo perché sapevo che sarebbe stato più ricettivo alle proposte e mi avrebbero permesso di essere più rapido nel primo test.

Introdurre un nuovo processo di lavoro non è mai facile. C’è bisogno del contributo di tutti perché le cose possano funzionare. Ho presentato fin da subito i cambiamenti come un modo per affrontare i problemi che erano emersi.

Ho spiegato che la sfida non era designer vs developer ma piuttosto tutto il team contro i problemi.

Una volta compreso questo messaggio tutti si sono resi disponibili a mettere mano al processo di lavoro.

Un nuovo backlog per il design

Per favorire la pianificazione del team di design ho creato una board accessibile a tutti dove documentare le loro attività. Come per le attività di sviluppo, anche la board del team di design è stata divisa in sprint di 2 settimane.

Il team di design ha poi scelto quattro stati per tenere traccia della progressione delle attività all’interno della sprint:

  • Da completare: le user story che il team di design si prefigge di portare a termine in questa sprint
  • In corso: attività di design attualmente in corso
  • Review: storie la cui progettazione necessità di review interna o esterna da parte di altri membri del team o decision maker
  • Completato: la storia contiene i mockup e le condizioni di completamento (spesso chiamate Condition of Satisfaction, o COS)

Board di design su JIRA (esempio di product backlog preso da un progetto in corso)

Quando il team di design termina un task aggiorna il backlog di sviluppo di conseguenza.

Per collegare il backlog di sviluppo e quello di prodotto abbiamo definito una convenzione. Si tratta di tre stati che abbiamo aggiunto alle user story del backlog di sviluppo:

  • discovery Il design team è in fase di ricerca. Sta indagando i problemi e le opportunità dell’obiettivo scelto.
  • developing-design Gli obiettivi della storia sono definiti. Il team sta lavorando alla creazione dell’esperienza d’uso.
  • ready-to-develop La storia è pronta e può essere sviluppata. Andiamo! 🏁

Pianificare per il futuro

Il product backlog non è solo il punto di riferimento delle attività in corso, ma permette di pianificare anche quello che verrà dopo. Il punto fondamentale è la pianificazione delle sprint in anticipo, perché porta diversi vantaggi:

  • Tutto il team ha visione su quale sarà la direzione
  • Crea un buffer tra le attività di design e sviluppo permette aggiustamenti di rotta senza rallentare
  • Il team di design può gestire attività che vanno oltre la singola sprint, come ad esempio una le sessioni di interviste e ricerca con gli utenti.
  • Il team di sviluppo può gestire attività come refactor del codice o miglioramento dell’architettura software senza impattare sulla roadmap, sfruttando i momenti di ricerca del team di design

Cosa abbiamo imparato

Cambiare è difficile

Cambiare il modo in cui si lavora è un processo lungo. Nel nostro caso le attività di migrazione a Dual-Track Agile di tutti i progetti sono ancora in corso. Oltre a questo i nostri team sono simili, ma non uguali. Questo ci porta ad ottenere risultati diversi con tempi diversi. Fa parte del gioco!

Mantenere la documentazione costa

In Belka consideriamo le attività di gestione del product backlog come attività del team di design. Mantenere un backlog è un’attività che richiede del tempo e, se non adeguatamente soppesata, rallenta la roadmap di sviluppo. È una cosa in più da fare ed è da tenere in considerazione!

Almeno due Sprint di anticipo

Per il design team, lavorare alcune sprint in anticipo è stata la chiave di volta per poter concentrarsi sull’esperienza utente e ridurre gli interventi in emergenza.

Dalla nostra esperienza il processo si può ritenere sano quando ci sono almeno due sprint di anticipo su sviluppo. Organizzare le sprint successive di sviluppo con storie ancora in fase di discovery aiuta a rendere tangibile quello che verrà dopo.

Divide Et Impera, funziona sempre? Quando funziona? Scopriamolo!

Suddividere il lavoro tra product backlog e backlog di sviluppo non si è rivelato sempre vincente. Dividere le attività di design da quelle di sviluppo aiuta a ridurre la complessità del backlog, di contro duplica le informazioni ed è uno sforzo di documentazione più alto.

Per questa ragione stiamo sperimentando anche l’utilizzo di un singolo backlog di progetto. Questo, come gli altri punti che ho raccontato, vanno sperimentati con mano durante lo sviluppo e tenendo monitorate le reazioni del team.

Luca a cavallo di Falkor

È un processo senza fine

Ultimo punto: provare, provare, provare senza aver paura di sbagliare. Sulla carta i principi sono validi ma la realtà dei fatti è che vanno provati con il team e adattati alle esigenze delle singole realtà e dei singoli progetti.

Se ti stai chiedendo ”ma posso applicare anche io nel mio team queste pratiche?”, la risposta è SI! Ti consiglio di iniziare dal pain point più sentito dal team e, partendo da quel punto, di introdurre gradualmente i miglioramenti di processo.

Noi, ad esempio, partendo da stand-up mattutini abbiamo snellito molto la comunicazione e abbiamo visto subito i primi risultati concreti senza necessità di stravolgere il lavoro di tutti.

Per dovere di cronaca ecco gli esperimenti tuttora in corso:

  • Unificare il product backlog con il backlog di sviluppo
  • Gestione degli stati della board di design in modo da allinearci con il double-diamond (che è il modo in cui viene descritto da manuale un processo di design)
  • Migliorare il coinvolgimenti di altri membri del team non direttamente impiegati nel progetto (e.g. l’amministratore della società che non segue direttamente lo sviluppo del progetto ma vuole restare aggiornato)

Riferimenti

Autore

Luca D'Incà