{"id":721,"date":"2017-04-11T17:32:52","date_gmt":"2017-04-11T15:32:52","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/design-discovery-pratica\/"},"modified":"2017-04-11T17:32:52","modified_gmt":"2017-04-11T15:32:52","slug":"design-discovery-pratica","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/design-discovery-pratica\/","title":{"rendered":"Design discovery pratica"},"content":{"rendered":"<p class=\"editors-note\"><strong>Nota degli editori:<\/strong> Siamo lieti di condividere un estratto dal Chapter 3 del nuovo libro di Dan Brown <cite>Practical Design Discovery<\/cite>, disponibile ora presso <a href=\"https:\/\/abookapart.com\/products\/practical-design-discovery\">A Book Apart<\/a>.<\/p>\n<p>Uno dei problemi di design pi\u00f9 difficili su cui io abbia mai lavorato \u00e8 stato per un&#8217;azienda che aiutava i gruppi IT nella gestione del rischio. Il loro prodotto era incentrato su componenti open source, poco costose e ampiamente supportate da un&#8217;enorme comunit\u00e0, ma spesso vulnerabili a causa di falle nella sicurezza.<\/p>\n<p>Quello che ha reso questo problema di design difficile \u00e8 stata la complessit\u00e0 della struttura sottostante al prodotto, un triangolo di concetti astratti collegati tra loro. Per lavorare sul problema, abbiamo creato una serie di sketch che ci hanno aiutato a comprenderlo.<\/p>\n<p>Il risultato \u00e8 stato un prototipo relativamente semplice, un modello della struttura generale dell&#8217;applicazione. Sebbene fossimo stati ingaggiati per creare un design dettagliato, il nostro cliente ha ammesso pi\u00f9 tardi che sapevano che non ci saremmo riusciti, ma che avevano una grande considerazione per l&#8217;impegno messo nel risolvere la struttura sottostante. Questi sforzi hanno impostato la direzione per qualunque altra cosa nel prodotto.<\/p>\n<div class=\"paragrafo\">\n<h2 id=\"section1\">Affermazioni che impostano la direzione<\/h2>\n<p>In maniera molto simile a quando inquadriamo i problemi, possiamo fare delle asserzioni che impostino la direzione e descrivano le decisioni di design. Queste decisioni saranno piuttosto di alto livello, il che significa che riguarderanno una visione olistica del sito o del prodotto. Le decisioni sui dettagli verranno in seguito, sebbene vedrete che alcune affermazioni diventeranno piuttosto specifiche come modo di chiarire e testare la direzione.<\/p>\n<p>Ci sono tre tipi di asserzioni che potete fare sulla direzione del design:<\/p>\n<ul>\n<li>I <strong>principi<\/strong> definiscono cosa dovrebbe o non dovrebbe fare il design. Queste dichiarazioni si fondano sulla ricerca e quando non le si pu\u00f2 legare alla ricerca, si pu\u00f2 far riferimento ad esse come a <em>implicazioni<\/em>.<\/li>\n<li>I <strong>concetti<\/strong> stabiliscono un approccio generale al prodotto espresso come un tema centrale o un&#8217;idea.<\/li>\n<li>I <strong>modelli<\/strong> descrivono il prodotto in modo astratto, mostrando l&#8217;architettura sottostante, la struttura, il flusso o l&#8217;approccio. Offrono un senso del modo in cui il prodotto funzioner\u00e0 (senza l&#8217;effettiva funzionalit\u00e0).<\/li>\n<\/ul>\n<p>Se cercate di prendere delle decisioni tattiche troppo presto, potreste creare un precedente senza capire in che modo influenzi quello che viene dopo: \u00e8 difficile tracciare le decisioni di basso livello a uno specifico obiettivo o a una dichiarazione di problema. Perch\u00e9 il pulsante \u00e8 blu? Non c&#8217;\u00e8 obiettivo di progetto nel mondo che possa giustificare una tale decisione.<\/p>\n<p>Al contrario, prenderete <em>alcune<\/em> decisioni di basso livello insieme alle vostre asserzioni, usando dei campioni per illustrare, chiarire e dimostrare l&#8217;applicazione delle decisioni di alto livello. Per esempio, potreste arrivare al principio di design che il tono del sito dovrebbe essere amichevole senza essere troppo casuale o informale. Potreste dimostrarlo con il design e il contenuto di alcune schermate di esempio, che mostrino messaggi che dicono \u201cThanks!\u201d invece di \u201cThank you very much\u201d che \u00e8 troppo formale o \u201cYou rock!\u201d che \u00e8 troppo casuale.<\/p>\n<p>Esplorare le grandi decisioni attraverso esempi potrebbe incoraggiarvi a riconsiderarle o a trovare dei posti nella product experience in cui servono delle variazioni. Magari la palette dei colori \u00e8 insufficiente per tutto quel che vi serve o la voce autoritaria non \u00e8 appropriata per alcune pagine.<\/p>\n<p>Azzardando una soluzione non state semplicemente chiedendo \u201cFunzioner\u00e0?\u201d, ma anche \u201cHo sufficienti conoscenze per sapere se questa funzioner\u00e0?\u201d, ossia, gli step verso la risoluzione del problema potrebbero far scattare ulteriori insight o domande riguardanti il problema. Una grande fase di discovery implica che si fornisca solo sufficiente forma e definizione in maniera tale che il team si possa allineare dietro a queste e seguire tale direzione per il prodotto.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2 id=\"section2\">Principi e implicazioni<\/h2>\n<p>I principi sono regole che aiutano i designer a valutare le proprie decisioni sul design. Forniscono una guida sotto forma di dichiarazioni assolute su quello che il design dovrebbe o non dovrebbe fare. Detto ci\u00f2, nessun insieme di principi pu\u00f2 essere esaustivo. A volte, sembrano dei comandamenti: regole che potrebbero essere applicate a vari tipi di decisioni di design e pertanto aperte all&#8217;interpretazione.<\/p>\n<p>Non c&#8217;\u00e8 uno standard del settore sul modo in cui vadano scritti i principi di design, quindi non violerete alcuna regola se userete dei pittogrammi o scriverete un dialogo, ma i principi sono solitamente costituiti da una frase, spesso scritta usando l&#8217;imperativo.<\/p>\n<blockquote>\n<p>Fa di pi\u00f9 con meno (Microsoft Design Principles)<\/p>\n<p>Progetta per il cliente e infondi sicurezza (Intuit)<\/p>\n<p>Usa i dati per prendere decisioni e migliorarle (Principles for 21st Century Government, Code for America)<\/p>\n<\/blockquote>\n<p>Queste mi piacciono ma non sembrano specifiche per un prodotto o un&#8217;azienda. I principi sono pi\u00f9 potenti quando sono direttamente rilevanti. Questi usano frasi pi\u00f9 elaborate che sono in stretta relazione con il prodotto:<\/p>\n<blockquote>\n<p>Pi\u00f9 di quadrati su uno schermo (Google Calendar)<\/p>\n<p>Le interfacce transitional sono pi\u00f9 facili da apprendere e pi\u00f9 piacevoli da usare (MapBox)<\/p>\n<p>Il tempo \u00e8 denaro, quindi crea per le persone in movimento (Windows User Experience Design Principles)<\/p>\n<\/blockquote>\n<p>A volte, troverete dei principi resi come frasi nominali di una o due parole, come se completassero l&#8217;espressione \u201cIl principio di ______.\u201d:<\/p>\n<blockquote>\n<p>Maggior contrasto (10 Principles of Codeacademy.com)<\/p>\n<p>Consistenza (First Principles of Interaction Design, Bruce Tognazzini)<\/p>\n<\/blockquote>\n<p>I principi a volte sono seguiti da descrizioni pi\u00f9 approfondite e da esempi. La mia variazione preferita di questo \u00e8 tratta dai <a href=\"http:\/\/bkaprt.com\/pdd\/03-01\/\">Windows User Experience Design Principles<\/a>. Questi principi includono domande che i designers dovrebbero porsi riguardo alle decisioni di design:<\/p>\n<blockquote>\n<ol style=\"margin-left: 1.5rem;\">\n<li>Personalizzazione, non customizzazione\n<ul>\n<li>La feature permette agli utenti di esprimere un elemento di s\u00e9 stessi?<\/li>\n<li>Avete fatto la distinzione tra personalizzazione e customizzazione?<\/li>\n<li>La personalizzazione deve essere una nuova feature o pu\u00f2 usare feature e informazioni esistenti (come la posizione dell&#8217;utente, l&#8217;immagine di background o tile?)<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<\/blockquote>\n<p>Indipendentemente dall&#8217;approccio che prenderete nell&#8217;inquadrare i principi, usate un linguaggio e delle strutture consistenti, anche se solo per renderli pi\u00f9 semplici da ricordare e usare. Se partite con un verbo, partite sempre con un verbo. Se scrivete una frase concisa o una frase completa per esprimere il principio, fate sempre cos\u00ec. Se scrivete principi di una singola parola, beh, c&#8217;\u00e8 un posto speciale tutto per voi in purgatorio.<\/p>\n<p>Nella pratica, io formulo i principi come dirette conseguenze di quello che ho imparato nella ricerca. Li chiamo <em>implicazioni<\/em> e le preferisco perch\u00e9 vanno bene nella narrazione: \u201cAbbiamo imparato che gli utenti spesso perdono l&#8217;orientamento nel sistema. L&#8217;implicazione \u00e8 che la UI dovrebbe avere come priorit\u00e0 chiarire il contesto\u201d.<\/p>\n<p>Le implicazioni rispondono alla domanda: \u201cQuindi?\u201d. Avete generato molti dati e adesso dovete spiegare perch\u00e9 tutto ci\u00f2 \u00e8 importante. Tipicamente, io lo documento in un foglio di calcolo che identifica le domande di progetto, le risposte che ho scoperto e le implicazioni risultanti (<strong>Fig. 1<\/strong>).<\/p>\n<div id=\"figure5\" class=\"illustration full\"><img decoding=\"async\" src=\"http:\/\/alistapart.com\/it\/wp-content\/uploads\/sites\/2\/2017\/04\/findings-and-implications-edit.jpg\" border=\"0\" alt=\"Tabella di tre colonne e cinque righe con un elenco di domande nella colonna uno, risposte nella colonna due e implicazioni nella colonna tre\" width=\"100%\" \/><\/p>\n<p>Fig. 1: Raggruppare le attivit\u00e0 genera risposte alle domande riguardanti il contesto o i requisiti.<\/p>\n<\/div>\n<p>In sostanza, i principi e le implicazioni fanno la stessa cosa, quindi non mi accanir\u00f2 sulla distinzione tra esse. In entrambe i casi, fanno una dichiarazione che s\u00ec, guida il designer, ma fornisce anche un test: i designer possono confrontare un&#8217;idea con il principio e determinare quanto da vicino\/attentamente aderisce alla guida.<\/p>\n<p>Non c&#8217;\u00e8 uno standard per i principi di design, sebbene ci siano molti suggerimenti l\u00e0 fuori (la sezione Risorse include alcune delle migliori). Ecco i miei suggerimenti per creare i principi di design.<\/p>\n<h3 id=\"section3\">Siate specifici<\/h3>\n<p>I principi dovrebbero essere il pi\u00f9 specifici possibili per il prodotto. \u201cFacile da usare\u201d non \u00e8 un principio significativo perch\u00e9 si potrebbe applicare a qualunque cosa.<\/p>\n<p>Per il progetto con l&#8217;azienda di risk management che ho descritto all&#8217;inizio di questo capitolo, abbiamo usato un numero di principi. Nelle prime versioni del loro prodotto, gli utenti si erano lamentati del fatto che fosse facile perdere il segno, quindi non riuscivano a tenere traccia di quello su cui stavano lavorando. Questo ci ha condotto al principio:<\/p>\n<blockquote><p>Mostrare sempre il contesto dell&#8217;utente all&#8217;interno del sistema, cos\u00ec che sappia dove si trova e su cosa sta lavorando.<\/p><\/blockquote>\n<p>Il contesto divent\u00f2 qualcosa di cui si parlava molto. Ci ha obbligato a ragionare attentamente prima di spostare le informazioni a una schermata diversa o prima di lanciare una dialog box per fare un&#8217;azione. A causa di questo principio, ci siamo spesso chiesti: \u201cL&#8217;utente sa dove si trova? La perdita di contesto qui va bene?\u201d.<\/p>\n<h3 id=\"section4\">Mettete in discussione le vostre scelte<\/h3>\n<p>I buoni principi vanno oltre la specificit\u00e0: pongono una sfida diretta ai designer. Vi obbligano a dare una ricontrollata al vostro lavoro: il principio annulla qualcuna delle vostre decisioni? Fatti nel modo giusto, i principi dovrebbero farvi agitare un po&#8217;.<\/p>\n<p>Nel prodotto di risk management, la complessit\u00e0 dei suoi requisiti ha inevitabilmente prodotto dei design densi ed esoterici. Delle visualizzazioni elaborate cercavano di catturare ogni sfumatura, di contenere ogni dettaglio. Allo stesso tempo, il nostro cliente aveva sentito che ai loro utenti non piacevano le visualizzazioni dense. Ci siamo mossi su un confine labile e ci siamo basati su questo principio:<\/p>\n<blockquote><p>Mostra solo l&#8217;informazione sufficiente per supportare le decisioni essenziali, niente di pi\u00f9, niente di meno.<\/p><\/blockquote>\n<p>L&#8217;auto-contraddizione borderline del principio ci ha spronato a riconsiderare quello che avrebbe dovuto esserci su ciascuna schermata mentre gli utenti lavoravano attraverso il processo. <em>Abbiamo tolto troppo? \u00c8 assolutamente necessario tutto quello che c&#8217;\u00e8 su questo schermo?<\/em> Da un lato, volevamo che gli utenti si sentissero sicuri su dove fossero, ma dall&#8217;altro, non volevamo che la pagina fosse sovraccarica di dispositivi di navigazione irrilevanti per il task corrente.<\/p>\n<p>Ci siamo anche costantemente chiesti \u201cCosa vuol dire \u2018giusto l&#8217;informazione essenziale\u2019?\u201d e \u201cQuali sono le \u2018decisioni essenziali\u2018?\u201d. Ogni iterazione del design ha testato il significato di queste frasi chiave.<\/p>\n<h3 id=\"section5\">Ispirare il proprio team<\/h3>\n<p>Principi specifici e provocativi potrebbero apparire come frustate: <em>Fai cos\u00ec e fallo in questo modo<\/em>. Ma un buon principio deve anche ispirare, indirizzandovi verso obiettivi ancora pi\u00f9 nobili. Apre possibilit\u00e0 incoraggiandovi a esplorare e fornisce una base logica che definisce il punto di arrivo.<\/p>\n<p>Nel suo riassunto di una talk di Stephan Hoefnagels di Microsoft del 2009, Luke Wroblewski scrive: \u201cGli obiettivi sono la cima della montagna che state cercando di scalare. I principi [di design] sono il sentiero che utilizziamo per raggiungere la cima della montagna.\u201d.<\/p>\n<p>Uno dei principi guida per il prodotto del mio cliente si basava sull&#8217;idea che il prodotto fosse focalizzato sulle cattive notizie: ogni schermata riguardava qualcosa che stava andando male nel dipartimento IT quel giorno, quando fosse seria la situazione e cosa non era in esecuzione. Tuttavia, come la maggior parte dei prodotti interattivi, questo doveva essere piacevole da usare. In breve, dovevamo trovare un equilibrio tra il vedere tutto nero e la soddisfazione derivante dal comprendere la natura e la portata delle cattive notizie. Ci siamo basati su questo principio:<\/p>\n<blockquote><p>Create fiducia dichiarando chiaramente i rischi e facendo in modo che si possa agire in base ai dati.<\/p><\/blockquote>\n<p>Sapevamo che l&#8217;obiettivo era di aiutare i clienti a gestire i rischi. Questo principio ha agito da sentiero verso la cima della montagna ispirandoci a concentrarci non solo sul riferire le cattive notizie ma anche sull&#8217;essere sicuri che i clienti potessero fare qualcosa a tal proposito.<\/p>\n<h3 id=\"section6\">Collegare i principi alla ricerca<\/h3>\n<p>I principi con base nella ricerca producono dichiarazioni pi\u00f9 forti. La campana a morto di ogni principio \u00e8 l&#8217;arbitrariet\u00e0: se un principio deriva dalla preferenza soggettiva del Chief Something Officer o perch\u00e9 riflette il modo (disfunzionale) in cui l&#8217;organizzazione ha sempre lavorato, i designer lo ignoreranno. Il vostro principio potrebbe altrimenti essere perfetto ma se la fonte \u00e8 sospetta, il team non lo prender\u00e0 sul serio.<\/p>\n<p>Inoltre, qui \u00e8 di cruciale importanza la partecipazione del team a tutte le attivit\u00e0 di discovery. Dal momento che hanno contribuito alla ricerca, possono anche aiutare a scrivere i principi. Partecipando nella realizzazione dei principi, il vostro team li far\u00e0 propri. Vedere i principi pi\u00f9 in l\u00e0 nel tempo far\u00e0 scattare dei ricordi delle osservazioni degli utenti, che possono integrare pi\u00f9 prontamente nel loro lavoro.<\/p>\n<p>I Windows User Experience Design Principles derivavano direttamente dalla ricerca. Nel leggere alcuni di questi principi, potete quasi sentire le frasi a supporto dette dagli utenti:<\/p>\n<ul>\n<li>Ridurre i concetti per far aumentare la fiducia.<\/li>\n<li>Le cose piccole contano, nel bene e nel male.<\/li>\n<li>Essere esperti di \u201cguarda\u201d e \u201cfai\u201d<\/li>\n<li>Risolvere le distrazioni, non la discoverability.<\/li>\n<li>UX prima di pulsanti e domande.<\/li>\n<li>Personalizzazione non customizzazione.<\/li>\n<li>Dare valore al ciclo di vita dell&#8217;esperienza.<\/li>\n<li>Il tempo \u00e8 importante, quindi create per le persone in movimento.<\/li>\n<\/ul>\n<p>Potreste argomentare che manca loro della specificit\u00e0. Tuttavia, quando prendete in considerazione la portata del progetto (un intero sistema operativo) sono sufficientemente provocatori e ispiratori. \u201cRisolvere le distrazioni non la discoverability\u201d \u00e8 un&#8217;affermazione audace, che offre chiare opportunit\u00e0 per rifinire il design senza dettare una soluzione in particolare. Apre delle conversazioni e inoltre le guida.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2 id=\"section7\">Concetti e grandi idee<\/h2>\n<p>Una delle mie scene preferite in <em>Mad Men<\/em>, lo show televisivo sulle agenzie pubblicitarie negli anni &#8217;60, \u00e8 il pitch alla Kodak alla fine della prima stagione. Kodak sta presentando un nuovo prodotto, un vassoio circolare che rende semplice il posizionamento delle diapositive e la loro proiezione. Lo chiamano \u201cLa Ruota\u201d, ammettendo \u201cSappiamo che le ruote non sono viste come una tecnologia esaltante\u201d.<\/p>\n<p>Il creative director Don Draper, il protagonista dello show, spiega che questo prodotto non riguarda la tecnologia: attinge ai nostri ricordi e alle nostre emozioni. L&#8217;agenzia poi svela il proprio concept per la campagna: la giostra.<\/p>\n<p>Stabilendo un concetto centrale, un team (che sia nell&#8217;advertising o nel web design) ha una fonte singolare di ispirazione, un template per valutare le idee. E mentre i principi possono servire come punti guida, solo un concept pu\u00f2 stabilire una vision. Con entrambe nel vostro toolkit, il vostro team ha una tensione potenzialmente interessante a cui attingere.<\/p>\n<p>Usare una giostra per descrivere un proiettore di diapositive crea una metafora traboccante di significato e possibilit\u00e0. Mostra due modi in cui possiamo esprimere una grande idea:<\/p>\n<ul>\n<li><strong>Come vi fa sentire il prodotto:<\/strong> le giostre evocano la gioia del rivivere ricordi felici.<\/li>\n<li><strong>Come funziona il prodotto:<\/strong> la giostra che gira mima il posizionamento e la visualizzazione delle diapositive dalla ruota.<\/li>\n<\/ul>\n<p>Ciascun approccio pu\u00f2 aiutarci ad esprimere la grande idea che sta dietro ai nostri prodotti digitali e siti web. (Sebbene io non abbia mai lavorato a un progetto che ci abbia fornito un concetto elegante come la giostra, che impiega entrambe gli approcci!)<\/p>\n<h3 id=\"section8\">Come vi fa sentire il prodotto<\/h3>\n<p>Lo scopo e la funzione dei prodotti interattivi offre opportunit\u00e0 mature per metafore, ma la metafora non \u00e8 l&#8217;unico modo per esprimere un concetto centrale. Per un progetto di un&#8217;applicazione web, il mio team ha espresso l&#8217;essenza con la frase \u201cPotere con flessibilit\u00e0\u201d. Non \u00e8 cos\u00ec immediato come la parola giostra, ma evoca la sensazione desiderata: che la app faccia sentire gli utenti come se potessero fare qualunque cosa.<\/p>\n<p>L&#8217;abbiamo elaborata con le descrizioni del modo in cui le persone potrebbero fare esperienza di potere illimitato con il prodotto:<\/p>\n<blockquote>\n<p>Fornire agli utenti uno status aggiornato cos\u00ec che sentano di avere il controllo<\/p>\n<p>Ridurre le barriere in entrata<\/p>\n<p>Permettere diversi stili di creazione di nuovo contenuto<\/p>\n<\/blockquote>\n<p>Abbiamo anche descritto il significato di \u201cPotere con flessibilit\u00e0\u201d dalla prospettiva dell&#8217;utente:<\/p>\n<ul>\n<li><strong>Conoscenza:<\/strong> avere i dati giusti per far luce su bisogni immediati<\/li>\n<li><strong>Reattivit\u00e0:<\/strong> essere in grado di fornire immediatamente risposte agli stakeholder<\/li>\n<li><strong>Risultato:<\/strong> apprendere subito e bene un tool di importanza cruciale<\/li>\n<li><strong>Controllo:<\/strong> essere in grado di ottimizzare il proprio contenuto per soddisfare bisogni diversi in situazioni diverse<\/li>\n<li><strong>Comfort:<\/strong> vedere l&#8217;applicazione come un&#8217;estensione del proprio processo di ragionamento<\/li>\n<\/ul>\n<p>Dal momento che questa era un&#8217;idea succinta, un po&#8217; di elaborazione ha contribuito a farle avere un forte impatto sia con il cliente sia con il team di progetto.<\/p>\n<h3 id=\"section9\">Come funziona il prodotto<\/h3>\n<p>I prodotti interattivi complessi traggono beneficio da un&#8217;idea centrale che descrive il modo in cui funzionano. Questo solitamente significa impiegare una grande idea per convogliare la struttura sottostante.<\/p>\n<p>Il <em>carrello della spesa<\/em>, per esempio, \u00e8 una metafora popolare usata sui siti di ecommerce. Potreste usarla anche se non steste lavorando a un sito di ecommerce. L&#8217;idea di \u201caggiungere cose al carrello\u201d \u00e8 una metafora famigliare che convoglia la struttura sottostante del sito. Abbiamo addirittura fatto affidamento su questa metafora nel nostro sito di career-guidance: gli studenti \u201caggiungono le carriere al proprio carrello\u201d dopo essere stati valutati.<\/p>\n<p>Ci sono alcuni altri framework affidabili per descrivere la struttura di un sito web. Per la applicazioni web, ce ne sono due comuni oltre al carrello:<\/p>\n<ul>\n<li><strong>Hub-and-spoke:<\/strong> questo \u00e8 probabilmente il pattern pi\u00f9 comune per strutturare un sito web o un prodotto digitale. La metafora hub-and-spoke implica che l&#8217;applicazione web ha una schermata centrale dalla quale gli utenti possono far partire altre funzioni.<\/li>\n<li><strong>List-detail:<\/strong> un altro approccio tipico consiste in una lista di item che gli utenti possono selezionare per maggiori dettagli, come la inbox dell&#8217;email.<\/li>\n<\/ul>\n<p>Dovete usare una di queste strutture? Ovviamente no. Ma se il vostro sito si presta a uno di questi approcci, avete la vostra <em>grande idea<\/em> attorno alla quale ruota tutto il resto. (Non \u00e8 un riferimento alla giostra, lo giuro).<\/p>\n<p>Per siti focalizzati sull&#8217;invio di contenuti (piuttosto che sulla funzionalit\u00e0 di compravendita), i framework sicuri gestiscono di pi\u00f9 il modo in cui \u00e8 organizzato il contenuto:<\/p>\n<ul>\n<li><strong>Topic:<\/strong> l&#8217;oggetto del contenuto o il tema di discussione<\/li>\n<li><strong>Azioni:<\/strong> che task supporta il contenuto (come la ricerca di prodotti rispetto alla risoluzione dei problemi dei prodotti)<\/li>\n<\/ul>\n<p>Queste non sono le sole strutture per categorizzare il contenuto ma sono i miei punti di partenza abituali.<\/p>\n<p>Nessuno di questi \u00e8 un design completamente sviluppato di per s\u00e9: sono tutti framework ben compresi che fungono da spina dorsale di un design pi\u00f9 grande. Sono grandi idee che descrivono in che modo funziona il prodotto.<\/p>\n<p>Non dovete fare affidamento su un&#8217;astrazione o metafora (come la giostra) per convogliare la grande idee ma al contrario attingere dall&#8217;emergente collezione di framework compresi. Il fatto che stiano diventando una parte dei gergo del web design \u00e8 testimonianza del loro potere e della loro flessibilit\u00e0.<\/p>\n<\/div>\n<div class=\"paragrafo\">\n<h2 id=\"section10\">C&#8217;\u00e8 altro oltre a questo articolo!<a class=\"subhead-anchor\" href=\"https:\/\/alistapart.com\/article\/practical-design-discovery#section10\">#section10<\/a><\/h2>\n<p>Leggete il resto di <cite>Practical Design Discovery<\/cite> su <a href=\"https:\/\/abookapart.com\/products\/practical-design-discovery\">A Book Apart<\/a>.<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Quando non possiamo ricondurre delle decisioni di basso livello a uno specifico obiettivo o a una dichiarazione di un problema, perdiamo di vista quello che dovremmo e non dovremmo fare in un progetto. Dan Brown ci mostra in che modo creare asserzioni che impediscano al design di deragliare.<\/p>\n","protected":false},"author":818,"featured_media":7000818,"comment_status":"open","ping_status":"open","template":"","categories":[177,9,278],"tags":[],"coauthors":[504],"class_list":["post-721","article","type-article","status-publish","has-post-thumbnail","hentry","category-numero-199-4-aprile-2017","category-usabilita","category-workflow-tools"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/721","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=721"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000818"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=721"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=721"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=721"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=721"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}