Design, bugie a fin di bene ed etica

Cos’è questo chiasso?#section1

Le banche del tempo sono scambi locali e virtuali in cui i vicini possono postare richieste e offerte di servizi in cambio di “timedollars”, una moneta alternativa non sostituibile basata su un’ora di servizio. Per esempio, se faccio un’ora di cucito per te, posso “spendere” 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ò ho reso l’idea.

Permettendo ai vicini di connettersi e di aiutarsi a vicenda, le banche del tempo creano una comunità in quella che era solo una location. Attraverso il mobile timebanking, le persone si sentono più connesse ai propri vicini e maggiormente supportate nella vita quotidiana. In realtà, questa è la value proposition che ha guidato il nostro progetto.

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

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ù problematiche. Per esempio, le offerte e richieste per servizi di timebanking erano, nell’app esistente, messi in liste su più livelli, con categorie gerarchiche come Craiglist, ma con molti più livelli di profondità.

Livelli di gerarchia nella vecchia app, richiedenti navigazione e task cognitivi. Queste categorie erano spesso vuote.

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é la popolazione utente era spesso anziana e con minor mobilità e secondo, che molti post da parte degli utenti per offrire o richiedere passaggi a un certo punto del processo venivano abbandonati.

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ù livelli della statica per dire “Hey, io vado da vicino a X a Y più o meno a quest’ora alcuni giorni alla settimana – a qualcuno può servire un passaggio?”. Perciò, abbiamo incorporato dei walk-through della vecchia app in interviste semi-strutturate che stavamo già facendo durante la nostra ricerca sulle motivazioni dello sharing peer-to-peer: le azioni e le risposte dei partecipanti supportarono le nostre ipotesi.

Tenendo a mente ciò, abbiamo proposto una nuova feature e abbiamo cominciato a farne un prototipo, TransportShare, al livello più 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.

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 “fudge factor” (quanto è flessibile questo tempo), se il viaggio è 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.

Come scegliamo#section2

Il nostro dilemma etico è emerso quando abbiamo progettato il processo di richiesta di un passaggio. Dopo che l’utente specifica i punti di “Start” e “End” per un passaggio, l’app mostra una schermata di riassunto con questi punti, l’ora del viaggio e alcune opzioni.

Image credit: Dan Turner e Stephanie Snipes

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’è 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à, sbagliato. Inoltre, in modo particolare in un’app che dipende dai valori di comunità e dall’onestà, sarebbe sembrato ingannevole.

Essere sinceri all’n-esima potenza è 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?

Oh, mi sbagliavo. Mi sono sbagliato proprio tanto.

Ed ecco… Un test#section3

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ì vi ho selezionato quelli che avevano usato una qualche forma di app peer-to-peer. (Stiamo pianificando degli ulteriori test di usabilità con più partecipanti senior, specificatamente per la leggibilità e l’accessibilità).

Ho condotto i test con un utente per volta, prima dando delle informazioni sulla natura delle banche del tempo (voi ci siete già passati) e impostando lo scenario in cui hanno bisogno di un vicino che li porti in auto in un posto vicino. Gli è stata data libertà 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.

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).

Gli utenti tendevano a muoversi facilmente attraverso l’intero task, finché non arrivavano al Subtask 6 (rivedere la richiesta sulla schermata di riepilogo) e lì mi sono accorto che c’era un problema.

I partecipanti esitavano vistosamente, commentando con espressioni tipo “ummm…”: le loro dita e i loro occhi andavano avanti e indietro sulla mappa, più o meno tra i punti etichettati come Start e End. Quando ho posto domande aperte come “Cosa vedi?” e “Cosa ti saresti aspettato di vedere?”, i partecipanti hanno detto che si sarebbero aspettati di vedere delle linee indicanti il percorso tra Start e End.

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 “reale” 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.

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à, riguardo a quello che gli utenti avrebbero voluto vedere e abbiamo scoperto che quello che avevamo fatto non andava bene per loro.

Il re-test#section4#section4

Con in mente questi risultati, ho deciso di fare un test di usabilità più piccolo con lo stesso protocollo e le stesse schermate ma con un cambiamento: una linea di collegamento tra i punti Start e End.

Image credit: Dan Turner e Stephanie Snipes

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 è un’indicazione che potrebbero non fidarsi del pathfinding di Google o Apple Maps, ma non siamo ancora a quel livello di cinismo).

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.

La differenza è solo una linea, una linea che i partecipanti sanno, consciamente o inconsciamente, che non è una vera rappresentazione della realtà, ma che hanno trovato confortante, fino al punto che, senza di essa, l’usabilità ne ha risentito molto.

Verso un’euristica#section5#section5

Allora, quando entrate in un ascensore, schiacciate il pulsante “Chiudi porta”? 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?

Ovviamente, adesso sappiamo che il pulsante di “Chiusura porta” non fa proprio niente. È un’affordance falsa o un pulsante placebo.

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?

Ricordatevi, i dark pattern sono dark non perché non siano efficaci (sono molto efficaci) ma perché 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’è un modo per creare un framework così che possiamo giudicare quando una decisione di design è etica invece che semplicemente efficace?

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.

1. Abbinamento tra affordance e mondo reale. 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.
2. Fornire valore emotivo positivo. L’affordance progettata dovrebbe rassicurare e far aumentare il comfort, non creare ansia. Cullarsi in una falsa sicurezza di torpore però sta andando troppo oltre.
3. Dare sollievo da ansia e tensione. Se il prodotto non può fornire un valore emotivo positivo, l’affordance dovrebbe servire a ridurre o risolvere una qualsiasi ansia aggiuntiva.
4. Aumentare l’efficacia dell’utente. L’affordance dovrebbe aiutare a migliorare l’efficienza riducendo steps, distrazioni e confusione.
5. Fornire actionable intelligence. L’affordance dovrebbe aiutare l’utente a sapere quello che sta succedendo e come proseguire.
6. Aggiungere contesto. L’affordance dovrebbe offrire maggior segnale, non introdurre rumore.
7. Spostate l’utente verso il risultato desiderato. 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.
8. Risolvere potenziali conflitti. Un’affordance dovrebbe aiutare l’utente a decidere tra scelte che altrimenti potrebbero essere poco chiare o ingannevoli.

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

Una questione irrisolta che vorrei sollevare per discuterne è la rappresentazione della falsa affordance o placebo. Il pulsante “Chiudi porta” non funzionerà se etichettato “Questo non chiude la porta ma premilo comunque”, ma nel mio caso vogliamo davvero che l’utente sia cosciente che la linea del percorso non è necessariamente la strada che verrà fatta. Come bilanciamo questa cosa? Quando diventa un inganno?

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

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à.

Illustrazioni: {carlok}