Responsive comp: ottenere un contratto senza mockup

Parliamo del processo#section1

Prima di cominciare a progettare, noi lavoriamo con i nostri clienti per definire chiaramente il contenuto e assegnare delle priorità all’informazione che andrà sul sito. La mia prima domanda è semplice: perché avete bisogno di un sito web? Poi chiedo: “Cosa sperate di ottenere come azienda e cosa cerca il vostro pubblico?” Le risposte a queste domande ci aiutano a definire la funzionalità e la gerarchia dell’informazione del sito.

Gerarchia, gerarchia, gerarchia#section2

Una volta compreso lo scopo del sito nel suo insieme, applicheremo quell’obiettivo a qualcosa di finito e che si possa realizzare, come la homepage. Prima ancora di passare ai wireframe, possiamo esprimere la gerarchia dell’informazione sul sito nella maniera più semplice possibile: mediante un elenco numerato. Per uno dei nostri clienti recenti, la American Association for Homecare, abbiamo fatto una lista in homepage che si presentava così:

1. Dichiarazione del brand: L’elemento emozionale primario del design. Non dà informazioni dettagliate ma dà agli utenti un’impressione di quello che rappresenta AAHomecare e li aiuta ad identificarsi con l’organizzazione.
2. Contenuto “featured” variabile: Selezionato dagli amministratori. Quest’area include contenuti in evidenza da tutto il sito, come ad esempio eventi, pagine, etc.
3. Navigazione del sito: Permette agli utenti di trovare il contenuto che stanno cercando.
4. Membership: Una breve lista dei benefici della membership AAHomecare, seguita da un invito alla sottoscrizione.
5. Eventi: Un feed dei prossimi eventi che contiene informazioni vitali e link al calendario degli eventi e alle pagine di dettaglio degli eventi.
6. Comunicazioni: Feed dei contenuti recenti da risorse come il blog, Twitter o le newsletter, con link agli articoli originali (ove sia possibile).
7. Contenuto del footer: Include i link a una parte della navigazione del sito, le pagine legali, gli sponsor aziendali e le pagine sui social network, così come l’ubicazione dell’informazione di copyright.

Senza nemmeno pensare ad alcuna decisione visuale sul suo aspetto, abbiamo creato un’accurata gerarchia dell’informazione di primo livello per la homepage del sito. Ora sappiamo che, indipendentemente da come apparirà la pagina, se possiamo presentare correttamente questa informazione, sarà una vittoria per l’azienda e per gli utenti del sito.

L’altro mio wireframe è un HTML#section3

Una volta che comprendiamo il contenuto e le priorità del sito, il nostro primo step in ambito visuale è quello di creare dei wireframe. Ma come avrete già notato, spostare il testo in un file Photoshop può essere frustrante e richiede molto tempo.

Ma sapete cosa va davvero alla grande per la disposizione del contenuto in un modo che esprima accuratamente la sua gerarchia? Avete indovinato: HTML e CSS! Quindi, facciamo fare a Photoshop un meritato riposino, lanciamo il nostro editor di testo preferito e il nostro browser WebKit, e cominciamo ad assegnare dei tag semantici al nostro contenuto usando un approccio mobile-first.

Quando avete solo qualche centinaio di pixel di larghezza con cui lavorare, le priorità diventano ancora più chiare e le decisioni difficili ancora più necessarie. Potreste chiedervi spesso: “Questa cosa deve davvero stare qui?”. Concentrandosi sul mobile first, possiamo anticipare queste discussioni e lavorarci in maniera più efficace; quanta più informazione riusciamo a togliere in questo punto tanto più i nostri utenti ci ringrazieranno.

Una volta che la nostra gerarchia mobile è chiara, è ora di allargare progressivamente il browser e di prendere in considerazione delle decisioni di layout più complesse. Ogni volta che incontriamo una larghezza in cui le cose cominciano a non stare più insieme, possiamo aggiungere una nuova media query per aggiustare il layout.

In Bearded, per aiutarci con lo sviluppo del layout nel browser, abbiamo sviluppato un grid system responsive che ci permette di applicare rapidamente delle proprietà alle colonne annidabili tramite CSS (o, più accuratamente, con SASS e Compass). Con questi comodi mix-ins a nostra disposizione, possiamo sperimentare rapidamente diversi approcci al layout responsive senza sforzi eccessivi.

A questo punto, i nostri wireframe HTML/CSS appaiono piuttosto gradevoli e dal momento che stiamo lavorando con lo stesso medium (codice e browser) per tutto il processo, possiamo far evolvere naturalmente i nostri wireframe nel design finale.

Il mio wireframe da grande vuole fare il design di un sito#section4

È proprio a questo punto che ci allontaniamo un attimo dal nostro HTML per definire degli elementi di stile sensibili (simili alle style tile di Samantha Warren o ai prototipi di stile di Sparkbox). Di solito, si tratta di un piccolo canvas Photoshop in cui riportiamo la tipografia con cui stiamo lavorando nei wireframe e cominciamo a sperimentare con il colore, la texture e le immagini. Una volta definiti, possiamo usare questi “mattoni” visuali per far evolvere i nostri wireframe verso un vero e proprio sito web.

Man mano che inseriamo nuovi elementi visuali, passiamo avanti e indietro tra l’editor di testo e Photoshop, ma quest’ultimo non è più il canvas di design primario: adesso è più simile a un blocco per gli schizzi. È necessario rendere perfetta la tipografia? No. Possiamo buttare uno screenshot del browser in Photoshop e cambiargli la grafica del background? Certo! Non volete mostrare questi schizzi mezzo-completati al cliente? Non c’è problema, non glieli mostrerete mai.

Non solo questo metodo rinforza l’approccio guidato dal contenuto nel design, ma crea anche qualcosa che è utile per il prodotto finale. L’HTML che create per il vostro comp permetterà agli sviluppatori di sapere che tipo di markup volete dal CMS. E se fate bene entrambe i lavori, vorrà dire che il CSS che state per scrivere verrà immesso nel sito finale semplicemente con dei piccoli aggiustamenti.

Non butterete più via i pomeriggi con i pixel di Photoshop, per perfezionare semplicemente una cosa che butterete via e ricreerete comunque in CSS. Alcune cose si ottengono più efficientemente con CSS, mentre altre sono più rapide in Photoshop, quindi scegliamo gli strumenti che ci sembrano più adatti in quel momento. In fin dei conti, finisce tutto nel browser. È il modo in cui progettiamo ed è il modo in cui lo vedono i nostri clienti.

La paura uccide la mente#section5

Starete pensando: “Oh sì, i clienti! Come si inserisce questo mondo mockup-less nel nostro processo di approvazione del design?” Mi fa piacere che l’avete chiesto.

Firmate sulla riga tratteggiata#section6

Abbiamo scoperto che mandare ai clienti i comp realizzati nel browser è estremamente semplice: mandiamo un URL via e-mail. I clienti possono guardare il design in diversi browser e su diversi dispositivi, ridimensionarlo, cliccare sui link e sulla navigazione e provare i vari stati di hover. Invece di chiedere ai clienti di fingere che un’immagine sia un sito web, gli mostriamo… un sito web!

Forniamo sempre un URL permanente con un /v1 alla fine, come ad esempio aafh-css.heroku.com/v1. Da quel punto, la versione uno non cambierà mai e le versioni seguenti avranno un loro URL, come aafh-css.heroku.com/v2. Procediamo così finché non raggiungiamo una versione approvata.<

Poiché ciascuna versione ha un URL permanente diverso (usiamo l’hosting gratuito Heroku per gli ambienti non di produzione come questo), possiamo anche mettere un certo numero di revisioni nel contratto, proprio come facevamo con i comp. Se il progetto richiede più modifiche di quelle previste, potrebbe essere ora di discutere l’aggiunta di ulteriori ore al budget.

Questo permette a ciascuno di ritornare indietro facilmente e di rivedere ogni comp ogni volta che lo desidera. Quando abbiamo finito le revisioni, i clienti ricevono la stessa form di accettazione che abbiamo sempre usato, ma al posto del nome del file, i design finali sono specificati dall’URL permanente di quella versione.

Ora, potreste chiedervi se i vostri clienti accetteranno questo nuovo processo. Finora, in Bearded non abbiamo avuto altro che reazioni positive. Il nostro contatto in AAHomecare l’ha perfino twittato. Non so voi, ma quella è stata la prima volta che un nostro cliente ha detto su Twitter quanto gli piacesse il processo di approvazione del design.

Questo è quanto: approvazione senza un mockup statico. Incredibile, vero?

Mandate questa parte al vostro project manager#section7

Voi direte: “Aspetta! E il budget? Le revisioni non ci mettono di più? Se al cliente non piace e dobbiamo ricominciare da capo?”

Potrebbe succedere. Ma non potrebbe succedere anche con un mockup Photoshop? E anche se dovessimo ricominciare da capo con il “look and feel”, è probabile che almeno i layout HTML e i wireframe vadano bene. Tra l’altro, poi, editare il codice CSS (specialmente con SASS) è molto spesso più rapido che editare un file Photoshop. Prendete per esempio il cambiamento dei colori del link o la selezione dei font su tutto il sito: più rapido in CSS che in Photoshop? Sì. Grande CSS!

Fortunatamente, la mia prima idea si è rivelata valida fin qui. Con AAHomecare il nostro processo di design è durato di più di quanto stimato, di un 35% circa. Non troppo male, secondo me, per un nuovo modo di lavorare. Nel frattempo le nostre ore in CSS sono state meno della metà di quanto stimato. Quindi, in fin dei conti, il nostro progetto è stato più efficiente e più redditizio senza i mockup. So che il vostro PM sarà entusiasta di tutto questo!

Progettare è programmare#section8

Tutti questi cambiamenti al nostro processo stanno anche rendendo più fluidi i nostri ruoli. Con i nostri designer che scrivono CSS, dove finisce il design e dove comincia lo sviluppo front-end?

Sovrapposizioni o meno, c’è ancora qualcosa da dire sull’esperienza. I front-end developer possono collaborare con i designer durante l’intero processo. Rivedono tutto, sistemano il codice eccessivamente complesso o ridondante e rimuovono gli stili ancora presenti. Quando incontrano un problema, i nostri sviluppatori aggiornano un log di best practices di cui i nostri designer possono prendere visione in un secondo tempo, così che possano migliorare le loro capacità di programmazione ed evitare di ripetere gli stessi errori in futuro.

I nostri design iniziali avranno ancora delle feature e delle visioni che necessitano di ulteriori elaborazioni, così come i miglioramenti dell’interazione che abbiamo tralasciato per riprenderli poi in un secondo tempo. Così il nostro processo di design non solo è più vicino allo sviluppo, ma anche il nostro processo di sviluppo diventa più vicino al design. Come sappiamo, questo vuol dire creare un internet migliore.

Questo livello di collaborazione può sfociare in un calpestarsi i piedi a vicenda, quindi usiamo Git per il version control. Git permette a più persone di lavorare contemporaneamente su un repository centrale per il codice, con metodi per la risoluzione dei conflitti e cambiamenti di roll back quando diventano necessari. Tralasciando la tecnologia, comunque, un semplice “Hey, sto lavorando sul calendario CSS” spesso funziona meglio, specialmente in un ambiente in cui la collaborazione e la fluidità sono la norma.

Pronti, partenza, implementare!#section9

Cosa ci fa perdere meno tempo su un prodotto usa e getta? Come facciamo a rendere più significative le ore che passiamo di fronte al computer e a far sì che i risultati siano più efficaci? Fa tutto parte di uno stesso problema.

Il responsive design ci dà l’opportunità di ripensare al nostro approccio alla progettazione per il web. Possiamo smettere di progettare “siti web” e “siti mobile”. Possiamo creare dei sistemi di distribuzione di contenuto flessibile: insiemi di regole che definiscono il modo in cui il contenuto sarà presentato a seconda del contesto.

È difficile ripensare al nostro processo e potrebbe sembrarvi oltremodo complicato, ma alla fine dei conti tutti gli ostacoli che incontreremo non saranno altro che ostacoli che possono essere superati. Internet cambierà, che ci piaccia o meno e noi dobbiamo adeguarci.

D’altronde, non vi stavate annoiando? Facciamo qualcosa di meglio: per il nostro workflow, per i nostri utenti e per i nostri clienti. Cominciamo adesso.

Illustrazioni: {carlok}