Uno degli errori più comuni quando si parla di sviluppo digitale è pensare che un progetto sia qualcosa di statico, definito una volta all’inizio e portato avanti fino alla consegna finale. In realtà un progetto assomiglia molto di più a un organismo vivente, cresce, si adatta, reagisce agli stimoli esterni e cambia continuamente forma durante il suo percorso evolutivo. Oggi parlare di progettazione significa parlare, prima di tutto, di apprendimento.
Alla base di ogni progetto dovrebbe esserci un’attenta analisi del problema. Prima ancora di raccogliere requisiti, definire funzionalità o disegnare interfacce, è fondamentale comprendere cosa abbia spinto un cliente a investire in un determinato prodotto. Quale problema sta cercando di risolvere? Quale opportunità vuole cogliere? Quale gap desidera colmare?
Il Business Problem Statement rappresenta la formalizzazione di questo approccio, un cambio di prospettiva che ci obbliga a fermarci e a formulare correttamente il problema prima di correre verso una soluzione. Molti progetti, infatti, falliscono non perché la soluzione sia stata sviluppata male, ma perché il problema iniziale è stato interpretato in modo superficiale.
Una volta definito il problema entra in gioco il lavoro del team. Il metodo Scrum si fonda su una mentalità collaborativa che mette insieme competenze differenti come designer, sviluppatori, stakeholder e figure di business che contribuiscono alla crescita del prodotto da prospettive diverse. Non esistono più compartimenti stagni nei quali ogni disciplina lavora isolatamente ma un processo condiviso in cui ogni competenza contribuisce a costruire una comprensione più profonda del problema e delle possibili soluzioni, e nel quale ogni risorsa si sente responsabilizzata sull’intero processo evolutivo del progetto, generando inevitabilmente una maggiore richiesta di seniority da parte delle aziende, che sempre più dovranno confrontarsi con l’automazione e con l’impiego di processi agentificati nello sviluppo.
Ma come può essere attuato questo percorso in un team eterogeneo? Esistono sostanzialmente tre figure indispensabili indicate nell’applicazione dal framework Scrum. All’interno del team troviamo il Product Owner, responsabile della massimizzazione del valore del prodotto, lo Scrum Master, che facilita il processo e supporta il team nel migliorare continuamente il proprio modo di lavorare, e i Developers, che non sono semplicemente esecutori ma partecipano attivamente alla comprensione del problema e alla costruzione della soluzione. I Developers rappresentano l’insieme di tutte le figure coinvolte nell’evoluzione del prodotto come UX Designer, UI Designer, UI Developer e sviluppatori, non esistono infatti distinzioni eccessivamente verticali in questo metodo e i team devono creare un continuo interscambio collaborativo e riflessivo.
I progetti, grandi o piccoli che siano, dovranno adattarsi alle nuove esigenze necessarie per ottimizzare i processi e rispondere a un contesto in continua evoluzione.
La convivenza continua tra la Delivery, ovvero la realizzazione concreta delle funzionalità validate, e la Discovery, che consiste appunto nella comprensione continua dei problemi, nella raccolta di evidenze e nella validazione delle ipotesi, definisce un parallelismo di attività che fino a poco tempo fa venivano considerate consecutive e che oggi diventano simultanee. Questo è ormai un requisito imprescindibile (il Dual Track Development) che le nuove generazioni del settore IT dovranno adottare, portando Delivery e Discovery ad essere non quindi due processi distinti ma due tipologie di lavoro che si intersecano e si alimentano reciprocamente.
Di conseguenza la ricerca e l’analisi non vengono confinate all’inizio del progetto, ma continuano durante l’intero ciclo di vita del prodotto, diventando attività distribuite nel tempo, frammentate in piccoli momenti di apprendimento che accompagnano l’evoluzione del progetto.
Ogni nuova informazione raccolta in itinere contribuisce a confermare o modificare le ipotesi esistenti e, talvolta, a generarne di nuove. Invece di considerare le nostre idee come prescrittive, impariamo a trattarle come ipotesi da verificare, ogni scelta progettuale diventa una scommessa consapevole che deve essere validata attraverso osservazioni, dati e feedback.
Non aspettiamo necessariamente di avere un prodotto completo per capire se stiamo andando nella direzione corretta, cerchiamo invece di validare il più rapidamente possibile le nostre intuizioni attraverso prototipi, simulazioni ed esperimenti. Ovviamente, più i prototipi si avvicinano a una rappresentazione realistica e concreta del prodotto, maggiore sarà la loro capacità di fornirci indicazioni affidabili sulla sua efficacia.
La Truth Curve descrive proprio il livello di affidabilità delle informazioni che raccogliamo. Più un esperimento si avvicina all’esperienza reale dell’utente, più possiamo fidarci dei risultati ottenuti.
Una discussione interna o un brainstorming producono evidenze limitate, mentre un’intervista può fornire informazioni più solide, ancora un prototipo testato con utenti reali aumenta ulteriormente il livello di affidabilità, fino ad arrivare al prodotto vero e proprio utilizzato nel mondo reale, che rappresenta la forma più concreta di apprendimento. L’MVP, Minimum Viable Product, rappresenta proprio il minimo investimento necessario per verificare un’ipotesi e raccogliere informazioni significative, da considerare frequentemente durante l’arco progettuale.
Naturalmente il modo migliore per apprendere resta sempre il contatto diretto con gli utenti. Attività come User Research, interviste e usability test permettono di osservare comportamenti reali e comprendere bisogni autentici, rimanendo strumenti estremamente potenti per aiutarci a sostituire supposizioni con evidenze.
Non sempre però abbiamo la possibilità di accedere immediatamente agli utenti, in questi casi possiamo utilizzare alternative più facili come le Proto-Personas e le Customer Journey Maps. Le Proto-Personas rappresentano una fotografia delle nostre attuali convinzioni sugli utenti, si tratta di personaggi immaginari a cui diamo dei tratti reali, delle occupazioni e delle tendenze comportamentali in modo da focalizzare meglio il nostro utente tipo, mentre le Customer Journey Maps ci aiutano a immaginare il percorso che una persona compirà durante l’utilizzo del nostro prodotto. Questi strumenti non rappresentano verità assolute, ma forniscono una direzione plausibile che potrà essere confermata o corretta attraverso successive attività di ricerca.
Rimane comunque un’alternativa indispensabile in caso della impossibilità di effettuare test reali; il mercato ormai ci insegna a ragionare in termini di outcome e non più di output. Una nuova funzionalità, una dashboard o un’applicazione rappresentano degli output, ma il vero valore è rappresentato dagli outcome, cioè dai cambiamenti che queste soluzioni generano nella vita degli utenti o nei risultati dell’organizzazione. Un prodotto efficace non è quello che contiene più funzionalità, ma quello che produce il maggiore impatto, che converte di più, che semplifica flussi complessi e che genera meno frustrazione e maggiore soddisfazione negli utenti reali, utenti che sono sempre più abituati a considerare la tecnologia come qualcosa di semplice e intuitivo, il cui vero contributo consiste nel tempo che consente di risparmiare durante il suo utilizzo.
Tutto questo si riflette in una trasformazione importante anche nella cultura aziendale. L’approccio ideale non è quello basato sui reparti handoff, dove ogni settore completa il proprio lavoro in maniera verticale per poi trasferire il semilavorato al settore successivo della catena di montaggio del progetto, bensi ci porta a un approccio collaborativo in cui tutti condividono una visione d’insieme del prodotto e partecipano alla sua evoluzione. Le organizzazioni più mature dal punto di vista della UX sviluppano progressivamente questa capacità, arrivando a diffondere la sensibilità verso gli utenti all’interno dell’intero team.
Tale percorso viene spesso descritto attraverso il concetto di Design Maturity, più aumenta la maturità del team, più la responsabilità dell’esperienza utente diventa condivisa aumentando nel modo lavorativo una richiesta sempre più concreta di seniority, al contrario delle tendenze registrate negli scorsi anni, convergendo, di fatto, verso una stessa idea: il metodo Scrum, calato nel contesto attuale, non propone una serie di strumenti isolati, ma una filosofia progettuale basata sull’apprendimento continuo, e su una collaborazione fluida, dove comprendere il problema, osservare gli utenti, formulare ipotesi, raccogliere evidenze, adattare le decisioni e migliorare costantemente il prodotto sono le chiavi per rimanere compatitivi. In un mercato che cambia continuamente, la vera differenza non la fa chi riesce a pianificare tutto in anticipo, ma chi riesce a imparare più velocemente degli altri.
Un’identità visiva efficace nasce da metodo, cultura del progetto e visione strategica.
Ogni logo che realizzo è il risultato di un’analisi attenta del contesto, dei valori e degli obiettivi del brand, seguita da una ricerca formale e concettuale mirata. Il design diventa così uno strumento di sintesi: essenziale, riconoscibile e coerente nel tempo.
Scopri alcuni dei miei lavori.
