Fail fast, fail forward

Come sfruttare il fallimento per migliorare il proprio design

Maria Teresa Stella
I Diari del Digitale
5 min readJun 26, 2018

--

Molto spesso fra articoli e post riguardo design e startup ho trovato, in più varianti, la frase

“Fail fast”

che si riferisce a una strategia che mira a testare un’idea il più presto possibile, per capire se è efficace e se può passare alla prossima iterazione o se invece si tratta di una perdita di tempo e denaro.

Da studentessa ancora un po’ inesperta pensavo che il concetto si riferisse più al mondo dell’imprenditorialità che a quello del design, convinta che per un designer il momento del “fallimento” potesse arrivare solo dopo alcune iterazioni. E poi, ammettiamolo,

Il rifiuto fa male.

Ecco un esemplare di tirocinante UX a cui hanno appena bocciato un lavoro

È inutile girarci attorno: sentirsi dire che un’idea su cui si ha lavorato per molto tempo va lasciata nel dimenticatoio è spesso difficile da mandar giù. Al contrario, durante la mia esperienza di tirocinio in Svezia ho imparato che il fail fast può diventare un ottimo mantra per uno UX Designer.

A volte basta un disegno

Una volta identificato bene il problema che il tuo design deve risolvere, è molto utile iniziare sfruttando gli schizzi su carta per comunicare le tue idee.

Questo era una delle prime idee, poi scartata, per il mio progetto di tirocinio

Lo schizzo non deve necessariamente consistere nelle possibili schermate del prototipo; si tratta di presentare il concetto (in modo simile agli storyboard) disegnando stickmen e altre forme semplici, in alternativa aggiungendo una breve spiegazione e un titolo. Questo metodo può essere molto utile per formulare e visualizzare la propria idea, e poi ottenere un primo riscontro.

Come suggerisce Bill Buxton*, si può iniziare con 10 o più schizzi, uno per ogni idea. Una volta pronti, si possono già presentare al team. Per ogni schizzo, è importante essere in grado di rispondere a due domande chiave:

  1. Qual è l’opportunità? (ovvero, siamo di fronte ad una possibile occasione non ancora colta dal mercato o dal nostro cliente?)
  2. Qual è il valore per l’utente? (cioè, il nostro design concept risolve effettivamente un problema?)

In questa prima fase, anche senza prototipi alla mano, gli schizzi ci aiutano a “fallire velocemente”: avendo dedicato poco tempo a ogni singola idea, è molto più facile scartare quelle che hanno ottenuto un feedback negativo e decidere quali invece si possono portare avanti.

Chiedere non costa nulla

All’inizio del mio tirocinio, facevo fatica a chiedere ai miei colleghi un riscontro sulle mie idee: tra la timidezza e la paura che non piacessero, aspettavo a volte troppo tempo prima di chiedere il loro parere.

Ansia portami via

Ma la verità è che a volte bastano solo pochi minuti di chiacchierata per ottenere punti di vista diversi, accorgersi di possibili sviste, oltre che ricevere spunti e consigli utili su come migliorare il proprio design concept.

Quando questo momento viene rimandato, si finisce per perdere più tempo ed energie su un’idea che potrebbe rivelarsi inefficace —e il rifiuto potrebbe fare più male. Al contrario, se si presenta un concetto su cui si è lavorato ancora poco è molto più facile accettare le critiche e migliorarlo nella prossima iterazione.

Inoltre, se si ha l’occasione di lavorare assieme ad altri designer, organizzare una design critique, anche breve, può essere vantaggioso per mettere a confronto più idee, scartandone alcune e portando avanti gli elementi migliori.

Go fast, go furious

Abituati sempre di più a curare i dettagli e a creare interfacce pixel-perfect, è facile cadere nel tranello e perdersi in alcune minuzie del nostro prototipo, pero ore o addirittura giorni.

Ma per applicare il fail fast, è necessario uscire da questo schema mentale — almeno in questa prima fase. Software come Sketch, InVision e Marvel vanno quindi utilizzati per creare un prototipo in poche ore, da poter testare immediatamente con gli utenti.

POP è una app molto utile che permette di passare direttamente da wireframe su carta a prototipi interattivi

Esci dall’ufficio

Nella fase finale del mio progetto di tirocinio, avevo appena completato la seconda versione del prototipo (una app per i visitatori dei musei d’arte) ed ero ormai prossima alla deadline. A solo 1 giorno e mezzo di distanza dalla presentazione per il team, non ero sicura se valesse la pena cercare di testare il prototipo con gli utenti o meno: reclutare i partecipanti e pianificare le sessioni di user testing avrebbe richiesto troppo tempo. Ma dopo aver parlato con il mio supervisore avevo ottenuto 3 parole magiche: Guerrilla Usability Testing.

A differenza delle pratiche di User Testing più conosciute ed applicate** il metodo Guerrilla è molto più rapido e grezzo: dopo aver stabilito quali tasks far provare agli utenti (bastano i 3 più importanti), bisogna uscire e “abbordare” 3–5 persone a cui far provare il prototipo. Nel mio caso, volendo puntare direttamente ai miei utenti target ero andata in uno dei musei locali; altrimenti luoghi consigliati sono ad esempio bar e centri commerciali, dato che è più facile trovarci gente rilassata che può dedicare a noi quei 10–15 minuti necessari per testare il prototipo.

I bar sono ottimi luoghi dove trovare la propria “preda”

Grazie a questo metodo si può quindi capire velocemente se la nostra idea al suo primo stadio piace e funziona coma dovrebbe, risparmiando tempo e costi.

TL;DR

L’approccio Fail Fast, che consiste nel testare le proprie idee il prima possibile, può rivelarsi molto utile nel campo del Design. Le nostre prime idee si possono presentare al team anche sotto forma di schizzi, per capire quali possono diventare dei prototipi. Per poi capire se si può investire su un’idea, il metodo Guerrilla è ottimo per ottenere un riscontro dagli utenti, raccogliendo opinioni e problemi di usabilità.

NOTE

*da Sketching User Experiences — The Workbook

**mi riferisco ad esempio al metodo di Steve Krug descritto nel suo manuale Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems

--

--