I bozzetti in aiuto alla comunicazione di progetto

Anche quest’anno (dopo il 2009, 2010 e 2011) ho partecipato come speaker a Better Software. Questa volta ho presentato “Carta, penna e calamaio. I bozzetti in aiuto alla comunicazione di progetto”.

Molte incomprensioni in fase progettuale derivano dalla mancanza di un vocabolario comune tra i diversi attori: clienti, designer, sviluppatori e project manager. I bozzetti realizzati su carta sono uno strumento semplice, ma efficace per valutare, scartate e scegliere le idee migliori e anticipare le problematiche; eliminando quella sensazione di aver perso un sacco di tempo e dover ricominciare da capo.

Su Slideshare ho caricato le slide sincronizzate con l’audio preso dalla sala. Buona visione e buon ascolto!
[slideshare id=14601420&doc=cartapennaecalamaioslideshare-121005062231-phpapp02]

Una newsletter è per sempre

Steve Jobs was originally obsessed with typography.

No, non si tratta dell’ennesimo tweet in ricordo di Steve Jobs, ma l’oggetto di una newsletter che AppSumo ha inviato lo scorso 6 ottobre, a poche ore dalla morte del CEO Apple.

Non ci sarebbe nulla di strano a cavalcare l’onda di santificazione che si è scatenata, se non fosse che in questo caso la passione di Steve Jobs è stata usata in maniera fin troppo esplicita per proporre l’abbonamento a un servizio di font.

Quando ho ricevuto l’email mi sono limitato a storcere il naso, ma a giudicare da quanto ho letto sull’utente Twitter di AppSumo, si è scatenata una piccola rivoluzione tra gli utenti del servizio che hanno trovato l’oggetto decisamente di cattivo gusto.

Noah Kagan di AppSumo è corso ai ripari informando che la newsletter era stata preparata giorni prima e che si sono dimenticati di intervenire in tempo per modificare l’oggetto. Non sta a me stabilire se questo sia vero (rimane comunque il fatto che Steve Jobs era gravemente malato da tempo, sicuramente prima che l’oggetto venisse scritto), ma lo trovo comunque un esempio significativo per sottolineare l’attenzione che va posta nel realizzare una newsletter.

La newsletter è uno strumento inviato nella casella di posta del destinatario e come tale assume un carattere personale, come se fosse stata forgiata esplicitamente per chi la sta leggendo, anche se così non è. Inoltre, quanto è stata inviata non c’è nulla più nulla da fare: non si può correggere il refuso scoperto nel frattempo, non si può allineare meglio l’immagine, non si può modificare il codice per sistemare la visualizzazione in quel particolare programma di posta. I giochi sono fatti.

Mi capita invece molto spesso di ricevere newsletter che sono evidentemente create troppo in fretta, con oggetti di dubbia utilità, ma anche con link di approfondimento che non funzionano, o che rimandano genericamente alla homepage del sito. E lasciamo stare l’argomento “annullamento iscrizione”, che quando c’è non è detto che effettivamente annulli.

La preparazione di newsletter è, invece, un’attività che va pensata con attenzione, proprio perché state in qualche modo invadendo la spazio privato della casella di posta elettronica di chi la riceverà.

E, giusto per non rimanere nel vago, ecco un esempio meno eclatante di quello di AppSumo che evidenzia come anche una newsletter a prima vista trasparente possa creare un po’ di malcontento in chi la riceve.

Qualche settimana fa insieme a un’agenzia con cui collaboro abbiamo deciso di inviare una newsletter agli iscritti invitandoli a ripensare la propria presenza online. Dopo aver valutato internamente alcune proposte, abbiamo scelto l’oggetto “Il tuo sito è per sempre?”.

Nel corpo dell’email è presente una bella immagine e il messaggio “Non hai sposato il tuo sito. Cambialo.”

Le statistiche hanno riportato un risultato molto buono: il 50% dei destinatari ha aperto la newsletter e di questi un altro 50% ha cliccato sul link per avere maggiori informazioni.

Eppure un paio di iscritti, i classici clienti “con cui si ha più confidenza”, hanno risposto di non aver apprezzato in pieno lo stile del messaggio. Forse non gli è piaciuto l’accostamento del matrimonio a un sito? O, più probabilmente, il fatto di averli in qualche modo invitati a divorziare da qualcosa? O forse ancora si sono domandati perché gli stiamo suggerendo di rottamare il sito: forse pensiamo che faccia schifo?

A posteriori avremmo forse cercato una frase meno ambigua. Ma non lo possiamo più fare: una newsletter è per sempre.

Perché i designer falliscono gli obiettivi

Scott Berkun ha recentemente pubblicato i risultati di un sondaggio utili per evidenziare i motivi che possono condurre i designer a realizzare prodotti non in linea con gli obiettivi.

Ecco le principali cause di fallimento secondo gli intervistati (tenete conto che il pubblico di Scott Berkun è composto in gran parte da project manager):

  1. Non designer che prendono decisioni relative al design;
  2. Manager che prendono decisioni senza un background appropriato;
  3. Designer che non compiono le opportune ricerche prima di iniziare il lavoro;
  4. Non è concesso tempo sufficiente per pensare nel lungo termine;
  5. Mancanza di ricettività ai feedback;
  6. Scarsa conoscenza delle logiche di business;
  7. Lo “user centered design” è considerato una disciplina importante, ma solo a parole;
  8. Non è concesso di sbagliare e neppure di sperimentare;
  9. Al designer non è data autonomia nella gestione del progetto;
  10. Si fa troppo affidamento a un unico stile di design.

Dal mio punto di vista di web project manager concordo con quasi tutti gli elementi di questa lista e ammetto che in passato ho forse preteso un po’ troppo controllo sulla parte creativa di un progetto (applicando di fatto quanto riportato al punto 1).

I risultati del sondaggio di Berkun ricordano tra l’altro molto da vicino i fattori che limitano l’influenza del design in azienda evidenziati da Luke Wroblewski e Tom Chi, soprattutto la mancanza di visione sull’importanza del design. 

Il tema è importante: ancora oggi il design è considerato un semplice abbellimento dell’interfaccia su cui chiunque può dare la propria autorevole opinione. L’analisi dell’applicazione si concentra spesso sulle sole funzionalità tecniche e di programmazione, ritenute il vero cuore dell’applicazione.

Attenzione però: se fino a qualche anno fa il cliente era conquistato da un prodotto che faceva quanto richiesto, oggi lo dà per scontato. A parità di funzionalità vince la soluzione più semplice da utilizzare, armoniosa, organizzata con logica, bella. Una sfida tutt’altro che banale.