{"id":303,"date":"2012-09-11T13:58:34","date_gmt":"2012-09-11T11:58:34","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/usabile-ma-inutile-product-discovery\/"},"modified":"2012-09-11T13:58:34","modified_gmt":"2012-09-11T11:58:34","slug":"usabile-ma-inutile-product-discovery","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/usabile-ma-inutile-product-discovery\/","title":{"rendered":"Usabile ma inutile: perch\u00e9 a tutte le aziende serve la product discovery"},"content":{"rendered":"

Brasilia \u00e8 una citt\u00e0 notevole, bizzarra, frutto della visione dell’architetto Oscar Niemeyer<\/a>: fu costruita in quattro anni, dal 1956 al 1960. Pi\u00f9 di 50 anni dopo, la sua bellezza ed eleganza sono rinomate.<\/p>\n

Tuttavia, la capitale del Brasile \u00e8 anche nota per qualcosa d’altro: quanto sia difficile viverci.<\/p>\n

Da lontano appare come una \u201csfavillante citt\u00e0\u201d, come scrisse una volta The Guardian<\/em><\/a>, mentre da vicino Brasilia \u00e8 \u201c\u00e8 un agglomerato urbano violento, oppresso dalla criminalit\u00e0 e dai rumori cacofonici degli ingorghi stradali. Il vero Brasile ne ha invasa la visione utopica.\u201d<\/p>\n

Questo problema echeggia anche nel panorama del web di oggi, dove i bisogni degli utenti ordinari si riversano costantemente nelle visioni utopistiche dei designer. Tutto intorno a noi vediamo dei bellissimi monumenti vuoti, eretti non per i propri utenti quanto per le persone che li hanno creati e per i Vicepresidenti che vanno in cerca di talenti. Anche i siti e le app che vanno oltre la bellezza in favore dell’usabilit\u00e0 spesso falliscono perch\u00e9 non riescono a trovare un mercato sufficientemente grande.<\/p>\n

Perch\u00e9 alcuni prodotti interattivi trovano abbastanza utenti da essere sostenibili? Perch\u00e9 ci sono cos\u00ec tante startup che falliscono, nonostante ci sia un rinnovato interesse nei confronti del design<\/a>?<\/p>\n

\u00c8 importante chiederci: cosa possiamo fare noi?<\/p>\n

\n

L’aumento dei prodotti usabili ma inutili<\/h2>\n

Da tempo abbiamo accettato<\/a> che per far s\u00ec che un prodotto sia utile, deve avere un livello accettabile sia di utilit\u00e0 (\u201cse fornisce le feature di cui si ha bisogno\u201d) e di usabilit\u00e0 (&8220;quanto siano semplici e piacevoli da utilizzare queste feature\u201d). Tuttavia, molto spesso, sembra che ignoriamo la prima in favore della seconda, finendo con centinaia di applicazioni semplici e piacevoli che non hanno alcuna ragione di esistere. Si potrebbe sostenere che la prima versione di Color cadeva in questa trappola<\/a> e quando \u00e8 stata l’ultima volta che abbiamo sentito qualcosa su Path<\/a>?<\/p>\n

Uno dei maggiori problemi in cui si imbattono in particolare i nuovi prodotti \u00e8 la mancanza di “product\/market fit”, come ha notato<\/a> Marc Andreessen:<\/p>\n

La qualit\u00e0 di un prodotto<\/em> di una startup pu\u00f2 essere definita nel modo in cui il prodotto impressiona un cliente o un utente che lo usa davvero: quanto \u00e8 facile usare questo prodotto? Quante feature ha? Quanto \u00e8 veloce? \u00c8 estendibile? Quanto \u00e8 raffinato? Quanti bug ha? La dimensione del mercato<\/em> di una startup \u00e8 il numero e il tasso di crescita di quei clienti o utenti per quel prodotto\u2026 <\/p>\n

La sola cosa importante \u00e8 arrivare al “product\/market fit”.<\/em> “Product\/market fit” significa essere in un buon mercato con un prodotto che possa soddisfare quel mercato.<\/p><\/blockquote>\n

Il problema si solleva quando le startup e le compagnie non passano abbastanza tempo ad aumentare la probabilit\u00e0 di un buon product\/market fit prima<\/em> di cominciare la progettazione e lo sviluppo. Il concetto di Lean Startup di \u201cMinimum Viable Product\u201d \u00e8 certamente utile, ma non sarebbe meglio concentrarci sui Minimum Desirable<\/em> Products<\/a>? Qual \u00e8 lo scopo delle iterazioni rapide se tutto quello che otteniamo \u00e8 il massimo locale<\/a> in maniera pi\u00f9 rapida?<\/p>\n

Ma prima di anticipare e discutere come sistemare questo problema, buttiamoci sulle domande importanti, sui \u201cperch\u00e9\u201d.<\/p>\n<\/div>\n

\n

Perch\u00e9 i prodotti non vanno bene<\/h2>\n

Il pi\u00f9 grande problema di Brasilia \u00e8 che gli architetti che l’hanno progettata non hanno considerato il modo in cui la citt\u00e0 avrebbe potuto essere usata una volta che milioni di persone ci avessero abitato. Hanno mostrato una certa Miopia Architetturale<\/a>, ossia hanno progettato ad uso e consumo del proprio settore ma non per le persone. Gi\u00e0 in precedenza ho scritto di un fenomeno simile nel nostro settore, la Miopia del Designer<\/a>. Attirati dai riconoscimenti (e dai clienti e dai dirigenti) che si meritano, i designer sono attirati dall’apparire in gallerie e blog post che fanno elenchi volti ad attirare molto traffico.<\/p>\n

Non c’\u00e8 niente di assolutamente sbagliato con questo bisogno di riconoscimenti ma diventa<\/em> un problema quando danneggia gli utenti. Se Brasilia ci pu\u00f2 insegnare qualcosa, \u00e8 che diventare sordi ai bisogni degli utenti ci porta lungo un pericoloso percorso discendente, in cui perdiamo il controllo dei nostri prodotti, senza modo di tornare indietro. Una volta che rilasciamo qualcosa, si pu\u00f2 solo iterare o fare pivoting. L’iterazione va benissimo se siete sulla strada giusta, mentre il fare pivoting \u00e8 pericoloso perch\u00e9 pu\u00f2 cambiare il corso e devastare sia gli impiegati sia gli utenti.<\/p>\n<\/div>\n

\n

Un modo migliore: la product discovery<\/h2>\n

Se vogliamo disegnare dei prodotti migliori e pi\u00f9 utili, dobbiamo smetterla di progettare delle soluzioni troppo presto e cominciare invece a fare product discovery, ossia operare secondo un processo che ci aiuti a comprendere in maniera corretta il problema, cos\u00ec che non si progetti in modo migliore ma si progettino cose migliori.<\/p>\n

Il product discovery \u00e8 costituito da tre step:<\/p>\n