În Interviuri

Interviu cu Gabriel Agu, web-designer

Gabriel Agu

Gabriel Agu este Senior Designer la Booking.com și are o experiență de peste 10 ani în domeniu. Vă invităm să aflați mai multe despre debutul, traiectoria și experiența sa profesională în interviul de astăzi.

Ctrl-D: Ai studiat limba și literatura engleză, dar lucrezi în design. Ce anume te-a determinat să-ți îndrepți atenția spre acest domeniu?

Gabriel: Am avut un parcurs destul de haotic până să-mi dau seama ce-mi place cel mai mult să fac. Am trecut prin teologie, litere, jurnalism, comunicare și PR, iar în cele din urmă am ajuns să fac web/UX design și nu știu ce o să se întâmple mai departe.

Am fost destul de norocos să am oportunitatea de a construi primul site și de a învăța puțin HTML în 2001, când eram încă în primul an de facultate. Atunci, printr-un accident fericit, am ajuns să fac site-ul unui proiect și mi-a plăcut foarte mult. Ca mulți alții, făceam o facultate pentru că „trebuia”, dar nu aveam nicio intenție să devin profesor sau traducător, singurele opțiuni de carieră oferite de facultatea de litere. La momentul respectiv, încă nu gândeam în termeni de „carieră”, dar îmi plăceau tehnologia, internetul, calculatoarele și designul, așa că m-am implicat în orice proiect care avea vreo legătură cu asta. După ce am terminat facultatea, m-am mutat în București pentru un masterat. Acolo erau infinit mai multe oportunități în IT/design, așa încât am reușit să mă angajez ca web designer și am continuat să fac ce-mi place.

 

Ctrl-D: Ai fost, deci, autodidact? Cum te-ai pregătit pentru această profesie?

Gabriel: Pe scurt, am învățat făcând, într-o perioadă în care resursele erau limitate.

În 2001, în Bacău, România, lucrurile stăteau foarte diferit față de Statele Unite sau Anglia. În timp ce Jeffrey Zeldman făcea primele teme pentru Blogger.com și definea specificațiile pentru CSS 2.1, eu așteptam cu nerăbdare ora 9.30 seara, să mă conectez la net prin X-net pentru că era mai ieftin. Și asta acasă la o profesoară, cu care lucram la primul proiect, pentru că nu aveam nici calculator personal, nici acces la internet altfel.

Resursele pe care le aveam la dispoziție erau destul de limitate și n-am avut nicio structură în modul în care am învățat. Pe de altă parte, asta îmi dădea și libertatea de a gândi în afara tiparelor, pentru că nu eram conștient de limitări și îmi imaginam tot felul de chestii trăznite pe care tehnologia nu le suporta atunci.

În primele câteva luni, foloseam editorul de text din Windows, Notepad, și salvam documentele cu extensia .html. Când am descoperit un editor HTML (primul a fost Coffee Cup HTML Editor, apoi MS FrontPage), eram complet fascinat de faptul că puteam să introduc un link în pagină și într-un alt panel vedeam codul HTML ca să știu ce anume trebuie să scriu. Acum mi-e groază când mă gândesc ce mizerie de HTML scria FrontPage, dar la momentul respectiv eram departe de a face diferența între cod HTML scris bine sau prost. Prima oară când am încercat să folosesc Photoshop (4.0) nu înțelegeam nimic din el și mi se părea că are prea multe butoane. Mi-a mai luat câteva luni să învăț ce pot să fac cu el.

Tutorialele erau aproape inexistente și, de multe ori, nici nu știam cum se numesc lucrurile pe care voiam să le pun într-o pagină web. Eram conștient că am foarte multe de învățat și că am foarte mult de muncă pentru a deveni mai bun, dar, cum orice noțiune nouă învățată era fascinantă, nu mi s-a părut prea greu să petrec ore în șir în fața calculatorului ca să încerc orice idee nouă.

Ca în orice alt domeniu, nu există scurtături. Devii mai bun doar muncind foarte, foarte mult. Talentul (deși nu cred că există talent pentru design) și pasiunea ajută, dar nu înlocuiesc miile de ore care constituie experiența efectivă. Și, câțiva ani mai târziu, când făceam asta full-time (când zic full-time, mă refer la noțiunea românească, de 10-14 ore pe zi, uneori 7 zile din 7), eram conștient în continuare că am nevoie de asta, pentru că doar așa pot evolua.

 

Ctrl-D: De mai bine de 2 ani lucrezi la Booking.com. Spune-ne puțin despre cum ai ajuns să lucrezi aici.

Gabriel: În 2011 am decis că nu mai am unde să cresc în piața și industria din România. Lucram deja la una dintre cele mai bune agenții din România, Green Pixel, lucrasem la proiecte destul de mari, dar voiam mai mult. Inițial, voiam să mă mut în Anglia sau Europa de Nord pentru că au o industrie cu o vechime mai mare și o cultură vizuală mult mai consistentă decât România.

Olanda și Booking.com nu erau pe lista de opțiuni, până când m-a sunat o agenție de recrutare să îmi propună un interviu acolo. Inițial, eram destul de reticent, pentru că nu știam mare lucru despre Olanda și Amsterdam (doar stereotipurile generale: droguri legalizate, lalele și biciclete). După un interviu telefonic, am avut un interviu în Amsterdam, cu designeri de la Booking în care am aflat mai multe despre cum lucrează; data-driven design mi s-a părut o provocare interesantă.

Aș putea să povestesc mult și bine despre cât de mult îmi place aici, dar am să spun doar că nu regret decizia luată atunci și că, în continuare, e un proiect fascinant (mai ales în condițiile în care are o creștere fantastică – când m-au angajat eram 15 designeri, acum suntem 60 și căutăm în permanență noi colegi).

 

Ctrl-D: Ce implică un proiect de data-driven design? Care sunt regulile nescrise ale acestuia?

Gabriel: Nu cred că există reguli nescrise. Sunt foarte multe articole și cărți care descriu metodologia pentru data-driven design. Resurse teoretice sunt din abundență. Cred că cea mai dificilă parte în trecerea de la teorie la practică e faptul că data-driven design trebuie integrat în cultura și filosofia companiei. Opiniile personale trebuie lăsate la o parte și datele trebuie să ghideze toate deciziile. Foarte mulți manageri (și designeri) nu pot să facă asta pentru că sunt convinși că expertiza lor are mai multă valoare decât ce spun datele despre comportamentul utilizatorilor. Siguranța de sine necesară pentru a ajunge în poziții de top management vine la pachet cu un ego foarte puternic și e destul de dificil să accepți că poți să greșești și să lași la o parte controlul cu care ești obișnuit. La fel și cu designerii, pentru mulți e greu să accepte că soluția vizuală și ceea ce li se pare lor inovativ nu funcționează.

Expertiza designerilor contează în continuare, chiar și în data-driven design, pentru că e nevoie de un designer care să decidă cum trebuie să arate și să se comporte un element din interfață, dar decizia finală nu mai aparține designerului, ci e luată pe baza datelor care spun ce e eficient.

În plus, există și un aspect cultural. A/B testing și data-driven design implică multe eșecuri. E inevitabil. Culturile în care există o aversiune puternică față de risc și eșec (iar România e o astfel de cultură) sunt foarte reticente în a adopta data-driven design.

Percepția tradițională în cultura românească e că dacă ai greșit ceva, o să fii pedepsit. Percepția în data-driven design e „dacă asta nu a funcționat, atunci știu încă un lucru care nu merge, așa că o să mai încerc încă 100 de lucruri până găsesc soluția care merge”.

Există suficiente exemple care arată că o abordare data-driven are șanse mari de succes per total pentru o companie: Google, Facebook, Amazon, Booking, eBay, Twitter – toate au în comun faptul că sunt data-driven și au un succes vizibil.

 

Ctrl-D: Atunci când colectezi informații, ai două tipuri de date în vedere: calitative și cantitative. La ce îți folosește fiecare dintre acestea, atunci când gândești un proiect de design?

Gabriel: Fiecare dintre aceste tipuri de date îți poate da o perspectivă asupra a ceea ce se întâmplă și îți poate da insights despre cum să îmbunătățești experiența utilizatorilor. Datele cantitative îți dau o perspectivă globală, dar anonimă. Datele calitative îți dau o perspectivă personală și directă, dar care s-ar putea să nu fie reprezentativă pentru toți utilizatorii.

În ședințe de user testing vezi cum interacționează utilizatorii cu produsul tău într-un mod foarte direct, iar feedback-ul primit îți arată rapid unde au probleme. Datele colectate în A/B testing pot valida diverse ipoteze care apar din user testing și poți afla dacă o problemă pe care o menționează un user în testing e comună pentru majoritatea utilizatorilor.

Ambele tipuri de date sunt utile, în moduri diferite. Ca designer, când stai toată ziua în fața monitorului și desenezi butoane sau scrii cod, e ușor să uiți că produsul respectiv e folosit de oameni, nu de un concept abstract numit user și că produsul pe care îl construiești trebuie să rezolve o problemă pentru ei, să le facă experiența de folosire cât mai ușoară, plăcută și delightful. Pentru asta, user testing te aduce cu picioarele pe pământ din când în când.

În același timp, datele rezultate din A/B testing îți dau perspectiva globală de care ai nevoie ca să construiești soluții eficiente și cu impact maxim. Au fost multe cazuri în care am văzut o problemă într-o sesiune de user testing și apoi un A/B test care a confirmat că era o problemă pentru majoritatea utilizatorilor, dar și cazuri în care A/B testing a demonstrat că impactul problemei respective era minor.

 

Ctrl-D: Folosești A/B testing-ul pentru creșterea conversiilor și nu numai. Care sunt principiile de bază ale acestei metode? Cum se derulează un asemenea demers?

Gabriel: Sunt multe aspecte într-un proiect care implică data-driven design. În primul rând, nu oricine poate să facă data-driven design. Pentru a putea lua decizii corecte atunci când testezi două variante de design pe utilizatorii produsului (website, app sau orice altceva), un aspect critic e sample size. Rezultatele trebuie să fie relevante statistic, iar pentru asta îți trebuie cât mai mulți vizitatori în fiecare variantă, pentru că trebuie să elimini, cu cât mai multă siguranță, variațiile. Minimul acceptabil e de 10.000 de vizitatori în fiecare variantă a testului. Asta îți poate da suficientă certitudine că efectul pe care îl vezi e real.

Noi avem un prag mult mai ridicat pentru numărul minim de vizitatori/variantă, pentru că avem un trafic general suficient de mare. În proiecte cu puțin trafic, data-driven design nu ar fi util pentru că datele colectate nu sunt relevante (și pot să facă mai mult rău decât bine, dacă unele decizii de business sunt bazate pe date greșite).

Există diverse unelte care te pot ajuta să afli, cu suficientă certitudine, dacă efectul pe care îl vezi e real și cred că e esențial ca orice companie care face data-driven design să aibă cel puțin un statistician care să valideze rezultatele.

Un aspect important e că trebuie să ai o ipoteză clar formulată și obiective clare pentru orice modificare vrei să faci. Făcând modificări la întâmplare, șansele să înveți ceva din ele și să îmbunătățești produsul în iterația următoare sunt extrem de reduse. Dacă definești clar scopul unei modificări, atunci și pașii sunt mai clari. Spre exemplu: „Vrem să creștem numărul de conturi înregistrate. Dacă modificăm mărimea butonului de sign up atunci va fi mai ușor pentru vizitatori să îl găsească și numărul de conturi înregistrate va crește”. Ai o ipoteză, o modificare pe care să o testezi și un set de metrics care îți vor arăta dacă modificarea are efectul propus. Dacă asta nu își atinge scopul, poți încerca altceva.

Un alt lucru important e ca orice modificare să aibă dublul scop de a îmbunătăți experiența utilizatorilor și de a fi benefică businessului. Dacă te concentrezi pe optimizarea pentru câștigul businessului, poți avea succes pe termen scurt, dar pe termen lung vei aliena utilizatorii. Dacă te concentrezi pe construirea produsului perfect, fără să ții cont de business metrics, atunci compania o să falimenteze la un moment dat. Succesul vine din confluența celor două aspecte și toată lumea are de câștigat atunci.

Totodată, nu sunt mulți designeri care se simt confortabil într-un mediu de data-driven design. Pentru unii, e important să inoveze sau să facă lucrurile așa cum vor ei, pe principiul „eu știu mai bine, eu știu ce e frumos etc”. Mulți percep data-driven design ca o limitare a creativității și libertății lor ca designeri. Majoritatea fac referință la situația în care Google a testat 40 de nuanțe de albastru pentru linkuri și dau asta ca exemplu despre cât de limitativ e mediul data-driven.

Eu văd lucrurile altfel. Pentru mine, un astfel de test mă învață ce funcționează mai bine, astfel încât, la următorul proiect, nu mai trebuie să petrec o oră încercând să decid ce nuanță de albastru să folosesc și pot să petrec ora respectivă încercând să rafinez experiența și să creez un produs mai bun. În plus, trebuie să accept tot timpul că pot să greșesc, chiar dacă am 10 ani de experiență în design (și am văzut destule experimente eșuând, când eram sigur că vor avea succes).

Un alt aspect care pare limitativ pentru designeri e faptul că data-driven design înseamnă modificări mici în loc de salturi. Atunci când testezi un redesign complet al unui site și are succes, nu o să știi care componentă din redesign a dus la succesul respectiv și nu ai învățat nimic din asta. La fel și dacă eșuează. Fiind atât de mare și complex, nu știi ce a dus la eșec (poate era faptul că butonul x era jos în loc de sus, poate că numele unui element din meniu era greu de înțeles, poate că x sau y). Rareori, și în data-driven design au loc salturi, atunci când atingi local maxima și singurul mod de a mai crește e o abordare complet nouă.

Pe scurt, local maxima înseamnă că ai optimizat produsul la maxim în forma curentă și singurul mod de a continua să crești e să faci un salt într-o zonă nouă, în care să începi de la local minima iarăși. Un exemplu ar fi redesignul integral al produselor Google, în condițiile în care fiecare produs era optimizat independent, dar platforma ca întreg nu putea să mai crească fără un pas major la nivel structural și de design care să-i aducă iar în zona de local minima.

 

Ctrl-D: Care ar fi câteva instrumente folositoare pentru designerii care lucrează cu A/B testing?

Gabriel: Practic, folosim aceleași instrumente ca toți designerii. Photoshop, editoare de text, version control șamd. Singurul lucru în plus pe care îl avem e o platformă în care putem monitoriza fiecare experiment (test) pe care îl rulăm pe site. O parte semnificativă din rutina de zi cu zi e analiza datelor rezultate din teste, pe care le folosim apoi pentru a trage diverse concluzii despre pașii următori.

În plus, cunoștințele de statistică (da, știu, sună ciudat pentru un designer) sunt destul de utile pentru a înțelege și interpreta datele. Chiar dacă backgroundul meu înainte de Booking e destul de divers (teologie, litere, jurnalism și comunicare), am învățat puțină statistică pentru că am fost curios și voiam să înțeleg ce reprezintă fiecare componentă a datelor, pentru a îmbunătăți apoi designul.

 

Ctrl-D: Care au fost cele mai mari provocări pe care le-ai întâmpinat în procesul de a îmbunătăți experiența utilizatorilor de pe Booking.com și ce soluții ai identificat?

Gabriel: Prima provocare a fost scara la care se întâmplă lucrurile în cazul Booking.com. Orice element de interfață pe un site cu milioane de vizitatori pe zi, în 42 de limbi și cu un volum fantastic de tranzacții, are cerințe de scalabilitate aparte, la nivel tehnic. Orice buton trebuie să fie suficient de flexibil și implementat, așa încât să arate bine pe majoritatea rezoluțiilor posibile, în toate cele 42 de limbi, pe desktop, tabletă și mobile, în majoritatea browserelor (în 2012 încă suportam IE6). Cu elemente mai complexe (cum sunt formularele sau integrarea unui nou element într-o pagină) lucrurile devin și mai interesante.

În același timp, lucrând la un produs cu o prezență globală, am învățat mai multe despre percepția cross-culture și despre cum răspund diferite zone ale lumii la anumite elemente vizuale sau moduri diferite de comunicare. Din motive de confidențialitate nu pot să dau exemple specifice, dar aproape întotdeauna comunicarea și interacțiunea cât mai simplă și naturală au dat cele mai bune rezultate.

Printre cele mai eficiente tehnici de comunicare pe care le-am folosit ar fi elemente de behavioral economics și mecanisme de persuasiune care pot fi integrate în design pentru a face un produs mai eficient. Acestea nu sunt o soluție miraculoasă care să rezolve orice problemă, dar într-un context în care sunt integrate în flow-ul natural al utilizatorilor, pot îmbunătăți semnificativ performanța unui produs.

 

Ctrl-D: De obicei, atunci când oamenii se gândesc la loializarea consumatorilor, cei mai mulți dintre ei se gândesc la tehnici de marketing. Cum poți loializa consumatorii prin elemente de design?

Gabriel: Loialitatea e extrem de dificil de măsurat, în aproape orice domeniu. Poți să definești diferite metrics de loialitate, cum ar fi vizitatori care cumpără de la tine în repetate rânduri, scorul NPS sau măsura în care aceștia interacționează cu anumite elemente ale produsului.

În opinia mea, consumatorii devin loiali unui produs bun. Partea aceasta e de departe cea mai importantă în loializare: construiește un produs bun pentru clienții tăi. Dacă produsul tău e greu de folosit sau nu rezolvă o problema reală, nu o să te ajute nici cel mai bun design de pe lume și nicio tehnică de marketing.

La nivel de design/comunicare, unele elemente pe care le poți folosi sunt: mesaje care să sublinieze faptul că alegerea pe care o faci cu produsul tău e bună (USPs în partea de pre-purchase), comunicare transparentă și clară în partea de purchase și un serviciu post-purchase de calitate. Foarte mulți comercianți ignoră serviciile post-purchase, considerând că, odată ce au finalizat vânzarea, relația cu clientul s-a terminat, lucru care de multe ori nu e adevărat. În realitate, asta e partea unde ai șanse mari să loializezi clienții arătându-le că sunt importanți pentru tine chiar și după ce au cumpărat.

 

Ctrl-D: Mulțumim pentru interviu, Gabriel! Rămâi în Ctrl!