La tua azienda ha un approccio maturo alla User eXperience? (#1)

A seconda del grado di maturità dell’approccio alla UX, un’organizzazione progredisce nel suo status; a partire da un’ostilità iniziale fino al ricorso diffuso alla “User Research”.

In genere tutte le organizzazioni progrediscono attraverso una sequenza di fasi pressoché universali; per questo è possibile abbinare anche la propria organizzazione ad uno delle fasi sotto descritte per vedere qual sia il prossimo passo da compiere.

Fase 1: Atteggiamento ostile verso l’usabilità

La fase iniziale è caratterizzata dallo slogan “Il miglior utente è l’utente morto”. Gli sviluppatori semplicemente non vogliono sentir parlare di utenti o delle loro esigenze; il loro unico obiettivo è quello di mettere a disposizione degli utenti le funzionalità richieste.

Secondo questo approccio, gli esseri umani sono irrilevanti in quanto sono obbligati a utilizzare il sistema, indipendentemente dal fatto che sia facile o piacevole farlo.

Se questo può essere stato anche necessario agli albori dell’informatica (1945-1965), quando l’hardware, molto costoso, soggiogava le persone ai suoi bisogni; nei periodi successivi non è più plausibile.

Anche oggi c’è una vasta scuola di progettazione informatica che è avulsa al concetto di user design: parte da chi realizza siti web nel presupposto di trasformare il Web in televisione, a una vasta schiera di ERP che, per obsolescenza dei manager e quindi mancanza di innovazione, sono refrattari a cambiare modo di lavorare (database-centrico), “tanto gli utenti sono obbligati ad usare quel software”.
Se la tua azienda è nella fase ostile, si può dimenticare di promuovere la User eXperience. Le persone devono voler cambiare il proprio atteggiamento prima che ci sia qualche possibilità di aiutarli a farlo.

Solo dopo che l’azienda è stata sufficientemente ferita dai suoi atteggiamenti preistorici, la gestione sarà pronta a prendere in considerazione l’usabilità e entrare nella fase successiva.

Fase 2: Esperienza utente Sviluppatore-Centrica

Prima o poi, la maggior parte delle aziende comprende il valore di realizzare progetti più facili da “usare” per gli esseri umani.

A questo punto l’approccio più ovvio (ma errato) è far affidamento alla intuizione stessa del team di progetto per determinare quello che costituisce una buona usabilità del prodotto.
Dopo tutto, i membri del team sono esseri umani, usano i computer e consultano siti web. Sicuramente sanno se una cosa è facile da usare o no. Inoltre i membri del team hanno anche un altro enorme vantaggio: sono già ingaggiati e partecipano a tutte le riunioni di progetto e non sono timidi nel condividere le loro opinioni.

Questo approccio funziona ragionevolmente bene per una classe di progetti software: ambienti di sviluppo, server Web, altri strumenti per gli sviluppatori o per geek. Progetti open-source come Perl, Linux e Apache hanno avuto un grande successo con grazie alla progettazione Sviluppatore-Centrica. Ma anche questi progetti avrebbe potuto essere migliori, con un contributo all’usabilità più sistematico da parte di persone al di fuori del team di progettazione.

I programmatori che lavorano sul cuore di Apache hanno una comprensione più profonda di esso in confronto ad altri esperti tecnici che vogliono solo usare Apache, non modificarlo.

Per i progetti destinati a un pubblico non-esperto, è disastroso contare sulla comprensione dello sviluppatore su ciò che è facile o non lo è. Tutti coloro che lavorano su un progetto conoscono troppe informazioni su di esso per rappresentare utenti esterni.

Per fortuna, quale differenza passi tra un modello concettuale di un membro del gruppo e quello dell’utente medio è facile da spiegare. E’ anche una pillola facile per i membri del team di ingoiare, perché si sta sostanzialmente dicendo loro che sono troppo intelligenti e competenti per sostituire l’utente medio.

Nella fase 2, si dispone di un enorme vantaggio: le persone si preoccupano usabilità. Detto questo, è ancora molto probabile ottenere proclami a parole dai dirigenti di alto livello, che fanno annunci come “la buona esperienza utente è una priorità assoluta”, mentre in realtà non si riesce a finanziare un vera attività sull’usabilità.
Così, anche se non si potrà saltare dalla fase 2 direttamente ad un processo di usabilità elaborato, si potranno trovare le persone ricettive alla logica di UX. Queste persone potranno anche mostrare una certa volontà di passare alla fase 3 – se si continua a spingere in quella direzione.

Fase 3: Sperimentazioni di User Experience

In questa fase, l’organizzazione si rende conto che non dovrebbe fare affidamento sul giudizio personale del team di progettazione su cosa è facile o difficile utilizzare da parte dei clienti.
La maggior parte delle decisioni di progettazione continuerà a fare affidamento al giudizio del team, però, in quanto le persone tendono a credere di essere allo stesso tempo modello e punto focale dell’universo. Così, anche se i progettisti sanno che devono ottenere dati dall’esterno, non cercano di ottenerli in modo molto deciso.

Nonostante tutte le barriere, in questa fase, alcuni gruppi all’interno della società avvieranno piccoli sforzi UX. Forse qualcuno assumerà una manciata di utenti per un semplice test. O forse un manager assumerà un esperto di usabilità esterno per la prima valutazione indipendente della qualità dell’approccio alla User eXperience della società.

Ciò che distingue questa fase dai livelli più alti è che non c’è alcun riconoscimento ufficiale della User eXperience come disciplina, né vi è un budget approvato e assegnato in anticipo. Tutte le attività e la ricerca sull’utente sono estemporanee e guidate dai sostenitori degli utenti che vogliono un po’ più dati per migliorare la qualità dell’unica funzione o interfaccia utente su cui stanno lavorando in questo momento.

Primitiva così com’è, la sperimentazione sull’usabilità è comunque efficace. Anche minimi sforzi di UX non possono fare a meno di creare grandi miglioramenti del prodotto in una società che non ha mai fatto degli studi di usabilità prima.

Quando si passa dalla fase 2 alla fase 3, si può fare affidamento sulla logica – e forse un po’ sull’adulazione – per convincere i membri del team di progettazione che sono troppo esperti per rappresentare un cliente medio. Nella progressione verso l’alto dalla fase 3, tuttavia, si può contare solo sui risultati.
Quando i progetti ottengono una piccola iniezione di usabilità, migliorano – si spera in modo tale che i risultati siano chiari a tutti. L’unico inconveniente è che veramente una migliore esperienza degli utenti sembri un fatto così ovvio (dopo è accaduto) che i manager potrebbe non riconoscere quanto lavoro è stato richiesto di semplificare la progettazione. Per evitare di essere trascurati è consigliato salvare le idee iniziali di progettazione, goffe come possono sembrare, e mostrare il confronto prima / dopo per documentare l’avanzamento introdotto dalla UX.

Fase 4: Budget dedicato alla UX

Forse un manager che ha finanziato un piccolo studio di usabilità con fondi nascosti viene promosso a direttore con un budget più grande. O forse un pezzo grosso decide di porre maggiore priorità agli aspetti di usabilità nella qualità del prodotto. Diversi scenari possono causare una società ad investire maggiormente nella User eXperience. In genere, la causa principale è che alcuni progetti ad-hoc durante la fase 3 di piccole dimensioni, hanno catturato l’attenzione dei pezzi grossi e li hanno convinti che l’azienda beneficerà se migliora l’esperienza dell’utente.

La grande differenza tra gli stadi 3 e 4 è un budget dedicato per la UX. Anche se piccolo, il bilancio è accantonato in anticipo, cioè le attività UX sono previste nello stesso modo degli altri processi di qualità.
A seconda delle dimensioni della società, il bilancio UX potrebbe coprire solo una percentuale di tempo di un singolo dipendente o potrebbe permettere un certo numero di specialisti UX a tempo pieno. In entrambi i casi, il personale specializzato in UX è sparso tra i dipartimenti della società e non ha dei processi sistematici stabiliti. Ma almeno ha la UX e l’usabilità nella descrizione del lavoro ed è stabilita una somma di denaro per attività come il reclutamento di utenti per i test.

In questa fase, l’azienda vede principalmente la UX come una pozione magica che è spruzzata sopra in modo sparso su un’interfaccia utente per renderla luccicante. Il metodo principale per garantire l’usabilità è il test-utente, che è invariabilmente condotto in ritardo nel processo di sviluppo dopo che l’interfaccia utente è stata almeno parzialmente completata.

Ciò è contrario alle migliori pratiche raccomandate, che richiedono test frequenti e all’inizio, compreso l’uso di prototipi di carta che le squadre possono testare senza sprofondare nei costi di un’implementazione di progettazione su larga scala.

Più il progetto va verso l’attuazione di una interfaccia utente, meno disposti si sarà ad apportare le modifiche architettoniche che sono in genere necessarie dopo che il progetto viene esposto per la prima volta ad utenti reali.

Per spostarsi verso l’alto dalla fase 4, è necessaria ancora di più la prova del ROI. Passando dalla fase 3 alla fase 4, è abbastanza facile ottenere risultati credibili: non si può fare a meno di fare notevoli miglioramenti la prima volta che si fa un po’ di lavoro di usabilità su un progetto. E, con un finanziamento per la sperimentazione, tali risultati sono a buon mercato.
Con un vero e proprio budget, è necessario che miglioramenti siano più consistenti per giustificare un aumento degli investimenti UX. Poiché i metodi di usabilità hanno sorprendentemente ROI elevato, quei grandi miglioramenti arriveranno, ma ci vorrà un po’ di tempo. E’ necessario avere più di un paio di storie di successo. Sono necessari diversi prodotti sul mercato con tassi di conversione più elevati, meno chiamate alle linee di supporto, un miglioramento della produttività, o di qualsiasi misura di business saliente per l’azienda.

Raccogliendo i risultati dei progetti con approccio all’UX si avranno alla fine abbastanza munizioni per rendere il business-case pronto per il passaggio alla fase 5: La User eXperience gestita.

Fasi 5-8: lo step successivo

Alla fase 4 l’azienda ha cominciato a prendere sul serio la UX, ma è ancora lontana da raggiungere l’ultimo stadio di maturità alla fase 8. Anche se la fase 4 è a metà strada, numericamente, la progressione attraverso le 4 successive fasi impiegherà più tempo del passare dalla fase 1 alla 4.

Questo articolo è una libera traduzione dell’articolo originale scritto da Jakob Nielsen nel 2006 che trovi a questo link. Se per te queste considerazioni sono nuove, siamo in 2 ad essere rimasti indietro di 11 anni.

Se sei interessato alla descrizione delle fasi dalla 5 alla 8 prosegui nella lettura di LA MATURITÀ ALL’APPROCCIO UX DELLA TUA ORGANIZZAZIONE

Agile Day Retrospective – IAD16

Ad uno sprint di distanza dallo IAD 2016 di Pavia sono qui a dedicare un po’ di tempo a fare retrospettiva. Che ne è stato dei bei propositi inseriti nel mio personale Backlog (che forse non è altro che una to-do-list ben organizzata)?

Le sessioni nell’arco delle due giornata sono state molte, e molte sono state interessanti, ma ne prendo fra tutte 3:

 

 

Riordinare il BackLog

Sicuramente uno speech molto concreto che ha già dato i suoi frutti, è stato quello di Susanna Ferrario su come mettere ordine agli impegni che come Product Owner e Development Team ci siamo presi nei confronti di clienti e utenti. Infatti Susanna oltre a spiegare che cos’è il decluttering  (il contrario di clutter, mettere in disordine) ha anche dato buone motivazioni per farlo.

 

 

Credo che il consiglio fra tutti che mi è servito è stato quello di non aver paura di buttare via le cose vecchie: se nel tuo BackLog ci sono degli elementi che stanno lì da molto tempo e vengono costantemente superati da altre attività più urgenti, è venuto il momento di disfartene.

Non aver paura di cancellare dal backlog un item che forse è solo una buona idea ma venuta nel momento sbagliato, se è veramente buona ritornerà in un futuro.

E così ho applicato i consigli direttamente al PBI del progetto che sto seguendo: cancellando PBI orfani, eliminando quelli già fatti o doppi, e spostando nel box delle idee quelli abbozzati ecco che la lista si è ridotta da 132 a 23 gustosi e valorosi items.

 

 

Chi è il Product Owner?

Perché sopra parlo di valorosi items? Perché di valore parla Alessio del Toro nel suo talk che va velocemente al punto: chi è il product owner e soprattutto qual è il suo compito primario. Qual è? Massimizzare valore…. (a me piace la versione anglosassone: deliver value che ha un’eccezione un po’ diversa in quanto il termine “deliver” porta con se un “a chi”).

A chi bisogna consegnare il “valore” da generare (oppure per chi si vuole massimizzare il valore)?

Al cliente e all’utente che ovviamente possono essere persone diverse, secondo le loro esigenze e necessità, e qui, schematizza bene Alessio, che le necessità delle persone compongono una piramide.

 

 

I 5 punti cardine dell’attività del Product Owner sono alla fine questi:

  • massimizzare il valore (deliver value)
  • avere una vision chiara (questo è ovvio per qualsiasi “condottiero”, ma va ripetuto)
  • essere la voce dei clienti (quelli che pagano per il valore consegnato)
  • gestire il Product Backlog (il valore assegnato agli items infatti permette sia di dare le priorità che gestire un decluttering efficace, vedi sopra)
  • collaborare col team e gli stakeholder (il P.O. non lavora da solo)

 

 

Programmare all’indietro ovvero: Test Driven Development

Ma tra il dire e il fare c’è di mezzo “e il” cioè: per trasformare in realtà il Backlog, bisognerà pur scrivere qualche riga di codice corretto e funzionante.

Per questo ci viene in aiuto Ferdinando Santacroce che in una sessione riesce a farmi capire come “invertire” la metodologia di programmazione: partire dai test per sviluppare un codice completo e corretto. Questo stravolge un po’ il paradigma del normale dello sviluppo (almeno per il sottoscritto).
Verso normale:

  • scrivo codice
  • scrivo il test (o per la maggioranza degli sviluppatori, provo alcuni percorsi critici nella speranza di non trovare errori)
  • se ho errori correggo il codice

Verso guidato dal test (Test-Driven Development):

  • scrivo il test
  • se va a buon fine, scrivo un altro test
  • se fallisce, scrivo il codice
  • se va a buon esito, posso fare refactoring

 

 

 

 

La prima volta che ne ho sentito parlare ho pensato che è da pazzi… poi nella sessione allo IAD Ferdinando ha mostrato una demo breve ma significativa e mi ha convinto che dovrei almeno provare. Il grande vantaggio è che tutti i percorsi vengono testati…. ma la cosa grande è che lo sviluppo diventa test-centrico. Poi è vero il mondo è pieno di software funzionanti scritti da programmatori infallibili, gli unit test sono una cazzata e la Apple è una Onlus per technopati.

Conclusione

Il mondo del software è in continuo cambiamento e lo IAD risponde all’esigenza delle aziende di maturare i processi di sviluppo del software: per questo molti speech (cui non ho partecipato) erano orientati al change management.
Andare allo IAD16 è stata un’esperienza arricchente che sicuramente ripeterò e consiglio a tutti quelli che come me amano “fare software” e lo vogliono fare bene.