Scadenze ristrette e necessità di una delivery rapida spesso si trascinano dietro un debito, o meglio uno UX Debt, che a lungo termine causa minor soddisfazione dei clienti. Quando poi ci si trova in un team Agile in cui la velocità e la flessibilità sono un requisiti necessari, le cose si complicano ancora di più. Per fortuna ci sono delle soluzioni pratiche per eliminare il debito e deliverare un prodotto di elevata qualità senza che ne risenta il cliente finale. Vediamo quali sono.
Cosa succede quando i team di sviluppo velocizzano delle azioni per arrivare in fretta al momento della delivery? Quando alla perfezione del codice si preferisce la velocità della delivery, in futuro si arriverà inevitabilmente al refactoring.
Ward Cunningham, uno degli autori dell'Agile Manifesto, nel 1992 ha coniato il termine “technical debt”, che ha poi descritto con una metafora:
“With borrowed money, you can do something sooner than you might otherwise, but then until you pay back that money you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.”
In poche parole, il debito tecnico rappresenta l'aumento di costo per la manutenzione della tecnologia a causa di scorciatoie prese durante il processo di sviluppo. Sarà un caso che di solito, nelle aziende, la decisione di accumulare debito tecnico sia presa da stakeholder non tecnici?
Partendo dalla definizione di debito tecnico, Joshua Kerievsky ha coniato lo “User Experience (UX) Debt”. Come nel caso del debito tecnico, anche nella UX si crea un debito, che di solito si traduce in una minor soddisfazione del cliente e possibili difetti. Questo debito è frutto del lavoro a strette scadenze e limiti impossibili imposti dal progetto che ricercatori e designer sono costretti a seguire. Secondo Nielsen Norman Group, questi sono i fattori che causano lo UX Debt:
Attenzione:
Correggere un problema di UX costa di più se fatto dopo il lancio
Questo perché il team deve rifamiliarizzare con i dettagli e le caratteristiche del prodotto già lanciato, debuggare il prodotto, aggiungere componenti, ecc. Da un punto di vista ingegneristico, scrivere correttamente il codice per la UI la prima volta è molto più semplice per gli sviluppatori rispetto a dover cambiare codice già prodotto e pubblicato. Ma, secondo NNG, ci sono anche altre ragioni relative più strettamente alla UX:
Nel caso degli ambienti Agile, ci sono situazioni in cui prevale la necessità di uscire sul mercato e di conseguenza l'importanza di trovare alternative che fanno risparmiare del tempo.
Cosa fare in questi casi? Considerare se arrivare più velocemente sul mercato vale il rischio di avere un impatto negativo sulla percezione dell'utente, e contemporaneamente anche valutare i costi di risoluzione post-rilascio. Se il gioco vale la candela, il debito di UX andrà tracciato, gestito, ripagato, ma non si vedrà con il tempo un alto tasso di abbandono.
In teoria, un team che utilizza un processo Agile in modo corretto non dovrebbe avere problemi di prioritizzazione del debito: si assegnano story points e si inseriscono negli sprint. Ma quando Agile significa più velocità che miglioramento continuo, è difficile inserire tutto negli sprint e qualcosa viene lasciato fuori.
Ecco due modi per gestire lo UX debt quando si lavora Agile:
Una soluzione può essere trovare il ritmo per gestire il debito. Jack Moffett, attualmente UX Manager in Boeing, suggerisce di proporre un certo numero di story points a sprint, oppure dedicare uno sprint allo UX debt a intervalli regolari. Questo finché il debito si estingue, poi sarà più semplice gestire il nuovo debito.
Quando i tempi sono troppo stretti si può programmare un Cheese day.
What is cheese? Here’s a rule of thumb: if you’re arguing about whether something is a bug or a feature, it’s cheese!
Quando il gioco si fa duro, un cheese day può togliere di mezzo quanto più debito possibile. Si tratta di pianificare anche un giorno su 60 in cui si cercano di togliere dalla lista più forme di formaggio possibili. Roy Man, Founder & CEO didaPulse.com, ha stilato una procedura ideale, ma anche realistica ed efficace:
2/3 settimane prima del Cheese Day: creare un progetto in una app o piattaforma a piacere (Trello, ad esempio) e incoraggiare tutti (dal Customer Support agli sviluppatori ai designer) a descrivere tutto ciò che annoia il cliente
dare un ordine di priorità ai formaggi secondo lo schema riportato qui sotto e separare i "Quick Wins" dai "Nice-to-haves"
programmare dalle 6 alle 8 ore di Cheese Day e andare dritti sui Quick Wins.
Qui, invece, il grafico di prioritizzazione dello UX Debt secondo Nilsen Norman Group:
UX Debt in the Enterprise: A Practical Approach, UXP Magazine
UX Debt: How to Identify, Prioritize, and Resolve, Nilsen Norman Group
Eliminate UX Debt (Improving Consistency & Usability), Jack Moffett
The Secret to Making UX a Top Priority in Agile