Agile e UX nel mondo reale

Ultima modifica 7 gennaio 2018 @ 18:33

Per muoversi nella zona franca tra UX e Agile bisogna aprire la mente, improvvisare e, soprattutto, essere in grado di disimparare i dogmi che qualche culto sacro del design ci ha imposto. Quando il tuo metodo somiglia a una liturgia quotidiana, e sei circondato da sacerdoti della prassi, qualcosa non va. Per questo vorrei chiarire immediatamente che non sono convinto che Agile sia la soluzione giusta in qualsiasi contesto, come non sono convinto che lo sia l’approccio tradizionale alla UX.

È necessario fare alcune premesse:

  1. Il mondo è pieno di ben più autorevoli e complete dissertazioni su come integrare il processo UX nei framework Agile. Molti di questi interventi, però, raccontano un mondo che poco somiglia alla mia realtà quotidiana.
  2. I framework Agile (Scrum, Kanban e Extreme Programming) non prevedono la UX. L’utente è un concetto astratto, non è realmente incluso nell’equazione.
  3. Il processo UX è puro waterfall. Ciò significa che per integrare la UX nel mondo Agile è necessario piegare il metodo e semplificarlo.
  4. Il termine UX, in questo articolo, significa prevalentemente co-design, ricerca sul campo, architettura dell’informazione e usabilità. Personalmente considero fuorviante l’etichetta UX.
  5. I framework Agile funzionano e sono qui per restare. Ignorare questo fatto equivale ad essere uno di quei pittoreschi personaggi che ballavano mentre il Titanic affondava. Se la parola Agile ti fa venire in mente solo performance sportive, ti suggerisco l’ottima Guida Galattica per agilisti.
  6. Questo articolo non include affascinanti infografiche riassuntive, non esistono scorciatoie: se ti interessa l’argomento, devi dedicarmi sette minuti del tuo tempo.

La visione del prodotto

Sebbene il concetto stesso di prodotto/servizio nel mondo Agile sia dinamico e incrementale, è, secondo me, essenziale sviluppare una visione globale prima di scrivere la prima riga di codice. In questa fase di product envisioning, trovano spazio design thinking e human-centered design, se la natura del progetto lo richiede. Se questa visione iniziale del prodotto manca, non solo sarà difficile trasmettere ad altri il senso del proprio lavoro, ma il software engineer potrà facilmente perdere la direzione e quella capacità di pianificazione richiesta da clienti che lavorano ancora con il concetto poco agile di deadline. Tenendo conto della differenza di impegno necessaria, per esempio, per fare innovazione di prodotto o re-design di prodotti esistenti, l’effort non sarà mai eccessivo. Si parla di una serie di co-design workshop, preceduti, quando possibile, da un minimo di user research (survey, interviste, focus group ecc.) grazie al quale l’utente non sarà più solo una figura mitologica. Lo scopo è sviluppare un concept, corredato almeno da una serie di wireflow, che farà da spina dorsale al progetto. Questo non significa che, successivamente, sprint dopo sprint, il prodotto non subisca evoluzioni in puro stile Agile.

Le figure coinvolte in questo sprint 0 sono product owner, UX designer, i vari stakeholder e, soprattutto, utenti reali.  Al termine di questa fase si avrà la comprensione del dominio necessaria a sviluppare uno o più design concept.

E quando la visione è impossibile?

Per effettuare come si deve uno sprint 0 sono necessari tre elementi: la comprensione della reason why da parte del cliente, il budget e il tempo. Se uno o più di questi elementi manca, è necessario un approccio più creativo. È capitato, per esempio, che un cliente chiedesse supporto UX per un prodotto complesso che era già in fase di sviluppo e con una deadline impossibile (suona familiare vero?). È evidente che in un caso come questo non è possibile fare user research. Non c’è il tempo per produrre documentazione e ogni cambiamento richiesto è una spada nel cuore del programmatore. Che fare?

Una strada percorribile è sedersi accanto agli sviluppatori e coinvolgerli nel processo di design, senza produrre inutile documentazione (basta una lavagna e qualche pennarello), concependo al volo soluzioni, insieme. Nel caso specifico decidemmo un ritmo settimanale di due giornate di co-design e tre di programmazione. In sei settimane il progetto fu terminato con successo. Parallelamente un altro team coordinò una serie di test con stakeholder e utenti che confermarono le nostre scelte di design.

Qualsiasi metodo va piegato e anche violentato, se necessario, altrimenti sarà la propria prigione cognitiva.

Il planning, ma con la UX

Una volta eseguito lo sprint 0, il team dovrebbe avere a disposizione tutte le informazioni e la conoscenza del dominio necessari per la visione globale del prodotto e per il design UX del primo, o dei primi, sprint. In questo caso io, contravvenendo a uno dei dogmi Agile, credo che fornire documentazione al programmatore, per esempio wireframe, specifiche funzionali, flussi ecc. sia una buona idea. Sia per condividere la visione ad alto livello del prodotto, sia nello specifico di una o più funzionalità relative a un dato sprint. Il programmatore, credetemi, apprezzerà. Lo UX designer, chiaramente, deve fare un passo evolutivo sia rispetto alla pretesa di essere l’unico riferimento per la progettazione, sia rispetto alle trappole dell’abitudine all’approccio waterfall. I documenti UX prodotti in questa fase devono essere living document, facilmente consultabili, commentabili e modificabili da tutto il team (Axure, InVision e altri strumenti sono già predisposti per la condivisione e il lavoro di gruppo. Anche Slack, ovviamente, aiuta).

Nella fase di pianificazione dello sprint, quando è il momento di scrivere le user stories, il ruolo dello UX designer è anche quello di supportare il product owner nella scrittura. Lo sviluppatore stimerà successivamente i costi di ogni storia e infine product owner, UX designer ed eventualmente qualche stakeholder prioritizzeranno le storie in base alle stime. La lista delle storie prioritizzate avvia lo sprint. Niente di nuovo quindi.

Le figure citate possono facilmente essere sovrapponibili: per esempio è possibile che product owner e UX designer coincidano, oppure che lo sviluppatore sia anche UX designer. Per qualche talebano della UX questa sarà un’eresia, ma è davvero credibile oggi verticalizzarsi su una sola area di competenza? Sul serio qualcuno crede che sia ancora professionalmente sostenibile?

Il workflow, ma con la UX

La successione degli sprint è rappresentabile su due layer, il primo è il dominio del software engineering, il secondo della UX.

  • Prima del primo sprint di engineering si svolgono le attività UX di envisioning di prodotto e il planning del primo sprint.
  • Successivamente parte lo sviluppo software del primo sprint.
  • Parallelamente lo UX designer progetta la UX per il secondo sprint.
  • Terminato lo sviluppo software del primo sprint, parte lo sviluppo del secondo.
  • Parallelamente lo UX designer valuta il rilascio software del primo sprint e progetta la UX per il terzo sprint.
  • Lo sviluppatore procede con il terzo sprint e corregge eventuali problemi UX evidenziati dalla valutazione del primo sprint.
  • Parallelamente lo UX designer progetta la UX per il quarto sprint e valuta la UX del secondo sprint.
  • Ad libitum…

Ovviamente le attività di planning sono continue, a partire dallo sprint 0 fino all’ultimo sprint.

Ora, però, siamo tutti adulti e intellettualmente onesti e sappiamo che l’entropia è sempre in agguato. Si può manifestare nella forma di un cliente che confonde la metodologia Agile con la libertà di caos, e si lascia andare a un delirio creativo che porta a modificare la visione globale del prodotto ad ogni sprint, oppure in forma di incomunicabilità tra colleghi, come se tutti seguissero alla lettera le Istruzioni per rendersi infelici del compianto Watzlawick e, per prendere una decisione serenamente o condividere idee, ci fosse bisogno ogni volta di una terapia di gruppo, eccetera. È la vita, bisogna arrendersi.

Ho iniziato l’articolo dicendo che bisogna aprire la mente, improvvisare e, soprattutto, essere in grado di disimparare i dogmi. Anche le indicazioni di questo articolo vanno prese con lo stesso spirito, non c’è alcuna pretesa di completezza o di correttezza. Posso solo dire che nella mia esperienza questo approccio ha funzionato.

4 commenti

Di Marco Bertoni

Marco Bertoni

Marco Bertoni si occupa di product envisioning e user experience per Mondora, la prima benefit corporation tecnologica d'Europa, parte del gruppo TeamSystem. La profonda attenzione all’etica di Mondora, che è anche una teal organization, si sostanzia sia nello sforzo continuo di rappresentare un cambiamento nella società sia nell’attenzione alla crescita umana e professionale.
In passato è stato design director, si è occupato di progetti di formazione e assessment per la pubblica amministrazione centrale, ha organizzato convegni e svolto attività di consulenza su user experience e inclusive design, occupandosi parallelamente di riabilitazione informatica per disabili sensoriali.