Lean UX Discovery: dare un nome alla scoperta

Forse alcune metodologie non ci insegnano nuovi modi di lavorare. Ci aiutano semplicemente a dare un nome a quelli che abbiamo già scoperto.

C’è una parola che gira da un po’ nella mia testa:

Scoperta.

Da Treccani:

scoperta /sko’pɛrta/ s. f. [part. pass. femm. di scoprire]. — 1. a. [lo scoprire fatti, luoghi, oggetti e sim.: la s. di nuove terre] ≈ rinvenimento, ritrovamento, (non com.) scoprimento, [riferito a oggetti e sim.] reperimento. b. [acquisizione alla conoscenza umana di fenomeni, leggi e sim., ancora sconosciuti] ≈ rivelazione. 2. (estens.) [presa d’atto del valore di un artista da parte della critica: la s. di Svevo fu opera di stranieri] ≈ riconoscimento. ‖ apprezzamento. 3. (estens.) [accertamento dell’identità dei responsabili di un azione: s. dei colpevoli] ≈ identificazione, individuazione, riconoscimento.

Conoscenza. Rivelazione. Identificazione.

Indugio sulla parola rivelazione.

Togliere il velo.

Disvelare qualcosa che agli occhi era nascosto.

Se togliamo il velo, potremmo vedere:

• qualcosa di conosciuto a noi, ma non altri altri;
• qualcosa di conosciuto a noi e agli altri;
• qualcosa di non conosciuto a noi;
• qualcosa di non conosciuto a noi e agli altri.

E poi c’è l’ultima scoperta, quella per cui la mia sorpresa è sempre enorme:

Quando scopri il nome di qualcosa che conosci molto bene.

Non è la prima volta che scopro che tra le metodologie aziendali si nascondono scoperte ormai radicate e praticate a cui qualcuno, lì fuori, ha dato un nome.

E a me piace dare un nome alle cose, proprio o improprio.

Mi capita sott’occhio, girando sui social, un nome proprio:

Lean UX Discovery

Leggo qualche articolo nel mare digitale, finchè interrogo l’artificio intelligente di OpenAI, ChatGPT, il quale ormai da tempo ormai mi risponde chiamandomi “Nicola”.

Ci ho rinunciato a correggerlo.

Per cui, mi sintetizza una sua definizione:

La Lean UX Discovery è una fase intensiva di ricerca e progettazione collaborativa che serve a capire cosa costruire, per chi e perché, prima ancora di scrivere una singola riga di codice o creare design ad alta fedeltà.

Si basa sul principio che il design è un’ipotesi e il codice è costoso: quindi, meglio validare le idee subito piuttosto che scoprire dopo 6 mesi di sviluppo che nessuno userà quel prodotto o che l’infrastruttura tecnica non lo supporta. Ecco i tre pilastri che la definiscono:

1. Eliminazione degli sprechi (Lean)

2. Team Multidisciplinare (La fine dei Silos)

3. Ciclo: Think → Make → Check

E qui succede una cosa strana.

Perché mentre leggo, mi aspetto di incontrare qualcosa che non conosco. Un metodo nuovo, una pratica da aggiungere alla mia cassetta degli attrezzi, un modo diverso di fare UX.

Invece riconosco qualcosa.

Ma questa cosa io la faccio già.

E forse è proprio questa la parte più interessante della scoperta.

Non scoprire qualcosa che prima non esisteva, ma scoprire che esiste un nome per qualcosa che fai da tempo.

La Lean UX Discovery mette insieme parole che, prese singolarmente, mi sono familiari: ricerca, collaborazione, ipotesi, confronto, prototipazione, validazione.

La novità non è necessariamente nei singoli pezzi.

È nel modo in cui vengono messi insieme.

E soprattutto nel momento in cui vengono messi insieme.

Prima di costruire.

Prima di innamorarsi della soluzione.

Prima di aprire Figma e iniziare a disegnare schermate.

Prima ancora che qualcuno dica: «Ok, quanto ci vuole per svilupparlo?».

Il problema prima della soluzione

Una delle cose che mi ha sempre affascinato del lavoro di progettazione è che spesso ci viene chiesto di trovare una soluzione prima ancora di aver definito bene il problema.

«Ci serve una nuova dashboard.»

«Dobbiamo rifare questa sezione.»

«Facciamo una nuova app.»

«Gli utenti non usano questa funzionalità, cambiamola.»

Sono frasi che sembrano già contenere una direzione.

E in parte la contengono.

Il problema è che una soluzione, quando arriva troppo presto, rischia di diventare il problema.

Perché se qualcuno ha già deciso che dobbiamo fare una dashboard, il nostro lavoro diventa facilmente quello di progettare una dashboard migliore.

Ma la domanda sta nel fare un passo indietro:

Perché ci serve una dashboard?

E ancora:

A chi serve?

Quale problema dovrebbe risolvere?

Come sappiamo che questo problema esiste davvero?

Come viene risolto oggi?

Cosa succederebbe se non costruissimo niente?

Queste domande non producono immediatamente un’interfaccia.

Producono qualcosa di molto meno spettacolare: conoscenza.

E forse è proprio questo il punto della discovery.

Scoprire prima di costruire

La parola Discovery mi piace perché non promette una risposta.

Promette un percorso.

Non dice: «abbiamo già capito tutto».

Dice: «andiamo a vedere».

E andare a vedere significa parlare con le persone, osservare come lavorano, raccogliere informazioni, mettere in discussione quello che pensiamo di sapere, confrontare punti di vista diversi.

Significa anche accettare che l’idea con cui siamo entrati nella stanza potrebbe non essere quella con cui ne usciremo.

Questa, secondo me, è una delle cose più difficili.

Perché progettare significa anche affezionarsi alle proprie idee.

Succede con un’interfaccia, con un flusso, con una soluzione che abbiamo appena disegnato e che improvvisamente ci sembra ovvia.

Ma una buona discovery dovrebbe permetterci di innamorarci un po’ meno delle soluzioni e un po’ di più dei problemi.

Non per complicare il processo.

Al contrario.

Per evitare di passare mesi a costruire qualcosa che non risolve niente.

E allora perché chiamarla Lean?

Qui arriva un’altra parola che conosciamo bene.

Lean.

Snello.

Ridurre gli sprechi.

Imparare velocemente.

Fare qualcosa, verificarlo, imparare, cambiare.

Il principio sembra quasi banale.

Eppure, applicato alla progettazione di prodotti digitali, cambia parecchio il modo in cui guardiamo al lavoro.

Se una nostra ipotesi è sbagliata, scoprirlo con una conversazione, uno sketch o un prototipo a bassa fedeltà costa relativamente poco.

Scoprirlo dopo mesi di sviluppo costa molto di più.

E non parlo soltanto di costo economico.

Costa tempo.

Costa energia.

Costa credibilità.

Costa anche quella piccola parte di noi che, dopo aver lavorato per settimane a qualcosa, deve ammettere:

Ok. Non funziona.

La Lean UX, in fondo, sembra suggerire proprio questo: cerchiamo di scoprirlo prima.

Il momento in cui mi sono accorta che lo facevo già

Ed è qui che torno alla mia scoperta iniziale.

Perché continuando a leggere, mi sono accorta che molte delle cose descritte dalla Lean UX Discovery fanno già parte del modo in cui, nel tempo, ho imparato a lavorare.

Parlare con le persone prima di progettare.

Fare domande.

Mettere in discussione il brief.

Cercare di capire quale sia il problema reale dietro la richiesta.

Coinvolgere persone con competenze diverse.

Fare emergere più possibilità prima di scegliere una soluzione.

Prototipare.

Testare.

Cambiare idea.

Ripetere.

Non perché avessi seguito alla lettera un framework.

Non perché qualcuno mi avesse detto: «Adesso facciamo Lean UX Discovery».

Semplicemente perché, lavorando, alcune pratiche diventano necessarie.

E poi, un giorno, incontri qualcuno che ha raccolto quelle pratiche, le ha organizzate, le ha descritte e ha detto:

Questa cosa ha un nome.

Ed è una sensazione stranissima.

Da una parte pensi: ma allora non sto inventando niente.

Dall’altra pensi: forse non sto inventando niente proprio perché qualcun altro ha già trovato un modo per raccontarlo.

Dare un nome non significa inventare

Forse è questo che mi interessa davvero dei metodi.

Non tanto il metodo in sé.

Ma la possibilità di dare un linguaggio a qualcosa che prima era difficile da raccontare.

Perché finché una pratica non ha un nome, spesso rimane personale.

Io faccio così.

Quando invece trova un nome, diventa condivisibile.

Puoi parlarne con un collega.

Puoi insegnarla.

Puoi metterla in discussione.

Puoi confrontarla con un’altra pratica.

Puoi anche decidere che non fa per te.

Dare un nome alle cose, quindi, non significa necessariamente inventarle.

A volte significa renderle visibili.

Ed è curioso che torniamo proprio lì.

Alla scoperta.

Alla rivelazione.

Al togliere il velo.

Perché forse una metodologia non è sempre una nuova terra da esplorare.

A volte è una mappa che qualcuno ha disegnato dopo essere passato nello stesso posto in cui sei passato tu.

E improvvisamente riconosci la strada.

Ma quindi, serve davvero sapere come si chiama?

Non sempre.

Posso continuare a fare discovery anche senza chiamarla Lean UX Discovery.

Posso fare domande senza chiamarle interviste qualitative.

Posso costruire un prototipo senza dire «stiamo validando un’ipotesi».

Posso coinvolgere gli sviluppatori prima del design senza trasformare necessariamente la cosa in un workshop con un nome preciso.

E forse va bene così.

Perché il rischio opposto è quello di trasformare ogni attività in una metodologia, ogni riunione in un framework, ogni post-it in un rituale.

E finire per fare le cose perché si fa così.

La cosa che mi interessa, invece, è il momento precedente.

Il momento in cui qualcuno si ferma e chiede:

Perché lo facciamo?

Cosa stiamo cercando di scoprire?

Quale ipotesi stiamo mettendo alla prova?

E soprattutto: cosa abbiamo imparato?

Se una metodologia riesce a farci fare queste domande con maggiore consapevolezza, allora forse il suo nome serve.

Non per dirci cosa fare.

Ma per aiutarci a riconoscere quello che stiamo già facendo.

E magari, la prossima volta che scopriremo una nuova metodologia, invece di chiederci immediatamente «come si applica?», potremmo chiederci:

Questa cosa la sto già facendo senza sapere come si chiama?

Perché a volte la scoperta non è trovare qualcosa di nuovo.

È rendere visibile qualcosa che conoscevamo già molto bene.

Brano consigliato per la riflessione post-lettura:

[embed]