Processo di progettazione efficiente e reattivo

Com'è il tuo processo di progettazione reattiva? Ritieni che sia efficiente? Il seguente articolo è un estratto dal capitolo di Ben Callahan "Processo reattivo", pubblicato per la prima volta nella versione eBook di Smashing Book 5 (indice). —Ed.

"Il rispondente di successo a questa richiesta di offerta fornirà tre opzioni di progettazione statica che il nostro team potrà valutare". Non sono mai stato un grande fan dell'adozione di un approccio di progettazione multi-opzione, ma lo capisco: a volte un cliente ne ha bisogno.

"Ognuna di queste opzioni fornirà il design per tre layout unici: home page, pagina dell'elenco, pagina dei dettagli". Va bene. Ora abbiamo fino a nove file di progettazione statici. Questo sta sfuggendo di mano.

"Ognuno di questi design di pagina unici dovrebbe tenere conto delle dimensioni di dispositivi mobili, tablet e desktop". Non sono mai stato bravo in matematica, ma posso fare questo calcolo. Ventisette file di progettazione statici?! Non succederà.

Questa è una richiesta di proposta nella vita reale che ho ricevuto non molto tempo fa. Risulta che il cliente era molto disponibile a un approccio più efficiente. Ma questa esperienza mi ha fatto davvero pensare... La cosa più difficile nel fare queste cose non è in realtà fare queste cose. È lavorare con le persone mentre fai queste cose.

Vedete, quasi tutti i potenziali clienti là fuori hanno già un sito web . Per noi, ciò significa che la maggior parte dei clienti arriva a questo con una serie di aspettative, insieme al proprio bagaglio da progetti web passati. Quel bagaglio può avere un impatto drastico sul modo in cui il tuo cliente si avvicina al progetto e tu. Per aiutare a diminuire gli effetti negativi di queste aspettative, ho scoperto che il modo migliore per gestirle è essere colui che le stabilisce.

Il mio obiettivo in questo capitolo è aiutarti ad avere più successo con i tuoi progetti web iniziando dall'inizio ; lavorando sin dal primo giorno per aiutare a definire le aspettative del cliente su ciò che accadrà e lavorando durante il ciclo di vita di un progetto per fare lo stesso.

Differenze chiave nel processo per un web design reattivo

Prima di aprire il tuo editor di testo preferito, prima di aprire Macaw, prima di estrarre il blocco da disegno o iniziare a scolpire con il testo, devi aiutare il tuo cliente a comprendere il processo. Ci sono molti modi per farlo, e il mio meno preferito è semplicemente provare a venderli con un nuovo processo. Nella mia esperienza, dimostrare il valore del tuo modo di pensare in anticipo, anche prima della firma di un contratto, è l'approccio migliore. Questo dà al tuo cliente la sicurezza di sapere di cosa stai parlando, ma significa anche che devi guadagnare la sua fiducia per provare un nuovo modo.

Per incoraggiare questo, ci sono quattro ideali che io e il mio team cerchiamo di tenere a mente mentre interagiamo tra loro: collaborare, iterare, adattare e stabilire le priorità. Lascia che ti spieghi brevemente perché queste idee specifiche ti manterranno sulla retta via.

Collaborare

Lo so, lo so. Tutti ovunque parlano di collaborazione e di come sia necessaria per fare un ottimo lavoro. Beh, sai una cosa? È vero. Ovviamente, devi collaborare all'interno del tuo team, ma c'è un altro tipo di collaborazione che è necessaria in questi giorni: collaborare con il tuo cliente . Ho un promemoria importante per te: anche i clienti sono persone. Potrebbero non avere la tua esperienza quando si tratta di progettazione e sviluppo web, ma sanno molto di più sulla loro attività di quanto tu possa mai fare.

Ancora una volta, si parte dall'inizio. In Sparkbox, ho cercato un modo per essere più collaborativo nel portare nuovi clienti a bordo. Come parte di questo, abbiamo adottato un nuovo approccio alla stesura dei preventivi. Invece di un cliente che viene da noi e spiega il suo progetto in modo che possiamo scomparire per una settimana e tornare con The Perfect Solution, lo abbiamo invitato ad aiutarci con il preventivo. È semplicissimo: lo chiamiamo stima collaborativa e i clienti lo adorano.

Iniziamo con un foglio di calcolo di Google di base che ha alcuni campi regolabili e calcola quanto pensiamo costerà fare il lavoro. Iniziamo con ampi intervalli perché lo facciamo molto presto nel processo, in genere dopo solo una telefonata di 30 minuti. Poi lo condividiamo con il cliente e ci lavoriamo insieme.

Ecco perché questo è importante: collaboriamo alla prima cosa che facciamo con i nostri clienti. Vogliamo che sappiano che aggiungiamo più valore quando lavoriamo con loro piuttosto che per loro. Questo è solo un modo in cui mettiamo i nostri soldi dove siamo.

Invitiamo anche i nostri clienti nei nostri canali di comunicazione del team con noi. Siamo grandi fan di Slack e Basecamp. Questi strumenti forniscono un ottimo mix di documentazione formale e conversazione informale, entrambi necessari per facilitare una collaborazione di qualità.

Nella riprogettazione aperta di Daniel Mall del sito web Reading Is Fundamental, abbiamo tutti avuto un'idea di come Dan porta i suoi clienti nel progetto con lui. Brad Frost ha fatto un ulteriore passo avanti con un progetto GitHub chiamato "Project Hub" che è uno strumento per tenere traccia dello stato di avanzamento del tuo progetto.

Ricorda, questi sono tutti solo strumenti. Gli strumenti possono aiutare, ma ciò che è veramente necessario è un cambiamento nel modo in cui pensiamo. Il mio amico Kevin Sharon una volta mi ha detto qualcosa di molto toccante. Ha detto: "Se non puoi dire 'No', non è collaborazione". Non so voi, ma ho avuto molte relazioni con clienti in cui non avevo l'autorità per respingere, anche se sapevo per esperienza che ciò che stavano chiedendo non avrebbe funzionato. Questi clienti vengono da te con soluzioni piuttosto che problemi che devono essere risolti.

Mi vergogno ad ammetterlo, ma ho anche avuto rapporti con i clienti in cui era vero il contrario. A volte la mia frustrazione ha la meglio su di me e dimentico che ho bisogno che il mio cliente faccia parte del progetto. Quando sentiamo un'idea dai nostri clienti e immediatamente non siamo d'accordo, siamo colpevoli quanto loro nel negare un processo collaborativo. Molti web studio non sono disposti a consentire questo tipo di collaborazione nel loro processo, spesso perché non credono che i loro clienti siano abbastanza creativi o tecnici per contribuire in modo significativo.

La collaborazione è una strada a doppio senso. Spostare la tua visione dei tuoi clienti verso che diventino veri contributori nel tuo lavoro si tradurrà in tutti i tipi di nuovi modi per includerli e aiutarti a creare un prodotto migliore.

Iterare

Cerchiamo regolarmente opportunità per fornire un piccolo sottoinsieme di funzionalità di alta qualità a una velocità incredibile. Adottare un approccio come questo dimostra progressi in anticipo e offre opportunità reali per lasciare che ciò che hai imparato crei slancio per portarti attraverso un progetto.

Se ritieni che potrebbero esserci sfide politiche nel cambiare il modo in cui lavora il tuo cliente, ecco un consiglio professionale (e lo sento in ogni progetto che facciamo): lavorare in modo iterativo può aiutare a trasformare gli scettici in sostenitori. La maggior parte delle persone è molto più propensa a farti provare un nuovo modo di lavorare su una piccola fase che su un intero progetto. Ancora una volta, il punto principale qui è dimostrare il tuo valore in anticipo per guadagnare la fiducia del tuo cliente.

Un modo in cui l'iterazione si manifesta è nella prototipazione. Siamo costantemente alla ricerca di opportunità per identificare una sfida significativa, suggerire una possibile soluzione, provare o smentire la sua validità attraverso la prototipazione, la revisione e la ripetizione.

Spesso cerchiamo la possibilità di iniziare con una fase di scoperta a pagamento prima di iniziare un grande progetto; pensalo come un appuntamento prima di sposarti. Questo ti dà l'opportunità di imparare molto di più sul progetto e com'è lavorare con questo cliente. Entrambe le parti sono in grado di determinare se il rapporto di lavoro è adeguato.

Gli impegni iniziali possono assumere molte forme, ma gli obiettivi primari sono:

1. Comprendere meglio lo scopo del progetto
2. Identificare e dimostrare possibili soluzioni alle sfide più grandi
3. Scopri se l'adattamento cliente/fornitore è giusto
4. Dimostra di essere capace
5. Fatti pagare per quanto sopra

I tuoi clienti apprezzeranno questo approccio e costruirai un'ottima base per il lavoro futuro. E se impari qualcosa che cambia drasticamente la tua comprensione del progetto, ti impegnerai solo in una piccola fase. Questo apprendimento informerà notevolmente il passaggio successivo del processo e ti spingerà verso una soluzione migliore.

Abbiamo un cliente con cui lavoriamo da molti anni; infatti, abbiamo da poco iniziato con loro il nostro trentesimo progetto. Per me, questo è un segno che abbiamo trovato un modo reciprocamente vantaggioso per lavorare insieme: loro vedono il valore in ciò che offriamo e siamo creativamente e tecnicamente soddisfatti del nostro lavoro con loro. Nel tentativo di individuare ciò che ha reso questa relazione di successo, continuo a tornare al nostro approccio iterativo. Ci sono state molte volte in cui sono venuti da noi con un problema e un'idea su come risolverlo. Invece di limitarci a mordere quello che potrebbe essere un progetto di 12 settimane, abbiamo regolarmente suggerito fasi più piccole e iterative che testano possibili soluzioni e hanno un investimento iniziale molto inferiore. Adottare questo approccio ci ha permesso di guadagnare la loro fiducia. Quella fiducia è indispensabile per creare una relazione sostenibile e l'iterazione è al centro di tutto.

Adattare

Quando il responsive web design è apparso sulla scena, ricordo di essere stato colpito dall'idea che la flessibilità intrinseca al prodotto che stavamo costruendo si stava facendo strada nel nostro processo. Samantha Warren ha detto meglio: "Il tuo processo dovrebbe essere reattivo come i prodotti che stai progettando".

La verità è che non esiste un processo perfetto per questo tipo di lavoro. Tu ed io dobbiamo abbracciare i vincoli che ci vengono presentati. Ogni progetto, cliente, ambito, sequenza temporale, budget, team, stack tecnologico, matrice di supporto è diverso. Le organizzazioni che hanno successo in questo business sono quelle che possono lavorare entro i vincoli di un progetto e continuare a svolgere un lavoro senza tempo.

Le mie opinioni sul processo sono decisamente difficili da spiegare a un cliente. Data l'opportunità, probabilmente rinchiuderei alcune persone chiave (cliente incluso) coinvolte nel progetto in una stanza per alcune settimane e darei loro il mandato di capirlo. Prendilo da me, ai clienti non piace essere rinchiusi in una stanza per settimane di seguito.

Invece, dobbiamo trovare un equilibrio tra un processo molto rigido (in cui ogni passaggio è strutturato e documentato) e uno improvvisato (in cui confidiamo che il team trovi l'approccio migliore man mano che procede). Ci sono molti fattori da considerare per trovare questo equilibrio. Eccone tre per cominciare: la dimensione della squadra; l'esperienza della squadra; e la criticità del progetto.

La dimensione della squadra

È molto più facile consentire una grande flessibilità nel processo quando si dispone di un team molto piccolo. Due o tre persone sedute nella stessa stanza saranno in grado di tenere traccia di ciò che sta accadendo senza molta struttura. Porta la dimensione della squadra fino a sei o sette e inizia a diventare difficile dare un senso all'impatto di ogni giocatore sull'andamento dell'intero progetto. Aumenta la tua squadra a dieci, quindici o più e diventa quasi impossibile.

Questo è molto personale per me. Quando ho avviato Sparkbox con i miei partner, eravamo solo in quattro. Ognuno di noi aveva un ruolo abbastanza ben definito e siamo stati in grado di operare in modo abbastanza efficace senza troppi processi. Poiché ci siamo seduti tutti insieme in una grande stanza, c'era una comunicazione costante su tutti gli aspetti della nostra attività.

Ora abbiamo 23 persone a tempo pieno, più tre apprendisti. Certamente non siamo cresciuti così velocemente come in alcuni luoghi - siamo molto attenti alla nostra crescita - ma la frase "dolori della crescita" suona ancora vera. Abbiamo dovuto sperimentare costantemente quando, cosa e come comunicare. È solo attraverso questa sperimentazione che possiamo trovare un equilibrio che fa per noi.

La lezione qui è che le dimensioni del tuo team influenzano il tipo di processo che puoi utilizzare per un determinato progetto. In genere, più persone hai in un progetto, maggiore sarà la rigidità di cui avrai bisogno. Man mano che le dimensioni della tua squadra diminuiscono, puoi farla franca con un processo meno formale. È responsabilità del tuo project manager monitorare il polso del team e adattare il processo per far sì che le cose si muovano senza intoppi.

L'esperienza della squadra

Quando lavori con un team inesperto, un processo più rigoroso aiuterà a mantenere tutti sulla stessa pagina. In effetti, credo che un team inesperto abbia bisogno di un processo concreto come contesto per acquisire esperienza. Solo dopo aver dimostrato il successo in un ambiente più rigido puoi iniziare a rimuovere gli strati del processo consentendo a un team più libertà nel modo in cui funziona.

Questo, ancora una volta, è un concetto abbastanza personale per me, soprattutto per il modo in cui organizziamo i team per un progetto. Mettiamo insieme un team unico per ogni progetto che prendiamo; anche nel corso di un progetto, è possibile ruotare le persone dentro e fuori dal team. Questo può creare sfide, soprattutto se l'esperienza di quegli individui è molto diversa. Per lo più, significa che dobbiamo essere consapevoli del fatto che persone diverse hanno bisogno di diversi livelli di processo per avere successo. I nostri project manager lo monitorano da vicino e si adeguano secondo necessità.

Abbiamo molti designer e sviluppatori esperti, quindi questo equilibrio riguarda principalmente la diffusione delle persone meno esperte. L'aggiunta di uno o due nuovi sviluppatori a un team altamente qualificato aumenterà il livello per tutti. I nuovi sviluppatori impareranno dai più esperti e i più esperti impareranno insegnando ai nuovi sviluppatori. Questo rende vincente!

La criticità del progetto

L'idea di quanto sia critico il progetto viene da un signore di nome Alistair Cockburn, uno dei firmatari originali del Manifesto Agile. Nei suoi scritti sui "Metodi di cristallo", Cockburn descrive la gamma di criticità completando questa affermazione.

I difetti causano la perdita di:

1. Comfort (non critico)
2. Denaro discrezionale (un po' critico)
3. Denaro essenziale (critico)
4. Vita (molto critica)

Più il nostro prodotto è critico, più rigido dovrebbe essere il nostro processo. Potresti averlo sperimentato se hai lavorato per piccole e grandi imprese. Le piccole aziende locali tendono a concederti più libertà nel modo in cui lavori perché hanno meno in gioco (criticità inferiori); le grandi aziende hanno molto più da perdere (criticità maggiore) se il tuo processo non produce buoni risultati.

Quando ho appena iniziato in questo settore, ho lavorato quasi esclusivamente con piccole imprese locali. Ho gestito progetti con note adesive, e-mail e una telefonata a settimane alterne. Ora, sono coinvolto con organizzazioni molto più grandi. La gestione di questi progetti richiede la partecipazione a stand-up giornalieri, retrospettive e riunioni di pianificazione degli sprint. Ci ritroviamo a costruire burn-up, a lavorare in JIRA (software di rilevamento dei problemi) e a calcolare la nostra velocità più di quanto io voglia ammettere. Tutto ciò è dovuto alla criticità del lavoro: una piccola percentuale di un numero abbastanza grande è ancora un numero enorme. Queste aziende più grandi lo capiscono e hanno messo in atto un processo per proteggerle da quelle formidabili perdite.

Dare priorità

Man mano che le dimensioni degli schermi per cui progettiamo diminuiscono, diminuiscono anche le nostre opzioni per comunicare la priorità. Pensaci: in genere utilizziamo elementi come dimensioni, posizione, ordine e contrasto per aiutare gli utenti a capire dove dovrebbero concentrarsi. Su un piccolo schermo, puoi fare solo così tanto con le dimensioni di un oggetto o la posizione di un titolo. Semplicemente non abbiamo le stesse libertà che abbiamo quando ci concentriamo su esperienze su schermi più grandi.

Per questo motivo, è fondamentale comprendere la priorità del contenuto e della funzionalità in un sistema. Luke Wroblewski ci ha brillantemente incoraggiato a pensare prima ai dispositivi mobili per aiutare i nostri clienti a capire ciò che è veramente importante. La verità è che, senza una solida comprensione delle priorità, il web design reattivo è solo congettura.

Abbiamo incoraggiato questo nei nostri clienti facendoli pensare in modo lineare molto presto nel processo. (Nella sezione "Come fare" di seguito, condividerò i tipi di strumenti che utilizziamo per farlo.) Il pensiero lineare ha il vantaggio di richiedere alle persone di scegliere ciò che è più importante, ed è questa priorità su cui è necessario un accordo. Stabilire questo subito nel tuo progetto getterà una base accettata su cui costruire e fornirà risposte a molte domande che ti ritroverai a porre più avanti nel progetto.

Di recente abbiamo avuto un progetto in cui il nostro cliente è venuto da noi con wireframe widescreen già assemblati. Lo avevano fatto nel tentativo di risparmiare un po' di soldi, e siamo stati felici di provare a lavorare con loro in questo modo. Quando abbiamo iniziato a progettare, il cliente non era soddisfatto del nostro lavoro. Solo a metà del progetto ci siamo resi conto che i wireframe widescreen non identificavano adeguatamente la priorità del contenuto e della funzionalità. Questo era il nocciolo dei problemi che stavamo avendo. Alla fine siamo tornati per eseguire alcune analisi del contenuto e la definizione delle priorità per riguadagnare slancio sul progetto. Se l'avessimo fatto prima, avremmo potuto lavorare in modo più efficiente durante tutto il progetto. Sfortunatamente, nel tentativo di aiutarli a risparmiare denaro, abbiamo dovuto eseguire alcune rielaborazioni che avrebbero potuto essere evitate se avessimo gettato prima le basi adeguate! Lezione appresa: stabilire la priorità in anticipo.

Quattro ideali

Mentre entri nel tuo prossimo progetto, tieni presente che devi includere il tuo cliente nel progetto. Cerca opportunità per collaborare con loro invece di lavorare solo per loro. Ricorda che più dimostri il valore all'inizio, più fiducia guadagnerai. L'iterazione ti aiuta a farlo: non aver paura di iniziare in piccolo! Inoltre, ricorda che dovrai sicuramente adattare il tuo modo di lavorare per adattarsi meglio a ciò di cui uno specifico progetto o cliente potrebbe aver bisogno. Infine, sforzati per stabilire una priorità di contenuto e funzionalità all'inizio del progetto. Ciò pagherà i dividendi più avanti nel progetto quando sorgono domande sull'importanza di determinati tipi di contenuti.

Al di là di questi quattro ideali, vorrei fornire un po' di una struttura per te mentre consideri quale tipo di processo funzionerà nella tua vita quotidiana.

Un quadro per considerare il processo

Il nostro processo è sempre in lotta per la sua vita

Una cosa che mi stupisce della maggior parte delle presentazioni o della scrittura sul processo è quanto sembrino fiduciose le persone che condividono. Forse siamo noi i valori anomali, ma il nostro processo è sempre in lotta per la sua vita. Se arriva un nuovo modo di lavorare, lo proveremo. Se pensiamo che ci sia anche solo un accenno di un modo migliore per fare qualcosa, scaveremo in giro cercando di scoprirlo. Questo è solo il modo in cui siamo cablati. Ho la sensazione che anche molti di voi siano cablati in questo modo.

Siamo d'accordo che il nostro processo non è mai completo.

Allontanarsi dagli hand-off lineari

La maggior parte del settore concorda sul fatto che dobbiamo smettere di gettare i risultati oltre il muro. Invece, molti stanno pensando a come riorganizzare i propri team nella speranza che il coinvolgimento delle persone giuste per tutta la durata del progetto aumenterà l'empatia dei compagni di squadra e alzerà l'asticella per tutti. Trent Walton lo descrive in modo eloquente nel suo post intitolato "Riorganizzazione". In esso, racconta che la struttura del tuo team spesso vincola il tipo di processo che puoi utilizzare e ci incoraggia a considerare team interdisciplinari più piccoli. Abbiamo visto che questo è vero e abbiamo adottato un approccio molto simile. In verità, i nostri processi lineari passati probabilmente sono sempre stati un po' inefficienti. Credo che il responsive web design abbia solo reso questa inefficienza molto più ovvia; affrontare il lavoro reattivo mi ha portato a conversazioni con i nostri clienti sulla loro struttura organizzativa: un'ulteriore prova del fatto che RWD è davvero un catalizzatore per il cambiamento organizzativo.

Abbiamo bisogno di coinvolgere più discipline per più progetti. Mi piace pensare a questo come a una spirale di un progetto con i nostri occhi fermamente concentrati sul prodotto finale, sull'unico risultato finale. Con ogni spirale attraverso, coinvolgiamo tutte le discipline e otteniamo più chiarezza in tutti i punti decisionali. Il concetto è semplice: consentire all'intero team di svolgere un ruolo per tutta la durata di un progetto. In altre parole, riconoscere e abbracciare l'impatto che apportare modifiche in un'area di un progetto ha sulle altre.

Io e il mio team siamo arrivati ​​a questa idea (a spirale attraverso un progetto) a causa delle nostre interazioni con un mio mentore aziendale. Si chiama Geoff ed è un ragazzo molto acuto. È stato CFO di alcune organizzazioni piuttosto grandi e ha fatto carriera aiutando i leader visionari a comprendere i dati finanziari della loro azienda.

Quando abbiamo incontrato Geoff per la prima volta, eravamo in modalità crisi. Avevamo una grande sfida davanti a noi, una sfida che né i miei partner né io sapevamo come affrontare. Geoff ci ha fatto sedere tutti e ci ha chiesto di "cominciare pensando alla fine". Voleva che spiegassimo come sarebbe stato dopo aver superato i tempi difficili che ci aspettavano. Voleva che definissimo il successo per questa volta nella vita della nostra azienda. Mentre continuavamo a incontrarci con Geoff, ho iniziato a sentirmi frustrato. Ogni volta che ci sedevamo, speravo che ci desse i consigli di cui avevamo bisogno per iniziare a risolvere il problema che stavamo affrontando. Invece, faceva continuamente sempre più domande. Questo è andato avanti per diverse settimane, ed è stato un momento difficile per me.

Non dimenticherò mai l'incontro che ho avuto con Geoff e i miei partner in cui tutto ha iniziato ad avere un senso. Il nostro incontro è iniziato come tutti gli altri; abbiamo esaminato la nostra attuale comprensione del problema prima di noi e ci siamo presi un po' di tempo per condividere ogni nuova intuizione che avevamo acquisito. Solo che questa volta, ognuno di noi ha iniziato a vedere emergere la soluzione. Non era perfettamente chiaro, ma cominciò a venire a fuoco. Delle tre opzioni che stavamo considerando, una cominciò a sembrare molto più allettante delle altre. Ciò che avevamo appreso negli ultimi mesi ci ha portato inequivocabilmente all'opzione migliore per affrontare il problema che stavamo affrontando.

Questa lezione è stata preziosa per me. Quello che mi ha insegnato è che un processo lineare ci richiede di prendere decisioni prima di avere tutte le informazioni. Come potremmo sapere tutto ciò che dobbiamo sapere per creare una serie di wireframe senza considerare il design visivo? Come possiamo perfezionare il design dell'interfaccia senza sperimentare del codice front-end? Quando ci comportiamo come se fosse possibile iniziare con il contenuto, quindi fare un po' di progettazione dell'esperienza utente, quindi un po' di progettazione dell'interfaccia utente e così via, ignoriamo l'impatto che ciascuno di questi risultati ha sugli altri. Invece, dobbiamo consentire loro di informarsi a vicenda. Dobbiamo dare loro spazio per respirare, adattarsi e utilizzare ciò che è stato appreso dal progetto per portarli avanti.

Questo è esattamente il processo a spirale attraverso il quale Geoff ci stava spingendo. Quelle settimane di domande stavano informando la nostra comprensione del problema. Invece di prendere una decisione (approvare un design dell'interfaccia utente) e andare avanti come se non cambiasse mai (OK, sviluppo front-end, vai a codificare questo design), Geoff ci ha costretto a riconoscere che non avevamo tutte le informazioni di cui avevamo bisogno per prendere la decisione migliore. Geoff voleva che aspettassimo "l'ultimo momento responsabile" per decidere.

Ho cercato di tradurre questa idea di spirale in ciò che facciamo ogni giorno e sono arrivato a una visualizzazione come questa:

Per favore, metti le tue discipline nelle fette di torta sopra: l'immagine è semplificata per illustrare l'approccio. È importante notare che quei punti non sono risultati finali nel senso tradizionale. Rappresentano l'opportunità per te di sederti con il tuo cliente e rivedere i tuoi progressi verso "l'unico risultato finale". Ciò significa: smetti di perfezionare i deliverable per paura di deludere il tuo cliente. È terribilmente inefficiente rendere belli i tuoi wireframe in Illustrator quando uno schizzo su una lavagna funzionerà. Abbiamo persino smesso di chiamarli risultati finali e abbiamo iniziato a chiamarli aggiornamenti .

Questo tipo di flusso di lavoro è abbastanza flessibile da poter essere utilizzato su qualsiasi tipo di progetto perché puoi semplicemente sostituire i tipi di discipline necessarie per il progetto. La cerimonia attorno al processo può essere resa più rigida o più improvvisata a seconda dell'esperienza delle persone coinvolte. La chiave è assicurarsi che tutte le persone siano coinvolte.

Questo approccio ritarda le decisioni finché non hai le informazioni giuste. Riconosce che le decisioni prese da una disciplina influenzeranno senza dubbio le altre. Apre la conversazione con il team e richiede il consenso di tutti i soggetti coinvolti. È meno formale ma più efficiente. È meno prevedibile, ma credo che abbia il potenziale per fornire un prodotto molto migliore.

Siamo d'accordo che dobbiamo cercare un contributo multidisciplinare.

L'efficienza è la chiave

Se avessimo tutto il tempo del mondo, non dovremmo preoccuparci del nostro processo: potremmo semplicemente provare cose fino a quando non ci siamo imbattuti in una grande idea. Io e te sappiamo entrambi che non è così.

Molte delle modifiche che apportiamo al nostro processo in Sparkbox sono dovute al fatto che stiamo cercando un modo più veloce per realizzare qualcosa. La promessa di una maggiore velocità è anche il modo in cui guadagniamo opportunità di lavorare con alcuni team interni di grande talento presso clienti più grandi. Tutti cercano guadagni di efficienza.

Siamo d'accordo che un buon processo è anche un processo efficiente.

In continua evoluzione. Multidisciplinare. Efficiente. Mentre entriamo nei dadi e bulloni di questa roba, voglio che teniamo a mente queste tre cose. Possiamo usare queste idee come filtro attraverso il quale prendere in considerazione nuovi approcci.

Basta teoria

Questa è abbastanza teoria. Entriamo nei dettagli di questo lavoro. Mi ritrovo a porre costantemente tre domande durante i nostri progetti web:

1. Per chi stiamo costruendo?
2. Cosa vogliamo che ottengano dall'esperienza?
3. Come dobbiamo presentare l'esperienza?

L'obiettivo è trovare un modo per dire le cose giuste (cosa) nel modo giusto (come) alle persone giuste (chi). Il segreto per una grande comunicazione di qualsiasi tipo è rispondere a queste domande. Ovviamente farai molte altre domande durante il tuo progetto. Domande come che tipo di schemi di navigazione dovrei usare su questo sito o abbiamo davvero bisogno di un annuncio nella parte superiore di ogni pagina? Sto suggerendo che avere le risposte a chi, cosa e come ti porterà nella giusta direzione mentre rispondi a tutte le altre domande che emergono.

Si spera che tu abbia già letto il capitolo di Dan Mall (poco prima di questo). In esso, fa un ottimo lavoro fornendo un contesto per capire con chi stai comunicando. Le sue spiegazioni sull'intervista e sugli incontri di inizio ti sposteranno solidamente nella giusta direzione.

Allo stesso modo, il prossimo capitolo di Eileen Webb riguarda la strategia dei contenuti per il tuo progetto responsive. È un capitolo completo e lei risponde alle domande su cosa stiamo cercando di comunicare meglio di quanto potrei mai fare.

Quindi, il resto di questo capitolo è dedicato a rispondere alla terza domanda: "Come?" Condividerò con te i tipi di strumenti che sono stati i più utili per me e il mio team di Sparkbox e confido che aiuteranno anche te!

Come farlo

Come accennato in precedenza, comprendere la priorità del contenuto e delle funzionalità che stiamo presentando è fondamentale per comunicare in modo efficace. Ecco alcuni modi in cui questa verità si manifesta nel lavoro che svolgiamo.

Guida alla priorità dei contenuti

Una guida alla priorità del contenuto è "in parte modellazione del contenuto, in parte wireframe ridotto" (vedi "Guida alla priorità del contenuto" di Emily Gray.); come un mini modello di contenuto, in ordine di priorità e con la collaborazione del cliente. (Vedi https://bit.ly/content-priority-guide per un esempio funzionante di una guida alla priorità dei contenuti.)

La guida alla priorità dei contenuti ti dice quali tipi di contenuti dovrebbero esistere in ogni pagina. Potrebbero essere cose semplici come il titolo, l'immagine principale e il corpo del post di un blog, oppure potrebbero essere molto più complesse: considera tutti i tipi di contenuto di cui potresti aver bisogno nella pagina dei dettagli del prodotto di un sito di e-commerce.

Consente inoltre la spiegazione di ogni tipo di contenuto. Se hai una breve descrizione di un prodotto, la guida alle priorità potrebbe dire: "Una frase che descrive il prodotto e ciò che lo rende unico". Per un oggetto come l'immagine di un eroe, potresti fornire alcuni dettagli sulla direzione artistica della foto se fosse pertinente per un caso specifico.

Le guide sulla priorità dei contenuti consentono inoltre di identificare rapidamente i componenti riutilizzabili. Questo è molto utile quando pianifichi la gestione di quel contenuto: riconoscere i modelli riutilizzabili significa che puoi costruire un sistema più efficiente per gestire il contenuto.

Ancora più importante, una guida prioritaria è in ordine di priorità . Provoca una discussione su ciò che è veramente importante in una pagina specifica. Questo aiuta enormemente quando consideri come risponderà un sito attraverso le larghezze del viewport. E poiché non contiene contenuto reale, facilita un'ottima conversazione sul cosa e il perché dei tipi di contenuto, che possono essere facilmente trascurati se inizi a scrivere immediatamente la copia.

Se i tuoi clienti hanno difficoltà a stabilire le priorità (e probabilmente lo faranno), potresti inserire queste decisioni su ciò che è più importante in un foglio di calcolo e fornire loro opzioni da controllare: primario, secondario, terziario, ecc. Il risultato è lo stesso: hai un elenco prioritario di tipi di contenuto per ogni pagina, ma il processo per arrivarci potrebbe sembrare un po' più amichevole per il cliente se gli vengono fornite alcune opzioni.

Informazione architettura

Una volta che hai una buona comprensione dei tipi e delle priorità dei contenuti che devono esistere nel sistema, è fondamentale considerare come raggruppare i contenuti e i percorsi attraverso i contenuti che desideri vengano seguiti dai tuoi utenti. Questo tipo di pensiero è fondamentale per la creazione di un sito utilizzabile.

Di recente ho visto Aaron Quinn parlare di architettura dell'informazione e ha detto qualcosa che mi è rimasto davvero impresso. Ha suggerito che potremmo fare troppo affidamento sul nostro buon senso quando si tratta di raggruppare le informazioni. Invece, ci ha chiesto di considerare il consenso sul buon senso quando pianifichiamo come i nostri utenti interagiranno con ciò che costruiamo. Lascia che ti spieghi perché con una breve storia.

Abbiamo un cliente con cui collaboriamo da più di un anno. Ha avviato un prodotto SAAS di grande successo che l'abbiamo aiutata a costruire. Questa donna è incredibilmente intelligente; lavora sul web ogni giorno: è così che si guadagna da vivere. Non molto tempo fa, stavo conversando con lei su ciò che sarebbe stato il prossimo passo per il suo prodotto e mi ha detto questo: "Penso che dobbiamo apportare alcune modifiche alle schede sul nostro sito". Mi sono fermato perché stavo cercando disperatamente di ricordare dove avevamo implementato le schede sul suo sito. Percependo la mia confusione, ha continuato a spiegare di più su ciò che sperava. Dopo qualche istante, ho capito che stava parlando della navigazione. È stato sorprendente che questa esperta imprenditrice del web si riferisse alla sua navigazione come "schede".

I tell you this because I want you to remember how much of a bubble we live in when we allow our instinct to drive the decisions we make. What may seem like common sense to you and me is likely a very different way of thinking about the web than pretty much all of our users. This is what Aaron Quinn was describing. We cannot rely on our instincts; we need to work with our users to find out how they think about the kinds of content we present to them. It's very difficult to remember this, but it makes a world of difference.

Now, back to planning the information architecture of a site given this context. Instead of grouping content that seems related to you using common sense, Aaron is suggesting we rely on the consensus of users . Information architecture is a very deep field. I can't pretend to cover the intricacies of this specialty in one section of one chapter. It's important you understand that it's impossible to do this kind of work well on an island. You must involve your client and the users of the site. Only then can you know if your intuition is correct.

Remove The Navigation

Let's agree that a good process is also an efficient process.

Ever-Evolving. Multidisciplinary. Efficient. As we jump into the nuts and bolts of this stuff, I want us to keep these three things in mind. We can use these ideas as a filter through which we consider new approaches.

Enough Theory

That's enough theory. Let's get into the nuts and bolts of this work. I find myself constantly asking three questions throughout our web projects:

1. Who are we building for?
2. What do we want them to gain from the experience?
3. How should we present the experience?

The goal is to find a way to say the right things (what) in the right way (how) to the right people (who). The secret to great communication of any kind is answering these questions. You will, of course, ask many other questions throughout your project. Questions like what kind of navigation patterns should I use on this site, or do we really need an ad at the top of every page? I'm suggesting that having the answers to who, what and how will lead you in the right direction as you answer all the other questions that come up.

Hopefully, you have already read Dan Mall's chapter (just before this one). In it, he does a great job providing some context around understanding who you're communicating with. His explanations of interviewing and kick-off meetings will move you solidly in the right direction.

Similarly, the next chapter by Eileen Webb is all about content strategy for your responsive project. It's a thorough chapter, and she answers the questions around what it is we're trying to communicate better than I ever could.

So, the rest of this chapter is dedicated to answering that third question, “How?” I'll share with you the kinds of tools that have been the most helpful for me and my team at Sparkbox and trust that they will also help you!

Getting It Done

As I mentioned earlier, understanding the priority of the content and functionality we're presenting is critical to communicating effectively. Here are a few ways this truth manifests itself in the work we do.

Content Priority Guide

A content priority guide is “part content modeling, part stripped-down wireframe” (see “Content Priority Guide” by Emily Gray.); like a mini content model, in priority order, and with client collaboration. (See https://bit.ly/content-priority-guide for a working example of a content priority guide.)

The content priority guide tells you what types of content should exist on each page. These could be simple things like the title, primary image and body copy on a blog post, or they could be much more complex: consider all the content types you might need on the product detail page of an e-commerce site.

It also allows for explanation of each content type. If you have a short description of a product, the priority guide may say, “One sentence describing the product and what makes it unique.” For an item like a hero image, you could provide some details about the art direction of the photo if that was relevant for a specific case.

Content priority guides also help you quickly identify reusable components. This is very helpful as you plan out the management of that content — recognizing reusable patterns means you can build a more efficient system to manage the content.

Most importantly, a priority guide is in priority order . It provokes a discussion about what's truly important on any specific page. This helps tremendously as you consider how a site will respond across viewport widths. And because it doesn't contain actual content it facilitates great conversation about the what and why of types of content, which can easily be overlooked if you start writing the copy immediately.

If your clients have difficulty prioritizing (and they probably will), you could place these decisions around what is most important into a spreadsheet and give them options to check — primary, secondary, tertiary, etc. The result is the same: you have a prioritized list of content types for each page, but the process to get there may feel a bit more friendly to the client if they're given some options.

Information Architecture

Once you have a good understanding of the types and priority of content that needs to exist in the system, it's critical to consider how that content should be grouped and the paths through the content you want your users to take. This kind of thinking is crucial to the creation of a usable site.

I recently saw Aaron Quinn speak about information architecture and he said something that really stuck with me. He suggested that we might be relying too much on our common sense when it comes to grouping information. Instead, he made the case for us to consider consensus over common sense when planning how our users will interact with what we build. Let me explain why with a quick story.

We have a client we've been working with for over a year now. She has bootstrapped a very successful SAAS product which we helped her build. This woman is incredibly smart; she works on the web every day — it's how she makes a living. Not too long ago, I was having a conversation with her about what was next for her product and she said this to me: “I think we need to make some changes to the tabs on our site.” I paused because I was desperately trying to remember where we had implemented tabs on her site. Sensing my confusion, she went on to explain more about what she was hoping for. After a few moments, I realized she was talking about the navigation. It was eye-opening that this savvy web entrepreneur referred to her navigation as “tabs.”

I tell you this because I want you to remember how much of a bubble we live in when we allow our instinct to drive the decisions we make. What may seem like common sense to you and me is likely a very different way of thinking about the web than pretty much all of our users. This is what Aaron Quinn was describing. We cannot rely on our instincts; we need to work with our users to find out how they think about the kinds of content we present to them. It's very difficult to remember this, but it makes a world of difference.

Now, back to planning the information architecture of a site given this context. Instead of grouping content that seems related to you using common sense, Aaron is suggesting we rely on the consensus of users . Information architecture is a very deep field. I can't pretend to cover the intricacies of this specialty in one section of one chapter. It's important you understand that it's impossible to do this kind of work well on an island. You must involve your client and the users of the site. Only then can you know if your intuition is correct.

Remove The Navigation

During some recent usability tests, I noticed that on small screens many users never attempted to locate or use navigation. These days, most of our small-screen navigation experiences are hidden behind obscure icons (hamburger, anyone?). I believe our expectation that users will properly identify, trigger and use our navigation is unfounded.

In an effort to combat this, we've begun considering a simple question — can someone use this site without the navigation?

Literally, remove the navigation from your site and see if your users can reach the content they want. In other words, plan out the content in such a way that your users can feel their way through the experience. Chances are, a good number of them will browse this way. We'd better be ready for them.

Style Comparisons

I learned about style comparisons when I had the opportunity to present with Dan Mall and Yesenia Perez-Cruz at Artifact Conference in Austin, Texas. Dan shared a story about how he was working to build a new office. Here's the relevant excerpt from his blog post:

“I could create an illustration or a 3D rendering of what I want my new office to look like, but that doesn't take advantage of his [the contractor's] great ideas. It's dictation, not collaboration. Instead, I show him a Pinterest board my wife and I created. I tell him that I love these beams or this mix of materials, and we can have a conversation. I revise my ideas through his expertise, and vice versa. This is how building a website should go.”

Not only is this a brilliant approach to building a new space, it can be applied directly to what we do each day. Our creative director, Jeremy Loyd, has been creating super-simple PDFs for our clients that ask them whether they think their brand would best be represented online with:

• A dark or a light site
• A flat or a textured site
• An illustrated or photographic site
• Whatever other style comparisons are relevant

You get the idea. The point is that it only takes a few minutes to put this together, because it doesn't really require any design. You can use screenshots of existing sites that embody the qualities you have questions about.

An approach like this is very useful when there isn't much clarity about the design direction up front. It helps us make sure we're in agreement about the direction we're headed. Truthfully, this is really just a simple tool to facilitate a conversation, to get people thinking and conversing about design.

One other trick from my friend Dan Mall which you can use to really drive this home is to quickly edit your client's logo into a screen capture of someone else's site. There is something about seeing their brand associated with a specific style which provokes a reaction. This makes for very fruitful conversations.

User Experience Design

No title in our industry is more overloaded and misunderstood than “user experience designer.” It means so many different things to so many different people. Recently, I've even noticed a trend toward expecting all designers and developers to do this work. And while I believe the best organizations have teams full of people who care about user experience, I also believe it has a deeper role to play.

I think about user experience as the glue that binds our design and our development together. It's what separates web design from other kinds of design — that our work is intended not only to be observed, but also to be interacted with. That interaction is so important. In my mind, a great user experience designer has an instinct for what will be easy for a user to understand. However, this must be balanced with the idea that design without testing is guesswork . For this reason, a great user experience designer knows how to research their users, how to collaborate with UI designers, how to prototype possible solutions, and how to select and execute usability studies to capture and analyze data which properly informs design and development.

Questo è molto. And since I'm not formally trained in user experience or human factors, I'm probably not qualified to write about each of those things. Instead, I want to focus on one lesson I've learned (see “Test the Aggregate”) and then share the kinds of updates we do with our customers to help us all agree on usability decisions across screen sizes and input methods.

Test The Aggregate

I work with internal user experience teams at larger clients, and one challenge I'm continually presented with is the desire to test the experience they are building at individual breakpoints. In other words, I've seen teams create three (or more) separate prototypes — for mobile, tablet and desktop — and then proceed to test each one independently. When this happens, each of these separate experiences will evolve on its own, usually resulting in three unique experiences which will be very difficult (if not impossible) to build in a responsive way.

To combat this, lately I've shared how critical it is to test the aggregate experience. Instead of building three separate prototypes for usability studies, build a single prototype with HTML and CSS that actually responds. We usually do this statically with an evolving set of front-end build tools (you can learn more about our front-end stack in the article “We Heart Good Tools: An Update on Our Build Process”) which means we can work quickly with fake data.

This concept is about letting go of the control you think you have. It's about making decisions which benefit the whole (the aggregate) even though they may require compromises in certain contexts. It recognizes that changes made at one of the breakpoints in your system will inevitably affect the experience at other breakpoints. It's about embracing the benefits you get with a single code line and adjusting our usability studies to account for this.

Se stiamo costruendo in modo reattivo, dobbiamo concentrarci sul test di una soluzione a sito singolo su larghezze di viewport. Dobbiamo misurare l'usabilità dell'insieme, non solo i punti di interruzione. Questo ci aiuterà a creare l'esperienza più utilizzabile per la maggior parte delle persone.

E ora, alcuni aggiornamenti che utilizziamo con i nostri clienti per aiutare a raggiungere questi obiettivi.

Contenuto prototipo

Hai sentito dire che un web designer dovrebbe imparare un po' di CSS, giusto? Bene, sono d'accordo e penso che un content strategist dovrebbe imparare un po' di HTML. Per questo motivo, e per molti altri, abbiamo creato prototipi di contenuti molto presto nel nostro processo di sviluppo web. Non appena iniziamo a ottenere un'immagine chiara del contenuto effettivo, iniziamo a contrassegnare quel contenuto con l' ipertesto . Questo è ciò che facciamo con l'HTML, giusto? Chi meglio avvolgere il contenuto in tag semantici se non le persone che capiscono meglio il contenuto? Sebbene anche strumenti come Markdown possano funzionare, penso che sia meglio imparare un po' di HTML di base prima di passare direttamente a Markdown. Capire perché stai scrivendo il contenuto in questo modo è importante tanto quanto scrivere effettivamente l'HTML. Strumenti come Markdown aggiungono uno strato di astrazione tra le tue azioni e l'output di quelle azioni: un'astrazione che va bene, una volta capito cosa ti dà.

Quando creiamo un prototipo di contenuto, tralasciamo intenzionalmente quasi tutti gli stili. Li lasciamo piuttosto brutti, quindi è molto chiaro che non abbiamo progettato nulla. Ciò mantiene la conversazione focalizzata sul contenuto e sulla priorità di quel contenuto. Sappi che quando mostri questo a un cliente, lui si occuperà immediatamente dell'ordine delle cose, che è esattamente ciò che vuoi che faccia: ottieni quella priorità giusta! Inoltre, di solito includiamo CSS quanto basta per mostrare i raggruppamenti, in questo modo:

Te l'avevo detto che era brutto.

Inondiamo anche i nostri prototipi di contenuti con link. Uno dei motivi per cui li creiamo è consentire alle persone di navigare da una pagina all'altra, per vedere se il flusso attraverso il contenuto funziona.

Ricorda, devi preparare i tuoi clienti a vedere questo tipo di brutto aggiornamento. Altrimenti, avranno sicuramente dei ripensamenti sul coinvolgerti nel loro progetto. Tuttavia, c'è qualcosa di potente nel vedere i contenuti non elaborati contrassegnati in un browser.

Una nota importante: riconosciamo che il markup puramente semantico probabilmente non è ciò che andrà in produzione. Anche se questo sarebbe l'ideale, la realtà del lavoro sul web oggi è che deve essere gestibile ed estendibile da individui e team con competenze estremamente diverse. Tuttavia, iniziare con questa versione pura del markup è un modo fantastico per ricordarci i nostri ideali. Quindi, mentre modifichiamo il markup per consentire lo stile, la riutilizzabilità, l'estendibilità e così via, siamo molto consapevoli che ogni modifica che apportiamo ci allontana dall'ideale. Ogni cambiamento è un compromesso e dovrebbe essere considerato profondamente come tale prima di essere apportato.

Wireframe statici

Gli ultimi anni hanno visto un po' di disgusto per i wireframe statici più tradizionali. Credo che possano ancora aggiungere molto valore. Credo anche che potrebbero non essere necessari in ogni progetto. Quando li utilizziamo, in genere li eseguiamo a larghezze ridotte - per quanto scomodo sia questo - per aiutarci a concentrarci sulla priorità. Limitare la nostra proprietà visiva forza questa attenzione. Abbiamo utilizzato molti strumenti per farlo, da Keynote a Balsamiq. Onestamente, uno qualsiasi di questi strumenti farà il lavoro. Trovane uno con cui ti senti a tuo agio e mettiti al lavoro.

Facciamo anche molti schizzi. Lavagne, carta e matita, varie app per disegnare. Scattiamo foto di questa roba e la condividiamo con i nostri clienti, mantenendo intenzionalmente tutto molto grezzo. La crudezza è una parte importante di ciò che facciamo. Aiuta i nostri clienti a sapere che non stiamo perdendo tempo a lucidare documenti che non trarranno vantaggio dalla lucidatura e mantiene il feedback concentrato. L'ultima cosa che vogliamo è qualcuno che commenti i colori dei nostri wireframe.

Wireframe interattivi

Parte dell'allontanamento dai wireframe più tradizionali è stata a favore di un approccio più interattivo. Come il Manifesto Agile promuove il software funzionante rispetto alla documentazione, molti nel nostro settore credono che dimostrare l'intenzione di un'interazione tramite un prototipo sia molto più potente che cercare di descriverlo staticamente. Al giorno d'oggi, gli strumenti disponibili per la prototipazione rapida sono estremamente efficaci: framework come Bootstrap e Foundation; Toolkit CSS (o Sass e LESS) come Bourbon e Pure CSS; strumenti di prototipazione visiva come InVision e Marvel. Anche strumenti di progettazione e sviluppo web visivi come Macaw o strumenti di presentazione come Keynote possono essere utilizzati per creare wireframe molto interattivi.

Il vantaggio di questo approccio è che puoi mostrare alle persone l'idea invece di cercare di spiegargliela. Se un'immagine vale più di mille parole, un prototipo vale più di mille immagini.

Ora stiamo lavorando con un'organizzazione che lo capisce. Uno dei loro obiettivi è portare la prototipazione rapida all'inizio del loro processo in modo che possano utilizzare i prototipi per studi di usabilità, oltre che per il codice di produzione. Il nostro lavoro con loro si concentra sulla creazione di un sistema di componenti che possono essere utilizzati in tutte le loro proprietà web. Questo sistema verrà eventualmente utilizzato anche per consentire al proprio team di creare wireframe interattivi molto rapidamente. Poiché l'avremo costruito pensando ai loro marchi, i wireframe interattivi assomiglieranno molto alle loro versioni di produzione, il che sarà estremamente utile nei loro test UX.

Questo tipo di approccio si concentra sul successo a lungo termine di una proprietà web. Incarna il flusso di lavoro "un deliverable" di cui abbiamo parlato in precedenza, coinvolgendo tutte le discipline nella creazione del prototipo e consentendo a ciò che viene appreso durante la sua progettazione e sviluppo di informare ulteriori decisioni. Credo che stiamo assistendo a un cambiamento verso le organizzazioni che creano sistemi front-end maturi invece di hackerare insieme CSS come ripensamento. Dare a un'organizzazione la possibilità di testare una versione statica del proprio lavoro sul Web con utenti reali è un passo importante per cementare questa norma come norma nel prossimo futuro.

Progettazione e sviluppo dell'interfaccia utente

"Un buon design è risolvere i problemi."

— L'arte e la scienza del web design, Jeffrey Veen (2000) .

Per quelli di voi che sono designer, questa citazione suona molto vera. Molte persone vedono cosa facciamo come decorazione, ma è molto di più. Negli ultimi anni, mi sono ritrovato pienamente d'accordo con il sentimento dell'affermazione di Jeff, ma anche profondamente consapevole della tendenza dei designer a perfezionare eccessivamente le proprie soluzioni. Questo mi porta a quello che chiamo "il punto di commutazione".

Se suddividi l'attività di progettazione in tre fasi - stabilire l'estetica, risolvere il problema e perfezionare la soluzione (come indicato sopra) - il passaggio dalla risoluzione dei problemi al perfezionamento della soluzione è il punto di svolta. Questo è l'ultimo momento responsabile per entrare nel mezzo del web. Se non lo fai, finirai per eseguire quella fase di perfezionamento più volte, e questo è altamente inefficiente.

Se hai mai passato ore a modificare un PSD, l'hai consegnato a uno sviluppatore per costruirlo e poi ricontrollato in una o due settimane, hai provato questo dolore. Tutto lo sforzo che hai fatto per perfezionare e perfezionare spingendo i pixel statici in giro è sprecato. Non appena il design cambia media (dal design statico in Photoshop o qualche altro strumento a HTML e CSS nel browser) è necessario un altro passaggio di perfezionamento. L'idea alla base del punto di commutazione è riconoscere quanto sia inefficiente. Invece di perfezionare con strumenti statici, fai codificare il design di base il prima possibile e gestisci il perfezionamento nel mezzo finale: il web.

Questo spesso richiede un abbinamento di design, letteralmente seduti insieme per dare vita a quelle raffinatezze. Anche se a volte può sembrare lento e doloroso, in realtà è estremamente benefico per tutti i soggetti coinvolti. Poiché un designer condivide con uno sviluppatore front-end i tipi di modifiche di stile che vorrebbe vedere, lo sviluppatore front-end impara cosa è importante in un design raffinato. Mentre lo sviluppatore front-end apporta le modifiche richieste, il designer vede come vengono apportate tali modifiche, forse imparando un po' di CSS. Questo processo rende tutti più intelligenti. Significa anche che la prossima volta che questi due accoppiano, andrà molto più veloce.

Al giorno d'oggi, dobbiamo essere a nostro agio con una serie di strumenti per avviare le conversazioni dell'interfaccia utente e dobbiamo spostare la codifica di quei progetti all'inizio del processo. Diamo un'occhiata ad alcuni modi per farlo.

Piastrelle in stile

Samantha Warren ha aperto nuovi orizzonti quando ha introdotto le tessere di stile come un modo per "definire un linguaggio visivo" per il web. Quelli di noi con un background di branding hanno immediatamente visto quanto potrebbero essere preziose le piastrelle di stile.

Le tessere di stile sono abbastanza semplici. In genere includono tavolozze di colori, scelte tipografiche, trame e stili iconografici o illustrativi. Non sono deliberatamente un comp. Invece, rappresentano un design appena sufficiente per determinare se ci stiamo muovendo nella giusta direzione. Per questo motivo, funzionano meglio quando il tuo cliente ha espresso ciò che desidera, ma non sei completamente convinto di essere sulla stessa lunghezza d'onda.

Ho imparato ad apprezzare le tessere di stile, soprattutto per la loro velocità. Laddove trascorrevamo una settimana a progettare una home page e una sottopagina in Photoshop, ora possiamo creare un semplice riquadro di stile nel giro di poche ore. Questo può far risparmiare tempo e denaro e darti la certezza che ti stai muovendo nella giusta direzione.

Samantha ha una manciata di esempi sul sito dei riquadri di stile e ci sono alcune ottime risorse elencate di seguito che coprono il loro utilizzo nel processo del mondo reale:

• "Get Your (Visual) Style On": Yesenia Perez-Cruz, Dan Mall e la mia presentazione alla Artifact Conference di Austin, Texas (13 maggio 2013).
• "Decisioni di design più rapide con le piastrelle di stile": Samantha Warren a An Event Apart ad Austin, in Texas (febbraio 2015).
• Il podcast della guida di stile con Samantha Warren

A causa della loro natura statica, non li usiamo troppo spesso. La nostra direzione di progettazione iniziale è in genere stabilita con un collage di elementi o un prototipo di stile, entrambi trattati in seguito.

Collage di elementi

Dan Mall ci ha presentato i collage di elementi come "un assemblaggio di pezzi disparati senza logica o ordine specifico". La loro natura variegata rende evidente che quello che stai guardando non è un progetto finalizzato; piuttosto, i collage di elementi forniscono ai clienti il ​​contesto di una varietà di componenti che potrebbero vivere insieme in un sistema. Ci aiutano a mettere un po' di carne sulle ossa di un wireframe; ci aiutano a immaginare la direzione in cui ci stiamo muovendo; ci consentono di iniziare a visualizzare gli elementi costitutivi del nostro sito, ma ci incoraggiano a non perdere di vista l'insieme.

Uno dei vantaggi dei collage di elementi è che puoi scegliere quali componenti mostrare. Al tuo cliente interessa davvero come viene presentata la ricerca ai propri utenti? Grande! Forse dovresti dedicare un po' di tempo ad affrontare questa preoccupazione: mettila nel collage degli elementi. Il tuo cliente è ossessionato dai pulsanti di invito all'azione? Mettili nel collage di elementi. Questa mentalità "scegli e scegli" rende facile personalizzare ogni collage con ciò che è più importante nel tuo progetto. I tuoi clienti lo apprezzeranno enormemente.

Su un progetto recente, dovevamo stabilire la direzione progettuale per una riprogettazione di una delle proprietà web del nostro cliente. Katie Kovalcin (una delle nostre designer) stava guidando lo sforzo di progettazione del nostro team e ha scelto di creare collage di due elementi invece di creare composizioni per la home page.

Il tempo totale che abbiamo investito nella creazione di questi due concetti di design è stato di circa 16 ore. Quando ho chiesto a Katie quanto tempo ci sarebbe voluto se le fosse stato chiesto di fare due composizioni sulla home page, ha risposto:

“In questo passaggio, cercando di capire la loro nuova estetica, sarebbe difficile destreggiarsi tra la ricerca di quell'estetica mentre si cerca di definire la gerarchia della pagina e anche di capire le interazioni. Quindi, per disporre l'intera home page come un modo per capire l'estetica a volte poteva richiedere fino a una settimana, a seconda di quanto dovevamo lavorare. Direi probabilmente vicino a 25-30 ore ciascuno.

Ma uscendo dal collage di elementi, è stato abbastanza facile andare avanti con il layout della pagina e tutte le altre cose perché non c'è molta confusione per capire quali stili di pulsanti useremo, o caratteri o colori .”

Ciò significa che, utilizzando un collage di elementi, abbiamo ridotto in quarti la quantità di tempo che abbiamo dedicato alla creazione di un'estetica.

C'è un'altra espressione davvero interessante nella citazione di Katie sopra; ha detto "sarebbe difficile destreggiarsi tra la ricerca di quell'estetica mentre si cerca di definire la gerarchia della pagina e anche di capire le interazioni". In altre parole, iniziare con una home page comp sta cercando di ottenere troppo, troppo presto. Quando facciamo prima un passo più piccolo (usando collage di elementi o tessere di stile), siamo in grado di dividere e vincere le sfide di progettazione che ci attendono. Questo porta i nostri clienti nella conversazione più frequentemente e ci consente di imparare mentre procediamo, il tutto con conseguente miglioramento del lavoro.

Prototipi di stile

Puoi pensare ai prototipi di stile come a riquadri di stile interattivi. Gli stessi tipi di elementi che potresti includere in un riquadro di stile (marchio del marchio, titoli, stili di paragrafo, stili di pulsanti, trattamento dei collegamenti, consigli sui colori) sono inclusi in un prototipo di stile. L'unica differenza è che lo facciamo un passo avanti e lo codifichiamo.

Il bello di questi è che possiamo mostrare il tipo di web reale, i colori reali, gli stati al passaggio del mouse reali, lo stile di illustrazione con i vettori web e come potrebbero rispondere il tipo e il layout di base. Chiediamo ai nostri clienti di esaminarli nel loro browser preferito. Questo apre conversazioni su cosa significa supportare un browser. Ad esempio, se utilizzano un browser che non supporta border-radius , non vedranno gli angoli arrotondati.

Possiamo anche costruire prototipi di stile in circa un giorno, il che ci offre gli stessi vantaggi in termini di efficienza che ci offre una tessera di stile. I clienti li adorano perché possono interagire con loro. Possono vederli sui loro telefoni e tablet. Possono iniziare a giocare con loro.

Infine, in un mondo in cui la maggior parte di noi crede che i web designer dovrebbero imparare a programmare, i prototipi di stile sono una fantastica introduzione alla scrittura di HTML e CSS. Grazie alla loro semplicità, anche un progettista non codificante può capire come costruirli. Prima che se ne accorgano, avranno la sicurezza di perfezionare i CSS di produzione, invece di simulare staticamente le modifiche che vogliono vedere.

Quando abbiamo progettato il sito originale di Sparkbox, e quando l'abbiamo riprogettato di recente, abbiamo utilizzato prototipi di stile per stabilire una direzione progettuale.

Disegno atomico

Jeremy Keith mi ha presentato per la prima volta l'idea di iniziare la progettazione con "gli atomi di un sito" durante il suo keynote Breaking Development intitolato "Non esiste Web mobile". Brad Frost ha formalizzato il termine nel giugno 2013 quando ha delineato un modello mentale per avvicinarsi alla progettazione di un “sistema di componenti” per il web.

La premessa di base è che dovremmo considerare cinque livelli di granularità nel nostro lavoro per realizzare sistemi di componenti riutilizzabili. Il livello più piccolo è chiamato atomo; pensa a un semplice input HTML o a un'etichetta per un input. Questi atomi possono essere combinati in molecole; forse una molecola di ricerca è composta da un pulsante, un'etichetta e un input. Queste molecole possono essere combinate per formare organismi; forse l'intestazione di un sito web conterrebbe le molecole di ricerca, brand e navigazione. Questi organismi vengono messi insieme per formare modelli e pagine. I modelli sono pieni di dati generici; le pagine sono modelli che contengono dati reali iniettati. Tutta questa teoria può aiutarci a creare codice più modulare, riutilizzabile ed estensibile.

Una cosa che ho imparato mentre ci avvicinavamo ai nostri progetti seguendo questa linea di pensiero è che il design atomico è molto più semplice quando gli si consente di evolversi dal refactoring. Un modo comune per lavorare è costruire un piccolo componente in HTML e CSS senza preoccuparsi troppo di atomi, molecole o organismi. Quindi, una volta risolto il problema di UX e UI con un'interfaccia, possiamo refactoring di quel codice in una struttura atomica. Questo approccio inverso significa che non perdiamo tempo nel tentativo di pensare troppo a cosa dovrebbe essere una molecola rispetto a un organismo. Al contrario, permettiamo ai vari livelli di evolversi man mano che il sistema stesso si evolve.

Il risultato di un approccio atomico è una libreria di modelli che possono essere integrati in un sistema.

Librerie di modelli

Una libreria di pattern è proprio quello che sembra: una libreria di pattern che esistono nel tuo sistema. Ci sono molte persone che lavorano su soluzioni di libreria di modelli in questi giorni; persone come Brad Frost, Anna Debenham, Jina Bolton e Bermon Painter hanno parlato e scritto sull'argomento. Infatti, Brad e Dave Olson hanno creato uno degli strumenti più conosciuti oggi disponibili, Pattern Lab. Pattern Lab è ottimo perché ti consente di separare il contenuto specifico dai moduli HTML e fornisce un framework atomico che semplifica la creazione di un sistema di pattern. Hanno anche aggiunto alcune fantastiche funzionalità per i test mentre sei in fase di sviluppo. Il tutto è molto facile da eseguire localmente e ha un'interfaccia semplice che può essere facilmente mostrata a un client. Se stai cercando di entrare nel design basato su modelli, questo è un punto di partenza fantastico.

Molte cose stanno accadendo in questo spazio in questo momento e ci sono molte altre risorse per quelli di noi interessati a saperne di più. Brad ha lavorato con Anna Debenham e Brendan Falkowski (insieme a poche altre persone) per creare risorse per la guida allo stile del sito web. Questa è una straordinaria raccolta di molti esempi, articoli, discorsi, podcast e altro ancora che riguardano la progettazione e lo sviluppo basati su modelli.

Finora, la sfida più grande è trovare un modo per mantenere aggiornata una libreria di modelli dopo che i modelli sono stati integrati con un sistema back-end. Non ho ancora visto la soluzione perfetta per questo, ma ci sono molte menti brillanti che ci stanno lavorando. Dai un'occhiata a Rizzo di Lonely Planet come un ottimo esempio di organizzazione che lavora diligentemente per risolvere proprio questo problema. Anche se non abbiamo una soluzione perfetta a lungo termine, ho visto enormi vantaggi dalla progettazione in questo modo. Ti fa pensare in modo modulare e questo rende il lavoro front-end che facciamo molto più facile da integrare e mantenere.

E i punti di interruzione?

Ogni volta che parlo o scrivo di processo, mi viene sempre chiesto di selezionare i punti di interruzione. Stranamente, questa conversazione non si pone quasi mai nel nostro lavoro reattivo quotidiano. Certamente, alcuni clienti si rivolgono a noi dopo aver svolto un sacco di lavoro per la revisione delle analisi e la definizione delle priorità dei dispositivi, il tutto in nome della documentazione dei punti di interruzione del sistema. Questa linea di pensiero non ha mai avuto molto senso per me.

Credo che sia stato Stephen Hay a dirlo per primo: "Inizia in piccolo e aggiungi un punto di interruzione quando il sito si interrompe". I nostri siti hanno spesso dozzine di punti di interruzione, la maggior parte di essi non si allinea alle dimensioni comuni dei dispositivi. Quando vedi che i tuoi contenuti e il tuo design non funzionano più in armonia, aggiustalo.

Ora, c'è una differenza tra ciò che Stephanie Rieger chiama breakpoint maggiori e breakpoint minori. (Li ho anche sentiti chiamare breakpoint e tweakpoint.) Lascia che ti spieghi ciascuno.

Principali punti di rottura

Quando ci sono cambiamenti nel layout che richiedono moduli separati per lavorare insieme nella loro modifica del design, utilizziamo un punto di interruzione comune (un punto di interruzione principale). Forse hai una regolazione del layout che sposta un elenco impilato di prodotti con larghezze di visualizzazione ridotte in un layout a due colonne con larghezze di visualizzazione più grandi. In questo caso, ti consigliamo di tenere traccia di dove si verifica questo spostamento del layout perché è probabile che ci siano molte altre modifiche che devono verificarsi alla stessa larghezza della finestra.

La maggior parte del lavoro che facciamo ha da tre a sei punti di interruzione principali. Queste sono spesso impostate come variabili Sass nel nostro flusso di lavoro in modo da poterle apportare modifiche in un secondo momento in un unico posto. È anche comune per noi avere una serie di punti di interruzione principali per le sezioni principali di un sito. Ad esempio, potremmo avere tre punti di interruzione principali nell'intestazione del nostro sito e tre punti di interruzione principali completamente diversi nel piè di pagina. Ciò mantiene il nostro lavoro modulare e consente a queste sezioni di evolversi in modo indipendente pur mantenendo la coesione con il sistema nel suo insieme.

Punti di interruzione minori

Quando sono necessarie modifiche più sottili al tipo o alla spaziatura, possiamo comunque utilizzare una query multimediale per apportare queste modifiche (un punto di interruzione minore). Si tratta in genere di modifiche di stile una tantum per cose come la dimensione del carattere (per tenere sotto controllo la lunghezza della linea) o per aumentare la spaziatura all'aumentare della larghezza della finestra. Questi piccoli aggiustamenti dimostrano una profonda attenzione ai dettagli che può davvero distinguere il tuo lavoro.

Invece di utilizzare variabili del preprocessore per questi, in genere utilizziamo solo numeri hardcoded. In alcune occasioni abbiamo anche utilizzato i calcoli del preprocessore per mantenerli relativi a un punto di interruzione principale. Ad esempio, se abbiamo un punto di interruzione principale a 30em chiamato $bp_header-show-nav , potrei voler regolare la dimensione del carattere di un'intestazione a 5em sopra il punto $bp_header-show-nav . In questo caso, ciò accadrebbe a 35 em. Se dovessimo spostare quel punto di rottura principale a 32 em in futuro, il cambiamento minore avverrebbe a 37 em. Pensare relativamente con punti di interruzione minori può aiutare se si sospetta che i punti di interruzione principali possano cambiare. Dovrai usare il tuo giudizio caso per caso per prendere le decisioni migliori.

Ulteriori letture

Per ulteriori informazioni sui punti di interruzione, consulta questi articoli:

• "Non c'è punto di rottura"
• "The In-Between" di Mark Boulton
• "Design pragmatico reattivo" di Stephanie Rieger

Transizione fuori

Al giorno d'oggi, non è sufficiente creare siti fantastici. Dobbiamo anche considerare la longevità di ciò che costruiamo. Mentre approcci come il design atomico possono aiutare, dobbiamo fare di più. Al momento, la maggior parte dei nostri progetti include una sorta di componente di formazione e non sto parlando di insegnare al cliente a utilizzare il CMS. Quando le organizzazioni iniziano a comprendere veramente il valore che il web offre loro, decidono di creare i propri team per possedere e mantenere le proprie proprietà web. Se vogliamo costruire qualcosa che duri, dobbiamo assicurarci che il team che si assume il nostro lavoro sia in grado di mantenerlo adeguatamente. Per questo motivo, stiamo facendo una formazione molto più approfondita sulle tecniche che utilizziamo per costruire per il web.

Fortunatamente, ora ci sono molti modi comuni per affrontare la transizione. Ogni repository che creiamo nel controllo del codice sorgente ha un utile file readme; forniamo test automatizzati a supporto del nostro codice; e stiamo lavorando su alcuni modi per trasferire il budget delle prestazioni di un progetto in modo che i nostri clienti continuino a mantenere la velocità dei loro siti. Insieme al pensiero atomico, forniamo anche esempi funzionanti di sottosistemi che costruiamo. Ad esempio, è comune per noi considerare come funziona la tipografia in tutte le proprietà web nel contesto del marchio di un cliente, quindi potremmo anche fornire una documentazione dettagliata su questo sistema tipografico, nonché una pagina di esempi che mostrano come utilizzarlo. Questo tipo di aggiunte al nostro lavoro semplifica notevolmente il passaggio del codice dal nostro team al team del nostro cliente.

Ci sono anche ripercussioni più profonde in tutto questo. Capire chi manterrà il sistema che stai costruendo dovrebbe anche influenzare le decisioni che prendi in merito alla scelta della tecnologia e alla tecnica di sviluppo. In altre parole, se il team web del tuo cliente non è pronto per usare Grunt con Assemble e un server locale dalla riga di comando, devi trovare un modo di lavorare che corrisponda meglio alle loro capacità. Ricorda, lo stai costruendo per loro.

È stato anche estremamente vantaggioso invitare i team di progettazione e sviluppo web del nostro cliente a partecipare con noi al progetto. Usare il progetto come un'opportunità per formare il team del tuo cliente dimostra un valore incredibile e ti rende una scelta facile tra i tuoi concorrenti.

Persone oltre il processo

Un'ultima cosa che ho imparato evolvendo costantemente il nostro flusso di lavoro è che il processo che scegli di utilizzare è molto meno importante delle persone che lo utilizzano. Se vuoi creare prodotti web migliori, inizia sviluppando il tuo personale. Questo ti porterà oltre qualsiasi modifica al tuo processo o flusso di lavoro.

Mantieni felice la tua squadra

Sulla stessa linea, consiglierei di leggere Flow di Mihaly Csikszentmihalyi. In questo libro, spiega la ricerca che ha svolto per comprendere meglio la felicità individuale. Descrive quello che chiama "canale di flusso", tracciando il livello di abilità lungo l'asse x rispetto al livello di sfida lungo l'asse y . Il canale di flusso è l'area in cui la tua abilità incontra una sfida adeguata. Troppa sfida per la tua abilità crea ansia e una sfida troppo piccola per la tua abilità si traduce in noia.

Questo può essere tradotto in ciò che facciamo considerando dove ci sfidiamo nel nostro lavoro quotidiano. In Sparkbox parliamo di una cultura dell'apprendimento. Questo (si spera) significa che l'abilità della mia squadra è in continuo aumento. Ne consegue, quindi, che per essere felici dobbiamo trovare sfide sempre crescenti che corrispondano alle nostre abilità in continua crescita. È nostra responsabilità bilanciare questa esigenza di innovazione con la responsabilità finanziaria nei budget che i nostri clienti hanno.

Questo è difficile. Per noi significava che dovevamo smettere di reinventare la ruota; ci ha portato a considerare librerie di elementi di interfaccia ben testati invece di risolvere ripetutamente gli stessi problemi su ogni progetto. Significa che dobbiamo capire dove ciascuno dei nostri clienti dovrebbe spendere soldi per innovare. E ha richiesto un po' di trasparenza tra quei clienti e il nostro team in modo da essere tutti sulla stessa pagina.

Alla fine, crea un team più contenuto, uno che ama il lavoro che fa perché li sfida nel modo giusto. E crea un client più contenuto, uno che rispetta i tuoi consigli su dove e perché dovrebbero investire. Questo è eccellente per tutti i soggetti coinvolti.

Avanti

Questa è la parte in cui ti ispiro profondamente e ti incoraggio a sfidare un nuovo audace mondo del web design. Ma, ad essere onesto, ho faticato a riassumere un sentimento di chiusura per questo capitolo.

Dopo un po' di riflessione, credo che ciò sia dovuto al fatto che la scrittura sul processo non viene mai completata.

Spero che, leggendo queste parole, ti sia sentito più ispirato a investire nella tua comprensione di come funziona il web e più disposto a investire nella comprensione dei tuoi compagni di squadra. Spero che ti sia sentito entusiasta di provare un nuovo approccio, ma spero anche che ti sia sentito autorizzato a strappare queste pagine se non funzionano per te. Solo tu, il tuo team e il tuo cliente potete capire il modo migliore per affrontare un progetto. Questa è la natura di ciò che facciamo.

Il momento è adesso - quindi, arrivarci!