Prototipi di workflow

La tecnica è semplice, parlare è difficile#section1

È facile fissarsi sui benefici di particolari tecniche o strumenti e supporre che quei benefici siano ovvi per chiunque. Ma nel corso dell’anno passato, ci è apparso chiaro che soddisfare le richieste del nostro web multi-device è in minor parte un problema di tecnica e in maggior parte di comunicazione. A volte le persone devono solo capire perché volete che cambino il proprio modo di lavorare.

Prima del progetto del Franklin Institute, i miei colleghi ed io abbiamo riunito tutte queste tecniche ma istintivamente ci siamo concentrati sui pezzi che influenzavano la nostra parte di processo. I designer e i developer parlavano e sognavano, ma perlopiù all’interno di stanza con l’eco delle loro rispettive discipline. Quindi, quando venne il momento di far partire il progetto, abbiamo dovuto fare dei discorsi difficili su come avrebbero funzionato le nuove tecniche per tutti noi come team e a volte siamo stati totalmente scettici sui suggerimenti altrui. In più di un’occasione ci siamo chiesti l’un l’altro: “È grandioso e funziona per quell’agenzia, ma come funzionerebbe qui?”

Allora probabilmente dovrete addurre buone motivazioni adattandole in maniera differente per ogni persona del vostro team. Se siete un designer, potrebbe voler dire spiegare ai vostri colleghi developer che vorreste cominciare a suddividere le cose in un sistema di design così che non dobbiate fare venti diverse iterazioni per lo stesso layout di pagina. Per gli sviluppatori, potreste dover convincere il vostro capo che uno “style prototype” sarà il modo migliore per presentare un sito al vostro cliente.

Qualunque sia la logica, rendetevi conto che il cambiamento rappresenta un costo effettivamente reale (almeno a breve termine) per i vostri colleghi, in termini di tempo e di comodità, e il loro scetticismo potrebbe essere una reazione a questo costo piuttosto che ai benefici meno immediati che dite che ne deriveranno. Concentrarsi sul perché invece che sul come può aiutarvi ad equilibrare queste due forze contrastanti.

Limitate il focus#section2

Al momento in cui scrivo, Bluecadet ha 22 membri dello staff a tempo pieno. È sufficientemente grande da rendere difficile lavorare sugli intricati dettagli di un cambiamento di processo a livello aziendale. Pertanto, partiamo in piccolo, a livello di progetto, invece di provare a realizzare un processo monolitico che viene passato dall’alto.

Date uno sguardo ai progetti che avete all’orizzonte. Pensate alle parti del vostro workflow che volete migliorare e scegliete nesolo una da introdurre nel vostro progetto. Perché solo una? Perché vi dà sufficiente spazio per sperimentare senza mettere in pericolo il vostro progetto.

Un mio mentore una volta mi disse che programmare (e in particolar modo programmare per il web) si riassume tutto nella riduzione del numero di “unknown” in un progetto a un numero gestibile. Uno va bene, due sono stiracchiati, tre è chiamare i problemi. Se pensate che esplorare i wireframe HTML/CSS possa avere un impatto positivo sul vostro lavoro, introducete solo loro. La maggior parte dei progetti ha già abbastanza attrito di per sé senza aggiungere o cambiare più processi allo stesso tempo.

Per il progetto del Franklin Institute, alla fine abbiamo deciso che l’innovazione che avremmo aggiunto sarebbero state le front-end style guide. Non si trattava di un gran cambiamento, ma era uno dei piccoli passi che pensavamo avrebbero potuto avere grandi benefici senza influenzare la nostra tabella di marcia.

Abbiamo preso questa decisione basandoci su due fattori, che potrebbero tornarvi utili quando con il vostro team penserete a quale potrebbe essere “quella singola cosa” da introdurre:

• Una buona idea che non ha funzionato molto bene in passato: avevamo creato una style guide statica per un progetto precedente, che rapidamente era diventata datata e quindi era stata eliminata, ma noi continuavamo a pensare che l’idea avesse degli aspetti positivi. Quindi, quando vi riunite come team, pensate a delle buone idee che avete avuto in passato, che magari si sono arenate e in che modo potrebbero funzionare se si cambiasse l’approccio ad esse.
• (Un po’ di) esperienza insieme (a molto) entusiasmo: si era unito al nostro team un nuovo front-end developer che aveva già sperimentato vari generatori di style-guide come Barebones e Pattern Lab e, cosa più importante, era eccitato all’idea di crearne uno. Qualcuno ha qualcosa che sta testando su un progetto personale o che ha usato con successo in un lavoro precedente? Se è così, siete già a metà strada: potreste solo dover trovare come inserirlo.

Allineate strumenti e tecniche con il vostro team#section3

Una delle discussioni ricorrenti che facciamo nel nostro studio è: “I nostri designer dovrebbero imparare a scrivere markup e cominciare a fare parte di questo processo di design nel browser?”. Abbiamo sentito numerose tesi persuasive a favore di questa idea, ma alla fine, abbiamo deciso che il focus principale dovrebbe essere come far arrivare i design nel browser prima nell’ambito del nostro processo, invece di chi dovrebbe fare quel lavoro.

Questo ci ha portato a provare a far lavorare insieme i designer e gli sviluppatori prima rispetto al solito durante il progetto e a fare in modo che lo sviluppatore creasse del markup che “seguisse la scia” degli schizzi e delle esplorazioni in Photoshop del designer. Abbiamo scoperto che così facendo traiamo vantaggio dai punti di forza dei singoli membri del nostro team. Significa anche che i nostri sviluppatori forniscono un feedback che rientra nelle iterazioni sul design mentre è ancora malleabile.

Attualmente siamo nel mezzo di un progetto di redesign di un magazine letterario e abbiamo scoperto che i rozzi mockup HTML/CSS creati dal nostro sviluppatore ci hanno aiutato a porre le domande giuste alla designer del nostro team. Dare alla nostra designer un problema specifico da risolvere (“Questi titoli occupano troppo spazio nelle larghezze più strette”) le ha permesso di giudicare il problema nel contesto dell’intero design. Ha potuto così poi spiegare cosa stava cercando di ottenere a livello visuale e perfino di trovare soluzioni che si estendevano oltre il problema immediato che stavamo cercando di risolvere. Guardava lo schermo mentre allargavamo e restringevamo il browser e poi diceva qualcosa come “Se sposti i titoli sotto alle foto, tutto questo problema sparisce”. Allontanarsi dalle idee dogmatiche riguardanti chi dovrebbe fare cosa le ha permesso di concentrarsi a fare quello che le riesce meglio, ossia risolvere problemi visuali.

Distinguere tra bisogni interni ed esterni#section4

Quando si cominciano a fare dei cambiamenti, si potranno cominciare a produrre dei deliverable importanti ma solo per il pubblico interno. Questo potrebbe essere perché hanno un’utilità limitata per il cliente o semplicemente non sono sufficientemente maturi. Gestire le aspettative è tanto importante quanto provare una nuova tecnica, quindi se il cliente vedrà qualcosa di nuovo dovrete investire del tempo per prepararlo a quello che riceverà, specialmente se non è il modo in cui è abituato a lavorare.

Per un progetto attuale stiamo producendo dei wireframe HTML/CSS per avere un’idea di quanto tempo effettivamente ci voglia per realizzarli. Dal momento che non lo sappiamo (ancora), il primo giro di deliverable per il cliente saranno ancora dei wireframe statici fatti in Photoshop. Se ci sembrerà che i prototipi HTML/CSS saranno sufficientemente maturi, li presenteremo al cliente nel giro finale.

Mentre lavorate, poi, datevi sufficiente spazio per fare degli aggiustamenti: cosa succede se ci vuole il doppio per produrre quel wireframe? Cosa succede se il cliente fa resistenza a mettere in parallelo le conversazioni sul wireframe e sul design? E se la cosa che avete prodotto ha un valore ma solo se accompagnata da altri deliverable?

Concentratevi sui prodotti, non sulle presentazioni#section5

Una delle cose che avremmo dovuto fare era chiarire l’obiettivo finale. Sembra ovvio: “Stiamo facendo un sito web”, ma se il vostro processo è in un qualche modo simile al nostro, in realtà passate molto tempo a creare di tutto fuorché un sito web. Per la maggior parte, farete foto di un sito web.

Recentemente, mentre lavoravo a una beta build di un sito web, ho scoperto che la maggior parte dei membri del team del nostro cliente stava usando delle versioni molto vecchie di Internet Explorer e di Firefox. Queste persone erano sorprese nel vedere qualcosa che differiva così tanto dai comp che gli erano stati presentati ad uno stadio precedente del processo.

Questa esperienza ci ha insegnato molto. Creare delle aspettative nel cliente è un modo per evitare sorprese, ma piano piano, come team, stiamo convenendo su una cosa: il browser è l’arbitro finale di quello che facciamo, quindi smettiamola di spingerlo in fondo alla linea di produzione. I componenti del nostro processo devono supportare il prodotto finale in ogni step del percorso.

Mettete in agenda il prototipo del vostro processo#section6

È facile fare di sì con la testa ed essere d’accordo su qualcosa: “Questo lo facciamo!”. Ma quando vi immergete nel lavoro di dettaglio, è altrettanto facile dimenticarsi di quella nuova cosa che eravate d’accordo di mettere nel mix. Pertanto, assegnate a qualcuno il compito di assicurarsi di rivedere i vostri prototipi di processo più volte. Questo potrebbe voler dire che dovete cominciare ad incontrarvi più frequentemente. Noi abbiamo trovato utile avere dei meeting ufficiali, ma la nostra speranza è che alla fine cominceremo a fare tutto questo in maniera meno strutturata, scegliendo di incontrarci informalmente quando sentiamo il bisogno di discutere qualcosa.

Se state lavorando in un team project-based, ricordatevi di condividere quello che state facendo con gli altri gruppi. Per esempio, in un progetto recente, abbiamo implementato dei blocchi di contenuto modulari che potrebbero essere riordinati al bisogno, ispirati da un post di Christopher Butler di Newfangled. Poi abbiamo mostrato quello che stavamo facendo ad una collega, che ha integrato qualcosa di quello che ha imparato nel suo successivo progetto. Ha anche posto delle domande acute che ci hanno aiutato a migliorare l’esperienza di content-authoring per il nostro cliente.

Condividendo con gli altri, si vince tutti: i vostri colleghi useranno le vostre nuove skill e voi sarete costretti a chiarire i vostri obiettivi e le vostre supposizioni.

Iterate il vostro workflow (giocate al gioco che dura di più)#section7

Quando rielaborerete il vostro processo, sarà bene tenere un log progressivo delle cose (sia positive sia negative) che avete incontrato ad ogni nuovo cambiamento introdotto:

• Qualcosa ha richiesto più (o meno) tempo del previsto?
• Ci sono state persone influenzate negativamente dal cambiamento?
• Come ha reagito il cliente?

Scomponendo le cose in parti più piccole, sarete in grado di valutarne l’efficacia. Potrete tenere quelle che hanno funzionato e rifinire (o scartare) quelle che non hanno funzionato. È inoltre importante avere un forum in cui condividere questi pezzi: in Bluecadet abbiamo fatto in modo che la condivisione fra di noi delle lezioni apprese dai progetti completati diventasse una parte regolare del meeting mensile di tutto lo staff.

Nel corso di tre progetti distinti, abbiamo finora testato sul campo:

• il contenuto ed il layout atomico/modulare
• le front-end style guide
• i wireframe HTML/CSS

Questo è quanto: ciascuna di queste cose che abbiamo provato le faremo probabilmente solo un po’ in maniera diversa la seconda volta, alla luce di tutti i dati che abbiamo raccolto dal primo giro di prova. Se ci fossimo seduti a discutere fino a che non fossimo stati sicuri del “Nuovo Modo di Fare le Cose”, beh, saremmo ancora là seduti a discuterne oggi.

Una delle cose di cui sono particolarmente orgoglioso è che lavorando pezzo per pezzo abbiamo fatto progredire il nostro workflow in parallelo all’essere onesti con i nostri clienti. Una delle nostre guideline interne è che tutti i nostri clienti non devono finanziare il nostro progetto di remodeling del workflow: la messa a punto deve risultare in benefici tangibili per noi al nostro interno, ma, ancora più importante, deve portare ad un prodotto migliore per i nostri clienti.

Provate qualcosa di nuovo. Adesso.#section8

Mentre finisco di scrivere questo articolo, stiamo provando un’altra cosa che speriamo di aggiungere a quella lista: prototipi HTML/CSS come design deliverable. Forse sostituiranno i comp statici oppure semplicemente li accompagneranno, non lo sappiamo ancora, ma va bene non saperlo. Per l’autunno probabilmente staremo realizzando cose molto diverse da adesso, grazie alle informazioni ricavate dagli esperimenti che facciamo man mano.

Spero che questo incoraggi voi e il vostro team a fare anche solo dei piccoli passi. Riunitevi e parlate delle parti del vostro workflow che possono essere migliorate, scegliete una cosa da provare insieme e cercate di capire dove potete infilarla. Come noi, probabilmente non riuscirete mai a tirare una riga sul calendario e a dire “Ecco il momento in cui abbiamo cominciato a fare le cose nel modo giusto”, ma vi andrete molto più lontano, un passo alla volta.

Illustrazioni: {carlok}