{"id":647,"date":"2016-08-17T11:24:52","date_gmt":"2016-08-17T09:24:52","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/design-bugie-a-fin-di-bene-ed-etica\/"},"modified":"2016-08-17T11:24:52","modified_gmt":"2016-08-17T09:24:52","slug":"design-bugie-a-fin-di-bene-ed-etica","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/design-bugie-a-fin-di-bene-ed-etica\/","title":{"rendered":"Design, bugie a fin di bene ed etica"},"content":{"rendered":"
\n

A meno che non siate un fan dei dark<\/a> o shady<\/a> patterns, probabilmente di tanto in tanto combattete con l’integrit\u00e0 dell’esercizio del design: equilibrare i desideri degli stakeholder con i bisogni degli utenti, per esempio, o guidare gli utenti verso gli hero path continuando a garantire loro la libert\u00e0 di esplorare.<\/p>\n

Recentemente, ho lavorato al redesign di una app mobile di timebanking, che aiuta i vicini a condividere dei servizi e a creare relazioni di sostegno vicendevole. L’aspetto del bene comune del progetto era affascinante: i valori di community, fiducia e supporto dell’app ci hanno fatto concentrare sulla soddisfazione dei bisogni degli utenti e dell’essere onesti nei nostri design. Quindi, ovviamente, volevamo mostrare agli utenti solo informazioni che fossero letteralmente, concretamente vere. Ma cosa succederebbe se una leggera deviazione dalla verit\u00e0 rendesse gli utenti pi\u00f9 felici e pi\u00f9 efficienti nel raggiungere i propri obiettivi? E se ritoccare un’interfaccia aiutasse a rassicurare e velocizzare l’utente lungo il percorso?<\/p>\n

Non si tratta di una questione insolita. Probabilmente vi sarete imbattuti in pulsanti \u201cChiusura porta\u201d che non fanno davvero chiudere l’ascensore o delle subdole progress bar che si riempiono con una frequenza arbitraria: queste false affordances e questi pulsanti placebo sono ovunque e potrebbero far sembrare un po’ pi\u00f9 semplice la vita. Ma \u00e8 design etico? E possiamo costruire un framework per lavorare con le false affordances e progettare con integrit\u00e0?<\/p>\n

\n

Cos’\u00e8 questo chiasso?<\/h2>\n

Le banche del tempo sono scambi locali e virtuali in cui i vicini possono postare richieste e offerte di servizi in cambio di \u201ctimedollars\u201d, una moneta alternativa<\/a> non sostituibile basata su un’ora di servizio. Per esempio, se faccio un’ora di cucito per te, posso \u201cspendere\u201d quel timedollar che ho guadagnato facendo tagliare il mio prato a qualcuno per un’ora. Lo ammetto, non so cucire e non ho un prato, per\u00f2 ho reso l’idea.<\/p>\n

Permettendo ai vicini di connettersi e di aiutarsi a vicenda, le banche del tempo creano una comunit\u00e0 in quella che era solo<\/em> una location. Attraverso il mobile timebanking, le persone si sentono pi\u00f9 connesse ai propri vicini e maggiormente supportate nella vita quotidiana. In realt\u00e0, questa \u00e8 la value proposition che ha guidato il nostro progetto.<\/p>\n

Con i team assunti da PARC<\/a>, Pennsylvania State University e Carnegie Mellon University, il nostro obiettivo era di fare il redesign dell’app mobile di timebanking esistente per renderla pi\u00f9 usabile e per mettere in connessione gli utenti pi\u00f9 facilmente attraverso delle tecnologie context-aware e di abbinamento.<\/p>\n

Abbiamo cominciato valutando i problemi dell’app esistente (mappando la Architettura dell’Informazione, registrando i binari morti e le ridondanze, facendo un audit del contenuto) e analizzando i dati sulle azioni dell’utente che sembravano pi\u00f9 problematiche. Per esempio, le offerte e richieste per servizi di timebanking erano, nell’app esistente, messi in liste su pi\u00f9 livelli, con categorie gerarchiche come Craiglist, ma con molti pi\u00f9 livelli di profondit\u00e0.<\/p>\n

\"Due<\/p>\n

Livelli di gerarchia nella vecchia app, richiedenti navigazione e task cognitivi. Queste categorie erano spesso vuote.<\/p>\n<\/div>\n

Le nostre analisi ci hanno mostrato due cose interessanti: primo, che il servizio richiesto molto spesso era un passaggio (ad esempio per andare dal dottore o per fare la spesa) perch\u00e9 la popolazione utente era spesso anziana e con minor mobilit\u00e0 e secondo, che molti post da parte degli utenti per offrire o richiedere passaggi a un certo punto del processo venivano abbandonati.<\/p>\n

Abbiamo ipotizzato che magari la natura tempestiva del passaggio scoraggiasse gli utenti dal postare una richiesta su una lista statica, magari gli autisti non pensavano di esplorare pi\u00f9 livelli della statica per dire \u201cHey, io vado da vicino a X<\/em> a Y<\/em> pi\u00f9 o meno a quest’ora alcuni giorni alla settimana – a qualcuno pu\u00f2 servire un passaggio?\u201d. Perci\u00f2, abbiamo incorporato dei walk-through della vecchia app in interviste semi-strutturate che stavamo gi\u00e0 facendo durante la nostra ricerca sulle motivazioni dello sharing peer-to-peer<\/a>: le azioni e le risposte dei partecipanti supportarono le nostre ipotesi.<\/p>\n

Tenendo a mente ci\u00f2, abbiamo proposto una nuova feature e abbiamo cominciato a farne un prototipo, TransportShare, al livello pi\u00f9 alto della app. Speravamo che la sua presenza sulla schermata home della app ne avrebbe incoraggiato l’uso e la sua somiglianza con le app di richiesta passaggi avrebbe facilitato gli utenti nell’esperienza.<\/p>\n

Abbiamo creato una lista di parametri che l’utente avrebbe dovuto specificare: il punto di partenza\/raccolta, il punto finale\/di discesa, l’orario in cui si passa a prendere, il \u201cfudge factor\u201d (quanto \u00e8 flessibile questo tempo), se il viaggio \u00e8 di sola andata o andata e ritorno e un campo di testo per ogni esigenza particolare o per delle osservazioni. Poi abbiamo creato dei prototipi, dalle bozze disegnate ai mockup low-fidelity fino a quelli high-fidelity, per arrivare ai prototipi interattivi usando Sketch e Invision.<\/p>\n<\/div>\n

\n

Come scegliamo<\/h2>\n

Il nostro dilemma etico \u00e8 emerso quando abbiamo progettato il processo di richiesta di un passaggio. Dopo che l’utente specifica i punti di \u201cStart\u201d e \u201cEnd\u201d per un passaggio, l’app mostra una schermata di riassunto con questi punti, l’ora del viaggio e alcune opzioni.<\/p>\n

\"Screenshot<\/p>\n

Image credit: Dan Turner e Stephanie Snipes<\/p>\n<\/div>\n

Dato che siete tutti designer eccellenti, avrete notato che non ci sono linee che collegano i punti Start ed End, nel modo in cui c’\u00e8 in altre app in cui viene creato un percorso, come Google o Apple Maps. L’abbiamo fatto deliberatamente: la nostra user research ha mostrato che chi offre dei passaggi spesso fa anche altre commissioni oppure potrebbe dover fare una deviazione. Dal momento che non potevamo anticipare questi bisogni, non potevamo garantire un percorso specifico: mostrare una strada sarebbe stato, come molta probabilit\u00e0, sbagliato. Inoltre, in modo particolare in un’app che dipende dai valori di comunit\u00e0 e dall’onest\u00e0, sarebbe sembrato ingannevole.<\/p>\n

Essere sinceri all’n-esima potenza \u00e8 una scelta etica, giusto? Non dovremmo mostrare nulla che potrebbe non essere accurato al 100% e ingannare l’utente, giusto? Farlo sarebbe sbagliato, giusto? Giusto?<\/p>\n

Oh, mi sbagliavo. Mi sono sbagliato proprio tanto.<\/p>\n<\/div>\n

\n

Ed ecco\u2026 Un test<\/h2>\n

A questo punto, avevamo delle domande concrete su cui fare ricerca che non avevamo ad uno stadio precedente e dei prototipi puliti e cliccabili in Invision che potevamo presentare ai partecipanti. Senza budget per i test, ho trovato dei potenziali partecipanti a un Meetup pensato per permettere alla gente di condividere e testare i propri progetti e l\u00ec vi ho selezionato quelli che avevano usato una qualche forma di app peer-to-peer. (Stiamo pianificando degli ulteriori test di usabilit\u00e0 con pi\u00f9 partecipanti senior, specificatamente per la leggibilit\u00e0 e l’accessibilit\u00e0).<\/p>\n

Ho condotto i test con un utente per volta, prima dando delle informazioni sulla natura delle banche del tempo (voi ci siete gi\u00e0 passati) e impostando lo scenario in cui hanno bisogno di un vicino che li porti in auto in un posto vicino. Gli \u00e8 stata data libert\u00e0 di azione nel scegliere se si trattava di un passaggio necessario subito o in un secondo momento e se sarebbe stato di sola andata o andata e ritorno. Ovviamente, ho incoraggiato il ragionamento ad alta voce.<\/p>\n

All’avanzare nel task, ho misurato sia il tempo su ogni schermata (o subtask) sia la risposta emotiva (valutata dalle espressioni del volto e dal tono delle risposte).<\/p>\n\n\n\n\n\n\n\n\n\n\n
Task: Richiesta Passaggio<\/caption>\n
Subtask<\/th>\nMedia<\/th>\nOutlier<\/th>\nEmozione<\/th>\n<\/tr>\n<\/thead>\n
1: Impostazione tempistica della richiesta<\/td>\n11s<\/td>\n12s<\/td>\n<\/td>\n<\/tr>\n
2: Impostazione solo andata\/AR<\/td>\n10s<\/td>\n17s<\/td>\n<\/td>\n<\/tr>\n
3: Scelta punto start<\/td>\n7.5s<\/td>\n11s<\/td>\n<\/td>\n<\/tr>\n
4: Scelta destinazione<\/td>\n6s<\/td>\n8s<\/td>\n<\/td>\n<\/tr>\n
5: Conferma richiesta<\/td>\n9.5s<\/td>\n14s<\/td>\n<\/td>\n<\/tr>\n
6: Revisione richiesta<\/td>\n14.8s<\/td>\n18s<\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Gli utenti tendevano a muoversi facilmente attraverso l’intero task, finch\u00e9 non arrivavano al Subtask 6 (rivedere la richiesta sulla schermata di riepilogo) e l\u00ec mi sono accorto che c’era un problema.<\/p>\n

I partecipanti esitavano vistosamente, commentando con espressioni tipo \u201cummm\u2026\u201d: le loro dita e i loro occhi andavano avanti e indietro sulla mappa, pi\u00f9 o meno tra i punti etichettati come Start e End. Quando ho posto domande aperte come \u201cCosa vedi?\u201d e \u201cCosa ti saresti aspettato di vedere?\u201d, i partecipanti hanno detto che si sarebbero aspettati di vedere delle linee indicanti il percorso tra Start e End.<\/p>\n

Nelle sessioni di debrief, i partecipanti hanno detto di essere consapevoli che qualsiasi percorso indicato sulla schermata di riassunto avrebbe potuto non essere la strada \u201creale\u201d e che i guidatori avrebbero potuto fare percorsi diversi a propria discrezione, ma la mancanza di linee di collegamento tra i punti Start e End li aveva sconcertati, causando esitazione e disagio.<\/p>\n

Gli utenti erano abituati a vedere linee di collegamento tra i punti del loro viaggio. L’avevo notato dal tempo che ci mettevano per interagire con quella schermata, dalle loro facce e dai loro ragionamenti ad alta voce. Alcuni pensavano che non sarebbero riusciti a completare il task o che l’app non aveva ancora terminato l’elaborazione. Altri hanno riferito un livello di fiducia minore nell’app. Avevamo fatto un’ipotesi, basata sull’onest\u00e0, riguardo a quello che gli utenti avrebbero voluto vedere e abbiamo scoperto che quello che avevamo fatto non andava bene per loro.<\/p>\n<\/div>\n

\n

Il re-test#section4<\/a><\/h2>\n

Con in mente questi risultati, ho deciso di fare un test di usabilit\u00e0 pi\u00f9 piccolo con lo stesso protocollo e le stesse schermate ma con un cambiamento: una linea di collegamento tra i punti Start e End.<\/p>\n

\"Lo<\/p>\n

Image credit: Dan Turner e Stephanie Snipes<\/p>\n<\/div>\n

Questa volta, i partecipanti hanno detto di sapere che i guidatori avrebbero potuto fare un’altra strada, ma non era importante: le linee del percorso erano quello che si aspettavano di vedere. (Magari questa \u00e8 un’indicazione che potrebbero non fidarsi del pathfinding di Google o Apple Maps, ma non siamo ancora a quel livello di cinismo).<\/p>\n\n\n\n\n\n\n\n\n\n\n
Task: Richiesta Passaggio<\/caption>\n
Subtask<\/th>\nMedia<\/th>\nOutlier<\/th>\nEmozione<\/th>\n<\/tr>\n<\/thead>\n
1: Impostazione tempistica della richiesta<\/td>\n7.8s<\/td>\n13s<\/td>\n<\/td>\n<\/tr>\n
2: Impostazione solo andata\/AR<\/td>\n9.8s<\/td>\n11s<\/td>\n<\/td>\n<\/tr>\n
3: Scelta punto start<\/td>\n6.5s<\/td>\n8s<\/td>\n<\/td>\n<\/tr>\n
4: Scelta destinazione<\/td>\n5.3<\/td>\n6s<\/td>\n<\/td>\n<\/tr>\n
5: Conferma richiesta<\/td>\n6.8s<\/td>\n8s<\/td>\n<\/td>\n<\/tr>\n
6: Revisione richiesta<\/td>\n8s<\/td>\n9s<\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Ho fatto un grafico dei tempi medi per utente per schermata e ho fatto la media delle risposte emotive (osservate: positiva, negativa, meh). Penso non sia irragionevole vedere tempi bassi per ogni interazione e risposta emotiva come un buon segno, mentre tempi alti per interazione ed emozione negativa come un segno di dover tornare sui miei passi e osservare il problema.<\/p>\n

\"Due<\/div>\n

La differenza \u00e8 solo una linea, una linea che i partecipanti sanno, consciamente o inconsciamente, che non \u00e8 una vera rappresentazione della realt\u00e0, ma che hanno trovato confortante, fino al punto che, senza di essa, l’usabilit\u00e0 ne ha risentito molto.<\/p>\n<\/div>\n

\n

Verso un’euristica#section5<\/a><\/h2>\n

Allora, quando entrate in un ascensore, schiacciate il pulsante \u201cChiudi porta\u201d? Se lo fate, che cosa vi suggerisce? L’avete schiacciato una volta e atteso o avete continuato a premerlo fino a che le porte si sono effettivamente chiuse? Come vi ha fatto sentire premere quel pulsante o la sua sola esistenza?<\/p>\n

Ovviamente, adesso sappiamo<\/a> che il pulsante di \u201cChiusura porta\u201d non fa proprio niente. \u00c8 un’affordance falsa o un pulsante placebo<\/a>.<\/p>\n

Il che ci riporta alla questione etica. Devo progettare elementi che non ingannano tecnicamente ma rassicurano e aumentano il comfort e l’efficacia del prodotto per l’utente? L’intenzione impedisce che questo sia un dark pattern?<\/p>\n

Ricordatevi, i dark pattern sono dark non perch\u00e9 non siano efficaci (sono molto<\/em> efficaci) ma perch\u00e9 mettono l’utente nella posizione in cui si agisce contro i propri interessi. Kim Goodwin parla di servizi e prodotti ben progettati che agiscono come le persone con criterio dovrebbero agire: magari a volte un essere umano coscienzioso dice delle bugie a fin di bene (non sto giudicando le vostre relazioni, comunque). Ma allora, a volte le bugie a fin di bene sono dei semi che sbocciano di un problema ingestibile o in una cattiva abitudine. C’\u00e8 un modo per creare un framework cos\u00ec che possiamo giudicare quando una decisione di design \u00e8 etica invece che semplicemente efficace?<\/p>\n

Originariamente, ho scritto di questo solo per fare una domanda e aprire una conversazione. Come risultato, le euristiche qui di seguito sono nei loro stadi primari. Incoraggio il feedback e la discussione.<\/p>\n

    \n
  1. Abbinamento tra affordance e mondo reale.<\/strong> L’affordance (falsa o placebo) dovrebbe essere in diretta correlazione con la situazione in cui si trova l’utente piuttosto che portare l’utente verso un nuovo contesto.<\/li>\n
  2. Fornire valore emotivo positivo.<\/strong> L’affordance progettata dovrebbe rassicurare e far aumentare il comfort, non creare ansia. Cullarsi in una falsa sicurezza di torpore per\u00f2 sta andando troppo oltre.<\/li>\n
  3. Dare sollievo da ansia e tensione.<\/strong> Se il prodotto non pu\u00f2 fornire un valore emotivo positivo, l’affordance dovrebbe servire a ridurre o risolvere una qualsiasi ansia aggiuntiva.<\/li>\n
  4. Aumentare l’efficacia dell’utente.<\/strong> L’affordance dovrebbe aiutare a migliorare l’efficienza riducendo steps, distrazioni e confusione.<\/li>\n
  5. Fornire actionable intelligence.<\/strong> L’affordance dovrebbe aiutare l’utente a sapere quello che sta succedendo e come proseguire.<\/li>\n
  6. Aggiungere contesto.<\/strong> L’affordance dovrebbe offrire maggior segnale, non introdurre rumore.<\/li>\n
  7. Spostate l’utente verso il risultato desiderato.<\/strong> L’affordance dovrebbe aiutare l’utente a prendere una decisione consapevole, a processare i dati o comunque procedere verso i propri obiettivi. Notate che gli obiettivi di business non sono gli stessi degli obiettivi degli utenti.<\/li>\n
  8. Risolvere potenziali conflitti.<\/strong> Un’affordance dovrebbe aiutare l’utente a decidere tra scelte che altrimenti potrebbero essere poco chiare o ingannevoli.<\/li>\n<\/ol>\n

    Questi punti non sono mutualmente esclusivi n\u00e9 si tratta di una checklist. Spuntare l’intera lista non garantir\u00e0 che tutti i vostri obblighi etici saranno soddisfatti, ma spero che soddisfarne la maggior parte elimini il design senza integrit\u00e0.<\/p>\n

    Una questione irrisolta che vorrei sollevare per discuterne \u00e8 la rappresentazione della falsa affordance o placebo. Il pulsante \u201cChiudi porta\u201d non funzioner\u00e0 se etichettato \u201cQuesto non chiude la porta ma premilo comunque\u201d, ma nel mio caso vogliamo davvero che l’utente sia cosciente che la linea del percorso non \u00e8 necessariamente la strada che verr\u00e0 fatta. Come bilanciamo questa cosa? Quando diventa un inganno?<\/p>\n

    Inoltre, posso raccomandare Design with Intent toolkit<\/a> di Dan Lockton, sotto licenza Creative Commons 3.0 standard. E Cennydd Bowles ha scritto e parlato delle questioni pi\u00f9 ampie del design etico: se questo \u00e8 un topic che vi interessa (e davvero, avete letto molte parole sull’argomento per giungere fin qui), vale la pena immergersi nel suo sito<\/a>.<\/p>\n

    Spero di continuare a riflettere su queste euristiche e a rifinirle con ulteriore feedback dai designer come voi. Creiamo insieme dei tool che ci aiutino a progettare con integrit\u00e0.<\/p>\n

    Illustrazioni: {carlok}<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

    La maggior parte di noi afferma di essere onesta nei propri design, ma cosa succederebbe se piccole deviazioni dalla verit\u00e0 rendessero il design pi\u00f9 semplice per gli utenti? Cosa succederebbe se i test di usabilit\u00e0 mostrassero che alcune piccole bugie in un’interfaccia in realt\u00e0 aiutano gli utenti a conseguire i propri obiettivi? Come possiamo evitare che le decisioni di design diventino ingannevoli? Dan Turner condivide le lezioni che ha appreso da un recente problema di design e propone un potenziale framework per lavorare eticamente con le false affordances.<\/p>\n","protected":false},"author":818,"featured_media":7000807,"comment_status":"open","ping_status":"open","template":"","categories":[279,152,267],"tags":[],"coauthors":[484],"class_list":["post-647","article","type-article","status-publish","has-post-thumbnail","hentry","category-interaction-design","category-numero-135-17-agosto-2016","category-user-research"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/647","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=647"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000807"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=647"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=647"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=647"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=647"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}