Design Talks: una migliore collaborazione tra designer e sviluppatori con Aaron Walter di InVision

Benvenuti alla nostra serie di Design Talks dedicata alla condivisione delle intuizioni di leader di pensiero e persone di spicco impegnate nel design di tutto il mondo. Intervistiamo esperti che lavorano con il design in contesti diversi, con obiettivi diversi e attraverso approcci diversi. In queste serie, speriamo di fornire ispirazione intellettuale e creativa a tutti i nostri lettori.

I designer spesso faticano a lavorare con gli sviluppatori e viceversa. Le squadre di entrambe le parti potrebbero imparare moltissimo l'una dall'altra, ma rimangono livelli di resistenza. L'ospite di questa settimana è Aarron Walter, VP of Design Education presso InVision e parleremo della collaborazione tra designer e sviluppatori.

Aarron attinge a 15 anni di esperienza nella gestione di team di prodotti e nell'insegnamento della progettazione per aiutare le aziende a mettere in atto le migliori pratiche di progettazione. Ha fondato la pratica UX di MailChimp e ha contribuito a far crescere il prodotto da poche migliaia di utenti a oltre 10 milioni.

La sua guida alla progettazione ha aiutato la Casa Bianca, il Dipartimento di Stato degli Stati Uniti e dozzine di importanti società, startup e società di venture capitalist. È l'autore del libro più venduto Designing for Emotion di A Book Apart. Troverai @aarron su Twitter che condivide pensieri sul design e puoi saperne di più su Aarron su aarronwalter.com.

On the Design Better Podcast gli host Aarron Walter ed Eli Woolery intervistano leader e influencer del design che condividono storie su come risolvono i problemi e sul loro percorso professionale. Gli ospiti includono David Kelley (co-fondatore di IDEO e fondatore di Stanford d.school), Julie Zhuo (VP di Product and Design su Facebook) e Jake Knapp (autore di Sprint più venduto), tra gli altri.

Ciao Aarron, è un piacere averti sul blog di Toptal Design. Gli sviluppatori vengono da Marte e i designer da Venere?

Nella mia esperienza, designer e sviluppatori hanno probabilmente più cose in comune di quanto non si rendano conto, ma ci sono sicuramente alcune differenze nette nel modo in cui pensiamo alle cose. I progettisti adorano pensare ai sistemi di progettazione e gli sviluppatori pensano a un codice modulare di facile manutenzione. Ma il modo in cui lo facciamo potrebbe essere leggermente diverso.

Gli sviluppatori hanno trovato il modo di scomporre il loro lavoro in pezzi più piccoli e i designer tendono a pensare all'intera cosa come alla "torta intera" ea come si mangia tutta la torta.

Questo è un punto in cui iniziano a sbattere le teste. Gli ingegneri vogliono essere in grado di spedire codice in piccoli passaggi e creare qualcosa molto rapidamente come parte della metodologia Agile. I designer tendono a voler fare un grande passo avanti in modo olistico: vogliono offrire un'esperienza coerente. Questo può essere un punto di contesa per questi due gruppi.

Cosa possono fare i designer per avvicinare un po' gli sviluppatori alla nostra prospettiva? In che modo i designer fanno capire agli sviluppatori che ogni piccola funzionalità fornita riguarda anche l'esperienza?

C'è un'opportunità per entrambe le parti di piegarsi qui. I designer a volte cercano di convincere uno sviluppatore che dobbiamo aspettare e costruire tutto, e poi farlo uscire dalla porta come questa bellissima e completa esperienza.

Ma se il ciclo di creazione è troppo lungo, i prodotti corrono il rischio di essere uccisi. Le persone iniziano a perdere interesse. Potrebbero dire: “Si tratta davvero di creare valore per il business? Stiamo spendendo un sacco di tempo, energia e risorse per questa cosa, perché ci vuole così tanto tempo? I designer devono pensare di più al ciclo degli affari.

Se Apple spedisce un telefono, un pezzo di hardware che ha un problema, potrebbe potenzialmente costare miliardi di dollari, ma se il software viene spedito e c'è un problema, possiamo semplicemente ripararlo, ripararlo e spedirlo di nuovo. Avvicinarsi al processo in questo modo ci consente di riconnetterci al ciclo di lavoro di sviluppo in modo più elegante.

I progettisti potrebbero anche provare a colmare il divario tra i due gruppi coinvolgendo gli ingegneri fin dall'inizio nel processo di progettazione in modo che si sentano inclusi nella fase di ideazione iniziale, non solo a valle. I designer potrebbero dire: "Ci è venuta questa idea brillante, falla per noi!" e questo fa sentire gli sviluppatori che non fanno parte del processo di ideazione. Sono solo le mani e qualcun altro è il cervello.

La relazione più disfunzionale tra designer e sviluppatori si verifica quando c'è una netta divisione del lavoro. Più inizia a fondersi e quei team lavorano insieme, meglio è. Di conseguenza, ci sarebbero più prospettive e proprietà condivisa che è davvero la chiave per designer e sviluppatori che lavorano insieme in modo efficace.

Capire meglio lo spazio dell'altro...

Cosa possono fare le squadre per capire meglio lo spazio dell'altro? I designer dovrebbero familiarizzare con lo sviluppo e viceversa?

In primo luogo, designer e sviluppatori potrebbero parlare di più con i clienti e conoscere insieme lo spazio problematico. Potevano parlare con tre o quattro clienti al mattino davanti a un caffè; tutti potrebbero imparare molto rapidamente e arrivare a una comprensione condivisa di quali siano le preoccupazioni.

In secondo luogo, in termini di processo di lavoro, è importante che designer e sviluppatori abbiano, forse non la fluidità, ma una certa comprensione del linguaggio dell'altro. Non intendo dire che un designer debba sapere come programmare o che gli sviluppatori debbano padroneggiare la tipografia, ma almeno c'è una comprensione condivisa.

Se i designer potessero inquadrare le cose in un linguaggio comprensibile agli sviluppatori - "tale e così non funziona e questo è un male per gli affari", allora gli sviluppatori arriverebbero rapidamente a comprendere il problema. Non è qualcosa che viene naturale per i designer, ma devono essere più bravi a comunicare il valore del loro lavoro quantitativamente , non solo qualitativamente . Il team di vendita, il team di marketing, l'ingegneria, il prodotto, i dirigenti, tutte queste persone parlano in numeri, parlano in modo quantitativo .

Detto questo, credo che il design porti qualcosa di molto prezioso, che ci siano alcune cose che contano che non possono essere contate. L'esperienza del cliente, la gioia, l'amore per il prodotto è estremamente prezioso ed è difficile da quantificare.

Può essere quantificabile, tuttavia, lungo la linea che la componente di qualità porterà un ROI quantificabile.

Sì, possiamo ridurre i costi dell'assistenza clienti con la progettazione, possiamo ridurre l'abbandono, possiamo aumentare la velocità di on-boarding. Avere metriche del genere su cui puntare aiuta la progettazione ad allineare i propri sforzi agli obiettivi aziendali. Più i designer possono farlo, più saranno compresi. Quanto più il design viene valutato in azienda come un vantaggio competitivo, tanto più aumenterà il potenziale per investimenti più pesanti.

Sulle insidie ​​della collaborazione tra designer e sviluppatori...

Quali sono alcune delle maggiori insidie ​​in cui si imbattono designer e sviluppatori che lavorano insieme?

Una delle maggiori insidie ​​è non avere una lingua condivisa, non avere obiettivi condivisi e rapporti molto sproporzionati. A volte ci sono team interfunzionali con un designer e 75 ingegneri. Sembra folle, ma è abbastanza comune.

La stragrande maggioranza di queste situazioni non è buona. Quel designer solitario è un espatriato. Sono estranei in una terra straniera dove non si adattano mai alla cultura... e il loro sistema di valori è diverso dal sistema di valori di tutti i loro colleghi.

In quell'ambiente, presentare un caso per una funzione UX è estremamente impegnativo per un designer: "Dovremmo avere questa animazione nel prodotto perché creerà un'esperienza più avvincente..." quando ci sono 75 ingegneri che dicono: "Sono 250 in più righe di codice e due giorni extra di lavoro. Ne vale davvero la pena?" E probabilmente non lo è. A loro sembrerà "gelo". Ma quelle micro-interazioni animate con un designer UX modellano davvero l'esperienza del cliente. Non sono l'unica cosa, ma sono importanti.

Quando hai quei rapporti irregolari tra designer e sviluppatori, diventa davvero problematico. Tuttavia, ci sono soluzioni. Aziende come Slack risolvono questo problema con il "design accoppiato". Se c'è un designer su 10 ingegneri in un team, e la stessa proporzione in un altro team, quei designer solisti trascorrono circa otto ore alla settimana lavorando insieme, presentandosi soluzioni l'un l'altro: "Ecco come sto risolvendo questo problema, fa questo ha senso per te? C'è un modo migliore per farlo?" Possono aiutarsi a vicenda a sbloccarsi e non sentirsi come se fossero su un'isola.

Sui designer che trasmettono l'importanza della UX...

In che modo i designer possono enfatizzare l'importanza del design incentrato sull'uomo con gli sviluppatori che non capiscono davvero l'HCD? Ad esempio, in che modo i designer comunicano che l'aggiunta di funzionalità non serve necessariamente al cliente, che l'esperienza di utilizzo del prodotto è più importante delle sue funzionalità?

Ci sono un paio di modi efficaci per farlo. La maggior parte dei designer probabilmente l'ha fatto in modo inefficace dicendo direttamente agli sviluppatori: “Ehi, l'aggiunta di più funzionalità non migliora l'esperienza. La gente dice di volerlo, ma in realtà rende il prodotto più complicato", ed è probabile che gli sviluppatori rispondano: "Non credo che tu abbia ragione, questa è un'opinione. Lo sentiamo dai nostri clienti, quindi dovremmo seguirli".

È meglio non affrontarlo frontalmente, ma farlo di traverso e dire: "Capiamo meglio lo spazio problematico insieme". Ho comprato il pranzo per noi domani e ho deciso di mostrarti cinque dei nostri clienti che usano il nostro prodotto.

Ho visto ingegneri dimenarsi sui loro posti quando osservano un cliente che utilizza effettivamente il prodotto e si rendono conto: "Abbiamo realizzato qualcosa che è piuttosto difficile da usare e le persone ne sono frustrate". Gli ingegneri vogliono fare un ottimo lavoro, proprio come i designer. Spesso, semplicemente non hanno l'opportunità di vedere il risultato del loro lavoro.

Probabilmente hai sentito parlare di Jeff Gothelf predicare che dovremmo concentrarci sui "risultati, non sui risultati". Questo è un altro modo in cui possiamo riformulare il nostro pensiero, ovvero che un risultato è: "abbiamo distribuito altre cinque funzionalità" rispetto a un risultato: "abbiamo ridotto l'abbandono del 10%".

Sul futuro della collaborazione tra designer e sviluppatori...

Parli con molte aziende e vedi molti team di progettazione e sviluppatori che lavorano insieme. Gli strumenti, gli ambienti e le metodologie stanno cambiando. Cosa riserva il futuro al rapporto designer/sviluppatore?

C'è un'acqua salmastra in via di sviluppo, quando acqua salata e acqua dolce si fondono insieme, c'è una coalescenza di strumenti di progettazione e ingegneria. Invece di un processo che sembra un passaggio di consegne in cui tutto ciò che è design è qui e tutto ciò che è ingegneria è laggiù, iniziano a fondersi insieme.

In tal senso, stiamo vedendo designer che trascorrono molto tempo in Jira, pensando alle storie degli utenti e iniziano a pensare anche con una mentalità ingegneristica. E viceversa, stiamo vedendo ingegneri che utilizzano strumenti come InVision Inspect, dove vedono le specifiche e la suddivisione di un sistema di progettazione e capiscono i componenti di come tutto si integra. Grazie a questi strumenti e alla fusione di discipline, si sta sviluppando una comprensione condivisa.

Che tu sia uno sviluppatore o un designer, puoi iniziare a capire il punto di vista del tuo partner chiave. Non significa che devi essere un programmatore esperto come designer. Ma non ucciderà un designer se sapesse un po' come usare Git e come scrivere un po' di HTML e CSS, forse un po' di JavaScript. Questo in realtà aiuterà i designer a capire come sono costruite le cose e promuoverà una migliore collaborazione tra designer e sviluppatori.

Ulteriori letture sul blog di Toptal Design:

• Come avvicinarsi al design per gli sviluppatori
• Design Talks: Research in Action con la ricercatrice UX Caitria O'Neill
• Design Talks: Design emotivamente intelligente con Pamela Pavliscak
• Design Talks: The Pursuit of Value-based Design con Nick Disabato
• Come passare da UX Designer a UX Consultant