Passare al responsive

Vorrei proprio potervi dire che c’è un vero percorso per rilasciare con successo un redesign responsive, ma dopo aver parlato con dozzine di organizzazioni, è chiaro che il processo mediante cui le grandi organizzazioni si convertono al responsive varia molto. Ci sono vari approcci diversi tra loro che potrebbero funzionare, ma dovete capire i benefici e rischi di ciascun di essi.

Potete fare il redesign dell’intero sito tutto in una volta o dovete fare lo staging del rollout nel tempo? Farete un retrofit del sito desktop esistente o comincerete da capo? Rilascerete una beta version del sito o farete una “rivelazione in grande”? Per trovare l’opzione adatta alla vostra organizzazione, ponetevi le seguenti domande:

• Quanto siete preoccupati per i clienti attuali sul sito desktop? Ora, nessuno risponderà “Non sono minimamente preoccupato”, ma alcune organizzazioni (ad esempio, le case editrici) fanno dei redesign piuttosto frequenti senza lanciare una beta version: semplicemente premono l’interruttore. Altre organizzazioni (per esempio, le banche) sanno di non poter rischiare di creare frustrazione nei clienti esistenti introducendo dei cambiamenti drastici senza un periodo di adattamento.
• State facendo il redesign di una applicazione web? Non permettete a nessuno di dirvi che le web app non possono essere rese responsive. Possono esserlo, ma ci vuole tempo e impegno. Se presentate molti dati in forma tabellare, se avete flussi di transazione basati su form complesse o delicate integrazioni con sistemi di backend legacy, assicuratevi di aggiungere del tempo nel vostro processo.
• Pianificate di fare cambiamenti al vostro contenuto? Un redesign responsive è un’opportunità fantastica per pulire e snellire il contenuto esistente: potreste non avere più un’occasione migliore di questa per sistemare contenuti cresciuti a dismisura che non fanno il loro dovere. Detto ciò, molte organizzazioni pensano di non poter fare tutto in una volta, quindi svelano la pulizia del contenuto a fasi.
• Pianificate di implementare un nuovo CMS o delle API? Molte organizzazioni riferiscono che il lavoro che è stato fatto da loro negli ultimi anni per cambiare piattaforma dei sistemi di pubblicazione ha reso più semplice la conversione al responsive. Ma dovrete decidere se fare prima il passaggio di CMS o il redesign. È più rischioso e più “time-consuming” farli entrambe allo stesso tempo.
• I vostri stakeholder sono preparati per il processo di revisione? Alcune organizzazioni utilizzano il redesign responsive per coinvolgere l’intera organizzazione nell’apprendimento di un nuovo processo. Altri usano un approccio “meglio chiedere perdono che permesso”, svelando prima il redesign e sistemando in seguito gli inevitabili pezzi rotti.

Una volta che conoscerete le risposte a queste domande, prendete in considerazione le opzioni per passare al responsive.

Retrofit#section1

Fare un retrofit responsive significa riscrivere il codice del front-end del sito web con qualche o nessun cambiamento al contenuto e al design esistenti.

Devo fare una confessione: prima di cominciare a parlare ad aziende che avevano lanciato un retrofit responsive di successo, ero sicura che questa fosse la peggiore di tutte le possibili opzioni, destinata a realizzare un’esperienza al di sotto delle aspettative per chiunque ne fosse coinvolto. I miei credo filosofici sul “modo giusto” per gestire i processi web non sopravvivono sempre negli scontri con il mondo reale: ammetto che un retrofit funziona bene in alcuni scenari.

In generale, i retrofit funzionano al meglio quando almeno una delle seguenti affermazioni è vera:

1. Il contenuto non cambierà (molto).
2. Alle applicazioni web complesse non serve un redesign.
3. C’è già un framework a componenti.

Aziende quali Capital One, Marriott e Nationwide Insurance hanno implementato dei retrofit responsive con successo. Fare un retrofit li ha costretti a concentrarsi sugli aspetti responsive del progetto senza essere distratti da questioni più grandi sul redesign del sito, dall’editing del contenuto o dal cambiamento di piattaforma CMS. Per molti siti web, un retrofit aiuta anche a mitigare i dubbi politici attorno al cambiamento o al danneggiamento dell’esperienza desktop, dal momento che non cambia molto.

Ecco come fare un retrofit nel modo giusto:

• “Non toccare il desktop” è un ordine dato spesso al team responsive, ma questa linea guida è troppo limitante. Obbliga il team a lavorare verso una parità di design non necessaria a scapito di prendere decisioni di design migliori per schermi più piccoli.
• “Non danneggiate il desktop” è un’ambizione più realistica e raggiungibile. Questo dà ai team la flessibilità di cui hanno bisogno per fare aggiustamenti al layout, al design, alla navigazione o al contenuto.
• Impostate aspettative realistiche con il vostro team e sviluppate un piano per fare dei cambiamenti sul lungo termine. Gli stakeholder potrebbero essere sorpresi quando vedranno in che modo il contenuto e le funzionalità esistenti si muovono sui vari schermi.
• Prendete in considerazione di scegliere una sezione per una ristrutturazione responsive completa. Una sezione completamente editata e riprogettata può fungere da utile metro di confronto con il retrofit. Scegliere una sezione per un redesign completo darà al team un’esperienza con il processo, mostrerà agli stakeholder cosa è possibile, fornirà un insight nel livello di sforzo che può informare la portata di processi futuri e offrire dati reali su come funzionerà un’esperienza completamente ripensata rispetto ad un retrofit.

Beta release#section2

Negli ultimi anni, applicazioni web popolari come Gmail, Flickr e Delicious sono state lanciate in beta e sono rimaste in beta. Questo approccio, definito “beta perpetua”, è stato il precursore delle pratiche di deploy continuo usate oggi da molte applicazioni per supportare lo sviluppo e i test continui.

Oggi, quando i team dicono che stanno lanciando in beta, spesso intendono che gli utenti possono fare “opt out” dal sito in qualunque momento e ritornare alla versione “classica” del sito web. Questo approccio “beta parallela” richiede una quantità significativa di tempo e sforzi aggiuntivi per sviluppare e rivedere, ma in cambio dà la possibilità di fare roll out del design lentamente, raccogliendo i feedback degli utenti e i dati statistici lungo il percorso.

Aziende come Fidelity, Heatport e il Guardian hanno investito in versioni beta parallele, che hanno dato loro un modo per testare ed imparare nel tempo da un responsive design. Stephen Turbek, SVP, User Experience Design in Fidelity, ha detto che la loro decisione di lanciare in beta è stata fondamentale per il loro successo:

Ecco cosa deve succedere per lanciare una beta con successo:

• una cultura “testa-e-impara” dovrebbe già esistere nella vostra organizzazione. I team devono sentirsi a proprio agio a lavorare con cicli brevi di iterazione e test, la maggior parte dei team dovrà fare test ogni sei settimane e addirittura con una frequenza settimanale o ogni quindici giorni. Se non state già lavorando così, costruire una cultura di apprendimento con la ricerca prenderà del tempo e aggiungerà complessità.
• Architettura tecnica e infrastruttura di pubblicazione devono esserci così che gli utenti possano fare opt in e out, il che può essere costoso.
• È cruciale l’executive buy-in da parte degli stakeholder che possono vedere il valore del processo di beta e vogliono investire nella manutenzione di due versioni del sito, per non parlare del gestire il traffico su due URL diversi.
• Il quality assurance testing (QA) diventa esponenzialmente più complesso quando si testa su più form factors. Non sottostimate il tempo o lo staff di cui avrete bisogno per fare QA di due versioni del sito.
• Fare roll out della beta in vari stage aiuterà a controllare chi vi può accedere. Alex Breuer, Creative Director al Guardian, ha detto che hanno scoperto che mostrare il sito in beta agli utenti che venivano da una ricerca o dai social “è stato un modo gentile per introdurre la nuova esperienza del Guardian.”
• Date per assunto che i primi feedback saranno negativi se il vostro sito beta esclude il contenuto o le funzionalità del vecchio sito. Aiutate gli stakeholder a capire che il feedback negativo non è un segno di fallimento: in realtà, ottenere subito questi commenti è proprio lo scopo della beta.

Responsive mobile-only#section3

Un’altra strategia di rollout, spesso, ma non sempre, implementata nel contesto di una beta release, è di sviluppare un sito web responsive che copra tutte le dimensioni di smartphone e tablet, preservando il sito attuale a larghezza fissa solo per gli utenti desktop. In un certo senso, questo approccio è un “sito responsive m.” ma questa parola fa incartare il mio cervello, quindi non chiamiamolo così e basta. Lo chiameremo sito responsive mobile-only.

Un sito responsive mobile-only fa si che l’azienda occupi il suo tempo concentrandosi su questioni più grandi e complesse. Le aziende sanno di aver bisogno di un sito che sia utile per gli utenti mobile, ma temono di danneggiare il traffico desktop esistente. Tuttavia, sanno anche che il sito necessita di un redesign completo o di miglioramenti importanti all’infrastruttura del backend, quindi non vogliono fare un retrofit. In questo senso, un design responsive mobile-only offre il meglio di entrambe i mondi. I team possono concentrarsi sull’ottenere il responsive design nella maniera corretta, senza avere a che fare con le politiche degli stakeholder e con i rischi operativi inerenti al cambiamento del desktop.

Ma questo approccio è anche il peggiore di entrambe i mondi: permette agli stakeholder di continuare a credere che il sito desktop sia il sito web “reale”, sminuendo la grande popolazione in continua crescita degli utenti mobile. Significa anche che, così come con tutti i siti m-punto, gli utenti smartphone e desktop soffriranno degli stessi problemi di performance dovuti ai redirect del server.

Ecco cosa potete fare per lanciare un sito responsive mobile-only di successo:

• Trattatelo come una beta anche se non lo state proponendo in stage. Dovete avere un piano raccogliere i dati, testare e rivedere il sito responsive. Nel tempo, pianificate un rollout a stage per gli utenti desktop.
• Prendete scelte difficili sul contenuto e le funzionalità. Questa strategia di rollout ha più successo quando viene usata per pulire e snellire un sito che col tempo è andato fuori controllo. Se non siete preparati per prendere delle decisioni difficili, fare un retrofit.
• Istruite il vostro team su cosa rende di successo un sito web responsive.
• Il rischio con un approccio “skunkwork” è che il team “mobile” proseguirà per conto suo e il resto dell’azienda non imparerà nulla dall’esperienza.
• Rendetelo il sito web vero. Impostate delle aspettative riguardo al fatto che questo processo non è per costruire un sito web “mobile”, ma è la creazione di un sito web che alla fine sostituirà quello desktop.
• Dovete sapere quando smettere di investire nel sito desktop e spostare le risorse al sito responsive. BBC News ha detto che continuare a lavorare sul loro sito desktop “stava succhiando risorse e morale e questo ci è costato caro, ritardano la nostra mossa strategica a ‘Responsive News’.”

Sezione per sezione#section4

Altre organizzazioni scelgono di cominciare con una sezione specifica, anche solo una pagina particolare o un tipo di template. Piuttosto che fare tutto il sito in una volta, scelgono di mettere in sandbox i propri sforzi e di dare ai team del tempo per fare pratica.

Con che sezione dovremmo cominciare? La risposta a questa domanda varia da un approccio di rollout all’altro. Alcune aziende riportano di aver scelto una sezione che sapevano di voler riprogettare. Celebrity Cruises ha cominciato dalla propria sezione Destinations, rendendola responsive come parte di uno sforzo più grande per riscrivere il contenuto e cambiare la piattaforma CMS. Altre aziende hanno cominciato con una sezione meno popolare, una sezione gestita dagli stakeholder che sono esaltati dal processo o una che ha una quantità di traffico mobile sproporzionata rispetto al resto.

E poi c’è Microsoft, che ha cominciato dalla homepage. Questo approccio alla villaggio Potemkin a un redesign responsive può frustrare gli utenti, promettendo loro un sito web che funziona bene sui device mobile, solo per tradire quelle aspettative al primo “tap”. Ma Chris Balt, Senior Web Product Manager in Microsoft, ha sostenuto che li ha aiutati ad ottenere il buy-in aziendale per passare al responsive:

Ecco come potreste metter mano al roll out di un redesign responsive a sezioni:

• Scegliete una sezione che rifletta i tipi di problemi o i design pattern che troverete altrove sul sito. Alcune sezioni, come “Investor Relations” o “About Us” potrebbero essere più semplici da implementare perché hanno dei contenuti e dei layout relativamente semplici, ma non forniranno altrettanti insight su come gestire problemi più complessi.
• Concentratevi sul vostro “core”. Come con il Pilates, il vostro core fa tutto il lavoro. Osservate il vostro traffico e i dati d’uso per identificare le pagine e le sezioni del sito che importano di più agli utenti. Dirigete lì la vostra energia.
• Assicuratevi che i vostri stakeholder first-round siano d’accordo con lo sforzo extra richiesto per supportare il redesign. Verrà chiesto loro di prendere decisioni con cui non hanno familiarità e avranno bisogno di condividere e difendere il loro rationale con il resto dell’azienda.
• Tracciate e documentate lo “scope” per prendere decisioni informate in futuro. Sapere quanto tempo prendono alcuni processi, dove i team di design e sviluppo hanno incontrato difficoltà e quali decisioni sono state difficili per gli stakeholder vi aiuterà a pianificare la fase successiva del lavoro.
• Prendete decisioni globali tenendo a mente tutti. Alcune scelte ricadono davvero su tutti. Gestire le immagini responsive, progettare i menu di navigazione, identificare i tipi di contenuto principali, sviluppare moduli riutilizzabili come parte di un sistema di design – questi argomenti richiedono il buy-in da parte di più persone che non semplicemente quelle che gestiscono una pagina o una sezione particolare.

Illustrazioni: {carlok}