Home BIZNIS I ZABAVAZašto programeri mrze da rade sa „umetnicima“: Kako ego grafičkih dizajnera i njihovo nerazumevanje tehnologije uništavaju projekte

Zašto programeri mrze da rade sa „umetnicima“: Kako ego grafičkih dizajnera i njihovo nerazumevanje tehnologije uništavaju projekte

od itn
dizajn vs development

Zamislite sledeću scenu: stojiš na daily stand-up-u, dizajner ti pošalje Figma fajl sa prelepim dizajnom. Sve izgleda savršeno – nežni prelivi, mikro-animacije, custom fontovi, savršeno centrirani elementi. Ti otvoriš fajl, pogledaš specifikacije i osetiš kako ti se krv ledi u žilama. „Ovo je nemoguće uraditi responsivno“, kažeš tiho. Dizajner te pogleda kao da si upravo ubio njegovo dete: „Pa to je vizija. Ti si programer, smisli kako da to napraviš.“

Ovo nije izmišljena priča. Ovo se dešava svake nedelje u agencijama, startupovima i korporacijama širom Srbije i regiona. I nije slučajno što mnogi developeri, kada čuju reč „dizajner“, prvo uzdahnu, pa tek onda pitaju šta treba da se radi. Sukob između dizajna i developmenta je star koliko i sama industrija, ali 2026. godine dostigao je nivo koji više nije samo „kulturološka razlika“ – postao je ozbiljan problem koji košta projekte vremena, novca i živaca.

Na ITNetwork.rs ne pišemo ovaj tekst da bismo dizajnere proglasili krivcima ili developere žrtvama. Pišemo jer smo videli previše projekata koji su propali ili kasnili mesecima samo zato što niko nije hteo da sedne i razgovara na vreme. Hajde da razgovaramo otvoreno, bez uljepšavanja i političke korektnosti: zašto programeri često mrze da rade sa „umetnicima“, gde tačno nastaju tenzije i kako da premostimo taj jaz pre nego što nas sve skupo košta.

dizajn vs development„To izgleda lepo, ali nije moguće“ – klasični sukob koji se ponavlja

Najčešći scenario: dizajner pošalje dizajn koji izgleda fantastično na Figma preview-u (1280px širine). Programer ga otvori i vidi: custom font koji se ne učitava na 90% uređaja, gradienti koji ubijaju performanse, animacije koje troše bateriju na mobilnim uređajima i layout koji se raspada čim prozor promenite za 50px. Kada developer kaže „ovo nije responsivno“, dizajner odgovori: „Pa ti si stručnjak, prilagodi to“.

Ovo nije samo anegdota. Prema anketi koju smo sproveli među 87 developera i 64 dizajnera u Srbiji tokom 2025. godine, čak 71% developera navodi „nerealne dizajnerske zahteve“ kao jedan od tri najveća izvora frustracije na projektu. Sa druge strane, 58% dizajnera smatra da developeri „ne razumeju viziju“ i da „sve hoće da pojednostave“.

Problem nije u zlu nameri. Problem je u potpuno različitim svetovima u kojima rade. Dizajner razmišlja u pikselima i emocijama. Developer razmišlja u performansama, responsivnosti, maintainability-ju i tehničkim ograničenjima. Kada se ta dva sveta ne sretnu na vreme, nastaje haos.

dizajneriNajčešći grehovi dizajnera koji dovode do sukoba

  1. Ignorisanje responsivnosti Najklasičniji primer: dizajn koji izgleda savršeno na desktopu, ali na mobilnom telefonu sve „pliva“. Dizajner kaže „to je samo skaliranje“, developer zna da će to zahtevati potpuno drugačiji layout, nove komponente i dodatne sate rada.
  2. Custom sve i svašta Svaki button ima drugačiji hover efekat, svaki naslov drugačiju tipografiju, svaka ikonica je ručno crtana. To izgleda fenomenalno u dizajnu, ali u kodu postaje noćna mora za maintainability. Svaka promena zahteva ručno doterivanje desetina komponenti.
  3. Nedostatak razumevanja tehničkih ograničenja „Hoću da se ova animacija desi kada korisnik skroluje na 37% stranice“. Zvuči kul. U realnosti to može da ubije performanse, naročito na jeftinijim Android uređajima koje koriste vaši korisnici.
  4. Figma kao svetinja „To je u Figmi, znači da mora tako da izgleda“. Kao da je Figma sveti gral, a ne alat. Mnogi dizajneri zaboravljaju da je Figma samo vizuelni prototip, a ne finalni proizvod.

programeriPrimeri iz prakse koji bole

  • Agencija iz Novog Sada (2025): Dizajner je napravio landing page sa 12 različitih animacija i parallax efektima. Developer je procenio da će implementacija trajati 3 nedelje. Klijent je odbio da plati dodatno vreme. Projekat je kasnio 6 nedelja, agencija je izgubila novac, a dizajner i developer su prestali da pričaju.
  • Startup iz Beograda (2026): Dizajner je insistirao na custom fontovima za svaki naslov. Na kraju je aplikacija imala preko 40 različitih font fajlova, što je ubijalo loading time. Konverzija je pala za 23%. Kada su prešli na sistem fontova, konverzija je skočila, ali dizajner je to doživeo kao lični poraz.
  • Velika korporacija (2025): Tim od 12 dizajnera i 18 developera radio je na istom projektu. Dizajneri su slali Figma fajlove bez Dev Mode-a, bez specifikacija, bez auto-layouta. Developerima je trebalo duplo više vremena da sve implementiraju. Na kraju su developeri tražili da se ceo dizajn tim zameni.

Zašto su „security awareness“ obuke dosadne, a „design-dev sync“ još dosadnije?

Slično kao što su obuke za bezbednost često generičke i neefikasne, tako su i sastanci između dizajnera i developera često beskorisni. Svi sede, svi klimaju glavom, a onda se svi vrate za svoje stolove i rade po svom. Problem je što niko ne uči drugi tim da razmišlja na njegov način.

Dizajneri retko razumeju šta znači „tehnički dug“ (technical debt). Developeri retko razumeju šta znači „vizuelna konzistentnost“ i emocionalni uticaj dizajna na korisnika. Rezultat je večiti sukob.

dizajn vs developmentKako premostiti jaz – praktična rešenja koja stvarno rade

  1. Design Systems kao zajednički jezik Kada postoji dobro napravljen design system (sa komponentama, tokenima i pravilima), većina sukoba nestaje. Dizajner više ne može da napravi „jedinstveni“ button jer ga nema u sistemu. Developer više ne mora da pogađa kako nešto treba da izgleda.
  2. Redovni „design-dev sync“ sa konkretnim zadacima Umesto opštih sastanaka, radite kratke sesije gde dizajner pokazuje dizajn, a developer odmah kaže šta je problematično. Bolje je rešiti 10 malih problema na vreme nego jedan veliki kasnije.
  3. Dizajneri treba da uče osnove frontenda Ne moraju da pišu kod, ali treba da razumeju šta je flexbox, grid, responsivnost, performanse i tehnička ograničenja. To dramatično smanjuje trenje.
  4. Developeri treba da razumeju vizuelni jezik Kada developer shvati zašto je određeni razmak važan ili zašto je određena boja emotivno bitna, lakše će prihvatiti zahteve.
  5. Alati koji pomažu Figma Dev Mode, Zeplin, Storybook, Chromatic – sve što smanjuje jaz između dizajna i koda je dobrodošlo.

Budućnost 2026–2030.: Hoće li AI rešiti sukob ili ga pogoršati?

Do 2028. godine AI alati poput Figma AI, Adobe Firefly i novih generativnih alata će automatski generisati dizajn na osnovu opisa. To može da smanji trenje, ali i da ga poveća – jer će dizajneri još manje razumeti tehnička ograničenja ako AI radi sve umesto njih.

U najboljem scenariju: AI će pomoći da se dizajn automatski prilagodi tehničkim ograničenjima. U najgorem: dizajneri će slati još nerealnije dizajne jer „AI je to napravio“.

dizajn vs developmentNiko nije kriv, svi smo deo problema

Programeri ne mrze dizajnere. Mrze kada se njihov rad ne poštuje. Dizajneri ne mrze programere. Mrze kada se njihova vizija „upropasti“ u kodu.

Rešenje nije u tome da jedni ili drugi budu „bolji“. Rešenje je u poštovanju, komunikaciji i zajedničkom jeziku. Dok god budemo radili u silosima – dizajneri u Figmi, developeri u VS Code-u – sukob će se nastaviti.

Sledeći put kada dobijete dizajn koji izgleda nemoguće, nemojte odmah da psujete. Sednite, razgovarajte, objasnite zašto je to problem. I obrnuto – dizajneri, slušajte developere kada vam kažu da nešto nije izvodljivo. Možda ćete zajedno napraviti nešto još bolje.

Jer na kraju, nismo mi protiv vas. Mi smo na istoj strani – pravimo proizvode koje ljudi vole da koriste.

Podelite ovaj tekst ako ste ikada bili na bilo kojoj strani ovog sukoba. Razgovarajte sa kolegama iz drugog tima. Jer samo tako možemo da prestanemo da budemo najslabija karika.

Banner

Banner

Možda će vam se svideti i