Vođenje UX i frontend tima kroz mnogo paralelnih projekata

„Tako je bilo u dizajnu“

Na površini rečenica zvuči sasvim razumno. Dizajn je pokazao jedno, izrada je uradila to, pa gde je problem? Problem je u onome što rečenica tiho pretpostavlja: da je dizajn potpuna specifikacija, potpisana i zapečaćena, i da je sve što nije pomenuo tuđa briga.

Nijedan dizajn ne pokriva sve. Prazna stanja, dugačka imena, spore veze, podaci koji nedostaju, drugi jezik, uloga na koju niko nije pomislio. Dizajn je izjava namere, a namera traži tumačenje. Kada se to tumačenje zameni doslovnom kopijom, praznine ne nestaju. Samo stižu do korisnika neispitane.

Zašto mi se taj stav ne dopada

Pre svega to vidim kao pitanje zrelosti, a ne veštine. Zreo developer čita dizajn onako kako dobar urednik čita rukopis: pažljivo i sa pitanjima. Ako nešto izgleda čudno, protivreči ranijem ekranu ili ignoriše slučaj koji podaci očigledno dozvoljavaju, podigne slušalicu. Rečenica „tako je bilo u dizajnu“ je ono što ostane kada se taj razgovor nikada nije desio.

Ona i deli odgovornost na način koji proizvod ne može sebi da priušti. Korisnika ne zanima iz čijeg sloja je greška došla. Vidi samo da postoji.

Zašto krivica završi na dizajnu

Ovo ima i neprijatnu stranu koja se retko kaže naglas. Od dizajnera se veoma često traži da isporuče pre nego što imaju ono što im treba. Zahtevi stižu kasno, dokumentacija još kasnije, a rok se ne pomera. Zato rade po instinktu i iz sećanja, popunjavajući praznine što razumnije mogu da bi stigli na vreme.

Kada se greška kasnije pojavi, trag vodi nazad do dizajna, jer je dizajn najvidljiviji artefakt. Ono što trag retko pokazuje je ulazni podatak koji je nedostajao i koji je uopšte naterao na nagađanje. Dizajneri nauče da taj teret nose tiho, i vremenom ih istroši.

Udeo organizacije

Mnogo toga uopšte nije lično. Organizaciono je. Projekti se guraju brzo jer moraju da se isporuče i fakturišu, a taj pritisak je i sam posledica okruženja i neizvesnosti u kojoj mnogi od nas žive i rade. Kada novčani tok zavisi od brzine, prvo nestane vreme odvojeno za razumevanje, a razgovori između disciplina su obično prva žrtva.

Nijedan pojedinac to ne može potpuno da popravi. Ali vođa tima može to da imenuje i da zaštiti bar malo tog vremena, jer se cena preskakanja uvek vrati kasnije, i to sa kamatom.

Edukacija na obe strane

Deo odgovora je edukacija, i ona ide u oba pravca. Developerima treba dovoljno dizajnerske pismenosti da prepoznaju kada nešto zaslužuje pitanje, i samopouzdanja da ga postave umesto da grade naslepo. Petominutni poziv sa dizajnerom skoro uvek košta manje od dana prepravki. Isto važi i za backend developere, čije strukture podataka oblikuju ono što interfejs može pošteno da obeća i koji često prvi vide da je ekran dizajniran oko podataka koji ne postoje.

Dizajneri, sa svoje strane, treba da dokumentuju stanja i obrazloženje, a ne samo srećan scenario, da objasne zašto je odluka doneta i da budu dostupni kada izrada počne. Dizajn koji je predat, a zatim branjen sa distance, poziva upravo na doslovno čitanje na koje se kasnije žali.

Kroz mnogo paralelnih projekata

Sve ovo postaje teže kada jedan tim radi na mnogo projekata odjednom. Manje je razgovora, više pretpostavki i manje sećanja na to zašto je bilo šta odlučeno. Ljudi menjaju kontekst nekoliko puta dnevno, a prostor za brzo, neformalno pitanje se smanjuje sa svakom promenom.

Ono što pomaže, po mom iskustvu, prilično je skromno. Dizajneri ostaju dostupni tokom izrade, a ne samo pre nje. Svaka predaja nosi kratku belešku o nameri i o slučajevima koje dizajn ne pokriva. Rane verzije se pregledaju zajedno dok su izmene još jeftine. A zajednička biblioteka komponenti daje obema stranama isti rečnik, pa pitanje može da se postavi jednom rečenicom umesto sastankom.

Ništa od toga nije o tome ko je bio u pravu. Radi se o tome da se sledeći put pitanje postavi pre nego što se rečenica izgovori.