{"id":467,"date":"2014-07-25T11:35:40","date_gmt":"2014-07-25T09:35:40","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/prototipi-di-workflow\/"},"modified":"2014-07-25T11:35:40","modified_gmt":"2014-07-25T09:35:40","slug":"prototipi-di-workflow","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/prototipi-di-workflow\/","title":{"rendered":"Prototipi di workflow"},"content":{"rendered":"

Lo scorso anno, la digital agency per cui lavoro, Bluecadet<\/a>, cominci\u00f2 un progetto di website redesign per The Franklin Institute<\/a>, un famoso museo della scienza di Philadelphia, che stava affrontando la pi\u00f9 grande espansione della sua storia. I miei colleghi ed io eravamo entusiasti perch\u00e9 non solo potevamo lavorare con un’istituzione locale iconica, ma anche perch\u00e9 il progetto rappresentava un’opportunit\u00e0 per incorporare un numero di tecniche nelle nostre pratiche riguardanti il responsive web design: atomic design, HTML wireframes, style tiles, element collage e front-end style guide. Avevamo previsto una serie di rapidi prototipi che avrebbero conferito slancio a un armonico “avanti e indietro” tra il design e lo sviluppo. Avevamo la sensazione che si trattasse di un’opportunit\u00e0 per esaminare a fondo il modo in cui creavamo per il web, dall’inizio alla fine.<\/p>\n

E ci siamo bloccati.<\/p>\n

Non riuscivamo a trovare dove inserire tutte queste nuove tecniche nel nostro modo preferito di lavorare. Non penso che siamo gli unici a sentirci cos\u00ec. Il modo in cui creiamo per il web sta cambiando cos\u00ec rapidamente che, se avete partecipato ad un numero sufficiente di conferenze o letto abbastanza libri e blog negli ultimi due anni, potreste sentirvi come noi: eccitati ma un po’ sopraffatti e preoccupati che la vostra organizzazione sia l’unica a non aver ancora adottato il<\/em> modo approvato dall’esperto di creare per un web device-agnostic.<\/p>\n

Tuttavia, c’\u00e8 un pericolo seducente presente ogni volta che si vede qualcuno descrivere il proprio modo di lavorare. \u00c8 facile ritenere il suo processo come una rigida verit\u00e0 universale. Il problema \u00e8 che voi e il vostro team non siete come tutti gli altri: avete punti di forza e debolezze diversi. Adottare interamente il processo di qualcun altro ignora il fatto che probabilmente gli ci sono voluti molti tentativi per arrivare a quel punto e ci vorr\u00e0 moltissima sperimentazione da parte del vostro team per capire cosa funziona per voi.<\/p>\n

Quindi probabilmente la soluzione non sta nel trapiantare la guideline di qualcun altro nel tentativo di sistemare l’intera cosa in un colpo solo. Magari c’\u00e8 un modo per usare lo stesso spirito iterativo di queste nuove tecniche ed applicarlo all’intero workflow. In altre parole, per prototipare il vostro workflow. Per certi aspetti, \u00e8 un trucco mentale: un modo per dare a voi stessi il permesso di provare delle cose, anche se non siete sicuri del risultato. Inoltre, riduce anche la posta della scommessa ad un livello in cui ci sentiamo a nostro agio: se ci incasiniamo qui, siamo ancora a posto<\/em>.<\/p>\n

Quella che segue, poi, non \u00e8 una ricetta ordinata o una formula: \u00e8 un insieme di osservazioni che spero vi aiuteranno a rilanciare il cambiamento nel workflow come un processo continuo fatto di piccoli e imperfetti passi.<\/p>\n

\n

La tecnica \u00e8 semplice, parlare \u00e8 difficile<\/h2>\n

\u00c8 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 \u00e8 apparso chiaro che soddisfare le richieste del nostro web multi-device \u00e8 in minor parte un problema di tecnica e in maggior parte di comunicazione. A volte le persone devono solo capire perch\u00e9 volete che cambino il proprio modo di lavorare.<\/p>\n

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\u00f9 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\u00f9 di un’occasione ci siamo chiesti l’un l’altro: “\u00c8 grandioso e funziona per quell’agenzia, ma come funzionerebbe qui<\/em>?”<\/p>\n

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\u00ec 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\u00e0 il modo migliore per presentare un sito al vostro cliente.<\/p>\n

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\u00e0, 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\u00e9<\/em> invece che sul come<\/em> pu\u00f2 aiutarvi ad equilibrare queste due forze contrastanti.<\/p>\n<\/div>\n

\n

Limitate il focus<\/h2>\n

Al momento in cui scrivo, Bluecadet ha 22 membri dello staff a tempo pieno. \u00c8 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.<\/p>\n

Date uno sguardo ai progetti che avete all’orizzonte. Pensate alle parti del vostro workflow che volete migliorare e scegliete nesolo una<\/em> da introdurre nel vostro progetto. Perch\u00e9 solo una? Perch\u00e9 vi d\u00e0 sufficiente spazio per sperimentare senza mettere in pericolo il vostro progetto.<\/p>\n

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 \u00e8 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\u00e0 abbastanza attrito di per s\u00e9 senza aggiungere o cambiare pi\u00f9 processi allo stesso tempo.<\/p>\n

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.<\/p>\n

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:<\/p>\n