Alberto Mucignat

Alberto Mucignat


Random thoughts around web stuffs (è tutto un equilibrio sopra la follia)

novembre: 2017
L M M G V S D
« Ott    
 12345
6789101112
13141516171819
20212223242526
27282930  

Categorie


La user experience non è misurabile

AlbertoAlberto

Excrement. That’s what I think of Mr. J. Evans Pritchard.
We’re not laying pipe, we’re talking about poetry.
John Keating, Dead poet society

Da tempo chi si occupa di user experience ha iniziato a confrontarsi con la necessità di avere informazioni quantitative (dati, numeri e percentuali, per intenderci) per poter operare (o giustificare ai committenti) scelte di design.

Per questo di recente si parla molto di misurare la user experience attraverso tool di analytics, sistemi di testing remoto, ecc. Ne ho parlato diverse volte qui nel blog.

Però, anche se il confronto con i dati sulle scelte di design credo sia un passaggio fondamentale nel nostro lavoro, oggi ho avuto un “a-ha moment” come dicono gli anglofoni.

È solo un esempio, ma vediamo se riesco a farvi capire quello che penso.

Da qualche tempo a Doralab impostiamo i wireframe basandoci su alcuni framework css, per poter facilitare il lavoro di produzione dell’html.

Oggi, ho chiesto agli amici-partner di Ideato quanto tempo abbiamo risparmiato lavorando in questo modo in un progetto che è andato particolarmente bene da questo punto di vista.

La risposta è che non abbiamo mai misurato questo dato confrontandolo con le soluzioni classiche, ma si stima che ci sia un risparmio di almeno il 20-30% nei tempi di produzione dell’html.

Anche se è una stima, è un dato importante.

Ma la vera chicca è una frase di Francesco Trucchia, uno dei fondatori di Ideato:

“la cosa che più conta è la fedeltà che si rispetta passando dal wireframe/psd all’html”.

Ecco, per me questo conta più di quel 20-30% di tempo risparmiato, perché la qualità è più importante della quantità.

Purtroppo, per i clienti, non ha un gran valore rispetto ai benefit quantitativi (e se invece prendessimo la qualità del lavoro come un KPI?), ma per gli utenti?

Non sono forse gli utenti a dover gli unici a poter stabilire il valore della ux? Per loro, probabilmente, la qualità dell’interfaccia finale è più importante di qualsiasi dato quantitativo.

E arrivo ad una generalizzazione, che cercherò di argomentare meglio nel futuro: ci piaccia o meno, la user experience non è misurabile, qualunque cosa facciamo.

Comments 16
  • Jacopo Romei
    Posted on

    Jacopo Romei Jacopo Romei

    Author

    In realtà probabilmente la qualità è tale solo se provoca effetti che – per quanto complessi e difficili da catturare – sono poi quantitativi eccome.
    Cito Mucignat – non so se lo conosci – a puro titolo di esempio: “più velocemente un utente arriva al proprio obiettivo, più l’esperienza per l’utente è positiva” [1].
    Bene, la user experience è non misurabile in sé, siamo d’accordo, ma poi alla fine alla fine un modo per misurare se qualcosa va fatto o meno c’è. Forse indiretto, forse fuzzy, ma c’è.
    La fedeltà dell’html al psd è un dato qualitativo senza dubbio, ma i casi sono solo due, non mutuamente esclusivi:
    – o questa fedeltà è utile a chi sviluppa (producendosi in quantitativissimi incrementi di ROI)
    – o questa fedeltà è utile a chi il sito lo usa alla fine (producendosi in quantitativissimi incrementi di ROI)

    Insomma, il grassetto “la user experience non è misurabile” è una affermazione più debole di “più velocemente un utente arriva al proprio obiettivo, più l’esperienza per l’utente è positiva”, sempre scegliendo questa come esempio particolare.

    [1] http://www.mucignat.com/blog/archives/1557-velocita-significa-ricevere-piu-attenzione.html


  • Alberto
    Posted on

    Alberto Alberto

    Author

    ok, è pur sempre vero che amo contraddirmi ogni tanto, ma lo faccio per una buona causa, sia chiaro, ovvero riuscire a definire con più chiarezza quello che penso.

    si, è pieno di dati che possiamo tirare fuori e la velocità è uno di questi.

    ma “quanto vale per l’utente” è un dato difficilmente quantificabile. tu riesci a “quantificare le tue emozioni”? (mi viene in mente un bambino che allarga le braccia per dire “quanto bene ti voglio”…).

    perché se parliamo di misurare la user experience, parliamo di quantificare qualcosa che ha un valore per quello user che sperimenta la experience.

    per me è chiaro che si possono misurare un sacco di cose, ma ce ne sono altre che vanno oltre scala (il bambino che si sforza di aprire le braccia il più possibile e vorrebbe avere le braccia più lunghe).

    il punto è questo, spesso la UX fa andare i valori fuori scala, però questo ancora ai clienti non basta, preferirebbero un +0,2% dei click sul banner, rispetto a un fuori-scala che mette fuori gioco i competitor. pensatè.


  • Matteo Balocco
    Posted on

    Matteo Balocco Matteo Balocco

    Author

    Cosa intendi per qualità? Dal post sembrerebbe che più la UI finale è coerente con il wireframe maggiore è la qualità. Ti riferisci a questo?


  • maurizio
    Posted on

    maurizio maurizio

    Author

    è ovvio che il sito deve essere il più fedele possibile al wireframe e/o al psd, e se chi produce questi elementi ha un’esperienza tale da progettare con “criterio” rende la vita più semplice a chi sviluppa.

    in ogni caso bella l’idea di preparare i wireframe secondo griglie css già impostate…
    sarei curioso di sapere quali sono i framework che avete sperimentato e se hanno aiutato anche voi in fase di prototipazione.


  • Matteo Balocco
    Posted on

    Matteo Balocco Matteo Balocco

    Author

    Maurizio, durante un workshop di Clearleft, qualche anno fa, mi incuriosì un passaggio di Richard Rutter in cui disse che invece i loro prototipi si focalizzano unicamente sull’interazione dell’utente e sulla modifica dell’interfaccia. La rispondenza tra ui del prototipo e ui definitiva per loro non è così importante almeno fino a quando l’interazione oggetto di test viene rispettata. Ma torno al punto. Vorrei capire cosa si intende per qualità, perchè non è molto chiaro.


  • Davide ‘Folletto’ Casali
    Posted on

    Davide ‘Folletto’ Casali Davide ‘Folletto’ Casali

    Author

    Io ho un’altra domanda: avete misurato un risparmio del 30% nei tempi di produzione dell’HTML, ma quanto si sono allungati i tempi di produzione dei wireframe?

    Dal mio punto di vista il wireframe deve essere qualcosa che deve essere possibile buttare via ad un costo davvero infinitesimale (il più basso possibile, comunque) e quindi ritengo molto più importante la facilità di stesura, modifica e cancellazione (mentale) del wireframe rispetto ad un guadagno nella stesura e/o fedeltà dell’html.

    Per mia esperienza, una tavola in Omnigraffle sono in grado di produrla ad alto livello (zoning), da zero, in una decina di minuti in full immersion, mentre una pagina intera costruita in dettaglio impiega da 30 min a 1.5h in rapporto alla sua complessità. Per un HTML corrispondente credo che il tempo si moltiplichi come minimo x3 anche usando l’uso di un framework.

    Quindi: ritenete che abbia così senso vincolare così tanto la stesura di wireframe, a maggior ragione in un contesto agile, dove la velocità di modifica è fondamentale sia da un punto di vista tecnico che da un punto di vista mentale?


  • Jacopo Romei
    Posted on

    Jacopo Romei Jacopo Romei

    Author

    Interessantissimo e appropriatissimo il punto di Davide.
    Con un certo agnosticismo (provvisorio!) attendo curioso la risposta di Alberto.


  • Matteo Balocco
    Posted on

    Matteo Balocco Matteo Balocco

    Author

    Non so se risponde alla domanda di Davide ma io lavoro con carta e penna e poi metto giù un prototipo con 960gs +jquery.
    Il prototipo mi serve poi per: 1) comunicare le scelte con il cliente 2) rendere comprensibile la ux agli sviluppatori (client e serverside) 3) testare con gli utenti.
    Il tempo che ci metto in più è ben speso e difficilmente riuscirei ad avere lo stesso rendimento con omnigraffle e/o balsamiq… anche perchè – nonostante i prototipi vengano buttati via – le interazioni utente al 90% si basano sulle stesse librerie js che saranno poi usate in produzione.
    Ciò non toglie che esistono progetti per i quali un omnigraffle è più che sufficiente a risolvere ogni problema di comunicazione tra i soggeti coinvolti.


  • Alberto
    Posted on

    Alberto Alberto

    Author

    Maurizio: noi abbiamo utilizzato blueprint e 960gs, ma ne abbiamo testati altri, ovviamente. l’idea è di fissare la griglia che si decide di usare e impostarla come layer su omnigraffle o indesign o whatever, durante il lavoro sui wf.

    Davide: in molte realtà, dove bisogna “cercare una mediazione” sui wf prima di prototipare e ancor prima di sviluppare, i wireframe sono lo strumento migliore. è un deliverable a perdere, che però per me è diventato importante in un sacco di progetti, specie di classe enterprise, proprio per la versatilità e l’economicità di cambiamento.

    in generale è sempre un problema di tempi di cambiamento. sarò palloso, ma continuo a sostenere che produrre wireframe PRIMA di prototipare ha ancora molto senso per molte realtà.

    senza contare che una volta iniziata la prototipazione, ci sono delle costraint (sia fisiche, che di “resistenza al cambiamento”) che impediscono di “deviare troppo” e di pensare veramente out of the box.

    per questo, oltre ai wireframe io ho proposto pure un passo indietro: quando lavoriamo carta e penna dobbiamo investire più energie in design concept e esplorazione. perché dal momento in cui inizi a prototipare, salgono i costi (in termini di tempo per ogni cambiamento)…


  • Davide ‘Folletto’ Casali
    Posted on

    Davide ‘Folletto’ Casali Davide ‘Folletto’ Casali

    Author

    A livello di prototipazione io uso comunque Omnigraffle, facendo in rapporto alle necessità un export su PDF (che mantiene le aree clickabili) o HTML (clickabile egualmente).
    Sto provando Azure beta e sembra un ottimo tool con una serie di workflow integrati, anche se pare più limitato in quanto a flessibilità: ottimo per il web, ma quando devi fare cose un po’ limite o prototipare progetti non necessariamente web diventa più complesso.

    In HTML passo solo quando la struttura è congelata. A questo punto la fase può essere ancora gestita in design (se si pensa di fare ulteriori iterazioni o momenti di test), oppure essere già passata agli sviluppatori (se si pensa di passare in un primo rilascio operativo prima).

    Per certi versi è come avere un processo completo di questo genere:
    carta -> graffle -> prototipo -> implementazione

    Dove tu mi sembra preferisca:
    carta -> prototipo -> implementazione

    Mentre io tendo a preferire:
    carta -> graffle -> implementazione

    Anche se, senza dubbio, dipende dal genere di progetto: meno ho un dialogo diretto con il team di implementazione, più tendo a fare il prototipo html, eventuali pagine master e raffinare le specifiche.

    (ho semplificato tagliando la parte di layout grafico, architettura etc, ma è giusto al fine di spiearsi senza troppo overload)


  • Cristiano Rastelli
    Posted on

    Cristiano Rastelli Cristiano Rastelli

    Author

    Questa mia solo per dire: interessantissimo thread!


  • Alberto
    Posted on

    Alberto Alberto

    Author

    Davide: no, in realtà noi lavoriamo con il processo classico, dove il prototipo (intendo: html/css/js e non server side) a volte lo facciamo noi, a volte invece un partner.

    anch’io uso un sacco le mappe cliccabili o il pdf, ma ormai stiamo andando verso prototipi html/css/js perché sono più “vicini alla realtà” come direbbe matteo. 😉


  • Davide ‘Folletto’ Casali
    Posted on

    Davide ‘Folletto’ Casali Davide ‘Folletto’ Casali

    Author

    Ok, mi esprimo meglio: tu dici “ormai stiamo andando verso”, mentre io ho al momento una posizione più “non sto andando verso”.

    Sfumature, probabilmente. 🙂

    Nota a margine: trovo interessante la tua scelta terminologica di “processo classico”. Potresti elaborare cosa intendi per “processo classico”? 🙂


  • Alberto
    Posted on

    Alberto Alberto

    Author

    davide: posizione accettabile, è interessante sapere come lavoriamo (sfumature, ma alla fine sono il succo del nostro lavoro…)

    ho usato il termine “processo classico” per errore. mi riferivo a quello che tu hai chiamato “processo completo”.

    ad ogni modo il confine tra wireframe e prototipo è veramente labile e spesso facciamo solo wf, a volte ha invece più senso realizzare subito un prototipo.


  • Marco Poli
    Posted on

    Marco Poli Marco Poli

    Author

    Volevo fare un passo indietro, tornando alla misurazione della UX.

    Anche secondo me l’analisi qualitativa è spesso “sacrificata” in favore di quella quantitativa (forse più facilmente accessibile), ma le reputo necessarie entrambe. Hanno funzioni diverse. La quantità mi dà le basi per fare ipotesi, ma di sicuro se la domanda a cui devo rispondere in termini di UX è “perché?” i numeri non bastano più;

    Penso che la UX, che per me è un prodotto dell’interazione (e quindi soggettiva), non possa essere misurata in termini numerici.

    D’altra parte se investiamo (e chiediamo) di investire in UX in qualche modo ci aspettiamo che produca qualcosa. Non è possibile ipotizzare un risultato e attrezzarsi per misurarlo?


  • Coach outlet factory
    Posted on

    Coach outlet factory Coach outlet factory

    Author

    Hi, I just wanted to tell you, you’re wrong. Your point doesn’t make any sense.