L’unico modo, per quanto approssimativo, di eseguire qualche stima è analizzare i posizionamenti dei competitors pesandoli in base all’importanza delle parola chiave.

In questo post provo a fornire qualche spunto utile per svolgere un’analisi competitiva SEO, concludendo anche con un cadeaux: un template Excel per la gestione e presentazione dei dati.

1. Identifica il tuo target di riferimento attraverso un campione di parole chiave da analizzare

Per prima cosa è necessario identificare un campione di parole chiave da monitorare:

• la keyword analysis dovrebbe comprendere un numero abbastanza esteso di parole chiave (almeno 40) su cui si desidera essere visibile e su cui i competitor sono particolarmente agguerriti;
• le parole chiave dovrebbero avere un numero di ricerche mensili soddisfacente (almeno >50), il valore è facilmente ottenibile con l‘AdWords keyword tool (ricerche mensili globali su corrispondenza esatta);
• le parole chiave dovrebbero essere in target: meglio evitare di scegliere parole chiave troppo generiche e non “raggiungibili” potrebbero falsare i risultati dell’analisi.

3. Utilizza uno strumento per rilevare i posizionamenti

Per poter ottenere dei dati comparati dove sono presenti anche i competitors, il modo più semplice per ottenere dei dati è quello di valutare i posizionamenti sul sito web.

Ci sono diversi strumenti per ottenere i dati sui posizionamenti per le parole chiave che hai selezionato: puoi fare una ricerca manuale (tanti auguri), oppure utilizzare uno dei molti software presenti in circolazione.

Qui ci sono diverse soluzioni possibili, le principali possibili offerte dal mercato in tal senso sono:

• WebCEO (più lento ma consigliato nel caso di monitoraggi continuativi, ma non con troppe parole chiave);
• Advanced Web Ranking (consigliato per analisi spot);
• Rank Tracker (valida alternativa ad AWR);

4. Il posizionamento medio non è sufficiente: pesiamo le keyword

• i risultati delle ricerche sono sempre più personalizzati in base alla locazione geografica,
• i dati di CTR sono fortemente influenzati dalla presenza di one-box di universal search;
• le SERP offrono spesso un numero di risultati organici diversi dai canonici 10;
• sempre più spesso nelle pagine dei risultati appaiono risultati multipli dello stesso sito;
• ecc.

Credo che però in alcune situazioni offrire dei dati di questo tipo possa essere utile per avere un’overview che, per quanto approssimativa, è sicuramente indicativa delle performance SEO di diversi siti web messi a confronto.

La giornata è stata capitanata da una personalità di spessore mondiale: il mitico Steve Krug, autore di “Don’t Make Me Think” e “Rocket Surgery Made Easy“, colui che ha sempre professato il concetto di usabilità semplice, da fare in casa, senza paranoie e senza paura di sbagliare.

 Foto scattata durante il corso da Alessandra Farabegoli, pubblicata nel suo account Twitter

1- Take it easy, don’t be afraid

La cosa che più mi ha colpito è la naturalità con la quale Steve ha parlato di usabilità, il concetto è semplice: non aver paura di coinvolgere gli utenti, in fondo un sito web è costruito per loro! E’ solo coinvolgendo gli utenti che potrai fare un lavoro su misura e offrire un’esperienza soddisfacente.

2- Sito web con un processo in costante evoluzione

Se sei coinvolto nello sviluppo di un sito web, non devi pensarlo come un monolite, come un processo con un inizio ed una fine. Un sito web è un prodotto digitale e come tutti i prodotti complessi dev’essere soggetto a migliorie che vanno andare incontro alle esigenze di chi lo usa.

3- Non essere innamorato della tua idea, mettiti in gioco

Ogni persona coinvolta in un progetto web ha le sue convinzioni: il business immagina il sito come un collage di call to action perchè il suo imperativo è vendere, lo sviluppatore pensa al sito web come un’entità complessa in grado di elaborare le richieste più impensabili, l’art director vuole un trionfo di creatività. Nessuno pensa agli utenti, ognuno pensa in base alla mansione che ha nel progetto (chiamiamola deformazione professionale ).
Il sito web, vivendo di continui compromessi, potrebbe avere dei difetti anche causati dall’imposizione di scelte errate.
Non bisogna innamorarsi delle proprie idee: metterle a test è sintomo di intelligenza e può essere fonte di ispirazione per reperire dei miglioramenti utili all’utente finale.
Vedere un utente usare il tuo sito può valere più di 1000 riunioni!

4- La costanza premia

Basta una mattina al mese: tre utenti ed un veloce debreif durante la pausa pranzo con una mail di recap che individua le tre criticità principali scaturite dagli utenti osservate.
E’ necessario schedulare le attività per un lungo periodo, sempre nello stesso giorno del mese per evitare il rischio di veder naufragare il test tra le mille urgenze che contraddistinguono la nostra vita lavorativa.
Rendere il test un appuntamento fisso, può essere un buon modo per creare una piacevole consuetudine, un momento di incontro e scambio per tutto il team.

5- L’usabilità deve costare poco

L’usabilità è una disciplina storicamente nuova, soprattutto per il mercato italiano: ci sono pochissime aziende specializzate e molto spesso hanno dei costi difficili da digerire per un’azienda che vuole iniziare.
Per avere chance di entrare negli ingranaggi dei progetti web deve costare poco: a partire dalla fase di test fino ad arrivare (se possibile) alla fase di risoluzione dei problemi.

6- Migliorare pian piano è meglio che fare redesign

Chi analizza o testa interfaccia potrebbe avere spesso l’istinto di voler “rifare tutto” per cercare la soluzione ideale scontrando molto spesso con il tema dell’infattibilità o dell’utopia.

Per rendere l’usabilità effettivamente utile bisogna ricercare piccoli fix piuttosto di un redesign completo. La ricerca di soluzioni indolori potrebbe aiutare anche la sinergia tra i vari componenti del team che lavorano su un progetto.

7. It’s all about process and culture

Iniziare a coinvolgere gli utenti ha sopratutto degli ostacoli “politici” e di relazioni: se sei un attore esterno incontrerei delle resistenze da parte di chi ha sviluppato il sito, se hai sviluppato il sito hai paura che ti venga “contestato” il tuo operato, se lo fai in-house hai paura che gli utenti dicano cose che possano dar fastidio ai manager, se stai sviluppando un nuovo servizio hai paura della riservatezza.

Insomma tanta paura: per sfatare la paura serve cultura, consapevolezza interna e la convinzione che l’utente ha sempre ragione.

8- L’usabilità deve passare dal coinvolgimento del team

La sala degli osservatori durante i test dovrebbe essere gremita come una curva da stadio: vedere gli utenti suscita sempre curiosità e interesse perchè si osserva l’obiettivo principale del nostro lavoro, vedere una persona che lo usa. Coinvolgere la persone e farle partecipare può far aprire gli occhi e abbattere i muri di resistenza delle aziende.

I problemi che l’utente incontra diventano condivisi (e non “i problemi del consulente”), si cercano soluzioni condivise e si costruisce sinergia e lavoro di squadra.

In un futuro i task potrebbero essere proposti addirittura anche dagli sviluppatori o dal business, quindi si passa da un modello accentratore dove c’è un responsabile ad un vero e proprio lavoro da task force interna.

9- Testare ti dà sempre delle belle sorprese

Ogni volta che mi è capitato di vedere un test di usabilità ho sempre avuto delle sorprese e quella sensazione/tentazione di voler spingere l’utente con il pensiero dove volevo senza riuscirci…troppo frustrante…

Per sintetizzarla con un tweet di Nicola Bonora

Usability test: entri che ti senti figo ed esci racchio

10- testare testare testare

E’ solo con la pratica e l’esperienza che si diventa grandi

Altri contenuti sull’argomento:

• lo storify di Nicola Bonora della Mentine Crew;
• il post di Roberto Fumarola sul blog di B2commerce;

Se penso ai tool classici di project management (come ad esempio Microsoft Project o AtTask) ne ho un’immagine di uno strumento davvero molto complesso con mille funzioni e grandi opportunità.

Permettono infatti di:

• definire dei progetti ai quali associare delle attività;
• schedulare attività con una definizione dei tempi assegnandone delle risorse;
• fare in modo che le persone segnino il loro impegno orario sui diversi task di progetto;
• definire delle dipendenze tra attività;
• costruire dei diagrammi di Gantt;
• fare la contabilità analitica della redditività di progetto (WOW! );
• e molto ma molto altro.

Personalmente sulla carta mi piacciono molto questi software, anche se non sono applicabili su tutti i progetti: funzionano molto bene per progetti caratterizzati da processi lineari e con iter ben consolidati con un inizio o una fine, con attività schedulabili già nelle prime fasi di progetto, dove sono impiegati diversi team di lavoro e dove l’impatto/influenza di attori esterni è medio/basso.

Lo sviluppo di un sito web complesso e strutturato è un caso di progetto con tempi abbastanza consolidati e lineari, dove strumenti di project management tradizionali possono anche funzionare bene.

Ma che cosa succede se al posto di parlare di sviluppo web si parla di promozione dei siti web? Sì insomma di web marketing…tipo SEO, SEM, DEM, ADV, CRO, ecc. (potrei andare avanti per anni gli gli acronimi )

Personalmente ho sempre diffidato molto dall’uso di questi tools: ne ho provati diversi ma non sono mai riuscito ad usarli per più di tre volte di fila, magari per incapacità del sottoscritto oppure per lo shock di aver provato ad usare Microsoft Project per gestire progetti SEO qualche anno fa … :-)

I motivi sono molti, eccone alcuni esempi:

• i progetti SEO e quelli di ADV online sono molto diversi tra loro e trovare un tool che soddisfi esigenze molto diverse tra loro è molto difficile perchè servirebbe flessibilità estrema;
• per progetti SEO o di conversion optimization un tool di project management classico è di difficile uso perchè le attività sono difficili da pianificare a priori: generalmente sono fondamentali attori esterni che raramente rispettano i tempi e dove le risorse sono assegnate da project manager di aziende o dipartimenti diversi (che hanno obiettivi e ordini di priorità diversi);
• per progetti di Direct Email Marketing non particolarmente complessi, il “costo” del setup del tool è troppo elevato e laborioso rispetto alla mole di lavoro da eseguire;
• per progetti di Online Advertising non avere una gestione amministrativa dei budget, fa in modo che il tool di project management contempi solo una piccola parte gestionale del progetto.

Inoltre c’è da dire una cosa importante molto spesso le esigenze per i progetti di web marketing sono davvero minime:

• ricordarsi le cose da fare ed il loro stato (fatto, non fatto);
• avere la loro priorità;
• essere aggiornato sugli avanzamenti delle attività;
• avere un repository dei documenti associati alle diverso cose da fare;
• scambiarsi messaggi e feedback nel team in modo ordinato;
• avere delle check-list o todo-list;
• ecc.

2. Trello, un tool di project management per il web marketing (ma non troppo)

In questi giorni però sono stato letteralmente fulminato da Trello, un simpatico tool consigliatomi dai mitici Yoox Guys Marco, Iolao che permette di gestire progetti di web marketing in modo tutto sommato efficiente  e veloce.

Il concetto è semplice: Trello è un gestore di lavagne virtuali completamente configurabile che generalmente corrispondono ad un progetto (nello screenshot in basso potete vederne un esempio di configurazione).

Ogni lavagna è composta da più liste, che possono corrispondere a gruppi di attività che possono essere organizzate in vario modo: tipo di attività, stato, ecc.

Nell’esempio sopra c’è una lavagna relativa ad un progetto SEO, dove le attività sono organizzate per stato:

• solo idee di ottimizzazione che non sono ancora diventati task da eseguire;
• i to-do che sono in corso di svolgimento nelle prossime due settimane;
• le attività pending che dipendono da attori esterni di progetto;
• delivered che contiene tutte le attività eseguite nelle due settimane correnti (e che prima erano nei todo o nei pending);

Ogni lista contiene diverse carte che generalmente corrispondono ad un’attività o ad una serie di micro-attività raggruppabili, alle quali è possibile associare diverse caratteristiche come ad esempio:

• delle etichette con colore diverso (che nell’esempio è un grado di priorità);
• una data di delivery richiesta (quando possibile)
• le risorse interessate nell’attività;
• eventuali documenti a supporto;
• commenti e scambio di informazioni;
• una check-list che può essere usata anche come lista di sotto-task;
• ecc.

3. Esperienza personale con Trello, tabella comparativa

Durante la settimana, le schede vengono aggiornate aggiungendo eventuali informazioni ai diversi task, aggiornandone lo stato o spostando le carte nelle diverse liste (ad esempio quando un task viene completato viene spostato da to-do a delivered).

Si tratta di uno strumento davvero molto semplice e alle portata di tutti: certo non si tratta di un tool di project management a completo in tutto e per tutto ma forse è proprio questo che lo rende più appetibile!

Ecco una tabella comparativa che riassume le caratteristiche dei due tipi di tools:

Caratteristica	PM tool Classico	Trello
Curva di apprendimento
Tempi di setup progetto
Flessibilità
Velocità di aggiornamento
Possibilità di assegnare risorse ai task, con deadline e grado di priorità
Aggiornamento stato task e progetto
Workspace collaborativo (documenti, chat, scambio messaggi, ecc.)
Valutazione rendimento economico di progetto
Pianificazione nel tempo (scheduling delle risorse, milestones, ecc.)
Valutazione carichi di lavoro
Costruzione di Gantt e viste grafiche avanzate sui progetti

Che esperienze avete nei tool di project management? Ne avete degli altri da suggerire? Avete mai usato Trello?

Cyrus Shepard in una recente Whiteboard su SEOMOZ ricorda che in questi ultimi giorni Matt Cutts ha rilasciato l’ennesimo editto SEO, dove rammenta che Google si sta muovendo per ridimensionare il posizionamento dei siti over ottimizzati.

per dirla con una frase…Smettila di ottimizzare, ma inizia a creare qualcosa di nuovo!

In questo scenario, guadagnare link di qualità lasciando da parte certe tecniche di link building border line è davvero uno dei temi centrali.

Nell’era della condivisione, uno degli strumenti più utili per ottenere link è quello di creare dei widget: un sito web fornisce gratuitamente  una funzionalità alla comunità del web e come “remunerazione” richiede l’inserimento di un link che punta al proprio sito.

Slideshare, ad esempio, ad ogni inserimento di una presentazione nel proprio sito propone all’utente un codice HTML contenente un link testuale verso la presentazione.

In questo post raccolgo una serie di consigli se vi accingete a prendere la strada della costruzione di un widget per generare link, con un esempio virtuoso finale.

1. Scopri come potresti essere utile e appetibile

Si tratta della fase più difficile e creativa in cui si deve capire come un’azienda o un sito possa essere utile ad altri siti, offrendo una funzionalità degna di essere ospitata altrove.

Le funzionalità offerte non devono essere per forza direttamente correlate ad un’azione di conversione, bisogna invece concentrarsi su una reale utilità per gli utenti.

Mi rendo conto che a parole possa sembrare facile, ma con un po’ di immaginazione e creatività in alcuni casi si possono raggiungere ottimi risultati.

Qualche esempio per qualche sito web:

• un comparatore di prezzi delle assicurazioni potrebbe offrire un preventivatore light che con pochi campi permette di ricevere una stima di prezzo indicativa;
• una testata giornalistica online potrebbe fornire la possibilità di includere una sidebar che include le ultime notizie su un determinato argomento;
• un e-commerce di abbigliamento potrebbe dare la possibilità agli utenti di condividere il proprio look preferito;
• un e-commerce di libri potrebbe fornire un widget con la propria libreria, oppure una lista di libri di una determinata categoria;
• un e-commerce di abbigliamento invernale potrebbe regalare agli utenti un widget per capire gli impianti sciistici aperti e la quantità di neve presente sul suolo;
• un’azienda che vende pannelli fotovoltaici potrebbe offrire uno strumento di calcolo dell’energia da un impianto.

E’ importante valutare bene come inserire i link all’interno del widget.

La prima cosa fondamentale è che il link del widget sia presente direttamente nel codice HTML del sito ospitante in modo che sia spiderizzabile e che passi link juice alla pagina di destinazione.

Oltre alla presenza del link in HTML è necessario che il testo ancorato e la pagina di destinazione siano scelti correttamente: è bene non focalizzarsi solo ed esclusivamente su un’unica pagina, ma potrebbe essere utile dosare link sia verso l’homepage del sito che alle pagine interne.

3. Evita le manomissioni

Per non vanificare il lavoro, un ulteriore consiglio è che il widget funzioni solo ed esclusivamente se il link è presente. Nel caso in cui un utente decida di eliminarlo, il widget dovrebbe cessare di funzionare.

Diciamo che l’eliminazione del link è come se l’utente rompa il patto tra le parti: niente link, niente funzionalità gratuita!

4. Scegli il modello di remunerazione

Si sa che nessuno fa niente per niente e i pixel del proprio sito sono molto importanti, quindi non è detto che il proprietario di un sito esterno sia disposto ad includere un widget esterno senza un’adeguata remunerazione.

In alcuni casi la sola funzionalità gratuita potrebbe non essere sufficiente.

Per gli e-commerce, ad esempio, se un utente inserisce il widget nel proprio sito si potrebbe addirittura utile “pagare l’utente” secondo i classici modelli di affiliazione. In questi casi il modello di remunerazione a CPA è l’ideale poichè potrebbe far guadagnare al proprietario del sito web una fee fissa o una percentuale sull’ordine effettuato.

Amazon gigante mondiale del mondo e-commerce ha scelto proprio questa strada per remunerare gli utenti che desiderano inserire il widget sul proprio sito web.

In altri casi, invece, si potrebbero regalare dei codici sconti o dei coupon.

Creare un widget di per sè potrebbe non essere sufficiente, è necessario anche spargere la voce in rete.

Per prima cosa occorre cercare quali sono i potenziali blog e siti che potrebbero essere interessati all’inclusione del widget, facendo una mappatura della rete.

Durante la mappatura della rete è importante raccogliere tutti gli indirizzi email, per poi inviare una DEM per stimolare gli utenti all’inserimento del widget.

Oltre al contatto di blogger e gestori di siti web in target, potrebbe essere utile fare una mappatura dei siti web che segnalano risorse utili, richiedendo poi la pubblicazione di un guest post dove si segnala la presenza del widget. In questo modo i lettori potrebbero essere interessati all’inserimento, sempre che sia una cosa davvero interessante.

6. Il caso de ilmeteo.net

Assieme all’amico Riccardo Mares, aka Merlinox, abbiamo trovato un caso davvero virtuoso per lo sviluppo di widget offerto da ilmeteo.net.

Il widget da loro creato offre la possibilità di fornire agli utenti del proprio sito web il meteo di qualsiasi località.

Il widget al suo interno contiene un link immerso nel codice HTML che punta alla pagina interna della località del sito ilmeteo.net.

<div id="cont_f13807ba8d0d6c1438beed30cc65a88b">

<span id="h_f13807ba8d0d6c1438beed30cc65a88b">

<a [...] href="http://www.ilmeteo.net/meteo_Roma-Europa-Italia-Roma--1-30862.html">

Meteo Roma</a>

</span>

<script type="text/javascript" src="http://www.ilmeteo.net/wid_loader/f13807ba8d0d6c1438beed30cc65a88b">

</script>

</div>

Inoltre se provate ad eliminare il link dal codice fornito, il contenuto del widget non viene visualizzato.

Avete altri esempi di widget interessanti da condividere?

In questo post vorrei “sbobinare” la presentazione che ho fatto sul mobile first: una filosofia di progettazione dei siti web che è diventata il cavallo di battaglia di Luke Wroblewski, autore di un libro e di moltissime presentazioni sull’argomento.

L’approccio classico alla progettazione di un sito web mobile molto spesso è subordinata a quella del sito web per desktop. Generalmente si parte dalla progettazione del sito per desktop, ragionando in profondità sul look ‘n feel, sui contenuti da servire all’utente e sulle funzionalità da rendere disponibili.

Dopo aver ragionato per mesi alla versione PC, si passa poi alla progettazione mobile: il rischio di questo processo è che si possa voler in tutti i modi di far incastrare tutti i contenuti in uno schermo molto più piccolo.

Il risultato è un sito web non pensato per gli utenti mobile e che spesso ricalca la stessa struttura e approccio del sito per desktop: questo causa spesso inefficienza e una scarsa soddisfazione degli utenti.

I motivi possono essere molteplici:

• ritardo di progetto a causa dell’incertezza del cliente sul design della grafica dell’homepage;
• la fase di approvazione dell’IA è stata molto faticosa, ripensarla per il mobile potrebbe generare eccessiva tensione nel progetto;
• poca dimestichezza del team a pensare mobile;
• ecc.

Il mobile first, invece, prevede un ribaltamento di prospettiva dove prima viene progettato il sito mobile e solo successivamente si lavora alla versione desktop.

Parlando di processi, pensare mobile first potrebbe permettere un grande anticipo del lavoro di sviluppo: la progettazione mobile generalmente è più breve perché è meno “disturbata” da tanti attori dell’azienda. Gli iter di approvazione sono più veloci poiché la discussione non si concentra su dettagli di interfaccia, sul pixel in più o pixel in meno, sul color grigio ma non troppo grigio, (e chi più ne ha, più ne metta )!

Con la chiusura della progettazione mobile, il team di sviluppo potrebbe già iniziare il suo lavoro, mentre nei piani alti dell’azienda si farà la progettazione per PC e ci si scannerà allegramente su dettagli grafici e isterismi vari degli Hippo.

Visto che nel 99% dei progetti in cui ho lavorato, i tempi di sviluppo sono sempre molto compressi mi sembra che pensare mobile first potrebbe essere davvero un vantaggio!

L’approccio mobile first non è detto che sia vantaggioso sempre, ma può essere utile soprattutto per siti web dove il mobile è effettivamente un fulcro importante per il business.

Pensiamo ad esempio a tutti i servizi di trasporto, i servizi pubblici, i siti web di telefonia mobile, ecc.

Sappiamo bene che se si parla di Trenitalia è come sparare sulla croce rossa, ma probabilmente siamo tutti d’accordo che pensare mobile first per un progetto del genere è davvero vantaggioso, no?

Quali sono i motivi che hanno spinto Luke Wroblewski a sposare questo approccio?

Per tre ragioni principali:

1. Il mobile è in una fase di crescita vertiginosa: Gartner stima che nel 2013 il traffico dati da mobile supererà il traffico dati da PC, diventando così la prima via di accesso al web.
2. I limiti del mezzo mobile, permettono di focalizzarsi non sui ghirigori, bensì sugli utenti, sui task che devono compiere, su informazioni essenziali e mirate: insomma ci si preoccupa più dell’aspetto funzionale senza curare troppo la grafica.
3. Le funzionalità che offrono i dispositivi mobile (ad es. GPS, accelerometro, fotocamera,ecc.) offrono l’opportunità di risolvere i problemi degli utenti, in modo diverso e innovativo!

Analizziamo ora le differenze tra i due approcci di progettazione.

Differenza #1: il contesto

La prima grande differenza è il contesto d’uso: quando si usa il mobile non ci si trova comodamente davanti al PC ma ci si trova in posti diversi in posizioni diversi, probabilmente non seduti davanti ad una scrivania con illuminazione perfetta, sicuramente con meno tempo a disposizione per svolgere un task o risolvere un problema.

L’immagine del manager che attende il business meeting checkando i suoi feeds nel suo feedreader (da notare lo slang), è soltanto uno dei casi. La verità è che in moltissimi usiamo il mobile in situazioni e contesti d’uso che si incastrano nella vita di tutti i giorni: dalla mamma che va a fare la spesa, allo studente pendolare di un’università di Milano, dalla ragazza shopping-addicted che lavora come commessa, all’operaio che va in discoteca tutti i fine settimana e scatta milioni di foto da condividere su Facebook, ecc.

Compete in questo post raccoglie alcune statistiche dei casi classici d’uso del mobile:, riassumibili con il grafico sotto:

In questi contesti d’uso spesso il mobile viene utilizzato in background, mentre si stanno facendo altre cose, il livello di attenzione è molto basso e soggetto a distrazioni. Gli utenti guardano lo smartphone, poi alzano lo sguardo verso la TV, poi riprendono quello che stanno facendo, ecc.

Hanno bisogno di informazioni veloci da consultare in modo immediato.

Luke nel suo libro usa una citazione di Rachel Hinman, ricercatrice di Nokia, davvero illuminante per comparare l’esperienza mobile da quella desktop:

Desktop behavior is ‘diving’ while mobile is ‘snorkeling’

Dal differente contesto d’uso è quindi possibile creare delle personas differenti da quelle del web, alle quali poi assegnare dei task che l’interfaccia e il sistema web deve supportare in modo semplice ed intuitivo.

Differenza #2: lo schermo

Senza dubbio un’altra differenza banale e scontata è che il mobile costringe a progettare per uno schermo più piccolo. Mentre per il desktop lo standard classico adottato è il 1024 x 768, per il mobile la risoluzione alla quale fare riferimento è la 320 x 480. Ad aggiungere maggiore complessità, bisogna considerare che ora per il mobile le risoluzioni di schermo sono diverse da modello a modello.

Se da un certo punto di vista la dimensione dello schermo può sembrare un limite, dall’altro può essere l’opportunità di focalizzarsi sui reali bisogni informativi degli utenti, ragionare sulle cose effettivamente utili per l’utente.

La legge principe di tutta la progettazione è “less is more”: la presenza di ogni singolo elemento nella pagina dev’essere ponderata bene lasciando da parte i fronzoli e “voli pindarici markettari”.

Lo schermo di dimensioni ridotte anche se costringe ad un design minimalista, permette la progettazione di interfacce che maggiormente interattive, dove ci sono interfacce composte da delle sotto-schermate affiancate l’una con l’altra attivabili attraverso le dita delle mani con le gestures.

Oltre al “less is more”, in questo caso è davvero importante e centrale curare nei minimi dettagli l’interaction design: una transizione poco intuitiva potrebbe precludere gli sforzi fatti.

In fase di prototipazione a causa dell’elevata interattività delle pagine, può essere utile non limitarsi ai wireframes ma intraprendere la strada di prototipi HTML navigabili e “toccabili” con mano.

Differenza #3: il modello di interazione

L’interazione non avviene più con i classici dispositivi di input tastiera e mouse, ma tutto avviene in modo più naturale con le dita.

Alcuni telefoni Android permettono anche l’uso di comodi bottoni sull’area inferiore dello smartphone, mentre iPhone ha un solo bottone centrale.

Inoltre, il contesto d’uso prevede un modello di interazione dove l’utente utilizza soltanto una mano: in questo caso bisogna prestare attenzione ai bottoni di azione per evitare che un utente abbia difficoltà a tappare e concludere un’azione.

Il modello di interazione, considerando le dimensione dello schermo, deve prestare attenzione alla grandezza degli elementi di azione, quali bottoni/form, ecc.

Permettere un’esperienza d’uso piacevole anche per gli utenti con grandi manone, in gergo americano “French Fry Finger“, molti player del mobile hanno deciso di darsi delle regole sulla dimensione degli elementi di azione di sistemi operativi, applicazioni, ecc.

Microsoft nella sua guida Windows Phone UI Design and Interaction Guide definisce una dimensione minima di 7mm con uno spazio di 2mm tra diversi elementi.

Sebbene lo scenario posse sembrare grigio, le gestures possono essere davvero un fulcro dove lavorare: l’uso della dita permette di svolgere dei compiti in modo veloce e innovativo.

Pensate ad esempio a Yahoo Sketch Search, dove è possibile ricercare un ristorante interagendo con le dita direttamente sulla mappa disegnando l’area all’interno del quale si vuole andare a mangiare.

Differenza #4: le capacità del dispositivo

Le capacità del dispositivo mobile offrono una grandissima opportunità per creare un progetto davvero innovativo ed interessante per gli utenti. Il mobile, infatti, ha dei dispositivi di input e output che possono davvero risolvere dei problemi agli utenti in modo che non hanno mai sperimentato.

Google Googgles, offre ad esempio agli utenti la possibilità di effettuare ricerca di contenuti attraverso l’uso della fotocamera come dispositivo di input.

Nearest Tube, invece, già due anni fa offriva la possibilità di orientarsi nella città di Londra con l’aiuto della sola fotocamera del telefonino ed una connessione internet. E’ sufficiente inquadrare la strada sulla quale si sta passeggiando e l’applicazione aggiunge all’immagine del luogo circostante anche l’informazione sulle stazioni della metropolitana più vicina.

Se pensiamo ai siti web di e-commerce che iniziano a targare i prodotti con l’RFID, allora l’immaginazione può portare anche più lontano!

Il mobile grazie a capacità di input che sfruttano il contesto ed il mondo reale, offre all’utente una terza generazione di interfaccia la NUI “Natural User Interface” lasciandosi alle spalle la GUI (Graphical User Interface) e la CLI (Code Line Interface).

Riassumendo…

Mobile first può mettere al centro il mobile nell’esperienza di progettazione di un sito web.

Risolvere dei problemi per gli utenti mobile, significa anche un sottoinsieme di problemi degli utenti PC ma con un approccio diretto.

Permette di concentrarsi sui reali bisogni informativi degli utenti (urgenti) e non sul pixel

Apre le porte a sperimentazioni per l’innovazione.

Può garantire un anticipo della fase di sviluppo migliorando l’efficienza e la qualità del progetto.

Perché non provarci?