Archivi tag: prototipo

Ancora su bozzetti di carta e prototipi

Pubblicato il da

Dopo “Progettare con la carta” in cui presento il metodo che uso per creare i prototipi con l’aiuto di bozzetti di carta, sono stati pubblicati in rete alcuni articoli che approfondiscono l’argomento.

The Messy Art Of UX Sketching di Smashing Magazine si spinge nel dettaglio, illustrando le principali tecniche. Tra gli strumenti da portarsi a casa ci sono sicuramente:

  • il colore per evidenziare l’importanza di alcune sezioni
  • i post-it nella creazione di tool-tip, popup e finestre modali
  • le fotocopie per realizzare bozzetti (processo generativo)

4 ways to prototype faster raccoglie in un breve articolo quello che mi sentirei di suggerire su questo tema:

  • iniziate a lavorare con la carta
  • adottate un solo software per creare i prototipi, non una selezione (keynote + photoshop + balsamiq + dreamweaver)
  • cercate, tra le diverse soluzioni, quella che vi permetta di produrre anche la documentazione funzionale
  • utilizzate strumenti che vi aiutino a condividere il lavoro

5 Sketching Secrets of Leonardo Da Vinci indica qualche suggerimento per migliorare la creazione dei bozzetti, prendendo spunto dai lavori di Leonardo da Vinci. Il paragone è forse azzardato, i consigli meno:

  • quello dei bozzetti è un processo generativo, che mira a creare diverse prospettive dello stesso concetto
  • oltre all’interfaccia, il bozzetto può essere completato da note a margine, per chiarire il contesto e gli elementi non facilmente deducibili dalla sola interfaccia
  • scopo dei bozzetti è di essere criticati costruttivamente; il processo è collaborativo
  • la soluzione a una problematica può arrivare da campi diversi
  • imparare a catalogare i lavori realizzati, così da avere una banca dati di soluzioni alternative

Progettare con la carta

Pubblicato il da

Da qualche mese sto sperimentando con soddisfazione uno strumento diverso per quella fase di progettazione che segue la definizione della strategia online e precede la creazione di prototipi. Prendo un foglio di carta e realizzo a mano bozzetti che possono poi essere condivisi e valutati insieme al team di User Experience.

Nulla di nuovo o che non avessi mai provato, ma che avevo abbandonato troppo frettolosamente ritenendola una pratica poco professionale.

Mi hanno aiutato a cambiare idea due letture: Paper Prototyping di Carolyn Snyder e il più recente Prototyping scritto da Todd Zaki Warfel per i tipi di Rosenfeld Media. Entrambi i testi forniscono ottimi suggerimenti su come realizzare prototipi con la carta e il libro di Carolyn Snyder arriva anche a spiegare come utilizzare questi prototipi in veri e proprie sessioni di test di usabilità con gli utenti.

Non mi spingo quasi mai, con la carta, fino alla fase di creazione dei prototipi. La carta mi aiuta a fissare sottoforma di bozzetti (sketch) diverse idee di interfaccia e interazione che possono poi essere valutate, scartate, scelte insieme al team UX. Si tratta quindi di un approccio quantitativo, che mira a produrre in tempi molto brevi diversi bozzetti che possano poi essere analizzati dal team e soprattutto criticati senza la paura di aver mandato all’aria ore o giorni di lavoro. Ogni bozzetto non dovrebbe richiedere più di mezz’ora per la stesura.

Trovo l’uso della carta efficace anche lavorando con team remoti: basta uno scanner e in pochi minuti il bozzetto è condivisibile con il resto del mondo.

Normalmente non uso un foglio di carta bianca, ma mi faccio aiutare stampando dei semplici template che includono l’interfaccia del browser e qualche guida di supporto (per esempio le risoluzione più diffuse). In internet è possibile trovarne decine: personalmente mi trovo molto bene con il lavoro svolto da UIStencil (il template è disponibile in formato PDF).

I diversi bozzetti sono poi criticati insieme al resto del team UX, solitamente fissandoli a una parete o a una lavagna.

Zaki Warfel in Prototyping riassume bene come dovrebbe svolgersi questo processo.

PT001: Figure 2.1Diagram of the iterative design and critique process. Warfel, Todd Zaki. 2009. Prototyping: A Practitioner’s Guide. New York: Rosenfeld Media. http://www.rosenfeldmedia.com/books/prototyping/

Si tratta, come è facile vedere nello schema, di un processo iterativo.

Lo sketching (creazione dei bozzetti) è la parte generativa del processo, il cui obiettivo è proporre diverse idee senza prestare attenzione ai dettagli o alle inconsistenze (fast and furious).

Lo scopo della critica dei bozzetti è quello di trovare, tra le tante idee, la migliore. Chi ha realizzato il bozzetto ne elenca i punti di forza, i colleghi del team UX evidenziano lacune e richiedono approfondimenti. Questa fase dovrebbe durare pochi minuti, perché il dettaglio della proposta avviene nella fase di creazione dei prototipi vera e propria.

A questo punto, cioè per la creazione dei prototipi e per i testi di usabilità con gli utenti abbandono la carta. Preferisco infatti farmi aiutare da strumenti che permettano di simulare un po’ più nel dettaglio le transizioni tipiche di una pagina web, come le interazioni Ajax. In questo senso il mio strumento preferito è Axure RP: costoso, ma che permette di realizzare veri e propri prototipi piuttosto che wireframe, sui quali la carta vince ancora.

Imparare dai propri errori

Pubblicato il da

La scorsa settimana ho ricevuto questa email da un nostro cliente:

Buongiorno [responsabile commerciale] e Antonio,

vi comunichiamo il nostro disappunto riguardo il vostro comportamento e il lavoro finora svolto.

Riteniamo che le numerose richieste di modifica in corso d’opera che vi stiamo sottoponendo siano la diretta conseguenza del vostro lavoro. Ci riferiamo al fatto che noi vi avevamo chiesto a_b_c e invece voi ci avete proposto d_e_f. Potrete concordare con noi che in questo modo non è stato raggiunto il nostro obiettivo. Ci troviamo ora a dover mettere in linea un prodotto che non è quello che volevamo.

La nostra critica si basa fondamentalmente sulla mancanza di idee e proposte da parte vostra che siete gli esperti del settore e sul vostro atteggiamento di mera esecuzione di ordini a seguito delle nostre richieste, che si basano sull’esperienza nel nostro settore, che a quanto pare non si possono sempre tradurre in campo informatico.

E’ la prima volta che ricevo una missiva del genere: c’è da rimanere sconcertati, vero?

Un messaggio con questo tono non arriva come un fulmine a ciel sereno, ma è una diretta conseguenza a una nostra email in cui, senza tanti complimenti, abbiamo chiesto al cliente di permetterci di chiudere le diverse attività in cantiere senza aggiungerne in continuazione di nuove. Non si fa così. Questo è però solo l’ultimo di una serie di errori che, da una parte e dall’altra, hanno caratterizzato la vita dell’intero progetto.

Prima di cominciare ad analizzare cosa non ha funzionato vale però la pena di inquadrare il progetto nel suo contesto e fornire qualche cifra di riferimento:

  • i primi incontri per la definizione del progetto insieme al cliente si svolgono a Giugno 2007, più di un anno fa;
  • il progetto prevede la realizzazione di un sito di presentazione, ricerca, prenotazione e di ecommerce non standard, che attinge ad anagrafiche e listini presenti in gestionali usati dal cliente;
  • il sito va a sostituire una precedente versione, anche questa realizzata da noi;
  • dopo aver raccolto gli elementi utili da più fonti e aver svolto diverse analisi, ad Agosto del 2007 è presentato e motivato al cliente un prototipo funzionante dell’intera applicazione. Prototipo lasciato a disposizione per ogni valutazione;
  • l’impegno previsto per la realizzazione del progetto è stimato in circa 350 ore uomo, con data di consegna 15 Febbraio 2008.

Il cliente, anche se non sembrerebbe leggendo l’email, è stato coinvolto in ogni fase del progetto:

  • la raccolta di elementi utili per la progettazione del sito è partita da una serie di incontri in cui il cliente ha espresso le proprie esigenze;
  • abbiamo presentato un prototipo funzionante dell’applicazione condividendo ogni scelta;
  • abbiamo realizzato, in un ambiente accessibile al cliente, circa 5 rilasci intermedi su dati reali per verificare le diverse funzionalità

Sembrerebbero le basi su cui realizzare un prodotto apprezzato. L’email ricevuta non lascia però spazio ad alcun dubbio: il cliente è insoddisfatto, è convinto che questo non sia il prodotto richiesto e manifesta chiari dubbi sulla competenza della società che li ha accompagnati in questo percorso. Come è possibile?

Se analizziamo più approfonditamente quello che è successo nell’arco di questi 12 mesi si capisce che in realtà di errori ne sono stati commessi tanti, troppi, da ambo le parti. Ecco i principali:

  • Errore 1: c’è bisogno di un sito nuovo (?) – Tutto comincia quando il cliente manifesta perplessità per alcune problematiche del sito attualmente online. Si tratta di alcuni bug e soprattutto di problemi relativi all’usabilità e non coerenza dell’interfaccia di navigazione. Il cliente viene convinto a riprogettare da capo l’intero sito, promettendo un’applicazione più usabile, più veloce, migliore. Viste le richieste, sarebbe forse stato più semplice sistemare quanto era già online.
  • Errore 2: ti costa 100. No 300. Vabbè facciamo 200 – Al cliente è proposto un investimento contenuto, il tutto senza verifiche. Dopo una breve sessione di macroanalisi si evince che l’impegno è invece circa tre volte rispetto quanto promesso. A questo punto inizia il tira-e-molla che porta il prezzo finale a circa il doppio, una via di mezzo che non fa felice nessuna delle due parti.
  • Errore 3: un cliente fantasma – Non abbiamo spiegato chiaramente al cliente che avremmo avuto bisogno, per tutta la durata del progetto, del suo apporto. Trovandosi davanti a un prototipo funzionante alcuni clienti sono infatti convinti che sia già stato fatto tutto, che sia sufficiente procedere con l’implementazione e vedersi consegnato il progetto dopo alcuni mesi. Nel documento di progetto va invece quantificato l’impegno richiesto al cliente in termini di verifica funzionalità, test, prove sul campo e supporto per le inevitabili domande che nascono nello sviluppo di tutti i giorni. Il cliente ha inoltre risposto con enorme ritardo ad ogni comunicazione che gli è stata inviata. Alcune email non hanno ricevuto risposta, altre dopo un mese, con casi di risposte dopo ben 5 mesi rispetto alle richieste. Abbiamo più volte sollecitato il cliente, via email e verbalmente, senza alcun risultato apprezzabile.
  • Errore 4: referenti aziendali non all’altezza – Punto cardine di un progetto di successo è l’interazione con referenti aziendali competenti e in grado di farsi portavoce delle richieste dei consulenti e dell’azienda per cui lavorano. Così non è stato. Il progetto è stato affidato a un dipendente part-time dell’azienda che non è riuscito a trasmettere dubbi, perplessità, richieste, proposte. Come se non bastasse un altro attore del progetto, che ha seguito la precedente realizzazione del sito, lavora part-time con orario di lavoro non coincidente con quello del referente principale. Non è sempre facile accorgersi della presenza di un referente non motivato, ma quando succede l’azienda va immediatamente informata oppure la situazione, come in questo caso, precipita. E, nella maggior parte dei casi, è il web project manager a dover alzare la mano.
  • Errore 5: il software si modifica anche all’ultimo minuto – Il software è un prodotto di ingegneria. Il fatto che un progetto web sia accessibile da un monitor fa sì che il cliente non sempre riesca a valutare, diversamente da altre opere di ingegneria, l’impatto di alcune richieste di modifica. Aver presentato un prototipo funzionante ha lo scopo di confrontare proposte e punti di vista, ma anche di limitare il numero di modifiche in corso d’opera. In realtà nulla è scolpito nella pietra e, come ben sa chi adotta metodologie di sviluppo agile, è impossibile prevedere ogni caratteristica a priori. Il problema in questo caso è ancora una volta legato alla mancanza di feedback da parte del cliente in tempi accettabili. Le richieste di modifica sono pervenute mesi dopo che la funzionalità era stata consegnata per verifica.
  • Errore 6: non serve capire chi è il visitatore – Al cliente è stato suggerito, prima ancora di iniziare l’analisi del sito, di compiere alcuni fondamentali studi relativi agli utenti a cui il sito si rivolge, alle loro aspettativi e modalità di ricerca. Per motivi di budget, ma non solo, il cliente si è limitato a indicare alcuni siti concorrenti che presentano, rispetto alla versione attualmente online, alcuni spunti di miglioramento. Questa è una strategia che non paga, perché a sito terminato rimane il dubbio che non tutto sia stato realizzato come si sarebbe dovuto.
  • Errore 7: il sito non fa quello che voglio – Il sito non deve fare quello che vuoi tu, ma quello che vuole il tuo utente (vedi punto precedente). Il nostro interlocutore, nel giustificare il nostro pessimo lavoro, parla di sito che non voleva, di sito che non corrisponde alle sue attese. Sbaglia due volte: perché ogni sua indicazione è stata presa in considerazione e perché cerca di mettersi nei panni di un visitatore che in realtà non conosce e si fa ingannare da dettagli e particolarità che sarà l’unico a notare.

Realizzare un progetto che soddisfi ambo le parti, soprattutto un progetto che richiede alcuni mesi di lavoro, è un’attività che il cliente e l’azienda di consulenza devono affrontare sapendo di mettere in campo tutto l’impegno necessario. Referenti non motivati, stime di costo in continua variabilità, scorciatoie di progettazione, tempi non rispettati sono gli elementi che piano piano, giorno dopo giorno, minano la riuscita di un progetto che è apparentemente solido. Esattamente quello che è successo in questo caso.