Nel 1981 Bruno Munari pubblica il suo libro “Da cosa nasce cosa”, un libro all’interno del quale senza troppi giri di parole Munari racconta il processo sempre uguale che porta un designer alla progettazione di un oggetto partendo dal problema da risolvere e trovando per esso una soluzione.

Nel 1981 io avevo solo 5 anni ma leggendo oggi questo libro trovo molte attinenze con le attività che cerchiamo di fare ogni giorno, progetti, prodotti, servizi e trovo quindi che sia un libro attualissimo.

Quante volte in una nostra giornata tipo usiamo la parola “problema”? Probabilmente troppe. Solitamente dato il problema cerchiamo di trovare una soluzione passando attraverso un’idea che ci permetta di risolvere la situazione. Ci sforziamo di semplificare usando uno schema P (problema) –> I (idea) –> S (soluzione).

Secondo Munari parlare di idea non ci aiuta molto perché l’idea dovrebbe offrire una soluzione pronta all’uso per poter risolvere il problema e questo solitamente accade molto raramente. All’idea è meglio sostituire la creatività (C), abilità che ci permette di trovare una soluzione tenendo conto di ciò che abbiamo e che emerge dall’analisi dei fatti e dei dati.

Il processo creativo

Il processo che porta da P (problema) a S (soluzione), secondo Munari si articola in diversi passaggi che provo qui a riassumere perché sono veramente tanti:

• P è il problema da risolvere. Come sempre l’esigenza del cliente che vogliamo soddisfare.
• DP è la definizione del problema. Sappiamo bene che il racconto del cliente contiene all’interno tante cose e DP è la fase in cui estrapoliamo quindi l’essenziale.
• CP sono i componenti del problema. In ottica agile saranno ad esempio gli elementi di uno story mapping con il quale frammentiamo e scomponiamo il problema in sotto-problemi di più facile risoluzione o gestione.
• RD è la raccolta dei dati. Essenziale per arricchire i componenti del problema e chiarirli. Il confronto con il cliente e il feedback loop ci aiutano ad attraversare questa fase.
• AD è l’analisi dei dati. Una volta raccolte e organizzate le informazioni servirà fermarsi e riflettere su cosa farne e come gestirle al meglio. Alcune cose andranno fatte subito, altre saranno potenzialmente inutili o troppo complicate. Il backlog refinement delle pratiche agili, Scrum tra tutte, va in questa direzione.
• C è la creatività che possiamo mettere in campo per trovare una soluzione che tenga conto di tutte le informazioni raccolte e analizzate ai punti precedenti.
• MT sono i materiali e la tecnologia che sceglieremo di utilizzare. Per un designer di oggetti fisici forse c’è più spazio per l’immaginazione ma anche nel caso di prodotti di altra natura decidere come e con cosa realizzeremo il progetto è un passo importante e che spesso si da per scontato in base alle competenze già acquisite del nostro team.
• SP è la sperimentazione che nell’ambito del design si traduce in prove ed esperimenti per poi arrivare ad uno o più prototipi. Una fase che dovrebbe essere in carico ai nostri team ma che spesso saltiamo per mancanza di tempo e necessità di massimizzare illusoriamente il risultato.
• M sono i modelli che andremo a scegliere dopo la fase di prototipazione. Capito cosa può funzionare e cosa effettivamente vogliamo realizzare, solo allora, decideremo di lavorarci sul serio realizzando dei modelli di riferimento.
• V è la verifica, fase fondamentale per assicurarsi che tutto funzioni a dovere prima di lanciarsi nella produzione industriale. Per noi sono le fasi di test e verifica con i clienti.
• DC sono i disegni costruttivi che permetteranno ad altri di poter realizzare industrialmente gli oggetti di design. Nel nostro caso potrebbe essere la documentazione, utile in futuro per aiutare altre persone a comprendere il funzionamento dei nostri prodotti e le decisioni prese.
• S è la soluzione, finalmente abbiamo accontentato il nostro cliente e se siamo stati bravi lo avremo fatto rilasciando valore reale e non solo accontentandolo rispetto alla richiesta iniziale.

Come ti anticipavo, il processo progettuale e creativo è molto lungo e articolato ma a ben guardare offre spunti attualissimi rispetto a quello che è il lavoro di ogni giorno a prescindere dalla natura e dal tipo di prodotti che realizziamo. Trovo che sia un processo molto vicino alle pratiche agili perché ci obbliga a prendersi il giusto tempo per capire, sperimentare, testare e solo dopo partire a testa bassa per risolvere il problema.

La prossima volta che qualcuno in una riunione comincerà con la solita frase “il problema è che…. e noi dobbiamo fare così…”, ripensa al processo suggerito da Munari e blocca sul nascere lo schema semplificato P (problema) –> I (idea) –> S (soluzione), specie se a proporre I è un manager che ragionevolmente non conosce in dettaglio tutte le implicazioni di P ed I rispetto a S.