Aggiornamenti

Social Networks

Sponsored by

ilariamauric.it è online dal 2009
23 maggio 2010

Whymca, 21 maggio 2010: la mia esperienza, quasi a caldo.


Il Whymca 2010 è stata un’esperienza splendida, oltre ogni aspettativa. Prima del mio intervento ero piuttosto preoccupata, perché era la prima volta che parlavo in pubblico e perché quasi tutti gli altri talk hanno avuto un taglio da sviluppatori. Però ero piuttosto tranquilla sul discorso che avrei voluto fare, anche grazie al “solito” Adriano e a mia sorella. Mentre Adriano ha avuto la pazienza di darmi vari consigli, Barbara è venuta con me a Milano e per tutta la mattina mi ha aiutato a fare ordine e mettere nella giusta sequenza i concetti che avrei voluto dire. E così tutto è scivolato via in poco meno di mezz’ora.
Dopo il Whymca, ho deciso di specificare che si tratta della versione 1.0.

Il metodo… e perdere il controllo.

Nel tempo rimasto, con mia grande sorpresa, è saltato fuori un bel dibattito, da cui ho raccolto molti suggerimenti… ci tornerò su al prossimo post.
Alla fine, una persona del pubblico ha obiettato che a suo parere, nel lavoro del designer, manca il metodo… per lui, tutto risulta essere molto emotivo, poco misurabile. La mia risposta è stata che tutta la mia presentazione voleva essere una spiegazione utile a far capire il metodo di lavoro e la motivazione delle scelte che facciamo. Alla mia risposta è seguita quella di Cristiano, davvero eccellente: l’utente non lo controlli, al massimo puoi controllare i processi. Per quanto ci si sforzi di proporre una buona interfaccia, l’utente può sempre spiazzarti, perché potrà avere comportamenti inaspettati… è inutile chiedere al designer di dare risposte certe e misurabili al 100%, perché di là ci sono persone, individui. Non simulazioni. Il nostro compito è quello di tentare, studiare per proporre la soluzione che possa essere il miglior compromesso possibile. Cristiano aveva già espresso questo concetto all’Italian Agile Day 2009, ma dopo il mio intervento e i consigli ricevuti (che sono quasi diventati una specie di primo test), le sue affermazioni hanno acquistato ulteriore spessore. Almeno per me.

Grazie al Whymca.

Ringrazio ancora una volta chi mi è venuto a sentire, chi ha commentato, chi mi ha dato suggerimenti e anche criticato… E ringrazio di cuore gli organizzatori del Whymca, con un pensiero particolare ad Alfredo (mr. In Gambissima, :D ed è proprio vero!). Per me, è stata la prima vera occasione di mettermi in gioco e parlare davanti a un bel gruppo di professionisti. Mi spiace di non essere riuscita a seguire gli altri interventi e a dare spazio a qualcuno che aveva ancora qualche domanda. Se leggerete questo post, fatevi avanti: vi risponderò da qui.

Tra qualche giorno pubblicherò l’elenco di consigli e risposte ricevute: la mia base di lavoro per passare a Mobile Monthly.Info versione 1.1.

11 Commenti
  • Ciao, ho seguito con molto interesse il tuo talk, visto che mi occupo di mobilizazione siti web. E devo dire che è stato molto interessante il punto di vista di un designer (io sono uno sviluppatore).

    Secondo me l’osservazione dello sviluppatore era più che altro un dubbio sull’esistenza di metologie simili a quelle in voga fra gli sviluppatori. Le risposte al suo dubbio, secondo me, non sono state del tutto esaustive.

    Forse delle metodologie precise non ci sono, ma esistono dei principi di usabilità dettati dallo studio sul cervello umano e da esperienze acquisite. Se così non fosse tutti gli studi su HCI (Human Computer Intercation) sarebbero parole al vento.

  • Ciao Filippo, grazie per avermi seguito e per questo commento.

    il talk di Andrea Picchi, successivo al mio, conteneva molte indicazioni riguardo al metodo usato per una buona progettazione (anche grafica). Tra le varie cose, Andrea ha parlato di ghestaltica e teoria della percezione, materie che ogni grafico dovrebbe aver studiato. Nel mio caso, faceva parte del programma di studi Isia. Un designer dovrebbe sapere applicare i principi di ghestaltica a ogni progetto: la differenza dei risultati è visibile (percepibile appunto). Layout chiari contro layout disordinati, strutture solide e comunicazione efficace contro strutture incerte e decoro fine a sé stesso. Misurare tutto questo, però, è difficile e solo i test con gli utenti possono fornire risposte di massima. Mentre per gli sviluppatori ci sono risposte certe, per i grafici non è così: non è un sistema che risponde a un test, ma sono le persone. Gli studi che citi esistono, ma sono appunto studi di massima, non eseguibili su ogni singolo progetto (oddio, forse qualcuno riesce a farli, se il progetto è particolarmente complesso e prevede investimenti adeguati).

  • Si infatti ho seguito con grande interesse il talk di Andrea. Anche se capisco che l’applicazione pratica di tutte quelle teorie non è scontata ed è in ogni caso un trade-off.

    Se hai avuto modo di leggere il libro Web Form Design di Luke Wroblewski è pieno di test effettuati sugli utenti e varie considerazioni scaturite in seguito (in quel caso il cliente era Ebay che ha tutti i mezzi necessari per effettuare simili test). Ma anche li, il libro, non da una risposta universale su come progettare le form, ma piuttosto delle linee guida con vari pro e contro dei diversi approcci possibili. Sta al designer trovare il giusto compromesso.

    In ogni caso resto in attesa della versione 1.1, buon lavoro.

  • solo un appunto, perché quello sul metodo e sugli utenti è un tema che mi sta a cuore.

    attenzione che andando avanti con il ragionamento “l’utente non lo controlli” si sta poco per arrivare a dire “progetto io, tanto poi l’utente fa come vuole”. e questo è un rischio, perché sostanzialmente porta il designer ad auto-assolversi e quindi gli lascia “troppa libertà”, con i risultati che vediamo ogni giorno. invece il design vive di vincoli, sopratutto di quelli umani, che sono necessari per progettare prodotti efficaci.

    (peraltro non è vero che “l’utente fa come vuole”: chi ha fatto ALMENO un test di usabilità lo sa bene. l’utente “fa quello che gli sembra sensato” quando non ha altre possibilità oppure quando il sistema è progettato male)

    HCD o UCD sono nate e codificate proprio per avere un processo che metta l’utente (o meglio la persona) al centro del processo. e per farlo BISOGNA lavorare con gli utenti, non c’è altra strada.

    il resto è opinione personale, “gusto del designer”, ecc.

    ciao, Alberto.

    ps: dopo anni mi annoia dover ancora, continuamente, discutere di queste cose, però è una battaglia che ho “l’obbligo morale” di portare avanti. ;-)

  • Alberto, non vorrei fraintendessi quello che ho sostenuto a Whymca. Ovvero che, a fronte di “regole certe” (diciamo così) a cui può attenersi un programmatore/sviluppatore (avendo a che fare con sistemi lineari e prevedibili) al contrario il lavoro di un designer ha degli elementi di incertezza e di indeterminazione che sono irriducibili.
    Prima di tutto perché ha a che fare con “materiale umano”, quindi per sua natura “non controllabile” a priori. E poi soprattutto perché le persone cambiano, evolvono. Giusto prima il talk di Ilaria c’è stata la presentazione di Luca Mascaro, e lui stesso ha dovuto ammettere che l’avvento di iPad ha completamente messo in discussione le sue certezze su come disegnare le interfacce per questo tipo di device. E’ inevitabile che un test con gli utenti che dovesse essere effettuato oggi ha validità qui e ora, ma fra un mese gli stessi utenti potrebbero nel frattempo avere acquistato un iPad, e il loro modo di usare il prodotto testato sarebbe probabilmente diverso. Pensa a come pensiamo/usiamo/valutiamo le interfacce oggi, che ognuno di noi possiede un iPhone, e come siamo cambiati rispetto a un paio di anni fa.
    Questo non fa che confermare da un lato l’importanza di fare i test con gli utenti, e su questo concordo assolutamente con te, ma dall’altro richiede però che a questi test venga assegnato un “giusto peso” nel processo di design di un prodotto/servizio, meno assoluto e più relativo, e su questo invece spesso ci scontriamo, o sbaglio? :-)

  • premetto che UCD/HCD non sono solo i test di usabilità, anzi, è un processo completo che mette al centro l’utente. su QUESTO, con te, ci “scontriamo” da tempo.

    tuttavia a volte trovo delle frasi ad effetto con cui non sono d’accordo, ma che reputo “pericolose”, se mi passi il termine.

    sono d’accordo sull’evoluzione dell’esperienza d’uso, per cui oggi cambiano i “pattern” (e molti ancora sulle interfacce “smart” non li conosciamo), ma questo non deve portarci a dire che allora non serve fare UCD perché l’utente è imprevedibile.

    però veramente non voglio continuare a discutere con te in eterno, anche perché sei una testa dura ;-) … cerco solo di evitare che altri cadano nel tranello ;-)

  • Per esser chiari, ed evitare che altri fraintendano le mie parole e cadano in qualche tranello: NON credo assolutamente che l’UCD sia inutile perché l’utente è imprevedibile, anzi! proprio perché non può essere previsto (non è lineare) va misurato, sperimentato, testato e nei limiti del possibile capito e compreso.
    Quindi viva l’UCD, ma temperato con la giusta dose di DDD (“designer-driven design”) ;-)

  • Ciao Alberto,
    mi spiace che ti annoi a discutere di queste cose, però penso che bisogna farlo perché se cambiano gli scenari, cambiano anche i processi e di conseguenza il comportamento degli utenti. Cambiano anche le professionalità coinvolte e le richieste.
    Nel mio post non dico che l’utente fa quello che vuole, ma che dobbiamo cercare il miglior compromesso possibile, perché davanti non abbiamo sistemi o simulazioni. Non avremo mai una risposta definitiva, come quelle che forse gli sviluppatori (o altri tipi di professionalità) riescono a dare.
    A me personalmente annoia dover spiegare ancora che dire “Non mi piace la grafica” è diverso da dire “Non funziona l’interfaccia”: spesso queste due fasi della progettazione vengono ancora confuse. Però, quando continuo a sentire osservazioni come quelle che ci sono state al Whymca, capisco che dobbiamo cercare di spiegare sempre di più e sempre meglio in cosa consista il nostro lavoro, per migliorarci, migliorare i processi che seguiamo e i risultati che cerchiamo di ottenere.
    Io la vedo così, ma forse perché ho iniziato da poco a buttarmi nella conversazione. Magari tra qualche tempo sarò stufa anch’io.

  • ciao Ilaria,
    sorry per il ritardo ma ero all’estero.

    Il mio “annoiarmi” era una semplice battuta/sfogo tra amici. Il fatto che NOI designer stiamo ancora a discutere di queste cose mi stanca. Non è una battaglia con quelli che non conoscono UCD o simili, ma con quelli che vedono il ruolo di designer come una certa superiorità.

    Io la chiamo “la sindrome del fantasista”: il Roberto Baggio che risolve tutto lui, per usare una metafora comprensibile nel belpaese. Purtroppo è un’idea che continuo a trovare in giro e mi stanca doverne ancora discutere, anche se -ripeto- è una missione continuerò a portare avanti. Il design è un processo, prima di tutto, i bravi designer possono fare la differenza, ma solo se stanno dentro il processo.

    Sul resto la penso come te, sia sul compromesso, che sulle fasi di design. Per me però dev’esser chiaro, che tra il “non mi piace” e il “non funziona”, in mezzo c’è un sacco di lavoro con gli utenti + un designer umile. Perché, sostanzialmente, il designer deve risolvere problemi, non “farsi bello” (per quello c’è il marketing ;-) ).

    ciao, Alberto.

  • Lascia un commento

    Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

    Informazioni e licenza


    Questo blog utilizza Wordpress è basato sul tema Gutenberg, modificato da me con i preziosi consigli di Nicolò e il fondamentale supporto di Luca
    Eccetto dove diversamente specificato, i contenuti del mio blog sono pubblicati con Licenza Creative Commons Attribuzione Non commerciale - Condividi allo stesso modo 3.0 (Italia License).