Il mobile-first è una filosofia di progettazione sorta attorno al 2009 secondo la quale per accomodare i siti alla fruizione da molti canali (desktop, tablet, smartphone…), e in generale con molte dimensioni dello schermo diverse (qui ne ho parlato tempo fa), è bene partire progettando il sito per il mobile, cioè la situazione con più vincoli, e poi farne una versione arricchita per i dispositivi più grandi.

Ma è efficace? Alcuni dati sembrano suggerire qualche dubbio in merito.

Questione di numeri, alla fine

La ragione principale per dedicare attenzione progettuale fin dall’inizio ai dispositivi mobili sta naturalmente nella loro crescente diffusione, con una quota di visita sempre crescente nei confronti del desktop. Questo vecchio grafico ci mostra che abbiamo già superato il punto di svolta.

Dal 2014 gli utenti globali provenienti da mobile superano quelli provenienti da desktop. Ma questo non rende il desktop meno importante, come vedremo.

Ma l’esigenza di un miglior metodo progettuale per i siti mobili deriva anche dall’osservazione che nei test di usabilità sugli smartphone e nelle statistiche d’uso degli accessi da mobile le persone tendono:

• a trovare meno facilmente le informazioni,
• a completare un minor numeri di transazioni,
• ad avere maggiori abbandoni e
• a rimanere per minor tempo sulle pagine.

In altre parole, tutti i parametri di comportamento utente sono peggiori sul mobile che sul desktop.

Un obiettivo importante di una logica mobile-first sarebbe quindi quello di alzare questi parametri, avvicinandoli a quelli del destkop.

L’efficacia (o l’assenza di-) del mobile-first

Per capire se ci stiamo riuscendo dovremmo avere dei dati di efficacia mobile vs desktop, prima e dopo l’adozione di questo approccio. Per capire se, cioè, i siti mobile-first funzionano meglio, per l’utente, sul mobile, senza nel frattempo perdere performance lato utente sul desktop.

Le prime risultanze non sembrano favorevoli.

Nel 2009 la differenza era circa del 20%

I dati di Nielsen sui test di usabilità su mobile, tanto per avere un punto di riferimento, risalenti al 2009, prima cioè che la strategia si diffondesse, dicono alcune cose:

• Che il tasso di successo per i siti mobili era sensibilmente più basso dei loro corrispondenti usati da desktop (circa 20 punti percentuali di differenza)
• Che siti ottimizzati, costruiti per il mobile avevano tassi di successo più alti di circa 10 punti rispetto ai siti non ottimizzati per mobile, quando usati da mobile.

Questi risultati sembravano confermare che ci fosse bisogno di siti pensati per il mobile. E che solo così avremmo potuto alzare il tasso di successo e gli altri parametri.

Dati parziali recenti su siti costruiti con pattern mobile-first mostrano una differenza del 17%

Da due test di usabilità recenti che ho avuto modo di coordinare e svolti su siti realizzati secondo logica mobile-first e testati sia su mobile che su desktop (per ciascun sito 8 utenti mobile e 8 utenti desktop, per un totale di 32 partecipanti testati), risulta che il tasso di efficacia sullo stesso sito è di circa 17 punti percentuali più basso se viene fruito da mobile.

Avete capito bene: erano 20 nei dati di Nielsen del 2009, sono 17 nei primi test attuali.

Possiamo leggerlo come un miglioramento, ma siccome non abbiamo campioni elevati noi, e non è dato sapere il numero del campione di Nielsen, il risultato potrebbe collocarsi all’interno del margine d’errore, e potrebbe non esserci alcuna differenza reale fra i due dati!

Ma se c’è, è evidentemente molto piccola. Tutto questo sette anni dopo e su siti appena ridisegnati!

Ad aggiungere alltri dubbi ci sono le statistiche. Su pressoché ogni sito mobile-first di cui ho modo di vedere le statistiche, le visite da mobile hanno ancora parametri più bassi delle visite da desktop, esattamente come prima dell’approccio mobile-first.

In altre parole: alcuni dati (parziali e limitati quanto vogliamo, e urge senz’altro raccoglierne degli altri) ci suggeriscono che non sembra funzionare. O, se davvero c’è un miglioramento, è ridicolmente esiguo.

Perché succede?

Non fidatevi, insisto: valutate le statistiche dei vostri siti, guardate il tempo in pagina, le pagine viste per visita, i tassi di conversione e ogni altro parametro che risulti utile al vostro modello di business, per visite da mobile e da destkop. Comparateli con quelli che avevate prima dell’adozione di una logica mobile-first.

Se anche nel vostro caso non si vedono grandi differenze, e i dati da mobile rimangono più bassi, abbiamo un problema.

Le ragioni di questo problema possono essere diverse.

1. Potrebbe essere che il mobile-first lo stiamo facendo male. Non è una ipotesi da escludere. Infatti il mobile-first si è diffuso più come una moda con i temi pronti per i blog e i cms, da installare e utilizzare, che come esito di un vero processo di progettazione. Quindi, temi che devono essere soprattutto belli sulla vetrina del negozio online che vende il tema stesso, applicati con minime personalizzazioni su blog o siti portfolio o vetrina, hanno influenzato i pattern di interazione usati anche negli altri siti. Voci di menu ridotte o scomparse, colonna unica o quasi, spazi larghi e vuoti, riduzione della densità informativa: questo è ciò che del mobile-first si sta vedendo soprattutto in giro. Anche in recenti e costosi redesign di nostri gruppi bancari: il che testimonia come minimo il rischio che il mobille-first sia stato usato come una moda, che i designer lo interpretino come un “mobile-only”, ovvero un tema mobile che su desktop ingrandisca semplicemente testi, bottoni e spazi vuoti, e che quindi venga meno il senso profondo di una progettazione per scenari.
2. Oppure potrebbe essere che il mobile-first, come logica, filosofia e strategia non funzioni.

A prevalere è il mix di fruizione, perciò le grandi aziende non adottano il mobile-first

I dati provenienti da ComScore, azienda statunitense specializzata in analytics, suggeriscono proprio questo: forse il mobile-first è sbagliato!

Quello che si sta vedendo dai dati generali di fruizione, è proprio che, mentre gli utenti mobili sono più di quelli desktop, la maggior parte delle transazioni avviene comunque su desktop, anche perché – dato trascurato – la maggior parte degli utenti visitano lo stesso sito da diverse piattaforme! Sono i cosiddetti “multi-piattaforma”, che come si vede da questo grafico, sono saldamente la maggioranza degli utenti che visitano i siti web:

Dati ComScore sulla prevalenza di visite multipiattaforma – ovvero lo stesso utente che visita il sito sia da mobile che da tablet o desktop – richiedendo così un design coordinato ma adattato e ottimizzato per entrambe le piattaforme

Questo, unito al fatto che le transazioni sono comunque maggiori sui siti “grandi” (tablet o desktop) fa sì che:

1. Il sito desktop è ancora più importante per generare traffico utile e remunerativo, quindi l’attenzione progettuale su questa versione del sito deve essere massima e non può essere solo un “adattamento” o un “allargamento” della versione mobile
2. Entrambe le versioni, desktop e mobile, devono essere coordinate, cioé devono fornire esperienze simili; e, tenendo conto delle differenze fra le piattaforme, potrebbero perciò dover essere entrambe pesantemente ottimizzate.

I grandi player adottano un approccio misto

Questo fa sì che i grandi player – che ne hanno la possibilità economica – evitino un approccio mobile-first basato su un codice unico per tutti i dispositivi, per orientarsi verso un approccio misto, che mescola tecniche responsive con tecniche adaptive.

Per chi non avesse dimestichezza con questi termini, in estrema sintesi:

1. le tecniche di responsive webdesign prevedono che un codice (HTML, CSS e JS) unico venga fornito a tutti i dispositivi, e che questi, sfruttando i breakopoint dei fogli di stile, riadattino la disposizione e la visibilità dei contenuti; fra gli svantaggi c’è che il contenuto è lo stesso per tutti i dispositivi e che viene caricato anche codice non necessario; è inoltre limitata la possibilità di riprogettazione per diverse piattaforme
2. Le tecniche di adaptive webdesign prevedono che il server riconosca il tipo di dispositivo usato dall’utente e invii versioni diverse dello stesso codice HTML, CSS, JS (e anche delle immagini e dei video) a seconda delle potenzialità del dispositivo; senza però usare URL differenti. Il vantaggio è che ogni dispositivo riceve una versione ottimizzata e progettata quasi ad hoc della pagina, con tempi di caricamento minori: solo ciò che serve a quel dispositivo viene caricato; fra gli svantaggi la difficoltà a mantenere versioni diverse, potenziali problemi di SEO e possibili errori nel riconoscimento della pagina; ogni contenuto deve poi poter essere adattato ai diversi dispositivi, il che nel tempo significa un mantenimento del sito più oneroso, non solo in fase di progettazione.

Le tecniche responsive sono quelle più usate in un approccio mobile-first, ma non sembrano funzionare come atteso, almeno per gli obiettivi di ridurre il gap fra versione desktop e versione mobile. Come dicevamo, molte aziende, specialmente grosse, tendono ad adottare una filosofia mista.

RESS, il costoso meglio dei due mondi

Tale filosofia è a volte chiamata (sempre dal solito Luke Wroblewski) anche RESS, ovvero REsponsive Web Design with Server Side Components. Usando tecniche molto più evolute e raffinate delle vecchissime tecniche di “browser sniffing” (un modo per riconoscere quale versione di browser l’utente stesse usando e servire una versione adattata del codice HTML), si riconoscono con elevato grado di precisione piattaforme, dimensioni del display, sistema operativo, velocità di connessione, oltre che versione del browser del client.

Queste informazioni vengono passate al server prima che venga servito l’HTML. A quel punto viene decisa quale versione di HTML, CSS, JS e immagini servire, non adattandole però a ogni dispositivo, ma pescandole da un bacino limitato di versioni, ottimizzate per “famiglie di dispositivi”.

Ad esempio, sugli smartphone viene servita una versione diversa da tablet e desktop, ma diversa anche dai vecchi telefonini con accesso a internet. Una versione che, a quel punto, è anche responsive: nel senso che può adattarsi e rispondere a una certa gamma di dimensioni del display, di densità, ecc, ma senza dover caricare tutti gli asset della pagina che si caricano su connessioni stabili e dispositivi più grandi e potenti.

Ogni versione servita del sito è dunque responsive, ma con un range minore di adattamenti, e una qualità più alta di ottimizzazione per “famiglie” di dispositivi. Questo elimina la necessità di servire lo stesso codice a tutti, e consente di progettare meglio per dispositivi differenti, aumentando ovviamente i costi di progettazione e gestione.

E per enti e aziende che non hanno le risorse per mantenere versioni diverse e ugualmente ottimizzate del sito?

Proposta: partire dalla progettazione, non dalle tecniche

Forse non tutti possono adottare un approccio RESS. Ma è anche un errore pensare che il problema sia solo tecnologico. La tecnologia non è neutra, quindi adottare un approccio responsive, adaptive o RESS pone certamente dei vincoli, ma bisogna ricordare che sopra a ogni approccio c’è la progettazione.

Qualunque filosofia riteniate di adottare, bisogna ricordare che ogni sito va prima di tutto correttamente progettato. Vanno cioè evitate le soluzioni stereotipate, i temi pronti, i pattern non verificati, magari derivanti da siti vetrina.

Vanno analizzati i bisogni degli utenti, armonizzandoli con il modello di business e una strategia di lungo termine. Va trovato il senso migliore per le versioni desktop (che rimangono ancora le più efficaci) e per quelle mobile, senza pretendere che servano allo stesso scopo. Accettando le differenze fra le piattaforme e i loro usi. E scegliendo soluzioni di interazione in base ai principi che rispettano o violano, piuttosto che semplicemente e pigramente perché sono “pattern consolidati”.

Questo è più difficile, perché apre a esiti più incerti e processi più lunghi.

Tuttavia, tutte le scorciatoie che io ho visto intraprendere negli anni per evitare di progettare sono finite inevitabilmente dove era logico finissero: in un buco nell’acqua.

Se non vogliamo che il nostro mondo web sia un luogo che porta a crescita economica, come i report europei a sostegno dell’agenda digitale continuano a predicare, forse dobbiamo cambiare approccio e passare dalle linee guida di design alle linee guida del processo di progettazione. E quindi fornire indicazioni su:

• Come fare analisi,
• Come capire i bisogni,
• Come organizzare i contenuti,
• Come disegnare le pagine nei diversi dispositivi/dimensioni in cui verranno fruiti,
• Come testare costantemente le ipotesi di progetto,
• Come monitorare costantemente i risultati.
• e così via…

Conclusioni

Ricapitolando:

• Il mobile ha dati di utilizzo anche superiori al desktop, ma molti utenti usano entrambe le piattaforme, e completano più probabilmente transazioni complese sui siti desktop
• Di conseguenza, un approccio mobile è necessario, ma il mobile-first, come realizzato finora (usando prevalentemente il responsive webdesign, temi pronti, e adattamento di versioni mobile anche sul desktop) non sembra garantire tassi di efficacia simili fra mobile e desktop
• Quindi è necessario progettare la miglior esperienza su tutte le piattaforme principali; il desktop in particolare non può essere trascurato perché rimarrà ancora a lungo la piattaforma sulla quale la maggior parte delle transazioni verranno compiute
• A seconda del budget, mobile, desktop e tablet vanno attivamente considerate piattaforme in cui le persone compiono attività differenti in modi differenti, e vanno inserite nel processo progettuale considerandole touchpoint (ovvero punti di incontro fra utilizzatore e servizio offerto) diversi, come in effetti sono.