L’usabilità sociale, in base alla definizione di Gianandrea, “è un attributo qualitativo che definisce quanto facile è realizzare interazioni social all’interno di una specifica interfaccia uomo-macchina-uomo“.

Puoi scaricare la checklist (pdf) e utilizzarla a piacimento per verificare l’usabilità sociale della tua piattaforma social.

In generale, sul tema ho alcune idee che spero di approfondire il 5 maggio durante il mio workshop a Better Software.

La prima idea è che non sono sicuro esista qualcosa che possiamo definire usabilità sociale come “attributo intrinseco” di un’applicazione web (in realtà Gianandrea la definisce “attributo qualitativo”, per cui non so se abbia un’idea simile alla mia, non ci siamo mai confrontati veramente).

La seconda idea nasce da una duplice osservazione: non è detto che un’applicazione sociale debba avere tutti gli attributi definiti nella checklist, ma soprattutto all’inizio bisogna scegliere bene quali avere e quali non avere.

Il design di un’applicazione prevede che si facciano delle scelte sulle funzionalità che potranno avere gli utenti. La strategia di design -lo dico da tempo- per me è prima di tutto scegliere cosa non fare.

Quindi, ad esempio, un social network ha tutto il diritto di non avere messaggi diretti tra gli utenti, ma solo i messaggi pubblici, se la sua natura non prevede quel tipo di interazione.

L’ultima idea è che ho sempre avuto difficoltà a lavorare con le checklist. Ci ho provato molte volte, anche perché di checklist sull’usabilità ce ne sono un sacco, ma preferisco di gran lunga una valutazione basata sul cognitive walkthrough.

Detto questo, stampo e incollo al muro la checklist, perché a ben guardare credo sia utile per il nostro lavoro. Se non altro a offrire spunti e idee, oltre a dare chiarezza nel progettare un’applicazione social.

Livia si concentra nell’ordine in cui investigare gli utenti e le statistiche:

It’s inneficient to start digging deeper to answer the WHY questions if you don’t have a baseline of WHATs identified.

È l’approccio che si usa comunemente, aggiungerei solo che andrebbe fatto ciclicamente: analizzare un po’ le stastistiche e poi investigare gli utenti, poi tornare a guardare le statistiche e fare altre ricerche con gli utenti. E così via.

Certo, tra i commenti al post, appare trafelato “un certo” Jared Spool che inchioda tutti con un’affermazione:

I’m not sure that you can separate the WHATs and the WHYs. I think good methodology is both.

Il punto di Jared è che il COSA (per esempio cosa misurare) spesso dipende molto dal PERCHÈ, quindi vanno semplicemente analizzati assieme.

Da questo si deduce che:

• durante la fase di ricerca sugli utenti bisogna fare anche analisi delle statistiche (e fin qui c’eravamo)
• dentro i team di design c’è sempre più bisogno di esperti di web analytics (!).

È un tema a me caro e ne ho parlato diverse volte qui sul blog:

• Web analytics e user experience
• Statistiche web e utenti: quando i numeri non bastano
• Numeri e persone: verso il design strategico.

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.

La cosa era passata un po’ in sordina, ma il vostro ha continuato a tenere monitorata la discussione, perché non è mica un tema da poco e in parte converge con la mia idea di rendere autonomi i clienti attraverso il lavoro di consulenza che facciamo.

Oggi Jared ritorna sul tema alla luce delle discussioni e ragiona su cosa succede quando hai finito il lavoro:

Is giving in to the clients’ desire to receive a list of solid recommendations the best for the clients?

[...]

When we finish our engagement with our clients, they’ve learned how to do the work themselves. They can continue researching and enhancing their designs, using the techniques and tricks we’ve taught them. We’ve done our job and they’re happy continuing on their own.

When Nick and the Catalyst team have delivered their recommendations, their client goes off and makes changes. The question I have, however, is this: are they left in a situation where the only way they can make any further changes and enhancements is to call Nick’s team back?

Unfortunately, many projects aren’t like Chris’s HBO site. They need to evolve as the business, the technology, and the customers mature. They need new features, new enhancements, and new ways of thinking about the problems they’re solving.

Are we leaving our clients with the best possible experience? Are we considering that when we first pitch the project and its deliverables?

Per me il discorso è chiaro e l’ho scritto anche nel mio post. Pensare di “formare” il cliente e renderlo autonomo aumenta la qualità del lavoro e rinforza l’esperienza che rilasciamo al cliente.

C’è anche un altro aspetto: lavorare in questo modo cambia il “deliverable” del lavoro, che non è più solo il “deliverable fisico” (report, wirefreme, prototipo, mockup, etc), ma soprattutto il metodo con cui si raggiunge il risultato.

Inoltre, Jared aggiunge, nel primo articolo:

What our preliminary research has found is a typical recommendation looks something like this: “Users had trouble seeing the field labels. I recommend you put the label on the top of each field, instead of on the left.”

However, some teams are using a different approach: “We’re seeing that our users have trouble with the field labels. We’d like to try an experiment and see if moving the labels to the top of each field makes an improvement.”

It’s a subtle difference. And it was the approach we saw most in use amongst those UX professionals who had a solid track record of consistently improving their designs. These professionals told us they refuse to make recommendations, but love to experiment.

Insomma, lavorare sul design significa soprattutto lavorare sul processo (incrementale, misurabile, etc) e aiutare i clienti ad avere un approccio giusto verso i cambiamenti.

E alla fine la consulenza di design rilascia knowhow prima che deliverable. La differenza tra quelli bravi e la classica “web design agency” è tutta qua.

(certo, chissà cosa ne pensano “dall’altra parte della barricata”…)

E quindi sopportami un pochino, che magari a volte mi escono delle vere perle (e ti ricordi quella volta di Troncon? che tempi, quante ne abbiamo viste eh? va beh).

Insomma, sono ricominciate le discussioni sull’italia del rugby e come ogni anno mi ritrovo in mezzo a quelli che:

• prima della partita: “potremo anche vincere, sempre che…” (aggiungere motivazione tecnica a scelta, o a caso).
• dopo la partita: “non abbiamo giocato male, certo abbiamo perso, però se solo…” (aggiungere motivazione tecnica a scelta o a caso)

Ora, anch’io prendo spesso queste posizioni, ma mi sarei anche rotto.

La verità è che l’italia potrebbe vincere domenica al flaminio, se lo volesse veramente.

Sia chiaro, domenica gli albioni ci fanno a pezzi. Però se uno lo volesse davvero…

Ci sono cose impossibili che molti hanno fatto, ma non è successo per caso: si sono impegnati oltre l’immaginabile (vedi contributo audiovisivo qui sotto).

Ecco, in generale, in Italia c’è invece l’idea che le cose succedono per caso, per fortuna o per amicizia (o una combinazione delle 3).

La verità è che se vuoi ottenere qualcosa, ti devi impegnare infinitamente tanto, per anni forse, e non smettere mai di crederci.

Poi, se uno ci pensa, tra trattenere il fiato per 17 minuti e battere l’inghilterra: qual’è la cosa più difficile da fare?

A me battere gli inglesi non sembra così impossibile.

D’altronde un mio professore all’università diceva: “L’impossibile non esiste, necessita solo un po’ più di tempo”.

Quindi per tornare in tema: se io fossi l’allenatore dell’italia farei le solite scelte a caso, ma poi farei vedere questo video a tutti, un’ora prima della partita. E poi gli chiederei: adesso cosa siete disposti a fare per vincere?

UPDATE: aggiungo alcuni stralci dell’intervista, per appuntarmeli e perché sono “highly inspirational”.

Sulla semplicità e priorità dei task:

Ours goals were to make the experience simpler, smarter, and cleaner. We removed many things from the default view that weren’t critical to watching videos and finding more videos to watch.
[...]
For viewers, the site is first and foremost about watching videos and finding great videos to watch. So our focus is to make those experiences the best they can be. In order to do that, we knew we needed to “unlaunch” some things to focus attention back onto what matters. We analyzed the usage of each UI element and feature, and were pretty rigorous about removing infrequently used elements from the default view.

Sulla tecnica di codesign utilizzata che guida le scelte di design, assieme ai dati (analitics, clickstreams, heatmaps, etc):

We used a participatory design technique called FIDO (Freehand Interactive Design Online); it’s kind of like refrigerator poetry for design. You provide a magnetic board to the study participant, and you ask him or her to design their ideal video watching interface by choosing just the right elements and functionality from a collection of magnets.
[...]
The most important finding was the distinct difference between what someone who watches videos wants versus the needs of someone who uploads and curates videos. (vedi foto)
These findings allowed us to discuss what was critical to the page and what was of secondary importance. We combined the data with other studies like heat maps of clicks on the page as well as session analysis to drive some tough discussions about de-emphasizing and un-launching things. This is hard, because every element is the result of some team’s hard work. But we now had data to make the right decisions.

Sulle metriche e gli effetti del redesign:

There are a few things we are watching closely. Obviously the time spent on site and how often they visit are very important metrics. We are looking to extend sessions by exposing people to a more diverse set of videos to watch. And from our UI clean up work, over time, we’ll see an increase of usage of our sharing and community features, as people take a fresh look at the options and discover things of interest to them.

Lo sottolineo, perché è importante: la semplificazione ha aumentato la scoperta delle nuove opzioni e l’utilizzo da parte degli utenti. Semplificare aiuta a favorire e intensificare le azioni degli utenti.

Sul processo interno e integrazione con i team di sviluppo:

One of the changes we’ve made over the past year is the role of user experience research. It was hard for the team to run traditional lab studies and share the findings quickly enough to impact the work before it shipped. So we shifted our time towards upfront, strategic research to understand our users and better inform the business, and instead of extended lab studies, we focus on lighter, quicker validation techniques. As a result, research is in a much more influential role. UX designers are working more strategically as well, driving aspects of the product vision, while concurrently keeping pace with the short release cycles. It’s challenging to balance the flows, but the team is doing a great job.
[...]
sometimes the product gets developed in silos, rather than holistically. So in UX, we’re moving to organize the projects around similar experiences instead of around our organizational structure. For example, historically the advertising department would focus on ads across the entire site. But we knew that the ways the ads look and behave in relation to the context in which they are placed is very important. So the same designers working on the video watch page and player design are driving the UX for the ads design. The result will be a cleaner, more intuitive, and more effective user experience.
[...]
Working directly and effectively with engineers is critical to the success of any designer at YouTube or Google. We form small interdisciplinary teams that often sit together and are focused on solving specific problems. Our focus on deep collaboration on product strategy up front bonds the teams; when you have shared goals and a shared vision, you tend to be better partners and better listeners. In UX, we are always gathering feedback and changing the ways that we work with other departments.

Sulla leadership e il management:

It’s very difficult to do great work without support from leadership. At YouTube, we have an executive team that cares deeply about the user experience and wants to do the right thing and to always be improving. I and members of my team meet regularly with our executives and share our work on an ongoing basis; their level of engagement is really remarkable. That focus gives me a lot of confidence to speak authoritatively. It gives me the ability to have high expectations of what the team must deliver. And it also gives us the inspiration to craft a longer term vision for where we are headed. This vision must be formed and shared as a team, since each team member will need to go out and share and apply that vision across every part of our organization and the site experience.

Posterous is an engineered product, while Tumblr is a designed product.

La cosa è interessante, anche perché di recente ho citato Posterous nella mia presentazione al Digital User Experience Festival. Secondo me Posterous ha reso efficacemente l’idea che “non serve iscriversi, basta una mail”.

Però significa puntare tutto su una funzionalità, anzichè sulla user experience:

In fact, that sign-up-via-email feature: engineering feature. [...] Very long signups can discourage users, but by God, pulling up their email client, finding a picture or a video to post, attaching it, and emailing it to post@posterous.com (or is it new@posterous.com? posterous@posterous.com?), that’s easier! It’s exactly the kind of thing where an engineer thinks “Oh, nobody does that, I’ll do that, that’ll be cool!” but in real life it’s useless. I mean, posting by email is a nice feature. But it’s not a killer feature.

E ancora:

Meanwhile Posterous is typical of the Silicon Valley engineering mindset where everything is measured, ranked, weighted. It’s like Google. And having terrible design like Google is great if you have a technology edge. But if you’re in a market where what matters is design edge, that’s not enough. There needs to be great design, by which I don’t mean looks (though they’re important), but how it works for the end user. [...] for consumer web apps today, design matters more than technology.

Tra Posterous e Tumblr io ho scelto da tempo immemore Tumblr e l’ho anche definita una delle interfacce più semplici che abbia mai utilizzato. Tempo fa ho provato anche Posterous, ma poi non ho capito bene come funzionava e ho lasciato stare.

Ecco, oggi ho la conferma del perché: design matters more than technology.

ps: con questo post mi inserisco sulla diatriba nata dall’articolo di Norman, che ha dichiarato che nell’innovazione è più importante la tecnologia rispetto ai bisogni dell’utente. Secondo me, Don sto giro ha preso un granchio.

Il conto ve lo faccio io: 11 ricerche in 50 secondi, una ogni 4,5 secondi.

Questa pubblicità mette assieme un’idea di brand experience (ti fa trovare le cose che cerchi e a cui tieni) con la velocità di Google (vantaggio competitivo verso gli altri: siamo i più veloci -anche perché tra un po’ Bing sarà superiore in termini di pertinenza dei risultati).

Come dire che Google non gioca a dadi.

Premetto che la cosa è interessante in se: alla Apple sanno bene che l’esperienza di una app viene spesso associata al prodotto e quindi avere pessime app significa anche avere un minimo di ricaduta sul brand.

Per cui da tempo hanno rilasciato una serie di linee guida per il design delle esperienze sulle app di iPhone e ora anche di iPad.

Tra i vari punti elencati, alcuni mi hanno colpito dal punto di vista dell’interaction design e architettura dell’informazione:

• Enhance Interactivity (Don’t Just Add Features): significa che per i nuovi device mobili, bisogna pensare ad arricchire l’interazione, anzichè aumentare il numero di features (less is more, again, ever)
• Flatten Your Information Hierarchy: gli spazi informativi si appiattiscono, l’accesso alle funzionalità è più diretto, meno “profondo” (in senso fisico: pensate all’alberatura dei “vecchi siti”)
• Start Instantly: la velocità di inizio è fondamentale (ne ho già parlato: la velocità è sempre più importante per l’interaction design)

C’è da immaginarsi che tra i parametri con cui Apple valuta l’approvazione delle app (e magari anche la loro “importanza di promozione” all’interno dello store) ci siano anche questi preziosi suggerimenti.

Food for thoughts.

Nella presentazione ho illustrato 4 pattern della progettazione di una web user experience che ritengo importanti e che sono emersi negli ultimi anni. Ne ho altri nel pensatoio, prima o poi metterò tutto assieme…

Durante il panel si è parlato di user experience, interazioni digitali e aziende in Italia: quest’ultimo punto è stato piuttosto dibattuto, come era prevedibile.

Era la prima volta che mi trovavo in un panel così “crossmediale” agli ambienti digitali e mi sono divertito parecchio: mi piacerebbe poterlo rifare altre volte.