Abbiamo raccontato in alcuni articoli del nostro blog e in puntate di Flowing Radio i vantaggi di un team cross-funzionale che esprime il suo massimo potenziale in un corretto approccio al progetto, dove la fase di apprendimento (learning) affianca o anticipa quella di sviluppo (delivery).
Le attività sotto il cappello della UX si dimostrano decisive nelle fasi in cui l’analisi dei dati raccolti – e poi analizzati dalle diverse figure professionali – permette di prendere decisioni cruciali per il percorso e il costo di sviluppo del progetto.
Spendere per alcune attività di analisi, prima, significa non sprecare soldi dopo. Riprendendo la bella metafora del “progetto software come un viaggio” del post di Antonio è come usare risorse per capire se il guado è sicuro piuttosto che buttare soldi per recuperare l’auto che non riuscirà ad attraversarlo.
Gli anti-pattern più frequenti
Nonostante la maturità del cliente faccia la differenza sulla sensibilità a questo approccio, di solito emergono due anti-pattern::
- La fretta: “Avete ragione, ma qui la delivery serve subito.”
La fretta è ben diversa dall’efficienza e dalla velocity. La fretta è l’alibi di chi non ha saputo gestire bene il progetto prima, o la conseguenza di processi che non funzionano nei sistemi aziendali.
In questo caso, senza le attività di analisi preliminari il cliente sta facendo una scommessa, e se la perde, la responsabilità sarà sua. - Il pregiudizio del costo: “Sarebbe fantastico, ma non ce lo possiamo permettere in questo progetto.”
Il budget è una leva che si muove insieme ad altre per finanziare il raggiungimento dell’obiettivo, intenderlo come il rubinetto dedicato a regolare unicamente la quantità di codice e interfacce prodotte equivale a decidere di non dotarsi di indicatori essenziali a scegliere cosa è meglio fare.
Il nostro percorso “tipo”: dall’apprendimento allo sviluppo del progetto
Dati questi anti-pattern, voglio esplicitare qui il percorso “tipo” che attuiamo nei nostri progetti per guidarli in modo sano, non facendone unicamente una questione di tempo o costo, ma di approccio.
Il nostro team incontra solitamente il cliente alla discovery, un format preliminare per “scoprire” le necessità del progetto, allinearci alle aspettative del cliente e pianificare insieme i prossimi passi più utili al raggiungimento degli obiettivi. Restituisce anche le prime indicazioni sul budget, che tengo a sottolineare non sono stime: è impossibile fare una stima precisa in questa fase, avremo chiare quali sono le prime attività che assorbiranno budget.
La nostra discovery può durare da una a più giornate in base allo scenario del progetto e in queste fasi tutto il team (dai designer UX/UI/ID ai developer FE/BE/OPS) viene a conoscenza delle informazioni che in un “classico” approccio a silos avrebbero ottenuto, ad esempio, solo gli ux designer con un design-brief su:
- obiettivi di business
- chi sono gli utenti
- chi sono i competitor
Il grande vantaggio è che già in questa fase abbiamo pienamente operativo il team con la sua cross-funzionalità. Avere dei developer che portano il loro punto di vista in questi momenti è prezioso e cruciale per ottimizzare le opzioni e parallelizzare tutte le attività che servono per procurarci dati sui quale progettare il processo di sviluppo del progetto. La fase di learning non è solo per designer.
A questo punto si approfondiscono alcune informazioni, come gli obiettivi di business, il modello di ritorno economico e il segmento di clientela, cercando di scorporare il macro obiettivo in business goal, che puntano a mettere in corrispondenza scenari in cui l’obiettivo d’impresa è soddisfatto e le aspettative degli utenti rispettate. Questa fase varia molto da progetto a progetto e l’attività viene di solito agevolata da format di product discovery come Impact Mapping e Lean Value Tree o da framework come SMART o Event Storming.
Anche in queste fasi il punto di vista delle diverse professionalità sono decisive per ottenere quella diversità che aggiunge valore alle fasi divergenti e rendere più efficaci quelle convergenti. Le decisioni stanno già tenendo conto di tutti i punti di vista di chi poi seguirà e lavorerà al progetto. Nessuno prende decisioni per conto di altri e prima o dopo gli altri. Nessuno eredita decisioni pregresse.
Al termine di questa fase il nostro team cross-funzionale è al corrente degli obiettivi del nostro cliente e sa anche agire per raggiungerli.
Vengono quindi avviate azioni di benchmarking perché l’analisi dei competitor è utile sia per capire se c’è qualcuno con un prodotto/servizio simile al nostro o se qualcuno ha risolto i nostri stessi problemi prima di noi. In questi momenti una SWOT analisys può essere di aiuto per capire i vari player in campo oltre al nostro cliente e per cogliere eventuali punti di forza o di debolezza delle loro soluzioni. L’attività offre un grande spunto alle figure professionali sulle soluzioni adottate da altri. In pratica, il team cross-funzionale in questa fase trae vantaggio da chi ha affrontato qualcosa di simile già prima, dalla progettazione dell’esperienza a quella tecnologica.
A questo punto il concept del nostro progetto inizia a prendere una forma e le prossime attività da fare diventano più chiare. È in questa fase che il team può iniziare a scindere la fase di learning da quella di delivery, dando vita ad un processo di questo tipo chiamato Continuous Discovery o (in ambito Agile) Dual Track Agile.
Il team ha infatti un piano, ma deve validarlo per non rischiare uno spreco di risorse. Ha troppe decisioni da prendere che sono ancora basate sulle assunzioni del team stesso, servono quindi attività che le verifichino. Tornando all’esempio del viaggio, il team ha formulato un’ipotesi condivisa della prossima meta e ha anche delle ipotesi su come raggiungerla, che è un punto di partenza necessario (va capito se il ponte è sicuro o se è meglio la discesa della montagna).
Questa fase è coadiuvata dalle cornici di lavoro scelte in precedenza. Il team potrebbe percorre delle scommesse se si era scelto un format come l’Impact Mapping o il Lean Value Tree o mappare delle epiche se il team proviene da un Event Storming. L’importante è verificare le idee emerse e ancorare le soluzioni a problemi reali. L’approccio che guida questa fase è quello Human Centered del Design Thinking che ci assicura che la soluzione ipotizzata risolva un problema riscontrato e che il problema riscontrato sia un problema reale. I dati importanti in questo momento sono soprattutto qualitativi in merito ad aspettative, aspirazioni e feeling dell’utente utilizzatore. È più rilevante la profondità del dato che la sua numerosità statistica. I format e i framework citati in precedenza ci aiutano su questo e ci impediscono di propendere per soluzioni emerse da dati puramente quantitativi o solo perché la sensazione è buona o qualcuno nel team ha più carisma o leadership nel promuoverla.
Il team a questo punto ha un’idea più chiara dei problemi e delle relative soluzioni e proprio queste ultime si stanno trasformando sempre più nelle funzionalità del progetto.
Il team cross-funzionale abbatte lo spreco di tempo garantendo una buona sinergia tra le varie figure professionali che in questa fase cooperano a braccetto ottimizzando tempi e processi, come raccontiamo in questa puntata di Flowing Radio.
Si arriva quindi alla fase più densa della “ricerca” dove gli sviluppatori metteranno in fila attività volte a validare le loro decisioni tecnologiche e i designer si dedicheranno ad attività di User Research per validare se il target individuato ha realmente i bisogni emersi che vorremmo soddisfare con le nostre ipotesi di soluzione. È importante verificare anche se il segmento di clientela identificato è corretto, dato che successivamente andremo a studiare le loro abitudini. La ricerca avviene solitamente tramite le interviste (che forniscono dati qualitativi e da poche persone) e questionari (che forniscono dati quantitativi e da tante persone).
Il lavoro che segue è l’approfondimento delle caratteristiche dell’utente che viene fatto con le Personas. Questo ha un duplice vantaggio: in primis esplicita le caratteristiche dei nostri gruppi di target, in secondo crea un’empatia tra il team e gli utenti identificati, che ritorna in modo benefico anche come consapevolezza del team stesso.
La fase di learning lascia man mano spazio a quella di delivery che inizia a concretizzare un backlog di attività che contiene il compromesso migliore del set minimo di attività più idonee da fare in questo momento.
- compromesso migliore = la scelta tra diversi scenari sulla base dei nostri obiettivi
- set minimo = minor impatto sul budget
- attività più idonee = la priorità sulle attività di maggior valore per l’utente
- questo momento = consapevolezza che più si va avanti, più dati avremo e meglio potremo decidere il percorso
Quali risultati dà questo percorso?
- comprendere l’idea del cliente stressandola affinché si raggiunga una quadra tra gli obiettivi di business e i bisogni degli utenti;
- ipotizzare le funzionalità del progetto perché rispondano a bisogni e siano tecnologicamente sostenibili;
- avviare processi di “ricerca” sia lato utente che lato tecnologico per validare le ipotesi.
A questo punto subentra la serendipità data la non linearità del percorso. Dopo le attività delle varie figure professionali del team avremo portato a casa diverse informazioni che avranno introdotto vincoli e risposte, offrendo nuove scenari per il raggiungimento degli obiettivi del cliente. Potremmo dover correggere alcune assunzioni fatte in precedenza, farlo sarà propedeutico alle valutazioni di ulteriori opportunità.
D’ora in poi il team lavora su una profondità diversa e potrà concentrarsi su quello che man mano farà prendere forma al progetto. Gli sviluppatori avranno modo di approcciare le scelte tecnologiche, framework, sicurezza e architettura della base codice. I designer potranno approfondire l’esperienza d’uso con un customer journey che mette in relazione le azioni cruciali degli utenti (solitamente ottenute da eventi o feature dei format precedenti) con il loro pensiero e sentimento. Grazie a questo lavoro avremo più chiari i punti in cui ci sono pain da rimuovere o gain su cui valutare opportunità.
Dopo questa fase siamo pronti a generare un backlog delle prossime attività che hanno un’alta probabilità di centrare gli obiettivi del progetto, dato che ha ridotto al minimo le assunzioni del team stesso. Si lavora quindi alle user stories che nella loro grammatica continuano ad avere intrinseco l’attore (utente), l’azione e il perché (che ci ancora all’obiettivo di business).
Seguono una serie di attività di Interaction Design con i flussi d’uso del nostro progetto che potranno tenere conto delle informazioni pervenute dalle scelte tecnologiche e dalle informazioni raccolte nella fase di “dev research”. A seguire viene svolto lo studio dell’architettura delle informazioni per esporre al meglio i contenuti per i nostri Utenti/Personas. Se il progetto ha una struttura contenuti importante si può ricorrere alla tecnica del card sorting per ottenere una sitemap. In genere i flussi sono assimilabili ai percorsi fattibili dagli utenti e la sitemap alla struttura che permette di percorrerli.
Proseguiamo quindi lo sviluppo dei wireframe che puntano a rappresentare l’embrione dell’interfaccia mettendo il focus sulle disposizioni, sui pesi e sugli intenti che offre ogni vista, tralasciando tutta la parte stilistica. Tutte le figure del team cross-funzionale sono chiamate ad approvare un wireframe, per far emergere in questa fase eventuali limiti che devono cogliere il punto di vista di tutte le professionalità.
Da questo momento in poi l’iteratività e la ciclicità propria degli approcci agili ci offrono il metodo per testare e reiterare sulle soluzioni man mano proposte, prima di rifinirle con le attività di design: design dell’architettura e design dell’interfaccia, dove di nuovo tutto il team disegna e progetta quello che darà la forma al nostro progetto.
Questo percorso non avviene sempre in modalità greenfield, come descritto qui, ma dipende molto dagli scenari e dalla maturità del progetto in cui ci troviamo ad intervenire. Ciò che teniamo fermo è il nostro approccio, dove capire cosa fare viene prima di capire come farlo.
