Ho risposto correttamente la prima volta che ho letto la schermata, perché non l’avevo mai vista e quindi sono stata attenta al messaggio. Tutte le altre volte che me la sono ritrovata davanti, ho sbagliato la risposta. Per ordinare al navigatore di fare una cosa, dovevo dirgli cosa NON volevo ottenere. Questa cosa può funzionare fino a quando l’utente non conosce il sistema, perché quando lo conosce non legge più il contenuto e procede per automatismi. Raramente, se non mai, mi è capitato di imbattermi in un errore così grossolano di copy e di ux. Alla terza volta, mi sono ripromessa di scriverci un post. Non solo perché si tratta di un errore di progettazione che genera nell’utente un forte disappunto, ma anche perché intuivo che sotto sotto, se ci avessi ragionato bene, avrei toccato temi come l’importanza del linguaggio, del tono e non so cos’altro.

L’usabilità delle parole

Sono passate settimane e il post mi rimaneva lì e nel frattempo sono andata allo UXCamp (Firenze) e all’Agile Day (Roma). Allo IAD ho ascoltato Yvonne Bindi, che ha parlato di usabilità delle parole. Nel suo intervento ha citato anche questo esempio del navigatore, oltre a molti altri casi eclatanti di cattivo uso delle parole sulle interfacce di qualsiasi tipo. Nelle sue slide c’è tutto quello che avrei voluto dire e molto di più.

Non esiste una professionalità come la mia se non lavora in team, con persone aperte al confronto. E non saprei tracciare in modo chiaro il confine tra il mio intervento e quello di qualunque altra persona nel team, durante lo sviluppo di un progetto web o sui nuovi dispositivi. Forse il premio alla fine l’ho preso io proprio perchè penso di aver capito fino in fondo questa cosa.

Ho tre suggerimenti da dare agli organizzatori:

1. se ho scritto “forse” è perché non mi hanno detto le motivazioni per cui mi è stato consegnato il premio e non conosco le modalità di valutazione. E visto anche il lungo viaggio fatto per ritirarlo, avrei voluto saperlo. La consegna di questi premi speciali è sembrata un po’ disorganizzata, ma di certo  è successo perché si tratta di una novità per un festival autorevole e storico come questo.
2. anche durante la divertente cerimonia serale, avrei voluto conoscere le motivazioni che hanno decretato un sito vincitore rispetto agli altri.
3. non emerge l’aspetto strategico di un progetto vincitore e questo dà l’impressione che la strategia non venga valutata. Moltissimi progetti candidati mi sembrano avere in comune una presentazione visiva e comunicativa molto curata e a effetto (quindi più epidermica), ma non è chiaro se questi progetti abbiano davvero costituito un successo per il cliente o abbiano risposto a un bisogno degli utenti.

A me sembrano tre punti importanti e spero che PWI trovi il modo di comunicarli meglio: il motivo per cui viene assegnato un premio e il motivo per cui un progetto è stato costruito in quella forma.
Grazie ancora agli organizzatori del PWI2001 e a IWA, per il riconoscimento e per l’esperienza emozionante che mi avete fatto vivere!

Mi dice che suoneranno Timo Maas…

Ellen Allien e molti altri.
Non è che sia di quelle persone che riesce a tirare tardi tre notti di fila, ma Adriano mi spiega che il tutto si svolgerà nell’isola di Pag. Finalmente ho un’occasione imperdibile per andare a scoprire un pezzo di Croazia in più, cosa che finora non sono mai riuscita a fare dato che i miei parenti vivono in Istria.

Saranno 4 giorni mica da ridere. Il programma è fitto e la musica inizia al pomeriggio. Se conosco un pochino Adriano e Jonathan, mi sa che riusciremo a vederci nelle ore serali! Io voglio andarci non solo per la musica, ma anche perché ho l’occasione di scoprire un piccolo pezzo di Croazia che non conosco e di godermi un mare semplicemente splendido.

Puoi seguire gli aggiornamenti del festival qui:
Web: http://www.supernovafestival.com/
Facebook: http://www.facebook.com/Supernovafest
Twitter: http://twitter.com/Supernovafest
Youtube: http://www.youtube.com/supernovafestival
Blip: http://blip.fm/Supernovafest
Mixcloud: http://www.mixcloud.com/supernovapodcast/

Per chi viene, ci vediamo lì. Per chi ci sta pensando, i biglietti li trova qui.

[DISCLAIMER] il pacchetto Large (viaggio + soggiorno + festival) mi verrà offerto da Amatori Tour Operator, a scanso di equivoci tutto quello che scrivo corrisponde a quello che penso e nella più totale trasparenza mi sentirò libera di scrivere come vivrò la vacanza.

In questo post, i Ninjas spiegano la loro visione sul ruolo dei brand e l’importanza del loro posizionamento nella società interconnessa. Condivido in pieno il loro punto di vista. Ci sono una miriade di motivi non professionali che mi portano a partecipare agli eventi del 13 febbraio, ma, visto che qui parlo di lavoro, mi limito a dire che da anni vedo una fissità di idee e di approcci nel mondo della comunicazione italiana, fissità che rispecchia una parte della nostra società.
Mi piacerebbe che questi eventi segnassero l’inizio di una boccata d’aria anche in questo settore. Una sveglia che suoni nelle orecchie di chi pensa che il suo anticalcare serve a donne superstiziose, che non sanno che prodotto usare – quindi ci vuole un uomo che glielo spieghi e che contestualmente le tratti come si meritano (cioè da galline);

oppure di chi pensa che per vendere un contratto di telefonia sia utile mostrare uno spogliarello in ascensore (spot che peraltro va in onda a qualunque ora del giorno);

oppure di chi dice che questi sono discorsi moralisti, e lo fa da 20 anni avendo i fondoschiena di due veline davanti alla faccia.

Qualche esempio di nuova, meravigliosa comunicazione c’è. Esistono aziende che sanno che i loro saponi vengono usati da splendide donne con taglie (o età) over-46;

oppure che le loro auto possono essere guidate da donne omosessuali persino belle (peccato che la provocante ma non volgare pubblicità della Twingo sia stata ovviamente subito censurata e ritirata);

oppure che i programmi possono addirittura essere condotti da donne intelligenti, capaci di fare interviste come quella di Daria Bignardi a Corrado Augias (un uomo che definire saggio mi sembra semplicemente riduttivo).

Domenica, mi piacerebbe vedere tanti uomini, non solo donne.
Mi piacerebbe non vedere neanche una sola bandiera di partito.
Ma soprattutto, mi piacerebbe che la sveglia suonasse per prima nelle orecchie di quelle donne che cedono alla tentazione del tutto e subito e pensano di essere sedute sulla loro fortuna. E per seconda nelle orecchie di quegli uomini (ma anche donne) che usano la scusa “colpa di voi donne, che fate così”, per raccoglierci tutte nello stesso fascio.

(n.d.r.: corretto dopo il commento di Jacopo e comprensione in progress )

Terza lezione: la qualità va definita secondo i valori giusti da apportare al progetto.

Dato che non sono sviluppatrice, mi fido del fatto che chi scrive codice stia facendo un buon lavoro. Ma a volte temo che ci sia uno sbilanciamento quasi nerd su questo punto, che però l’utente non percepirà mai come valore aggiunto. E magari si chiede all’interaction designer o al grafico di risparmiare sull’interfaccia o sulla presentazione. Basta che funzioni, insomma. Quando questo accade, significa che è di nuovo mancato il dialogo nel team, cioè la definizione della qualità e innovazione giusti da offrire per un determinato progetto. Quando si pianifica, uno degli obiettivi è di far emergere il sapere tacito del cliente ma anche del team. È così che si definiscono chiaramente requisiti e funzioni. O almeno, è la strada giusta per farlo.

Una necessaria conseguenza: anche la comunicazione e grafica vanno assorbite dal team.

È ormai chiaro per tutti che lo studio dell’interfaccia è un tesoro per il progetto. Ma dove sono la comunicazione e la grafica? Quando lavoriamo su progetti fortemente orientati alla comunicazione, è d’obbligo mettersi d’accordo con il team per fare in modo che gli sviluppatori non si limitino ai soli aspetti tecnologici. Può sembrare che si chieda di lavorare offrendo una qualità inferiore, ma in realtà si chiede di lavorare offrendo una qualità bilanciata e più opportuna, perché la presentazione impatta sull’emozione e il gradimento visivo o esperienziale di un utente e quindi contribuisce a far funzionare il sistema.

Sono tutti aspetti da chiarire in fase di definizione di un progetto: se si parla di un software, il sistema deve funzionare perfettamente e l’utente deve riuscire a usarlo senza difficoltà; ma su molti progetti web pubblici (e penso anche a molte applicazioni per smartphone), lo scopo (il ROI) non è solo l’esperienza dell’utente ma anche l’obiettivo di business che l’azienda vuole raggiungere, attraverso uno studio accurato della comunicazione.

Riguardando il grafico di Jacopo, noto immediatamente l’assenza dei loop legati al progetto grafico o all’aumento di fedeltà dell’interfaccia: (dalla ux al visual). Il wireframe ha un piccolo loop iniziale e poi vedo molti loop di sviluppo. Io credo che un flusso del genere funzioni molto bene quando si parla di software o comunque di applicazioni molto tecniche. Ma i progetti sui quali lavoro io stanno quasi sempre a metà strada tra la comunicazione e lo sviluppo. La sfida, per me, sarà trovare il modo di integrare il flusso individuato da Jacopo con il mio flusso di lavoro. Cioè come inserire il discorso “comunicazione” (quando c’è) in tutto questo sistema. Questo punto è fortemente sentito dal team con cui lavoro e stiamo cercando di capire come risolverlo.

Non vorrei che l’agile diventasse un rigido paravento di pratiche dietro cui lo sviluppatore si può trincerare, perdendo di vista l’opportunità richiesta dal progetto.

La metodologia agile secondo me ci aiuta a costruire questo terreno comune di fiducia reciproca, avendo rispetto dei nostri ruoli e bilanciandoli in base alle opportunità. In pratica, mi sembra un buon sistema per arrivare insieme a un approccio più maturo sul nostro lavoro. Vorrei che gli sviluppatori smettessero di guardare i visual designer come a fighetti che aggiungono fighetterie inutili. E io non voglio più vedere alcuni sviluppatori come nerd concentrati esclusivamente sul codice.

Breve nota: in questo paragrafo ho volutamente usato il termine “processo” (forse impropriamente) e non metodologia. Mi sembra però che questo territorio sia piuttosto nuovo e quindi non so se esistano parole più corrette. Ad ogni modo processo mi piace, perché mi ricorda un bel commento di Cristiano.

Dopo il CSMA10.

Inizio a tirare qualche filo di una ricerca che ho iniziato appena ho potuto muovermi da libera professionista. Non intendo dire che ho trovato il modo giusto di fare le cose, ma penso di aver iniziato a vedere e capire (uso intenzionalmente questi due verbi) quali sono le attività che devo svolgere per portare un valore sensibile al team di sviluppo. È curioso ed è anche un grande classico: nel momento in cui ho iniziato a capire, mi sono chiesta come mai non riuscissi a vedere prima determinate situazioni. Credo che sia dovuto a un insieme di fattori che a un certo punto, semplicemente, maturano. Diventa più chiara la comunicazione con gli altri, al punto che all’improvviso sembra di parlare tutti la stessa lingua. Diventa spontaneo il tentativo di visualizzare o verbalizzare le criticità, guardandole nelle loro componenti atomiche. Perché è lì, quando le spezzetti, le mostri, le avvicini tra loro e chiedi “intendevi fare una cosa del genere?” che ci si accorge che forse manca una parte o avevi dimenticato o valutato male un aspetto. Capisco quanto mi stanno tornando utili tutte le discussioni a cui ho partecipato nell’ultimo anno. Dall’Agile Day 2009, all’IA Summit di Pisa, dal Whymca allo Experience Camp di Lugano fino al seminario DotNet. Sarà che ho iniziato a scrivere questi post mentre sono ancora pervasa dall’atmosfera che si è creata al CSMA10, però provo un sincero senso di gratitudine verso tutte le persone che negli ultimi mesi hanno condiviso tante delle loro esperienze, conoscenze e punti di vista. Mi hanno scritto in privato, mi hanno fatto riflettere prima, durante e dopo un evento, hanno scritto un post sui loro blog.

Abbiamo bisogno gli uni degli altri. Suona banale, ma è così. Mai come quest’anno, da quando parlo direttamente con gli attori che lavorano su un progetto, ho potuto sentire una voglia reale di spiegare le esigenze e risolvere i problemi. E tutto il gruppo esce vincente, Cliente compreso.

Seconda lezione: l’interaction design fa parte dello sviluppo.

L’interaction design è parte dello sviluppo (Alberto Mucignat direbbe anche che i wireframe sono veri e propri contratti) e il team dovrebbe essere pronto a raccogliere le change request anche da questo punto di vista. Sembra scontato, ma non lo è. Quando ci si trova d’accordo su questo punto, tutti iniziano a venirsi incontro. Io inizio a capire meglio quali strumenti devo tentare di dare agli sviluppatori, domando e rifletto per fare ipotesi sensate di interazione. E loro sono più disposti a capire che anche l’interazione va digerita (in tempi brevi) e poi testata ed eventualmente corretta. Da parte mia, quanto prima metto a fuoco il progetto e le cose che l’utente potrebbe fare (le user tasks), tanto prima riesco a definire le loro criticità e il valore che si può aggiungere.

Fino a ieri questi confini erano molto incerti perché si faceva confusione tra presentazione e interfaccia. Ma ora stiamo arrivando a una maturità che ci permette di distinguere chiaramente queste differenze e quindi aggiungere il valore là dove è davvero importante. In più, se sento che la mia parte di lavoro fa parte dello sviluppo come le altre, sono molto più stimolata a riflettere, confrontarmi e fare analisi sul progetto.

Ancora una volta, dopo il seminario con DotNetMarche, ho notato che è una questione sentita da tutti e anche al CSMA ne abbiamo parlato a lungo. Lorenzo mi ha fatto pensare quando mi ha detto: “Se leggo una user story, io vedo, per esempio, un database”. Io magari ne avvicino cinque e vedo un carrello con molte funzioni che vanno discusse.

È da circa un anno e mezzo che e-xtrategy mi ha messo di fronte a progetti impostati secondo metodologie agili. Per tutto questo tempo ho cercato di ricostruire i motivi per cui mi si chiedeva di lavorare così. Ho visto i vantaggi e mi sono scontrata con diversi problemi. Al CSMA sono finalmente partita da zero: teoria, metodi, scrittura delle storie, planning e planning game, iteration e release planning, suddivisione in task… E finalmente ho potuto riempire il vuoto “culturale” che avevo. Siamo partiti da un finto progetto, sulla base della traccia suggerita da Stefano Ottaviani: un sito di e-commerce per la vendita di ebook online, che per motivi di tempo abbiamo ridotto a una semplicissima applicazione collegata con Twitter. Atomizzando il finto progetto deciso al CSMA, ho potuto fare le mie domande e tirare le fila.

Prima lezione: una nuova visione sulle user stories.

Da quando cerco di lavorare con questo metodo, la scrittura delle user stories mi è sembrata la prima grande novità metodologica. Mi sono sembrate molto utili per definire un progetto nel dettaglio, discuterlo e condividerlo, oltre che metterlo in ordine di priorità. Tutto questo mi ha messo di fronte all’evidenza di dover definire meglio il mio ruolo come designer delle interfacce e all’esigenza di trovare un terreno di dialogo comune con gli sviluppatori.
Da quando scriviamo un progetto con le user stories, mi sono sentita come se fossimo un gruppo di persone dentro un appartamento vuoto da riempire. Ogni storia era come un mobile che ognuno portava e lasciava lì dentro, in ordine sparso. A me veniva richiesto di mettere in ordine le stanze e trovare un posto per ogni cosa, oltre che trovare i mobili mancanti. In questa situazione, avevo difficoltà a inquadrare il progetto nel suo insieme, mi occorreva tempo per fare ordine e quindi anche per discutere i punti critici. Questo creava problemi perché è importante che tutto il team abbia chiaro il progetto nel più breve tempo possibile. Al CSMA credo di aver trovato la chiave giusta: posso inserirmi nella scrittura delle storie facendo ordine fin dall’inizio. Ho capito che gli sviluppatori hanno bisogno di spezzettare un progetto in piccole parti, mentre noi designer abbiamo bisogno della visione d’insieme. Il metodo che potrei usare è proprio quello di guidare il processo di scrittura individuando gli scenari (e sottoscenari) in cui l’utente si trova (o, forse, dovrei dire “che proponiamo all’utente”). Tra l’altro, ho scoperto che questi scenari corrispondono all’incirca a un tipo di user story che in gergo viene chiamata “epic” (storie molto grandi che quindi andranno spezzettate).
Curioso perché credo che davvero che sia un uovo di Colombo. Non vedo l’ora di mettere in pratica questo sistema.

Due interventi su tutti.

Se avessi scritto questo post subito dopo la conferenza, probabilmente mi sarei sforzata di tirare fuori gli aspetti interessanti e positivi di questa applicazione (o dovrei dire “piattaforma”). Ma ho preferito lasciar passare qualche giorno per assorbire l’entusiasmo e rifarmi un’idea meno condizionata.

Contestualmente all’evento e agli aspetti generali di Foursquare, segnalo due interventi su tutti: quello di Gianluca Diegoli e quello di Stefano Mizzella. In poche parole: i contro e i pro. È su quello che ho letto in queste slide che vedo i difetti e le opportunità di FourSquare. Non saprei aggiungere altro, ve ne consiglio la lettura.

Cosa ne penso io.

Uso Foursquare da qualche settimana. Dopo la prima sensazione di divertimento e novità, ci sono due cose in particolare che hanno iniziato a non piacermi:

• il check-in è fastidioso come un dito in un occhio. E ovviamente non è una cosa da poco. Il check-in è la conditio-sine-qua-non… ed è una condizione che mi sta antipatica. Trovo che vada bene per chi abbia voglia di giocare e questo non è il genere di giochi che mi piacciono. Nel mio caso, ho notato che fare il check-in mi aliena dalla compagnia con cui sto, provocando (una giusta) irritazione negli altri e un senso di idiozia da parte mia. Sono d’accordo con Michele che conoscere i posti frequentati dal mio network contribuisce a consolidare la fiducia che ho nelle persone, ma questo per me vale quando si parla di lavoro. Nella vita privata, ho molti altri servizi che posso usare in alternativa, meno invadenti di questo.
• vorrei che il servizio venisse da me. Dato che non ho voglia di giocherellare al check-in, vorrei che il servizio funzionasse in qualche modo anche senza dover premere il dannato bottone. Quando il satellite mi trova, posso comunque ricevere informazioni geolocalizzate… ma di certo per questo ci sono già innumerevoli applicazioni. E ci sarebbe un altro tipo di problema di privacy, immagino. Probabilmente questo è un limite per me, che passo molte ore davanti al Mac o allo smartphone per lavoro… e quindi non ho certo voglia di rimettermici anche quando vado a mangiarmi una pizza con gli amici.

Questi sono i miei due cents ed è per questo che forse Foursquare non fa per me. Per ora continuerò a usarlo in situazioni lavorative, ma credo proprio che rinuncerò a tutti gli altri aspetti che riguardano la vita privata.

Ho ascoltato le sessioni mattutine, mentre quelle pomeridiane si sono rivelate troppo tecniche, per me. Così ne ho approfittato per scrivere questo post.

Mi è sembrato che il seminario fosse rivolto perlopiù agli sviluppatori ma, anche questa volta, ho notato che le questioni di usabilità, interfaccia utente, architettura dell’informazione, feedback e test sono considerate parte dello sviluppo, al pari del resto del lavoro.

Devo confessare che non conoscevo diversi termini usati durante le presentazioni (al di là degli interventi tecnici)… a partire proprio dal titolo del workshop: da oggi, spero di ricordarmi i termini SOA e deploy. Magari non il loro significato preciso (roba da ingegneri…) ma almeno la loro esistenza.

Vorrei dare un consiglio a tutto il gruppo DotNetMarche e anche ai relatori: per favore, condividete le vostre slide (magari su SlideShare)! Durante il workshop ho dato per scontato che le avrei trovate online e ora non solo non trovo i titoli, ma non posso neanche inserirle in questo post. O forse sono io che non vi trovo.. quindi rendetevi più “trovabili”.

Le sessioni introduttive di Ricci e Servienti.

La prima sessione della giornata è stata di Gian Maria Ricci, che ha spiegato i motivi per cui il metodo waterfall non è più adatto a risolvere i problemi di sviluppo e ha introdotto il concetto di agile, spiegando motivi e metodi.

Mauro Servienti ha proseguito inquadrando alcune delle questioni centrali relative all’impostazione di una nuova applicazione, basandosi su problemi riscontrabili nel mondo reale: trovare il giusto interlocutore, fare le giuste domande, ricordarsi in tutte le fasi dello sviluppo che il focus è sull’utente, il dialogo all’interno del gruppo di lavoro e con il cliente (evitando i tecnicismi). Anche nel suo intervento, ho notato che il metodo agile viene dato per scontato, al punto che è ovvio che il gruppo di lavoro scriva, discuta e condivida le storie. Infine, anche per Mauro, le storie dovrebbero essere indipendenti tra loro e comportarsi quasi come se fossero microapplicazioni, perfettamente funzionanti al momento del rilascio.

Prototipi con Sketchflow di Scardova.

Alessandro Scardova ha presentato una sessione molto pratica. Inizialmente, ha spiegato l’importanza dei prototipi e la necessità di avere un feedback dagli utenti. Poi ha mostrato come usare Expression SketchFlow per avere degli “schizzi” interattivi online, utilizzabili dagli utenti che possono anche lasciare un commento. In questo modo, il gruppo di lavoro avrebbe un prototipo funzionante e pieno di appunti lasciati dagli utenti.

Il suo intervento è quello che mi ha aperto più domande, ma purtroppo non c’è stato il tempo di fargliele in diretta. Gli segnalerò questo post, sperando che abbia voglia e tempo per venire a rispondere qui.

Alla ricerca della parola giusta (cioè dello strumento e del metodo giusti).

In diversi (ormai tantini) anni di lavoro, ho sentito molte parole legate al concetto di schizzo / prototipo, ma ogni settore (dalla carta al web) sembra usarle senza una vera soluzione di continuità: perciò posso dire bozza, draft, menabò (o menabau), timone, mockup, wireframe… ogni volta avendo il sospetto che dev’esserci un modo “definitivo” di usare questi termini.

A naso, mi viene da dire che bozza e draft sono la stessa cosa. Una bozza mostra una proposta grafica che verrà usata come guida durante lo sviluppo. In un’ottica di sviluppo agile, la bozza potrà avere diversi dettagli variabili e dovrà mostrare il look&feel del sito. Fino a qualche tempo fa, la grafica mostrava tutte le funzionalità del progetto. Negli ultimi anni, però, i progetti sono diventati sempre più complessi e abbiamo visto che questo non è più possibile. Perciò in grafica si prevedono diversi ingombri che verranno approfonditi meglio in fase di sviluppo (o forse di prototipo, il giorno che capirò meglio come farne uno).

Il prototipo è una specie di schizzo (sketch.. altra parola da aggiungere all’elenco) interattivo che verrà usato come strumento per discutere con l’utente delle funzionalità e delle criticità legate al progetto. Individua le principali questioni d’uso e funzionalità, ma non le approfondisce. Anche qui, gli approfondimenti verranno fatti in fase di sviluppo.
Alessandro, all’inizio delle sue slide, ha detto anche che il prototipo è utile in fase di quotazione, perché mostra a grandi linee il funzionamento e le criticità del progetto.

Forse è solo una questione di parole, ma non ne sono molto sicura… Certo è che mi piacerebbe usare le parole giuste per le cose che faccio.

Le mie domande.

• dove collochiamo il wireframe? Per me ora il wireframe è utilissimo per decidere i pesi grafici e i principali contenuti del progetto. Spesso ci è servito per scrivere le storie, altre volte sono partita dalle storie e ogni elemento del wireframe ne soddisfa una. Mi piacerebbe creare un wireframe interattivo… Ma dovrei forse separare le due cose? cioè usare il wireframe più per un discorso grafico e il prototipo per un discorso di funzioni e usabilità?
• se il wireframe, il prototipo e la grafica non mostrano mai un prodotto definito, quand’è che lo vede il cliente? In teoria, durante i rilasci frequenti che verranno poi corretti in base ai feedback… Eppure, si è detto più volte che questo sarebbe un rischio per gli sviluppatori.
• il prototipo mostra necessariamente dei bottoni e dei contenuti impaginati, anche se a livello molto grezzo. Quanto cambiano queste impaginazioni dal prototipo alla grafica? se l’utente si è abituato a trovare nel prototipo un menù a sinistra e una scheda organizzata in un certo modo, quanto posso allontanarmi da questa impaginazione al momento di studiare la grafica?
• e infatti, quand’è che è giusto studiare la grafica? prima, durante o dopo il prototipo?
• il prototipo serve per la quotazione e questo è un sogno per gli sviluppatori. Loro possono quantificare un progetto su una base piuttosto chiara, ma se poi il progetto non passa? chi ci rimette è quello che ha investito il tempo a creare il prototipo e testarlo… Come si fa in questi casi? Finché il “prototipista” lavora in azienda, è comunque l’azienda che perde l’investimento; ma se il prototipista è un freelance (ehm… tipo me) alla fine è solo lui (o lei ) che ci rimette… Forse andrebbe fatto sempre un accordo a monte tra prototipista e sviluppatori, per dividere onori e oneri?

Concludendo.

Una delle questioni che vorrei tentare di risolvere rimane sempre il ruolo della grafica, intesa anche come comunicazione. Continuo ad avere l’impressione che certi metodi funzionino su progetti molto tecnici o destinati a un uso riservato. Ma per quelle interfacce in cui la comunicazione gioca un ruolo fondamentale, mi sembra improbabile che il cliente (e in fondo anche l’utente quando testa) capisca un box grigio al centro della grafica e un prototipo in Comic Sans. Il proposito di creare un progetto davvero utile per l’utente è ineccepibile, ma spesso i progetti non sono fatti solo di funzionalità. È su questo confine labile tra uso e comunicazione che sto cercando l’equilibrio giusto per inserirmi nel flusso delle iterazioni, senza perdere di vista l’aspetto comunicativo ed emozionale che un’applicazione potrebbe contenere.

17 luglio 2010.

Prima conferenza dei sindaci di Foursquare
L’hanno organizzata i Mimuli Roberto e Francesca, insieme a Tommaso e Lisa. Me ne ha parlato Adriano e ci ho messo poco a capire che avrei dovuto esserci anch’io. Nel suo post, Adriano dice tutto: non è tanto il network in sé che interessa quanto il fenomeno della geolocalizzazione e lo spostamento dell’uso di internet dai media tradizionali ai nuovi dispositivi. Che forse è quello che potremmo chiamare anche “internet delle cose”. Vediamo che argomenti salteranno fuori.

2-3-4 settembre.

Campo Scuola sulle Metodologie Agili
Grazie al gruppo XPug Marche, che ho conosciuto su invito di Lorenzo, a settembre saremo a Fabriano per una full immersion agile di due giorni e mezzo. Saremo in 12 e cercheremo di affrontare un progetto dall’inizio alla fine, seguendo i metodi che ci suggerirà Jacopo Romei, il nostro “agile coach”. Non vedo l’ora di partecipare. Da quando e-xtrategy ha introdotto questo metodo di lavoro, ci sono molti punti interrogativi riguardo alle questioni di ux, interfaccia e grafica, quindi voglio cogliere l’occasione per  provare a svoltare. Credo che la chiave stia nel cambiamento di approccio ai progetti e all’organizzazione delle scadenze. Ma, anche qui, vedremo.
Intanto sono contenta di aver progettato il logo del Gruppo.

Prima metà di novembre.

UX Camp Firenze
Ho perso l’edizione 2009 e non vorrei mancare anche quest’anno. Il programma e l’evento sono ancora tutti da definire, ma su Twitter se ne sta già parlando. Io e Ale faremo di tutto per esserci.

Aspettando lo stop…

Con la pausa d’agosto davanti e il clima di ferie che si inizia a respirare, sto cercando la calma e la lucidità per fare un’analisi delle cose fatte da marzo a oggi, tra lavori ed eventi che ho seguito. Intanto, voglio cogliere l’occasione per ringraziare gli organizzatori dell’IA Summit e dell’Experience Camp di Lugano, per la qualità degli interventi e l’apertura al confronto. Devo ringraziare anche la “Mimula” Francesca, per questa intervista.

E grazie anche al solito Alfredo, che mi ha dato l’opportunità di disegnare la launcher icon per la sua applicazione androidiana “SMS for free”.

Una piccola nota personale.

Per luglio e agosto ho messo in programma la visita a due splendide mostre fotografiche (che consiglio a tutti), quelle di Steve McCurry e Francesca Tilio. E naturalmente tanto mare.