I professionisti 80/20 sono comunicatori migliori

Ho passato la maggior parte del 2014 lavorando a due redesign: uno per una grande catena di pizzerie, l’altro per un importante venditore di biciclette. Il team coinvolto nei redesign, composto da cinque persone inclusa me, era oltremodo esaltato perché potevamo lavorare su due enormi siti riguardanti due nostre passioni: pizza e bici! Ci tenevamo tanto ad essere realmente coinvolti in ogni fase di questi progetti per essere sicuri del loro successo. Lungo il percorso, abbiamo imparato importanti lezioni su come affinare un tale coinvolgimento per arrivare a un risultato migliore.

Lavorare con lo stesso team su due progetti contemporaneamente ci ha permesso di sperimentare un po’ con i nostri processi e di fare dei confronti. Il sito per la Pizza, basato su un e-commerce, aveva il focus principale sui flussi utente, quindi abbiamo cominciato creando i wireframe HTML per ogni pagina: quelle che una volta erano sembrate idee grandiose su una lavagna si erano trasformate in prototipi funzionanti! Muovendoci nel design, i prototipi hanno preso vita in tutta la loro gloria di formaggio fuso. Ma arrivati al nono mese di lavoro, non appena abbiamo cominciato a rifinire i template, abbiamo realizzato che stavamo osservando la terza puntata dello stesso redesign.

Non è una circostanza insolita: spesso i team ricreano involontariamente i design più volte nelle varie fasi. Il risultato finale non è per niente come l’obiettivo che il team si era prefisso. Qual è la causa di questo scollegamento?

Nella mia esperienza, deriva da una comunicazione insufficiente tra team con vari insiemi di competenze. Alcuni team sono composti da specialisti che vogliono tutti far sentire le proprie idee e le proprie voci (con risultati molto variabili) mentre si lotta per tempo, risorse e budget. In alternativa, quando un generalista lavora sull’intero sito, rischia di avere troppe cose da fare: la lotta tra esplorare ed iterare può produrre soluzioni superate e prevedibili. Sia la troppa specializzazione sia la troppa generalizzazione possono sopraffare i professionisti (e i budget) e nessuno dei due approcci funziona.

Come diventare un professionista 80/20#section1

Fortunatamente, c’è un modo migliore. Quando i designer e i developer (e i web team interi) lavorano a stretto contatto, con flessibilità e comprensione condivisa, possono utilizzare il loro tempo e le loro risorse in maniera più efficiente e creativa. Sia che il vostro processo sia a cascata o agile, una solida base del team si applica a tutti: vi permette di dare forma ad una soluzione che giova a tutti i membri di un team di progetto.

Per evitare gli errori che abbiamo commesso nel nostro processo per il Sito Pizza, abbiamo bilanciato in maniera diversa le nostre responsabilità per il Sito Bici. Siamo diventati quelli che io chiamo professionisti 80/20, focalizzandoci per l’80% del nostro tempo sui propri punti di forza, distribuendo il restante 20% tra altre discipline per il bene dell’intero progetto.

La collaborazione 80/20 riguarda le persone, le passioni. Sembra grandioso, vero? Allora, da dove si comincia?

Stabilite la base#section2

Essere un bravo professionista significa vedere oltre sé stessi, per raggiungere gli obiettivi e soddisfare i bisogni più grandi del proprio team. Mentre date forma al vostro processo è importante mantenere una discussione aperta e onesta con i vostri colleghi di team. Fate un inventario comprensivo delle persone del vostro team. Invece di etichettare qualcuno come “designer” o “developer”, fate un bilancio del loro effettivo insieme di capacità e passioni. Ho lavorato con degli strepitosi graphic designer, degli incredibili UX designer e dei sorprendenti interaction designer, che avevano tutti lo stesso titolo: designer. Quello che funziona dipende dalla persona.

Abbiamo tutti sentito il discorso che i designer devono scrivere codice. E mentre questo può essere l’ideale in alcuni casi, il punto sta nell’espandere il proprio spettro personale di capacità per essere più utili al proprio team, sia che questo significhi acquisire conoscenze di design, content strategy, UX o addirittura project management. Per creare una solida base per il team, si comincia identificando quali buchi debbano essere riempiti e se ci sono spazi in cui le persone possono venirsi incontro. In qualità di professionisti, potete identificare anche voi dove dovreste sviluppare il vostro 20% di abilità in surplus in un progetto.

Se immaginate il vostro team come uno spettro di capacità, ogni persona dovrebbe avere un insieme di skill che copre una parte dello spettro (con una certa sovrapposizione con un’altra parte). Facciamo finta che questo spettro vada dal graphic design (rosso), al codice (blue), con tutte le sfumature di viola nel mezzo. Come Designer, vado dal più rosso dei rossi a un viola rossastro. Questo lascia fuori il resto del viola e del blu perché possano essere presi da qualcun altro. Supponiamo che il mio team includa un ibrido designer/developer, Ava, che ha tutte le sfumature di viola. Supponiamo anche che io abbia nel mio team anche un backend developer solo blu, Carter. In questa istanza, abbiamo coperto tutte le basi con le nostre competenze. Se fossimo stati solo io e Carter, però, saremmo rimasti con un significativo vuoto nel mezzo. Avremmo bisogno o di estendere il nostro 20% di insieme di skill nell’area viola o di aggiungere un’altra persona per riempire il vuoto. Le estremità dello spettro varieranno da persona a persona e da team a team.

Rafforzare i punti deboli#section3

Ogni volta che qualcuno mi ha detto “Dovresti scrivere codice!”, ho sempre pensato “Ma lo sviluppatore McCoderson può farlo molto meglio e molto più velocemente di quanto non potrò mai farlo io!”. Ed era vero, per cui ho continuato la mia ”full immersion” nel design. Nel tempo, però, lavorando tutti i giorni a stretto contatto con i miei sviluppatori sul Sito Pizza, il mio interesse è cresciuto lentamente. Una volta che ho cominciato a incorporare i wireframe HTML nel mio processo di design, ho cominciato a vedere in che modo potevano essermi utili. Potevo aggiornare il contenuto più rapidamente, il mio layout era automaticamente responsive e potevo concentrarmi solo sulla gerarchia dei contenuti piuttosto che preoccuparmi di ridimensionare i box ogni volta che cambiava il contenuto.

Più mi rendevo conto che i deliverable programmati potevano essere deliverable di design, più capivo che potevo mostrare le interazioni al cliente in anticipo. Animazioni, dropdown, popover, etc.: queste cose sono design. Vogliamo quanto prima il feedback del cliente su questi aspetti perché apparentemente dettagli minori come gli hover riflettono il brand e rinforzano il design tanto quanto la scelta di un’immagine o dei colori.

Questa scoperta è stata così liberatoria che in effetti da quel momento in poi volevo includere il codice nel mio processo perché preferivo lavorare in quel modo, non solo perché pensavo “Questo mi renderà una designer migliore“. Adesso mi ritrovo a leggere di mia spontanea volontà cose come gli SVG inline e l’elemento picture e quasi non mi riconosco!

Date un’occhiata sincera al vostro processo e cercate in che direzione volete espandere il vostro 20%, non dove pensate dovreste espanderlo. Torniamo per un secondo a Carter, il backend developer. Magari vuole migliorare le sue skill front-end, ma cosa intende per “front-end“? Il suo codice o il suo occhio per il design? Quello che gli manca probabilmente non è un talento per scrivere del meraviglioso codice DRY, ma piuttosto la capacità di riconoscere delle sfumature di design. Magari potrebbe cominciare col leggere articoli sulla tipografia o controllare altre risorse di design, invece di tuffarsi in JavaScript.

Una volta che comincerete a riconoscere queste aree secondarie, potrete cominciare a portare i vostri nuovi interessi offline ed esplorare meetup e talk diverse da quelli a cui partecipereste di solito. Ho scoperto che nulla mi ha aiutato a migliorare il mio 20% di skill più del semplice fare amicizia con sviluppatori di grande talento, sia sul posto di lavoro che fuori.

Imparare gli uni dagli altri#section4

Lo sviluppatore del team Sito Bici ha creato un file Grunt con tutti i bisogni dell’intero team, inclusi i design deliverable e il modo in cui gestiamo i wireframe. Una volta che tutto ha cominciato ad essere all’interno di un project hub basato sul codice, eravamo tutti sempre aggiornati. Potevamo buttarci in qualcosa e aiutarci a vicenda come necessario, specialmente nei giorni stressanti della consegna. Anche il project manager era capace di usare ed aggiornare l’hub.

Anche gli sviluppatori hanno imparato da me. Averli coinvolti dal primo giorno ha significato che erano inclusi in molte delle nostre design review. Cominciavano a capire il processo di pensiero dietro alle nostre decisioni di design e tutti potevano capire in maniera olistica il sistema che stavamo creando insieme. Quando abbiamo cominciato a definire la parte dei wireframe e quella della user experience del sito, ogni membro del team aveva dei suggerimenti guidati dal comportamento e dall’esperienza e questi suggerimenti hanno trovato un loro posto nel progetto, sia in termini di come sarebbe apparso visivamente sia di come l’avremmo realizzato. Con tutti coinvolti fin dall’inizio, le nuove idee, che in precedenza non sarebbero mai state considerate, avevano influenzato i deliverable, sia che fosse stato uno sviluppatore a suggerire un design pattern fuori dagli schemi o un designer a creare un performance budget.

Quando si verificano queste conversazioni, le barriere tra i compagni di team spariscono gradualmente. Probabilmente vi suggerirete dei tool gli uni con gli altri e comincerete a fondere i processi. In questo processo di merge, prenderà forma un nuovo processo collaborativo. Quando ci prendiamo in prestito a vicenda i propri tool, cominciamo ad apprenderne i benefici e come potrebbero funzionare per i nostri bisogni e alla fine cominciamo a parlare lo stesso linguaggio. Essere allineati su obiettivi di progetto oggettivi aiuta a tenere in ordine le revisioni e a stabilire più facilmente le discrepanze. Non si tratta di rendere più semplice il lavoro di chiunque, ma si tratta di concentrarsi su quello che è meglio per il progetto. Un processo condiviso non è qualcosa che potete semplicemente decidere di fare, piuttosto, emerge dall’imparare come lavora un’altra persona.

Mettete da parte l’ego#section5

Per programmare rapidamente un design, la direzione generale deve essere approvata per la maggior parte dal cliente. Dico “principalmente“ perché le iterazioni migliori avvengono nel browser una volta che cominciamo ad interagire con i nostri design. Qui è dove le sovrapposizioni sullo spettro del 20% entrano davvero in gioco. Ci saranno buchi nel design che dovranno essere riempiti e sta allo sviluppatore creare una roadmap utile su cui il designer potrà iterare. Immaginate che un primo concetto di homepage venga approvato e ci buttiamo nelle iterazioni di sviluppo, ma io non ho ancora avuto modo di assegnare degli stili ai dropdown della navigazione. Mi piace quando gli sviluppatori fanno un tentativo di styling di queste cose. Se necessario, posso sempre migliorare i dettagli che mi sembra non vadano bene. Quando gli sviluppatori hanno un po’ di senso del design, sono in grado di buttarsi nel procedimento e di prendere decisioni di design che il designer potrebbe non aver considerato in un layout fluido o per un certo comportamento. I designer adorano essere perfezionisti, ma dobbiamo imparare a lasciar andare e a non essere spaventati dal permettere agli sviluppatori di saltare nella programmazione di un template di un mockup “imperfetto“.

Non c’è niente di sbagliato nel progettare parti e moduli man mano che lo sviluppatore trova buchi nella pagina o nelle media query. Come sostiene Dan Mall, si tratta di decidere nel browser, non di fare design nel browser. Potreste non aver ancora deciso tutto, ma va bene: lo capirete più avanti. I nostri siti web sono fluidi e così dovrebbero essere anche i nostri processi.

Riorganizzare un processo non è facile#section6

Il cambiamento può essere difficile per qualunque organizzazione, specialmente quando sono state stabilite delle linee guida rigide per i processi attuali. Dovete lavorare per abbattere qualsiasi barriera di comunicazione, sia conoscendo un nuovo membro del team in un nuovo progetto, sia lavorando all’interno della vostra organizzazione per eliminare i silos, o cercando di introdurre una nuova idea di workflow con il vostro capo. Un processo malleabile è un processo forte.

Il posto migliore da cui cominciare sono i vostri project manager. È difficile inserire un nuovo processo in un progetto in corso retroattivamente, quindi cercate di inserire questo aspetto nella fase di pianificazione. Se state per cominciare un progetto, fate conoscere al manager le vostre idee e come potrebbe essere formato un po’ diversamente il project plan. È importante che il project manager capisca il piano così che possano dare delle aspettative in linea con questo al cliente. È ugualmente importante che capiscano come ne sarà influenzata la timeline, dal momento che potrebbe discostarsi dal tipico flusso a cui è abituato il vostro team.

Nelle grandi organizzazioni, i manager potrebbero aver bisogno di girare le idee al di là dei manager degli altri dipartimenti. Cercate di capire se il vostro prossimo progetto può essere un giro di prova per sperimentare un nuovo processo e offritevi volontari per guidare l’iniziativa. Samantha Warren ha fatto una fantastica presentazione a An Event Apart sul far circolare le idee di design in un’organizzazione. Se questo non sembra fattibile, cercate di creare voi stessi delle relazioni con le vostre controparti. Cercate di capire se sono aperti a provare nuovi metodi e a lavorare più a stretto contatto. Se riuscite ad imbarcare più persone, potrebbe essere più facile convincere chi si trova in posizione di potere che si potrebbe provare qualcosa di nuovo. I team che lavorano organicamente bene insieme sono una dimostrazione potente di quanto possa essere efficace la collaborazione.

Tutti ne traggono benefici#section7

Buttatevi a capofitto nelle vostre passioni mentre cercate di capire le parti in movimento attorno a voi. Padroneggiare la propria specialità non è solo cruciale per lo sviluppo professionale e per la soddisfazione personale, ma serve anche al vostro team perché contribuite ad allargare ulteriormente lo spettro delle competenze.

Quando parliamo apertamente degli obiettivi finali condivisi, il nostro lavoro di squadra diventa più forte. Quando saltiamo su e aiutiamo con i deliverable cross-disciplinari, il nostro lavoro di squadra diventa più forte. Ma ancora più importante, quando combiniamo i nostri punti di forza collettivi e lavoriamo insieme fluidamente, abbiamo la ricetta perfetta per un progetto strepitoso.

Siate fedeli alle vostre passioni, ma prendetevi del tempo per imparare qualcosa degli insiemi di capacità degli altri che aiutino a creare un unico team dinamico. La linea guida 80/20 è un posto a cui aspirare, un posto in cui spingiamo le nostre capacità e passioni mentre arricchiamo la nostra conoscenza così da poter lavorare meglio con i nostri compagni di team. Essere un professionista 80/20 vi rende più forti e crea un team più forte.

Illustrazioni: {carlok}