UX & UI

UX Debt: i rischi che si corrono e come gestirlo in Agile

In un team Agile, dove velocità e flessibilità sono un requisiti necessari, lo UX Debt è (quasi) inevitabile. Ecco due soluzioni pratiche per eliminarlo.

Angela Meduri

feb 3, 2021

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.

Le origini: il debito tecnico

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?

Non solo "tecnico". Nasce lo UX Debt

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:

saltare la fase di user testing
trascurare gli standard del brand e le linee guida di stile
interpretare male la visione del prodotto
acquisire o fondere con altri prodotti
scarsa comunicazione o documentazione
test della QA insufficiente
refactoring ritardato
ecc.

I rischi di rimettere mano alla UX post rilascio

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:

lanciare un prodotto non ottimale ha un impatto negativo sul mercato nel lungo periodo, perché i consumatori legheranno il brand a una cattiva esperienza,
cambiare il design dopo che i clienti si sono abituati, anche se non è ottimale, causa da parte loro un doversi riadattare al prodotto, e cambiare la abitudini non gli piacerà,
cambiamenti continui possono far mancare la percezione di consistenza e coerenza del prodotto,
Internet non dimentica: la cattiva esperienza sul prodotto già rilasciato non si potrà cancellare dalla memoria del web.

UX Debt in ambienti Agile: è la norma?

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.

Come gestire lo UX Debt quando si lavora in Agile

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