Alberto Mucignat

(post lunghetto e simil-rant, me ne scuso in anticipo)

Ripesco solo ora un post di qualche tempo fa su Tesla e lo sviluppo continuo. Al di là della vecchia diatriba tra metodi agili, sviluppo continuo, waterfall, ecc, c’è un punto nuovo che mi pare corretto analizzare:

As many companies are discovering, incremental improvement doesn’t have the same cachet to a consumer as new and better. While it may seem irrational, inefficient and illogical, the reality is that people like shiny new toys. They want newer things. Often. And they want to be the ones who own them, control them and decide when they want to change them.

Questa analisi non mi convince pienamente, ma vale la pena andare in profondità. I concetti importanti espressi dal post sono due:

1. il fatto che le persone non si aspettano miglioramenti continui, bensì vogliono cose nuove
2. il fatto che le persone vogliono essere in controllo (anche delle cose nuove).

Se con il primo concetto non sono d’accordo molto, nella mia esperienza in effetti le persone sono terrorizzate dagli upgrade continui: c’è un alto rischio di ritrovarsi modificate delle funzionalità a cui erano affezionati e gli eventuali benefici dell’upgrade si possono apprezzare solamente dopo qualche tempo di utilizzo. Questo è forse il punto critico più importante degli sviluppi continui: aggiungere feature e migliorare le esistenti non deve assolutamente inficiare l’attuale esperienza d’uso.

Lo dico meglio: è veramente dura cambiare le feature volendole migliorare (di certo testare con le persone è fondamentale in questo) e avere anche una transizione indolore. Idealmente, l’aggiunta di nuove funzionalità non deve peggiorare o rallentare la vecchia esperienza a scapito di nuove feature magari secondarie per gli utenti esperti, ma quasi mai è così. Ricordate il vecchio Schema per la risoluzione dei problemi: “Funsiona? No sta tocarlo!” (scusate il dialetto, ma viene meglio in veneto).

Certamente è interessante l’esempio di Tesla: nel caso di un bene fisico, riuscire ad avere degli improvement è sicuramente un beneficio importante e che differenzia dai competitor in maniera sostanziale. Tuttavia il redesign completo è sicuramente un’azione necessaria dopo tot tempo: l’ottimizzazione continua rende impossibile l’applicazione di nuovi pattern, principi e linee guida di design.

Arriva cioè un momento in cui i cambiamenti continui richiedono un salto di paradigma.

Un primo punto è riuscire a capire quando questo momento è arrivato. Il principio del diminishing return è sicuramente un buon metodo per capirlo: quando i benefici per gli utenti sono minimi rispetto al costo dei cambiamenti è forse venuto il momento di fermarsi e ripensare completamente l’approccio.

Forse quando si passa dal “risolvere problemi noti” a “implementare nuove richieste degli utenti” (o nuove feature proposte dal team) sicuramente è necessaria una valutazione sulla necessità o meno di fare un cambio sostanziale di prodotto.

A Basecamp sono voluti diversi anni di miglioramento per riuscire a proporre un prodotto con un paradigma completamente nuovo. Non conosco il rate di passaggio dal vecchio al nuovo, ma per quanto mi riguarda siamo rimasti con il vecchio. E questo è un altro punto fondamentale: se il nuovo paradigma crea una frizione di utilizzo, il rischio è che la user base decida di non cambiare e rimanga con il vecchio (sempre che sia possibile, ma i ragazzi di 37signals su questo hanno lasciato la porta aperta, cosa molto rara in questo ambito).

Ed ecco un altro importante insegnamento: quando hai un progetto di successo, preparati a mantenerlo anche dopo un eventuale passaggio di paradigma, c’è sempre chi vuole continurare a usare il vecchio, sia pure pagando!

È anche il caso (per me) di OS Mavericks, che sto posticipando il più possibile. Un caso simile relativo ad Apple è stato il passaggio a iOS7 per i possessori di iPhone: salto di paradigma totale con poca attenzione al precedente utilizzo e parecchie incongruenze.

La risposta che sento spesso è che quelli che non vogliono “passare al nuovo” sono una minoranza, che le feature non più presenti o modificate sostanzialmente le utilizzavano solo una minoranza di utenti. Ebbene, attenzione alle minoranze, possono essere molto pericolose: un tempo consigliavo Basecamp a tutti, ora lo sconsiglio proprio perché secondo me la nuova versione non è così efficace. E se le minoranze coincidono con gli influencer il rischio è quello di perdere molta adoption rate.

Si dovrebbe cercare una sintesi in tutte queste osservazioni, ma i consigli credo son sempre poco specifici, dovendo ogni volta valutare attentamente caso per caso. Tuttavia ecco i mie punti:

• portare avanti il miglioramento continuo fino a che i problemi noti sono risolti efficacemente
• dopo la risoluzione dei problemi noti (o comunque quando la coda dei problemi influisce su una porzione risibile della user base) valutare l’aggiunta di nuove feature solo se necessarie e solo se si è molto convinti (questo punto è strategicamente complesso, ma altrettanto importante)
• valutare le nuove feature sia un’ottica di cambiamento continuo che di salto di paradigma: cosa conviene fare?
• garantire eventuali retro-compatibilità o l’utilizzo in toto del vecchio servizio
• attenzione sempre alle minoranze attive (quelli che inviano feedback, i blog che si lamentano dei redesign, gli influencer, ecc).

Scegliere quello che conviene fare in termini costi/benefici al terzo punto può non essere semplice e mi piacerebbe sapere se esistono framework noti a supporto.

Un’ulteriore opzione può essere quella di fare “realign continui”: redesign periodici che vanno a modificare anche strutturalmente e progressivamente il comportamento del prodotto senza però snaturarlo nell’immediato.

Significa cioè fare dei “piccoli saltelli digeribili” in termini di user experience, seguendo un disegno di redesign strategico. Come dire per andare da A a B passando per una serie di passaggi che implichino cambiamenti anche importanti, ma facendoli a piccoli passi per renderli digeribili alla user base.

La differenza tra questo approccio e il miglioramento continuo è nella continua ricerca di un miglioramento strutturale, più che di un over-perfezionamento. In pratica, si dovrebbe evitare di avvicinarsi troppo all’effetto del diminishing return che ho descritto in precedenza, cercando anzi di anticipare i cambiamenti strutturali per evitarlo.

Avere cioè un prodotto che si rinnova continuamente a piccoli saltini, più che perfezionarsi maniacalmente per poi dover richiedere un redesign completo ex-novo. (Poveri giappi, mi rendo conto, loro che vivono di riso e kaizen…)

Ed ecco il rovescio della medaglia: la maggior parte delle aziende ha difficoltà a mantenere un committment alto verso determinate scelte durante un tempo medio-lungo, specialmente se queste sono strutturali. E questi sono approcci che richiedono committment delle figure aziendali con responsabilità strategiche, oltre a un piano di design molto dettagliato e preciso (design stategy). Soprattutto, richiede un UX team interno all’azienda che si faccia portatore di questa strategia, con un “Head of UX” equiparabile agli alti C-level, come dico da tempo.

Riprendo infine la parte dell’affermazione iniziale che ritengo comunque sempre valida: “And they [gli utenti] want to be the ones who own them [i prodotti], control them and decide when they want to change them.”. You betcha.

Food for thoughts.