Kako navesti developere da zaista koriste dizajn sistem
Biću iskrena: navesti developere da koriste dizajn sistem je teško, bar na početku. Vodim tim u kome dizajneri i frontend developeri sede jedni pored drugih, a usput sam uvodila sisteme i u mnoge druge timove, pa sam čula svaki mogući prigovor. Ali primetila sam i nešto što me tera dalje. Kada developeri zaista počnu da koriste sistem, uvek počnu da ga poštuju, a njihov posao postaje lakši. Niko nikada ne traži da se vrati na staro.
Zašto je teško na početku
Developeri nisu teški ljudi. Oni su zauzeti ljudi koji su se već opekli. Većina je dobijala lepe dizajne koji su ignorisali kako proizvod zaista radi, komponente koje su postojale samo u Figmi i pravila koja su se menjala svake druge nedelje. Zato kada dizajner stigne sa novim sistemom, prirodna reakcija je sumnja: da li je ovo još jedan sloj posla, još jedna stvar koja će nas usporiti?
Ta sumnja je opravdana, i raspravljanje sa njom ne pomaže. Pomaže da se što brže pokaže da sistem oduzima posao umesto da ga dodaje.
Autoritet, pažljivo korišćen
Neko mora da bude vlasnik sistema, i u mojim timovima to sam ja. To znači imati poslednju reč u vizuelnim odlukama i odlukama o interakciji: koje komponente postoje, kako se ponašaju i kada je izuzetak prihvatljiv. Bez tog autoriteta sistem se polako rastvara u zbirku lokalnih varijacija, od kojih je svaka sama za sebe sasvim razumna.
Ali autoritet radi samo ako mu ljudi veruju. To zarađujem doslednošću, objašnjavanjem razloga iza pravila i otvorenom promenom mišljenja kada mi developer pokaže nešto što sam propustila. Pravilo koga se držim je jednostavno: na odluci mogu da insistiram samo ako mogu da je objasnim. Ako ne mogu, to još nije pravilo.
Kreativnost u pristupu
Autoritet postavlja granice; kreativnost pomaže ljudima da ih pređu. Tokom godina prestala sam da prezentujem sisteme i počela da dolazim do developera tamo gde već jesu. Govorim njihovim jezikom: tokeni su varijable, komponente imaju svojstva i stanja, a registar se čita kao dokumentacija, a ne kao mudbord. Staram se da sistem postoji u kodu, a ne samo u dizajn fajlovima, pa je njegovo korišćenje put najmanjeg otpora.
Tražim i prvu malu pobedu. Developer koji za jedno popodne napravi složenu formu jer polja, stanja validacije i razmaci već postoje postaje najbolji zagovornik sistema, mnogo ubedljiviji od bilo čega što bih ja mogla da kažem. A pored biblioteke držim prostor za učenje, sa kratkim beleškama o tome zašto su stvari takve kakve jesu, da niko ne mora dvaput da me pita isto.
Kada jednom počnu
Promena, kada dođe, upečatljiva je. Isti developeri koji su sumnjali u sistem počnu da ga brane. Ukazuju na nedoslednosti pre mene, predlažu nove komponente sa ispravnim stanjima i imenima i suprotstavljaju se svakome ko pokuša da ručno upiše boju. Razgovori između dizajna i razvoja postaju kraći i mirniji, jer obe strane govore istim jezikom.
To poštovanje vredi svakog teškog razgovora na početku. Dizajn sistem koji developeri zaista koriste nije nešto što dizajner može da nametne. To je nešto što ceo tim izabere, kada se sam uveri koliko olakšava posao. Moj posao je da ih dovedem do te tačke sa dovoljno čvrstine da držim liniju i dovoljno mašte da linija bude vredna držanja.
Pročitajte sledeće
Dizajn sistemiSkupovi koji ne znaju jedan za drugog: rad na klijentovom dizajn sistemu
Da li vaš dizajn sistem počinje da bledi?
Rado bih čula više →