Il debito di progettazione
Ciao, siamo Elena Gonzalo👩🏻🎨, UX Designer e David Úbeda👨🏼🎤, manager di LoB Digital Design & UX.
Oggi vi portiamo un articolo/riflessione a quattro mani.
A seguito di un articolo molto interessante pubblicato dal nostro collega Daniel Crespo su linkedin ci siamo resi conto che, anche se non lo avevamo notato consapevolmente, il debito tecnico ci ha influenzato e impattato nei progetti e servizi che progettiamo e nel ciclo di vita di questi. I professionisti entrano ed escono regolarmente dai progetti in diverse fasi e spazi di tempo, e i prodotti digitali si comportano come un essere vivente; nascono, crescono, si riproducono (a volte) e alla fine muoiono, e il 90% delle volte lo fanno fuori dal nostro controllo.
Allora, che cos’è?
Il debito tecnico nel design del prodotto è una realtà che riduce esponenzialmente la qualità di un progetto.
Tuttavia quando viene messo in produzione, in diverse iterazioni e con poco controllo, può diventare un prodotto inflessibile. Pertanto, al momento di metterlo in produzione può essere in attesa di caratteristiche e questo è chiamato debito.
Il debito tecnico del design di prodotto esiste e anche se è difficile da gestire, ci aiuta a non perdere traccia di tutto ciò che non abbiamo potuto implementare e che è rimasto nel design backlog quando è stato messo in produzione. E cosa è stato lanciato perché è stato fatto in quel modo.
Uno scenario comune nei progetti di design di prodotti o servizi è non avere un archivio (e tempo) dove possiamo tenere traccia di tutto ciò che abbiamo progettato per l’architettura dell’informazione, l’accessibilità, l’usabilità, il design UiD e l’interazione e che non si è riflesso nel prodotto finale.
Il debito tecnico ci influenza nel design del prodotto?
Naturalmente, i product designer non sono così speciali come pensiamo di essere, e molte volte quella visione ‘creativa’ o ‘artistica’ che ci piace tanto ci fa dimenticare alcuni aspetti tecnici o di gestione del progetto che riguardano anche noi.
Chiamiamolo debito di design d’ora in poi
Proprio come il debito tecnico, il debito di design appare spesso, più di quanto ci piaccia ammettere, quando i designer e i ricercatori lavorano con scadenze strette o limiti di progetto poco agili, influenzando il prodotto finale e riducendone la qualità. E non stiamo parlando di futuri evolutivi in cui il disastro sarà enorme.
Queste sono tutte quelle idee meravigliose, che sono state anche testate, e sono cadute nel dimenticatoio.
Perché dovremmo evitarlo?
Logica pura: è più facile farlo bene la prima volta che dover fare dei cambiamenti dopo il lancio.
Inoltre, i cambiamenti, in un ambiente digitale stanno per arrivare, così come le evoluzioni e i nuovi sviluppi sullo stesso prodotto, questo è inevitabile, quindi è conveniente avere basi e documentazione solide, pulite e reali in modo che ogni nuova evoluzione non diventi un nuovo design con poca e cattiva relazione con la versione precedente del prodotto.
La riprogettazione e l’evoluzione delle funzionalità in produzione consuma molte risorse inutili: il team di progettazione deve ri-familiarizzarsi con i dettagli delle funzionalità già implementate, spendere tempo a riprogettarle per adattarle alle nuove funzionalità ed eventualmente aggiornare altre parti del prodotto per essere coerenti con le nuove funzionalità introdotte.
“Ora devo imparare come è organizzata l’architettura dell’informazione e ridisegnare i componenti solo per aggiungere un nuovo livello di navigazione, ma questo non era già previsto?”
Ok, questo è successo a te. Anche l’esperienza utente è un costo addizionale del debito
E quali sono i vantaggi del controllo positivo del debito di progettazione? Molti, parecchi:
Nella zona commerciale
Legato all’immagine dell’azienda
Collegato al team di sviluppo
Cosa fare per evitarlo?
Non esiste una formula magica per evitarlo, poiché molte cose dipendono da caratteristiche soggettive. Ricordiamoci che lavoriamo progettando prodotti viventi, quindi, il debito esisterà durante il processo, ma possiamo usare certi consigli e strumenti per renderlo privo di rischi e non estremamente dannoso per i nostri utenti finali e il nostro business.
Per gestire il debito del design del prodotto, dobbiamo prima riconoscerlo. Ci sono due tipi di debito, intenzionale e non intenzionale.
Identificare il tipo di debito:
Trattare con diversi tipi di debito richiede tecniche diverse. Quindi puoi seguire questi consigli:
E alcuni consigli per le fasi del ciclo di vita del prodotto.
Nascono; anche se possiamo iniziare con 0 debito di progettazione è qui che dobbiamo stabilire le regole e le norme per evitare solo l’accumulo di debito tecnico, il meglio? che stimiamo lo sforzo di documentazione, il trasferimento di conoscenze e i meccanismi necessari per evitare il debito tecnico come un compito essenziale del progetto. Il meglio ancora? costruire l’interfaccia grafica basata su un KIT UI o Design System e un’architettura delle informazioni scalabile.
Come possiamo farlo se il progetto ci sfugge di mano? o si evolve nelle funzionalità o nelle specifiche per mano di profili tecnici o di business fuori dal controllo di un ux o interface designer? beh, mi spiace, c’è poco da fare se non aggiornare la documentazione quando hanno bisogno di noi alla fine del disastro, perché alla fine torneranno da noi, e lo sapete.
La cosa cambia quando possiamo essere nell’evoluzione del prodotto; documentare, annotare, conservare le versioni precedenti e pensare ai designer che verranno dopo.
Si riproducono; o rilasciamo una nuova versione sul mercato. Molto importante, la documentazione non parte da 0. Trasferisce la conoscenza dalla versione precedente a quella nuova. Scrivete i cambiamenti o gli aggiustamenti di progetto fatti e perché. Coloro che non imparano dai loro errori sono destinati a ripeterli.
Muoiono; il prodotto finisce la sua vita utile. Forse questo è il meno sensato, ma lo spiegheremo con un esempio reale. Assicuratevi di poter sempre recuperare quel design.
David; ho 3 cd con progetti a mano libera che non potrò mai più aprire 😪
Approfondimenti
Cosa farà apparire o aumentare il debito di progettazione? Cosa dobbiamo fare?
- Aggiustamenti UI necessari per diversi ambienti tecnologici – Lavorare sulla base di una libreria di componenti o di un sistema di progettazione
- Mantenere il flusso di lavoro per tutta la vita del progetto.
- Evoluzione dei bisogni o delle funzionalità senza passare per il design – Mantenere il flusso di lavoro per tutta la durata del progetto.
- Cambio di designer con diverse competenze – Utilizzo di librerie, approccio Atomic Design, file di progettazione originali ben strutturati e documentare i progetti.
- Cambiamenti del cliente – Mantenere il flusso di lavoro per tutta la durata del progetto.
- I profili tecnici intraprendono cambiamenti di funzionalità. – Questo non dovrebbe mai accadere, è uno dei casi che generano il maggior debito di progettazione. Mantenere il flusso di lavoro per tutta la durata del progetto.
- Mancanza di progetti agili – Abbraccia l’agilità (lo so, è molto ovvio).
- Mancanza di strategia UX – Evangelizzare i benefici e il ROI di una buona strategia UX per affrontare progetti di design di prodotti e servizi.
E infine molto importante, documentare, documentare ciò che è stato implementato, e soprattutto ciò che è stato lasciato in arretrato per dopo.
Grazie mille.