Progettare per il “percorso felice” migliore scenario lascia i nostri utenti più vulnerabili ai margini

Nella nostra spinta alla velocità, ci siamo condizionati a ignorare i nostri utenti più vulnerabili. Progettiamo per il percorso felice, e la società ne paga il prezzo.

Per creare prodotti digitali, i designer spesso iniziano sviluppando una serie di scenari o casi d’uso. Questi scenari aiutano a determinare le caratteristiche, le interazioni e l’infrastruttura tecnologica necessaria in un prodotto.

Come esempio, pensiamo a Facebook. Quando Mark Zuckerberg stava inizialmente creando il social network, potrebbe aver avuto in testa uno scenario come questo:

“Una studentessa che vuole condividere le foto di una festa con i suoi amici”

Questa è una dichiarazione semplice, ma anche qualcosa di così semplice può aiutare un designer a concettualizzare il tipo di soluzione richiesta. Nel caso di un prodotto digitale, possono iniziare ad immaginare le schermate che potrebbero essere necessarie, gli elementi su quelle schermate, e così via.

Gli scenari sono di due tipi fondamentali: percorso felice e casi limite.

Il percorso felice è uno scenario in cui tutto è perfettamente allineato affinché la funzione/prodotto funzioni esattamente come il designer intendeva:

“Una benigna studentessa va ad una festa e fa alcune foto inoffensive. Torna a casa al suo computer con un’eccellente connessione internet, si collega e carica le sue foto senza problemi, vanno nel database e vengono diffuse ai suoi amici.”

Questo è un percorso felice come lo pensiamo oggi. Come potrebbe dire Riccioli d’oro, tutto è giusto.

Molti designer iniziano con il percorso felice perché è il percorso di minor resistenza. Richiede il minor sforzo di concettualizzazione perché elimina molte delle scomode complessità che potrebbero esistere. Questo non significa necessariamente che sia facile da progettare; è solo relativamente semplificato.

Il secondo tipo di scenario è il caso limite. I casi limite deviano dal percorso felice e, teoricamente, accadono meno frequentemente del percorso felice. Ci sono due tipi di casi limite.

Il primo sono casi limite tecnici, dove qualcosa va storto nel flusso tecnico dello scenario. Forse c’è un errore nel processo di caricamento delle foto e non va mai a buon fine. O forse un utente inserisce dati errati in un campo del modulo. Questo è il tipo di complessità tecnica che una persona QA può testare. Molto spesso un processo di progettazione affronta questo tipo di casi limite, o almeno affronta quelli principali. Qualsiasi designer o ingegnere decente sa che è importante gestire gli errori e aiutare l’utente a recuperare da essi.

Poi ci sono quelli che io chiamo casi limite contestuali: deviazioni comportamentali dal percorso felice. Nel nostro scenario di caricamento delle foto, un caso limite contestuale potrebbe coinvolgere l’utente che carica una foto che è offensiva o pornografica, o che carica una foto di qualcun altro che non vuole che quella foto viva sul sito. Questo tipo di caso limite può avere implicazioni molto significative nel mondo reale. Sfortunatamente, questi sono anche i casi limite che raramente vengono affrontati nel processo di progettazione.

La spinta per la velocità

Oggi il successo nel mondo tecnologico è definito dalla velocità, dalla scala e dalla crescita – quanto grande può diventare un’azienda e quanto velocemente può arrivarci. Il motto di Facebook è “muoviti velocemente e rompi le cose”, e i team di prodotto in tutto il settore sono ossessionati da quanto velocemente possono “spedire le caratteristiche”. I VC scrivono persino libri su come gestire le startup ad alta velocità, in modo da poter convalidare (o invalidare) la propria idea il più velocemente possibile e sprecare il minimo assoluto del tempo delle persone (leggi: dei VC). Lo chiamano “blitzscaling.”

L’idea di muoversi velocemente è diventata profondamente radicata nella nostra cultura del design, della tecnologia e del business.

Uno dei modi in cui raggiungiamo la velocità è concentrandoci sul percorso felice. Spesso la strategia di un team è quella di ottenere il percorso felice come un MVP (prodotto minimo realizzabile) in modo da poterlo portare rapidamente agli utenti prima di mettere più impegno nella gestione dei casi limite. Il problema è che i team raramente tornano a gestire i casi limite. Inevitabilmente, vengono fuori nuove priorità e tutti vanno avanti. Quello che una volta era considerato un MVP è ora considerato un prodotto finale.

Con il tempo, questa costante priorizzazione degli edge cases condiziona i designer e gli ingegneri ad iniziare ad ignorarli. Sovraccaricati di lavoro e di scadenze impossibili, diventa più facile far finta che i casi limite non esistano.

L’impatto del percorso felice

Qualche settimana fa, una startup chiamata Superhuman ha rilasciato una nuova funzione di “ricevuta di lettura” per il loro client di posta elettronica. Se io ti mando un’email usando Superhuman e tu la apri in qualsiasi client di posta elettronica tu usi (Gmail, Yahoo, ecc.), la funzione di ricevuta di lettura mi invia una notifica che mi dice che l’hai aperta. Abbastanza semplice. Ma c’erano due colpi di scena nell’implementazione di Superhuman. In primo luogo, la ricevuta di lettura non mi diceva solo che avevi aperto il messaggio, ma mi dava anche i dati sulla posizione in cui ti trovavi quando l’hai aperto. Accidenti. Secondo, tu, il destinatario, non avevi modo di rinunciare alla funzione. Indipendentemente dalle impostazioni del tuo client di posta elettronica, mi avresti sempre inviato una ricevuta di lettura. Doppio yikes.

Questo tipo di funzione ha enormi implicazioni per le vittime di stalking, abusi, e tanti altri scenari negativi. Non sorprende che ci sia stata una protesta, e Superhuman ha modificato la funzione. Ma la caratteristica non avrebbe mai dovuto lasciare il cancello in primo luogo. Quando c’è stata la controversia, Superhuman ha scritto un post sul blog e il CEO ha twittato delle scuse:

“Non abbiamo immaginato il potenziale per un uso improprio.”

Se questo tweet è da credere, sembra che l’idea che ci potessero essere deviazioni dal percorso felice non sia nemmeno venuta fuori nel processo di progettazione. Non era nemmeno sul loro radar. La nostra spinta alla velocità ci ha condizionato a progettare come se i casi limite non esistessero. Non è che decidiamo semplicemente di non risolverli, è che non li immaginiamo nemmeno. Queste sono pratiche tramandate nelle aziende e nelle scuole di design. Molti di noi sono così ben addestrati a questo punto, che rallentare non garantisce nemmeno un risultato migliore; ignorare i casi limite è inconsciamente inserito nel nostro processo.

Come le aziende spingono per la scala e la crescita a rotta di collo, stanno armando la tecnologia contro i gruppi che non rientrano nel loro percorso felice definito.

Stiamo guardando l’impatto cumulativo di questo gioco sul web ogni giorno. Piattaforme enormi come YouTube, Facebook e Twitter sono state tutte progettate con una mentalità da caso migliore, da percorso felice – un utente benigno che condivide ciò che ha mangiato a pranzo o pubblica un video del suo gatto. I casi limite di abuso, molestia e disinformazione sono stati tutti ignorati fino a quando hanno raggiunto una scala in cui il controllo pubblico ha reso impossibile continuare a ignorarli, ma a quel punto era troppo tardi. Affrontare i casi limite non è nel DNA di queste aziende. Quando hai passato 15 anni a fondere il tuo modello di business con il percorso felice, i tuoi processi, le strutture organizzative e la mentalità non sono orientati a pensare oltre. Quindi queste piattaforme sono lente a rispondere o completamente incapaci di farlo.

Il design del percorso felice non è centrato sull’uomo, è centrato sul business. È buono per le aziende perché permette loro di muoversi velocemente. Ma la velocità non fornisce alcun beneficio all’utente. Mentre le aziende spingono per la scala e la crescita a rotta di collo, stanno sistematicamente armando la tecnologia contro gruppi e casi d’uso che cadono al di fuori del loro percorso felice definito.

Chi è nel percorso felice?

Parte della giustificazione del design del percorso felice è che i casi limite sono rari. In alcuni casi, potrebbero interessare solo l’1% degli utenti di un prodotto. Mike Monteiro sottolinea la fallacia di questo pensiero nel suo libro Ruined by Design:

Facebook sostiene di avere due miliardi di utenti… l’1% di due miliardi sono venti milioni. Quando ti muovi velocemente e rompi le cose, l’1% è ben all’interno del punto di rottura accettabile per il lancio di un nuovo lavoro. Eppure contiene venti milioni di persone. Hanno dei nomi. Hanno dei volti. Le aziende tecnologiche chiamano queste persone casi limite, perché vivono ai margini. Sono, per definizione, gli emarginati.

In cima a questo, l’effettivo processo di progettazione del percorso felice spesso implica avere una persona utente predefinita che si adatta bene ai vostri casi d’uso senza complicazioni. Questo aggrava il problema del percorso felice perché significa che non solo stiamo guardando una visione artificiosa dello scenario stesso ma anche una fetta artificialmente piccola di potenziali utenti.

Dopo tutto, il percorso felice è privo di rischi e complicazioni. Per definizione, le persone con meno rischi e complicazioni sono gli utenti meno vulnerabili di un prodotto.

Tutti gli altri, come ha sottolineato Monteiro, siedono ai margini e non vengono quasi considerati fino a quando il danno è fatto e c’è qualche tipo di protesta.

Il più delle volte, gli umani che siedono ai margini dei nostri prodotti sono gli stessi umani che siedono ai margini della società.

Quando Superhuman stava progettando la sua funzione di lettura delle ricevute, non la stava progettando per le persone a rischio di stalking e abusi (statisticamente, molto probabilmente donne). La stavano progettando per il loro utente di default, che presumo sia un qualche VC (statisticamente, molto probabilmente un uomo) che invia un’email urgente a un fondatore (statisticamente, anche questo molto probabilmente un uomo).

Sto facendo una supposizione qui – forse includono le personas delle donne nel loro processo di progettazione – ma qui è il vero problema: le loro personas sono irrilevanti. Nonostante quello che diciamo sull’avere empatia nel design, l’utente di default siamo sempre noi stessi. L’idea dell’empatia del designer è il più grande trucco che abbiamo mai fatto a noi stessi. A meno che la persona per cui stai progettando non condivida la tua esperienza di vita, non puoi metterti nei suoi panni in nessun modo significativo. Scoprire le intuizioni dei consumatori non è la stessa cosa dell’empatia, e il design centrato sull’uomo non è uno scudo magico contro i pregiudizi.

Gli umani che siedono ai margini dei nostri prodotti sono gli stessi umani che siedono ai margini della società.

Un rapido sguardo al sito web di Superhuman mostra che il loro team di prodotto e ingegneria è composto per l’83% da uomini. Forse qualcuno ha fatto pressioni sulla funzione di lettura delle ricevute, forse no. Ma è quasi garantito che un uomo ha preso la decisione finale. In linea di massima, i ragazzi non vanno in giro con la paura degli abusi o dello stalking. Non è, nel complesso, la nostra esperienza di vita.

“Non abbiamo immaginato il potenziale di abuso.”

Progettare per la velocità ci ha allenato a ignorare i casi limite, e la schiacciante prevalenza di team omogenei composti dai meno vulnerabili tra noi (leggi: maschi) ci ha condizionato a centrare la loro esperienza di vita nel nostro processo di progettazione.

Il canarino nella miniera di carbone

I minatori si portavano dietro i canarini nella miniera di carbone. L’idea era che i canarini erano più vulnerabili ai gas nocivi che possono accumularsi in una miniera. Se il canarino stava bene, tutti sapevano che la situazione era sicura. Se succedeva qualcosa al canarino, era un segnale per tutti di uscire.

Questo è un sistema robusto. Se si progetta per il benessere dei più vulnerabili, si progetta per il benessere di tutti. Oggi non progettiamo così. Oggi progettiamo per i meno vulnerabili e poi facciamo finta che non succeda mai niente di male in una miniera di carbone.

L’ampiezza degli scenari che consideriamo determina quanto i nostri prodotti siano resistenti alle deviazioni del comportamento previsto. Oggi stiamo costruendo piattaforme enormi, con una portata e un impatto enormi, eppure sono enormemente fragili. Se siamo onesti con noi stessi, queste piattaforme rappresentano un fallimento del design. Il loro successo dipende da un intenzionale disprezzo per la complessità umana, e la società ne paga il prezzo.

Il vero percorso felice non è il percorso di minor resistenza; è il percorso di maggior resilienza.

Dobbiamo ridefinire cosa sia un percorso felice e reimparare ad abbracciare la complessità. Nel nostro esempio di condivisione di foto su Facebook, cosa succederebbe se il nostro scenario iniziale fosse invece simile a questo:

“Un ragazzo condivide una foto compromettente di una donna con i suoi amici, e la donna è in grado di rimuoverla dal sito”

Questo è ciò che un percorso felice dovrebbe essere. Ci porta allo stesso punto dell’affermazione originale, e dobbiamo ancora progettare e costruire le interazioni necessarie per permettere a quel tizio di condividere la sua foto. Ma fa anche qualcosa di cruciale: centra l’utente più vulnerabile su quello meno vulnerabile. Cuoce l’idea dell’uso improprio e degli esiti negativi nel cuore del nostro processo di pensiero e la fonde nel DNA dell’organizzazione.