{"id":837,"date":"2018-06-27T09:15:15","date_gmt":"2018-06-27T07:15:15","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/discovery-economica\/"},"modified":"2018-06-27T09:15:15","modified_gmt":"2018-06-27T07:15:15","slug":"discovery-economica","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/discovery-economica\/","title":{"rendered":"Discovery economica"},"content":{"rendered":"
\n

Se aprite un qualunque manuale di design, vedrete lo schema del ciclo di design: scoprire, inventare, creare, valutare e ripetere. Ogni volta che abbiamo un nuovo cliente o cominciamo a lavorare a una nuova feature, cominciamo dall’alto del cerchio con la scoperta (o discovery). \u00c8 il momento del progetto in cui definiamo il problema che stiamo cercando di risolvere e quale sar\u00e0 il nostro primo approccio per la sua risoluzione.<\/p>\n

\"Un<\/p>\n

Il caro vecchio ciclo del design<\/p>\n<\/div>\n

Solitamente, in un’azienda strutturata parliamo della discovery all’inizio di un ciclo di sprint, dove ci sono cose come i budget, i product team e i clienti esistenti. Il processo di discovery potrebbe includere delle interviste agli stakeholder o il riversamento di dati esistenti sugli utenti. E usciamo sempre dalla fase di discovery con una qualche idea su come procedere.<\/p>\n

Tuttavia, la discovery \u00e8 intrinsecamente diversa quando lavorate in una no profit, in una startup o in un’azienda agli inizi. Potrebbe esserci un team di design composto da una sola persona (voi), con zero dollari da spendere ed esserci solo poche persone che sanno dell’esistenza dell’azienda. Non ci sono clienti da intervistare e zero dati da esaminare. Questo potrebbe anche essere il caso di grandi aziende quando vogliono testare le acque per una nuova direzione senza impegnarsi troppo (o spendere troppo). Ogni volta che avete dei vincoli di budget, dati e stakeholder, dovete essere flessibili e astuti nel modo in cui condurrete la discovery research. Ma non potete risparmiare sul rigore e sull’accuratezza. Se l’idea con cui uscite dalla fase di discovery non \u00e8 buona, il vostro grande lancio potrebbe diventare un flop che pone fine alla vostra azienda.<\/p>\n

In questo articolo vi guider\u00f2 in un ciclo di discovery research, ma lo applicher\u00f2 a una idea di startup (fittizia). Introdurr\u00f2 delle strategie per condurre la discovery research senza budget, senza dati utente esistenti o risorse di cui discutere. E vi mostrer\u00f2 in che modo, facendo progressi, la ricerca dia forma al business.<\/p>\n<\/div>\n

\n

Scrivete l’ipotesi del problema<\/h2>\n

Una tremenda quantit\u00e0 di inchiostro (reale o virtuale) \u00e8 stata versata proclamando che tutti dovremmo \u201cinnamorarci del problema non della soluzione<\/a>\u201d. Ed \u00e8 stato inchiostro ben speso. Quando si arriva al product building, una filosofia incentrata sul problema \u00e8 la pietra d’angolo di qualunque azienda user centric.<\/p>\n

Ma in che modo, esattamente, sapete quando avete tra le mani un problema che valga la pena risolvere? Se lavorate in un’azienda grande e stabile, potreste avere del feedback dagli utenti e dei dati che vi indicano la via come frecce luminose su una strada ben segnalata verso un problema che vale la pena risolvere. Tuttavia, se state lanciando una startup o lavorando a un’azienda pi\u00f9 grande che si sta avventurando in un nuovo territorio, pu\u00f2 essere pi\u00f9 simile a fare un’escursione nei boschi e cercare il successivo segno che indichi la pista. Le vostre idee probabilmente si basano su esperienze personali e istinto.<\/p>\n

Quando le vostre idee si basano sulle esperienze personali, sulle supposizioni e sull’istinto, \u00e8 importante realizzare che hanno bisogno di un livello di ispezioni superiore alla media. Dovete valutare la domanda \u201cHo un problema che vale la pena risolvere?\u201d con un livello pi\u00f9 alto di rigore rispetto a quello che avreste in un’azienda con un budget da investire e una quantit\u00e0 di dati esistenti. Dovete prendere tutte le vostre idee e supposizioni ed esaminarle accuratamente. E il modo migliore per esaminare le vostre idee e categorizzare le supposizioni \u00e8 con le ipotesi.<\/p>\n

Come descrive il dizionario, un’ipotesi<\/em> \u00e8 \u201cuna supposizione o una spiegazione proposta fatta sulla base di prove limitate come punto di partenza per ulteriori indagini\u201d. Questa serve inoltre come una buona descrizione del perch\u00e9 innanzitutto facciamo discovery research. Potremmo avere un’idea in merito a un problema che vale la pena risolvere ma non ne conosciamo ancora la portata o i dettagli critici. Articolare i nostri istinti, idee e supposizioni come ipotesi di un problema<\/em> getta le fondamenta per l’avanzamento della ricerca.<\/p>\n

Ecco una formula generale che potete usare per scrivere l’ipotesi di un problema:<\/p>\n

\n

Dal momento che [supposizioni e intuizioni sul problema], gli utenti sono [in un qualche stato sgradito], hanno bisogno di [idea di soluzione].<\/p><\/blockquote>\n<\/div>\n

Per questo articolo, ho deciso di \u201clanciare\u201d una startup fittizia (e oltremodo ambiziosa) come esempio. Ecco l’ipotesi del problema che ho scritto per la mia startup:<\/p>\n

\n

Dal momento che il loro business model si appoggia sull’advertising, i social media tool come Facebook sono deliberatamente progettati per \u201cagganciare\u201d gli utenti e renderli dipendenti dal loro servizio. Gli utenti sono infelici di ci\u00f2 e preferirebbero piuttosto avere una relazione pi\u00f9 sana con i social media tool. C’\u00e8 la volont\u00e0 di pagare per un servizio di social media che sia progettato tenendo presente la salute mentale.<\/p><\/blockquote>\n<\/div>\n

In questo esempio, potete vedere che le mie supposizioni sono:<\/p>\n