Kako odobriti dizajn web-stranice prije nego postane kod?

Figma je 15. listopada 2026. predstavila Specs i otvorila šire testiranje takozvanih slojeva koda. Cilj je na istom mjestu povezati pisane zahtjeve, vizualni dizajn, radni prototip i programski kod. Dizajner, naručitelj i razvojni tim tako mogu raspravljati o rješenju koje više nije samo statična slika ekrana, nego se može ponašati poput stvarne web-stranice.

Za hrvatsku malu ili srednju tvrtku to ne znači da sada može preskočiti planiranje weba. Upravo suprotno: što je jednostavnije brzo pretvoriti ideju u uvjerljiv prototip, to je važnije znati što se zapravo odobrava. Klikanje kroz nekoliko lijepih ekrana nije isto što i provjera sadržaja, korisničkog puta, mobilnog prikaza, obrazaca, administracije i iznimnih situacija.

Brži prijelaz iz dizajna u kod mijenja trenutak odobrenja

U klasičnom tijeku projekta između dizajna i razvoja postoji vidljiva granica. Najprije se dogovore struktura i izgled, a zatim razvojni tim prema njima izrađuje funkcionalnu stranicu. Novi alati tu granicu čine manje očitom jer dizajn može sadržavati stvarni kod, podatke, animacije i interakcije.

To ubrzava ispitivanje ideja. Primjerice, tvrtka može ranije provjeriti kako se otvara mobilni izbornik, kako korisnik prolazi kroz obrazac ili što se događa nakon pritiska na gumb. Međutim, isti dojam funkcionalnosti može stvoriti pogrešan zaključak da je rješenje gotovo i spremno za objavu.

Prototip može izvrsno prikazivati zamišljeno ponašanje, a da još nema povezanu bazu podataka, stvarno slanje obrazaca, sigurnosne postavke, analitiku, optimizirane fotografije ili uređeno administracijsko sučelje. Zato odobrenje treba biti preciznije od rečenice: „Izgleda dobro, možete nastaviti.”

Prototip nije isto što i gotova web-stranica

Dobar prototip odgovara na pitanja o rasporedu, prioritetima i načinu korištenja. Gotova web-stranica mora pouzdano raditi u stvarnim uvjetima. Ta razlika postaje posebno važna kada se pomoću AI alata iz dizajna brzo generira početni kod.

Prije odobrenja utvrdite u kojoj se fazi projekt nalazi:

• Skica korisničkog puta provjerava redoslijed stranica i koraka, ali ne mora imati završni vizualni izgled.
• Vizualni prototip prikazuje boje, tipografiju, fotografije i komponente, ali može koristiti ogledni sadržaj.
• Interaktivni prototip omogućuje klikanje i simulira ponašanje, no radnje ne moraju biti povezane sa stvarnim sustavima.
• Prototip podržan kodom može sadržavati stvarne interakcije, ali još nije nužno siguran, pristupačan, optimiziran ni spreman za održavanje.
• Produkcijska stranica prolazi razvoj, unos sadržaja, tehničke provjere, testiranje i pripremu za objavu.

Ako naručitelj i izvođač pod istom riječju „prototip” podrazumijevaju različite rezultate, lako nastaju neplanirani troškovi i kašnjenja. Opseg faze zato treba zapisati, a ne ostaviti ga na dojmu koji ostavlja prezentacija.

Što treba provjeriti prije prelaska u razvoj

1. Je li odobren stvarni sadržaj?

Naslov od dvije riječi i ogledni odlomak često izgledaju urednije od stvarne ponude tvrtke. U prototipu zato treba isprobati približno stvarne duljine naslova, opisa usluga, cijena, pitanja i odgovora. Ako sadržaj još nije konačan, barem dogovorite njegovu strukturu, odgovornu osobu i rok za dostavu.

2. Jesu li prikazana sva važna stanja?

Obrazac nema samo početni izgled. Potrebna su stanja uspješnog slanja, pogreške, obveznog polja i privremene nedostupnosti. Webshop mora predvidjeti proizvod bez zalihe, različite varijante, neuspjelo plaćanje i praznu košaricu. Sustav rezervacija treba prikazati zauzet termin, otkazivanje i potvrdu rezervacije.

3. Je li provjeren mobilni prikaz?

Nije dovoljno smanjiti široki dizajn na širinu mobitela. Treba provjeriti redoslijed informacija, veličinu gumba, duljinu izbornika, obrasce, tablice i fotografije. Ako korisnik glavnu radnju ne može jednostavno obaviti jednom rukom, problem treba riješiti u prototipu, a ne nakon objave.

4. Je li jasno što se uređuje kroz administraciju?

Tvrtka treba znati hoće li samostalno mijenjati tekstove, usluge, proizvode, cijene, članove tima ili dokumente. Polja i korisničke ovlasti nisu samo razvojno pitanje. Ona određuju koliko će svakodnevno održavanje biti jednostavno i koliko je lako slučajno narušiti raspored stranice.

5. Jesu li komponente dosljedne?

Gumbi iste namjene trebaju imati isto ponašanje, boju i naziv. Kartice usluga, obrasci i upozorenja trebaju slijediti zajednička pravila. AI može brzo izraditi novu varijantu, ali bez jasnog sustava može proizvesti niz sličnih, a ipak nedosljednih elemenata. To kasnije otežava korištenje, razvoj i održavanje.

6. Postoji li zapis odluka?

Nakon sastanka treba biti jasno koja je verzija odobrena, što ostaje otvoreno i tko donosi konačnu odluku. Upravo je povezivanje pisanih zahtjeva s dizajnom važan dio Figmine novosti. Neovisno o alatu, poslovna je korist ista: odluke trebaju ostati uz rješenje na koje se odnose.

Primjer odluke: novi web za servisnu tvrtku

Zamislimo tvrtku koja ugrađuje i održava tehničku opremu. Prototip naslovnice izgleda dovršeno: sadrži veliku fotografiju, četiri usluge i istaknuti gumb „Pošaljite upit”. Klik na gumb otvara lijepo oblikovan obrazac. Vlasnik bi na temelju tog prikaza mogao odmah odobriti izradu.

Prije toga ipak treba odgovoriti na nekoliko poslovnih pitanja. Treba li korisnik odabrati vrstu uređaja? Je li potrebno poslati fotografiju kvara? Obavlja li tvrtka uslugu na svim lokacijama ili samo na određenom području? Tko prima upit i u kojem roku odgovara? Treba li hitne intervencije odvojiti od redovnog održavanja?

Odgovori mogu promijeniti raspored cijele stranice. Područje rada možda treba prikazati prije obrasca. Fotografija problema može zahtijevati prijenos datoteke i posebnu obavijest o obradi podataka. Hitni upit može trebati telefonski kontakt umjesto običnog obrasca. Prototip je koristan upravo zato što se te odluke mogu provjeriti prije skuplje faze razvoja.

U sklopu UX/UI dizajna i izrade prototipova planiramo korisničke tokove, sučelja i interaktivne prikaze za provjeru ideje. Kada projekt prelazi u izradu web-stranice, dogovoreni dizajn treba povezati sa stvarnim sadržajem, obrascima, mobilnim prikazom i sustavom za uređivanje.

Odobrite odluke, a ne samo izgled ekrana

Najkorisniji rezultat novijih alata nije automatski generiran kod, nego ranija mogućnost provjere kako će web funkcionirati. Tvrtka može prije razvoja uočiti nedostajuće korake, nejasne poruke i nepraktična ponašanja. No to vrijedi samo ako prototip promatra kao alat za odlučivanje, a ne kao dokaz da je projekt već završen.

Prije konačnog odobrenja zatražite pregled korisničkog puta, važnih stanja, mobilnog prikaza, stvarnog sadržaja, administracije i otvorenih pitanja. Završna kontrolna točka treba glasiti: znaju li naručitelj, dizajner i razvojni tim što se gradi, kako treba raditi i prema čemu će se provjeriti rezultat?

Ako imate prototip ili postojeći web, ali niste sigurni što treba provjeriti prije razvoja ili redizajna, možete nam se javiti za razgovor i pregled projekta. Cilj pregleda nije dodati nepotrebne funkcije, nego na vrijeme razjasniti odluke koje utječu na korištenje, opseg i održavanje web-stranice.