Discuții despre design: o mai bună colaborare între designeri și dezvoltatori cu Aarron Walter de la InVision

Bun venit la seria noastră Design Talks dedicată împărtășirii ideilor liderilor de gândire și a oamenilor de top implicați în design din întreaga lume. Intervievăm experți care lucrează cu design în contexte diferite, cu obiective diferite și prin abordări diferite. În aceste serii, sperăm să oferim inspirație intelectuală și creativă tuturor cititorilor noștri.

Designerii se luptă adesea să lucreze cu dezvoltatorii și invers. Echipele de ambele părți ar putea învăța o cantitate enormă una de la cealaltă, totuși mai rămân straturi de rezistență. Invitatul acestei săptămâni este Aarron Walter, VP of Design Education la InVision și vom vorbi despre colaborarea dintre designer și dezvoltatori.

Aarron se bazează pe 15 ani de experiență în conducerea echipelor de produse și în predarea designului pentru a ajuta companiile să adopte cele mai bune practici de design. El a fondat practica UX la MailChimp și a contribuit la creșterea produsului de la câteva mii de utilizatori la peste 10 milioane.

Îndrumarea sa de proiectare a ajutat Casa Albă, Departamentul de Stat al SUA și zeci de corporații importante, startup-uri și firme de capital de risc. El este autorul celei mai bine vândute cărți Designing for Emotion from A Book Apart. Veți găsi @aarron pe Twitter împărtășind gânduri despre design și puteți afla mai multe despre Aarron la aarronwalter.com.

Pe Podcastul Design Better, Aarron Walter și Eli Woolery intervievează lideri de design și influenți care împărtășesc povești despre modul în care rezolvă problemele și calea lor în carieră. Printre oaspeți se numără David Kelley (cofondator IDEO și fondator Stanford d.school), Julie Zhuo (VP de Produs și Design la Facebook) și Jake Knapp (autorul cel mai bine vândut Sprint), printre alții.

Bună Aarron, este o plăcere să te am pe Blogul Toptal Design. Sunt dezvoltatorii de pe Marte și designerii de pe Venus?

Din experiența mea, designerii și dezvoltatorii au probabil mai multe în comun decât își dau seama, dar cu siguranță există unele diferențe distincte în modul în care gândim lucrurile. Designerilor le place să se gândească la sistemele de proiectare, iar dezvoltatorii se gândesc la codul modular care este ușor de întreținut. Dar modul în care procedăm despre asta poate fi ușor diferit.

Dezvoltatorii au găsit modalități de a-și împărți munca în bucăți mai mici, iar designerii tind să se gândească la întregul lucru ca la „tortul întreg” și cum mâncăm tot tortul.

Acesta este un punct în care încep să bată capul. Inginerii doresc să fie capabili să livreze cod în pași mici și să facă ceva foarte rapid, ca parte a metodologiei Agile. Designerii tind să dorească să facă un mare pas înainte într-o manieră holistică – vor să ofere o experiență consecventă. Acesta poate fi un punct de disputa pentru aceste două grupuri.

Ce pot face designerii pentru a aduce dezvoltatorii puțin în perspectiva noastră? Cum îi fac designerii să înțeleagă dezvoltatorii că fiecare caracteristică mică livrată se referă și la experiență?

Există posibilitatea ca ambele părți să se aplece aici. Designerii încearcă uneori să convingă un dezvoltator că trebuie să așteptăm și să construim totul, apoi să-l scoatem pe ușă ca această experiență frumoasă și completă.

Dar dacă ciclul de creare este prea lung, produsele riscă să fie ucise. Oamenii încep să-și piardă interesul. Ei ar putea spune: „Este aceasta de fapt crearea de valoare pentru afacere? Cheltuim o mulțime de timp, energie și resurse pentru acest lucru, de ce durează atât de mult?” Designerii trebuie să se gândească mai mult la ciclul afacerilor.

Dacă Apple livrează un telefon - o piesă hardware care are o problemă - ar putea costa miliarde de dolari, dar dacă software-ul este livrat și există o problemă, putem doar să-l corectăm, să-l reparăm și să expediem din nou. Abordarea procesului în acest fel ne permite să ne conectăm mai elegant la ciclul de lucru al dezvoltării.

Designerii ar putea încerca, de asemenea, să reducă decalajul dintre cele două grupuri prin implicarea inginerilor în procesul de proiectare de la început, astfel încât să se simtă incluși în faza timpurie de ideare, nu doar în aval. Designerii ar putea spune: „Ne-a venit această idee genială, fă-o pentru noi!” și asta îi face pe dezvoltatori să simtă că nu fac parte din procesul de ideare. Ele sunt doar mâinile și altcineva este creierul.

Cea mai disfuncțională relație dintre designeri și dezvoltatori are loc atunci când există o diviziune distinctă a muncii. Cu cât începe să se amestece mai mult și acele echipe lucrează împreună, cu atât mai bine. Ca rezultat, ar exista mai multe perspective și proprietate comună, ceea ce este cu adevărat cheie pentru ca designerii și dezvoltatorii să lucreze eficient împreună.

Despre a înțelege mai bine spațiul celuilalt...

Ce pot face echipele pentru a înțelege mai bine spațiul celuilalt? Ar trebui designerii să se familiarizeze cu dezvoltarea și invers?

În primul rând, designerii și dezvoltatorii ar putea vorbi mai mult cu clienții și ar putea afla împreună despre spațiul cu probleme. Puteau vorbi cu trei-patru clienți dimineața la o cafea; toată lumea ar putea învăța foarte repede și să ajungă la o înțelegere comună a preocupărilor.

În al doilea rând, în ceea ce privește procesul de lucru, este important pentru designeri și dezvoltatori să aibă — poate nu fluență — dar o oarecare înțelegere a limbajului celuilalt. Nu vreau să spun că un designer trebuie să știe cum să codeze sau că dezvoltatorii trebuie să stăpânească tipografia, dar cel puțin există o înțelegere comună.

Dacă designerii ar putea să încadreze lucrurile într-un limbaj pe care dezvoltatorii îl înțeleg – „un astfel de lucru nu funcționează și asta este rău pentru afaceri” – atunci dezvoltatorii ar ajunge rapid să înțeleagă problema. Nu este ceva care vine în mod natural pentru designeri, dar aceștia trebuie să fie mai buni în a comunica valoarea muncii lor cantitativ , nu doar calitativ . Echipa de vânzări, echipa de marketing, inginerie, produs, directori, toți acești oameni vorbesc în cifre, ei vorbesc cantitativ .

Acestea fiind spuse, cred că designul aduce ceva foarte valoros, că există unele lucruri care contează care nu pot fi numărate. Experiența clienților, bucuria, dragostea pentru produs sunt super valoroase și este greu de cuantificat.

Totuși, poate fi cuantificabil, în continuare, acea componentă de calitate va aduce un ROI care este cuantificabil.

Da, putem reduce costurile de asistență pentru clienți cu design, putem reduce rata de pierdere, putem crește viteza de îmbarcare. Având astfel de valori pe care să vă puneți ochii, vă ajută să proiectați să-și alinieze eforturile la obiectivele de afaceri. Cu cât designerii pot face asta mai mult, cu atât vor fi mai înțeleși. Cu cât designul este mai apreciat în companie ca un avantaj competitiv, cu atât va crește potențialul pentru investiții mai mari.

Despre capcanele colaborării dintre designeri și dezvoltatori...

Care sunt unele dintre cele mai mari capcane cu care se confruntă designerii și dezvoltatorii care lucrează împreună?

Unul dintre cele mai mari capcane este faptul de a nu avea un limbaj comun, de a nu avea obiective comune și de a fi foarte disproporționat raporturile. Uneori există echipe interfuncționale cu un proiectant și 75 de ingineri. Sună nebunesc, dar este destul de comun.

Marea majoritate a acestor situații nu sunt bune. Acest designer singuratic este un expatriat. Sunt străini într-un tărâm ciudat în care nu se încadrează niciodată în cultură... iar sistemul lor de valori este diferit de sistemul de valori al tuturor colegilor lor.

În acel mediu, prezentarea unui argument pentru o caracteristică UX este extrem de dificilă pentru un designer: „Ar trebui să avem această animație în produs pentru că va crea o experiență mai convingătoare…” când sunt 75 de ingineri care spun: „Sunt încă 250 linii de cod și două zile suplimentare de muncă. Chiar merită?” Și probabil că nu este. Pentru ei, le va părea „înghețare”. Dar acele micro-interacțiuni animate cu un designer UX modelează într-adevăr experiența clientului. Nu sunt singurul lucru, dar sunt importante.

Când aveți acele rapoarte inegale între designeri și dezvoltatori, devine cu adevărat problematic. Cu toate acestea, există soluții. Companii precum Slack rezolvă această problemă cu „design pereche”. Dacă există un designer la 10 ingineri într-o echipă și același raport în altă echipă, acei designeri solo petrec aproximativ opt ore pe săptămână lucrând împreună, prezentându-și soluții unul altuia: „Iată cum rezolv această problemă, face asta are sens pentru tine? Există o modalitate mai bună de a face asta?” Se pot ajuta unul pe celălalt să se deblocheze și să nu se simtă ca pe o insulă.

Despre designeri care transmit importanța UX...

Cum pot designerii să sublinieze importanța designului centrat pe om cu dezvoltatorii care nu înțeleg cu adevărat HCD? De exemplu, cum transmit designerii că adăugarea de caracteristici nu servește neapărat clientului, că experiența de utilizare a produsului este mai importantă decât caracteristicile acestuia?

Există câteva moduri eficiente de a face acest lucru. Majoritatea designerilor au făcut-o probabil într-un mod ineficient, spunând dezvoltatorilor direct: „Hei, adăugarea mai multor funcții nu face o experiență mai bună. Oamenii spun că își doresc, dar de fapt face produsul mai complicat”, iar dezvoltatorii sunt probabil să răspundă: „Nu cred că ai dreptate, asta este o părere. Auzim asta de la clienții noștri, așa că ar trebui să-i urmăm.”

Cel mai bine este să nu o abordați frontal, ci să o faceți lateral și să spuneți: „Să înțelegem mai bine spațiul cu probleme împreună.” Am cumpărat prânzul pentru noi mâine și am aranjat să vă arăt cinci dintre clienții noștri care folosesc produsul nostru.

Am văzut ingineri zvârcolindu-se pe scaune când privesc un client care folosește efectiv produsul și și-au dat seama: „Am făcut ceva care este destul de greu de folosit și oamenii sunt frustrați de asta.” Inginerii vor să facă o muncă grozavă, la fel ca designerii. De multe ori, pur și simplu nu au ocazia să vadă rezultatul muncii lor.

Probabil ați auzit de Jeff Gothelf predicând că ar trebui să ne concentrăm pe „rezultate, nu rezultate”. Acesta este un alt mod în care ne putem reformula gândirea, că rezultatul este: „am livrat încă cinci funcții”, față de un rezultat: „am redus rata de pierdere cu 10%”.

Despre viitorul colaborării dintre designeri și dezvoltatori...

Vorbești cu o mulțime de companii și vezi multe echipe de proiectare și dezvoltatori lucrând împreună. Instrumentele, mediile și metodologiile se schimbă. Ce rezervă viitorul relației designer/dezvoltator?

Există apă sălmată în curs de dezvoltare - când apa sărată și apa dulce se amestecă împreună - există o coalescență de instrumente de inginerie și proiectare. În loc de un proces care se simte ca un transfer în care tot ceea ce este designul este aici și tot ceea ce este inginerie este acolo, încep să se îmbine.

În această măsură, vedem designeri petrecând mult timp în Jira, gândindu-se în poveștile utilizatorilor și începând să gândească și cu o mentalitate inginerească. Și invers, vedem ingineri care folosesc instrumente precum InVision Inspect, unde văd specificațiile și defalcarea unui sistem de proiectare și înțeleg componentele cum se potrivesc toate. Datorită acestor instrumente și a unui amestec de discipline, se dezvoltă o înțelegere comună.

Fie că sunteți dezvoltator sau designer, puteți începe să înțelegeți perspectiva partenerului dvs. cheie. Nu înseamnă că trebuie să fii un programator expert ca designer. Dar nu va ucide un designer dacă ar ști puțin despre cum să folosească Git și cum să scrie ceva HTML și CSS, poate puțin JavaScript. Acest lucru îi va ajuta de fapt pe designeri să înțeleagă cum sunt construite lucrurile și să promoveze o mai bună colaborare între designeri și dezvoltatori.

Citiri suplimentare pe Blogul Toptal Design:

• Cum să abordați designul pentru dezvoltatori
• Discuții de design: cercetare în acțiune cu cercetătorul UX Caitria O'Neill
• Discuții despre design: Design inteligent emoțional cu Pamela Pavliscak
• Discuții despre design: Urmărirea designului bazat pe valoare cu Nick Disabato
• Cum să treceți de la UX Designer la UX Consultant