“Design Handoff” je proces zbog kojeg developer i dizajner ne moraju imati “standoff”

Svaka tvrtka koja se bavi dizajnom i razvojem radi tzv. design handoff – znala to ili ne. Radi se o procesu predaje završenog dizajna na implementaciju u projekt, u Neuralabovom slučaju web ili eCommerce aplikacije.

Iako se nekima može činiti da su u blaženom neznanju oko još jednog “jednostavnog procesa” koji ne treba posebno imenovati, upravo je to i problematično. Dok tvrtke ne osvijeste da rade design handoff te da je to proces kojim treba upravljati, događa se ovo…

Radili smo po fazama. Dizajneri bi napravili svoj dio posla, a tek bi potom developeri preuzeli taj dizajn… i počeli s pitanjima! Nismo imali predetaljnu dokumentaciju, a design file je bio glavni izvor informacija. Rezultat toga je bio da su se neke stvari zaboravljale ili se nisu uopće definirale. Uz to, developeri su uključivani samo za određene funkcionalnosti, što bi na kraju dovelo do toga da se ta funkcionalnost, iako radi, ne uklapa u cjelokupnu viziju projekta.

Spomenuti problemi bi se multiplicirali ako bi na projekt došli novi developeri, jer se informacije nisu dijelile, dodaje Neuralabov Lead dizajner Emanuele Lizzi. U Neuralabu su tako shvatili da moraju svoj design handoff pretvoriti u pravi proces.

Prvo postavite standarde kojima ćete se voditi

Tijekom razvoja projekta,  u strukturirani design handoff, Neuralabova senior dizajnerica Martina Babić preporučuje da se krene čim prije. Razlog njenog inzistiranja je jednostavan – ubrzava cijeli proces:

Developeri najbolje znaju tehnološke mogućnosti i kako predloženo implementirati. Zbog toga je idealna situacija ona u kojoj su developeri dio svake faze od samog početka (u Neuralabu su to: discovery faza, ideacija sadržaja i korisničkog iskustva, dizajn faza, development faza te na kraju – edukacija uredništva, testiranje i puštanje u rad).

Tako se, primjerice, može izbjeći slučaj da se klijentu prezentira dizajn nekog UI elementa za kojeg kasnije otkrijemo da ga nije moguće implementirati zbog nekih pozadinskih ograničenja.  Tada je najnezgodnija stvar iskomunicirati taj problem prema klijentu koji je dizajn tog istog UI elementa već vidio i odobrio. Potom je potrebno raditi izmjene na temelju developer feedbacka, ponovno slati klijentu, čekati odobrenje… to traje, a znamo što takve iteracije čine za krajnji datum lansiranja.

Iako je rano uključivanje developera u projekt možda i najbitnija stavka design handoffa, još je važnije, kako bi proces funkcionirao, da tvrtka jasno posloži dizajn sustav (tzv. design system) koji definira sve bitne komponente i standarde kojima se dizajneri (i developeri) trebaju voditi u svom radu. Emanuele objašnjava kako su u Neuralabu implementirali više tih standarda ne bi li cjelokupan design handoff bio još kvalitetniji. Među najvažnijima navodi:

1. Pisanu, asinkronu kumunikaciju s klijentom u Trellu i kroz Gitbook.
2. Izbjegavanje upotrebe telefona i one-on-one komunikacije gdje se stvaraju silosi znanja
3. Otvaranje grupnog chata sa članovima tima uključenima u projekt.
4. Uključenost dizajnera i developera u kompletni prodajni proces i prije početka samog projekta.
5. Međusobni timski audit – developeri savjetuju oko izrade UX-a dok dizajneri savjetuju oko implementacije UX-a
6. Kontinuirano poliranje dizajn sustava.
7. I već spomenuto, uključivanje developera u cijeli proces od početka projekta

Napredak dolazi učenjem iz iskustva

Sve gore navedene stavke pomogle su Neuralabovim dizajnerima i developerima da strukturiraju design handoff u jasan proces. Martina objašnjava kako im je oduvijek ideja u tvrtki bila ideja da design handoff bude što kompletniji i strukturiraniji, no to nije bilo uvijek jednostavno izvesti.

To je normalno i očekivano iz evidentnog razloga – na svakom se novom projektu susrećemo s novim izazovima, griješimo te, iz tih grešaka, učimo. Ta novostečena znanja potom nastojimo ukomponirati u interne procedure koje će koristiti cijelome timu (dizajnerima, developerima, product managerima, a i klijentima u krajnjoj liniji), tj. svima onima koji su ili će tek biti involvirani u projekt.

Danas se Neuralab može pohvaliti svojim  procesom design handoffa, koji je s vremenom još više unaprijeđen upravo zbog svih iskustava koje su prošli. Neke od tih podijelili su s nama kako vi ne biste morali učiti na svojim greškama…

I najmanji detalj postaje veliki problem ako se ne komunicira

Kad je u pitanju najvažnija stavka kojom se vode u Neuralabu pri primopredaji projekta u ruke developera, senior dizajner Vedran Hanževački dodaje kako rano uključivanje omogućava developerima da vrlo rano uoče funkcionalnosti koje bi u kasnijim fazama projekta mogle predstavljati problem ili iz nekog razloga uopće nisu moguće s pojedinim tehnologijama.

Martina zato naglašava da će strukturirani, planirani design handoff olakšati posao upravo vama – dizajneri. Sama je to iskusila na veoma balanom slučaju – jednom prilikom developeru nije iskomunicirala logiku iza spacera:

Pretpostavljala sam da je ona jasna iz dizajna iz što je, naravno, jako pogrešno. Vjerojatno je bilo jasno samo meni, koja sam radila na tome. Oboje smo to shvatili u trenutku kada je development cijelog predloška bio već gotov te nakon što je klijent unio većinu sadržaja. No, na kraju “dev did his magic” i problem je riješen.

Iz tog iskustva, primjerice, Martina je naučila da ne pretpostavlja kako je ono što je jasno njoj, jasno i drugima. A usvojila je i još dvije bitne lekcije, da:

• Detaljno raspiše sve informacije i specifičnosti za koje misli da bi mogle biti korisne devu pa čak i na više mjesta ako je potrebno. Od viška glava ne boli.
• Postavlja pitanja (ovo se odnosi i na dizajnere i na developere)! Tako se potencijalni problemi mogu izbjeći na vrijeme.

Senior dizajnerica Iva Kosović zato s razlogom uspoređuje design handoff s odnosom pilota i kopilota:

Oboje su prisutni tijekom cijelog procesa, ali se s obzirom na fazu (dizajn ili development) mijenja tko je glavna odgovorna osoba na projektu. Tijekom dizajn faze potrebna je konstantna komunikacija između dizajnera i developera, kako bi se osiguralo da će sve što je prezentirano klijentu zaista tako biti i kada development faza završi. 

Zapisujte kako biste znali što (ne) napraviti

Ako se i vama znalo dogoditi da zaboravite na specifičnosti neke funkcionalnosti ili na neke dogovore s klijentom koji su nastali na jednom od milijardu sastanaka, Martina ima savjet:

Koliko god pisanje dokumentacije može biti naporan i dosadan posao, predivno je kada se možeš osloniti na istu. Također, za neke specifičnosti koje naučim u ovakvim situacijama (posebno greške koje sam sama ponovila više puta) imam posebno mjesto u bilježnici gdje ih zapisujem da se ne zaborave i ne ponavljaju!

Naravno, dokumentacija se skuplja na jednom mjestu, kako bi se – naglašava – svatko u firmi brzo i lako snašao ako treba preuzeti zadatak od kolege, odnosno svog pilota.

S druge strane, to dokumentiranje kreće u samoj dizajn datoteci, točnije Figmi koju Vedran opisuje kao “najbolji alat ikad”:

To je najjednostavniji način za uputiti developera u pravom smjeru i dati mu informacije koje nisu vidljive iz dizajna ili za brže uočavanje, npr. kod paragrafa bilješka: max-width: 700 px . Taj jednostavan komentar developeru odmah daje do znanja da se paragraf teksta može proširiti na više od 700 px i time je ušteđeno vrijeme jer neće doći do nepotrebnog dopisivanja na chatu ili čak krivog programiranja.

Dobra nomenklatura projekt čuva

Neovisno o alatu, ključan dio procesa dokumentiranja za design handoff je i nomenklatura tj. imenovanje ključnih elemenata. Emanuele smatra kako je to najteži dio i priznaje da još na njemu rade:

Imamo otvoreni interni projekt gdje definiramo nomenklaturu da bude “općenita” da nije pretjerano tehnička i da daje dosta slobode developerima kad je u pitanju koji pristup koristiti kada rade. Treba izbjeći specifičan žargon za objašnjavanje kako nešto radi jer onda developeri ne znaju koliko imaju “lufta” u razvoju rješenja – ne znaju je li to tako strogo definirano ili se samo netko nespretno izrazio. Uglavnom, i ovo je nešto na čemu dizajneri i developeri moraju skupa raditi. 

Dobra praksa za početak je složiti glossary u kojem se definira što određeno nazivlje znači. Na primjer “Block” definiramo da označava neku sekciju kod web stranice koja se može iskoristiti za više predložaka i pozicionirati na različita mjesta unutar stranice.

Iva se nadovezuje da nomenklatura može izazvati popriličnu pomutnju ako se ne uskladi. Dok dizajneru ne igra veliku ulogu hoće li za naziv ikone napisati “get-a-quote” ili “može cijena?”, developeru će pravilna nomenklatura uštedjeti vrijeme.

Kompromis je ključ

Kao i za mnogo drugih stvari tijekom projekta, dizajner, developer i PM nekad će se složiti o nomenklaturi, ali nekad i neće. Dapače, nekad će očito doći do konflikata između njih tijekom rada. Vedran na spomen ove teme s osmjehom napominje:

Mi dizajneri volimo reći da developeri samo vole prigovarati, ali na kraju uglavnom naprave ono što smo željeli. Šalu na stranu, kao i u svakom odnosu pa tako i dizajner-developer, kompromis je ključ. 

Emanuele napominje kako im je takva organizacija pomogla u radu s klijentima i razvoju projekata poput Carnetove web stranice za koju su od početka stvorili tim koji su sačinjavali i dizajneri i developeri. Accessibility je bio izuzetno bitan za Carnet, tako da su od početka radili na tome zajedno, jer čak iako se radilo prvenstveno o developerskom radu, dizajner je bio potreban za konzultiranje.

Komunikacija se proširila i na klijente koji su davali povratne informacije na dizajn i odobravali svaki korak prije produkcije. Emanuele pojašnjava kako direktan kontakt s klijentom pomaže izbjeći usko grlo u realizaciji projekata. Shodno tome, Neuralab je oformio ‘Client Handbook’ – sveobuhvatan vodič koji pomaže klijentima da budu aktivni sudionici u procesu dizajna i razvoja od početnih ideja do konačne izvedbe.

Što je dizajneru banalno, developeru ne mora biti

Iako zvuči kao klišej, jedino rješenje za smanjenje tenzija i konflikata koje Emanuele i Vedran spominju je upravo konstantna komunikacija  i razumijevanje, napominje Martina:

Često je neka promjena dizajnerima banalna dok developerima nije i obratno. Kada mi nešto nije jasno, ne ustručavam se pitati. Naprotiv, znam biti prilično dosadna s pitanjima. To je možda najbolji savjet koji imam za podijeliti – nikada se nemoj sramiti pitati i učiti! Mojih nekoliko go-to pitanja za developere u takvim situacijama su:

• Što je problem i zašto?

• Koji su njihovi prijedlozi rješenja?

• Koliko je vremena potrebno za realizaciju tih prijedloga?

• Koje je, prema njihovom mišljenju, najbolje rješenje uzimajući u obzir sve 4 strane (dizajner/developer/klijent/korisnik)?

I tako zajedničkim snagama, dođemo do nekog zaključka.

U konačnici, da bi se i procesi i komunikacija u sklopu design handoffa poboljšali na razini cijele industrije, ključna je i edukacija, zaključuje Iva:

Rekla bih da su ovakvi članci dobra praksa kako educirati developere o dizajn procesu, isto tako i dizajnerima koristi čitanje članaka o tehnološkim novostima. Osim vanjske edukacije, u Neuralabu održavamo i interne radionice na kojima predstavljamo dobre prakse koje su nam pomogle unaprijediti poslovne procese.