Specifikacija web shopa je dokument koji opisuje kako prodavnica treba da radi pre nego što razvoj počne. Ne svodi se na spisak stranica ili izbor boja, već povezuje poslovna pravila, korisničke scenarije, podatke, integracije i način provere isporučenog rešenja.
Pre razvoja treba jasno definisati najmanje: šta se prodaje i kako je katalog organizovan, kako nastaje i obrađuje se porudžbina, koje načine plaćanja i dostave podržavate, sa kojim sistemima shop razmenjuje podatke, ko upravlja sadržajem i kako se prihvata funkcionalna verzija. Ako ove odluke ostanu neodređene, promena obima projekta obično se pojavljuje tek tokom izrade.
Ovaj dokument može biti kratak ili vrlo detaljan, u zavisnosti od složenosti prodaje. Njegova svrha nije da unapred predvidi svaku liniju koda, već da ukloni nejasnoće koje utiču na arhitekturu, procenu i testiranje. Kada su zahtevi spremni, sledeći korak je razgovor o izradi web shopa kroz konkretan obim i prioritete.
1. Poslovni cilj i granice projekta
Specifikacija treba da počne od odluka koje određuju obim, a ne od vizuelnih detalja. Zapišite ko koristi shop, šta kupuje, na kom tržištu se prodaje i koji proces danas predstavlja problem. Na primer, drugačije se projektuje prodavnica sa nekoliko desetina pažljivo predstavljenih proizvoda nego katalog sa velikim brojem varijanti, čestim promenama zaliha i više skladišta.
U ovom delu definišite:
- primarne grupe kupaca i njihove najčešće kupovne scenarije;
- proizvode ili usluge koje ulaze u prvu verziju;
- tržište, jezik, valutu i teritoriju isporuke;
- šta je obavezno za lansiranje, a šta može da sačeka narednu fazu;
- ko donosi konačne odluke i ko odobrava sadržaj i funkcionalnosti.
Posebno izdvojite ono što nije deo prve verzije. Ograničenje obima nije znak da je projekat nepotpun; ono omogućava da se prioritetne funkcije razviju, testiraju i puste bez stalnog pomeranja cilja.
2. Katalog, kategorije i podaci o proizvodu
Katalog je osnova web shopa, pa specifikacija treba da opiše strukturu podataka, a ne samo izgled kartice proizvoda. Za svaki tip proizvoda navedite koje informacije postoje, koje su obavezne i kako se ponašaju u različitim stanjima.
Obavezna polja i varijante
Tipična polja mogu da uključuju naziv, šifru, opis, fotografije, cenu, poreski tretman, dostupnost, dimenzije, težinu i povezane proizvode. Ako proizvod ima veličinu, boju, materijal ili drugo svojstvo, definišite da li je to varijanta sa sopstvenom šifrom, cenom i zalihom ili samo informativna karakteristika.
Važno je unapred razjasniti sledeće situacije:
- da li se proizvod može kupiti kada je zaliha nula;
- šta se prikazuje kada je proizvod privremeno nedostupan;
- da li različite varijante imaju različite fotografije, cene ili rokove isporuke;
- da li proizvodi mogu biti aktivni, skriveni, arhivirani ili dostupni samo uz upit;
- kako se prikazuju akcijska cena, osnovna cena i eventualna ograničenja ponude.
Kategorije i atributi
Ne mešajte kategorije i filtere. Kategorija odgovara na pitanje gde proizvod pripada u strukturi ponude, dok atribut ili filter pomaže korisniku da suzi izbor. Dobro definisana taksonomija kasnije olakšava navigaciju, internu pretragu i SEO. Više o tome kako struktura utiče na oba cilja možete pročitati u tekstu SEO i UX kategorija u web shopu: struktura koja radi za korisnika i crawler.
U specifikaciji navedite i ko unosi podatke, u kom formatu se pripremaju fotografije i da li se katalog uvozi iz postojećeg sistema. Veliki broj proizvoda može promeniti izbor načina unosa, validacije i sinhronizacije.
3. Korisnički tok od proizvoda do potvrde
Umesto da se definiše samo lista stranica, opišite najvažnije tokove. Minimalni scenario može da izgleda ovako: korisnik dolazi na kategoriju, filtrira ponudu, otvara proizvod, bira varijantu, dodaje je u korpu, unosi podatke, bira dostavu i plaćanje, potvrđuje porudžbinu i dobija povratnu informaciju.
Za svaki korak zapišite:
- šta korisnik vidi i koju odluku donosi;
- koja polja su obavezna i kako se prikazuje greška;
- šta se dešava ako je proizvod rasprodat tokom kupovine;
- da li je kupovina moguća bez kreiranja naloga;
- koje potvrde dobija korisnik nakon slanja porudžbine.
Ne preskačite alternativne i neuspešne scenarije. Odbijena transakcija, nevažeća adresa, prekinuto plaćanje, promenjena cena ili nedostupna varijanta nisu izuzeci koje treba rešavati tek pred lansiranje. Oni su deo specifikacije jer direktno utiču na poverenje kupca i operativni rad.
Product page kao zaseban zahtev
Stranica proizvoda treba da podrži odluke kupca: izbor varijante, pregled ključnih karakteristika, dostupnost, dostavu, povrat i sledeći korak. Ne određujte samo da „postoji product page“, već navedite koje informacije moraju biti vidljive, šta se menja izborom opcije i kako se ponaša poziv na akciju. Za dodatni razvojni kontekst pogledajte Product page: šta development mora da podrži za bolju konverziju.
4. Korpa, checkout, plaćanje i dostava
Checkout je deo specifikacije u kojem se najčešće kriju neizgovorena pravila. Potrebno je definisati koje podatke kupac unosi, da li se adresa za dostavu razlikuje od podataka za račun, kada se obračunava dostava i šta se prikazuje pre konačne potvrde.
Razjasnite:
- kupovinu kao gost ili obaveznu registraciju;
- polja za kontakt, adresu, račun i napomenu uz porudžbinu;
- zone dostave, pravila za cenu dostave i pragove za besplatnu isporuku, ako postoje;
- načine plaćanja koji ulaze u prvu verziju;
- trenutak u kojem se porudžbina smatra primljenom;
- šta se dešava kod neuspešnog plaćanja, otkaza ili povraćaja.
Za svaki status porudžbine napišite ko ga menja i koja obaveštenja se šalju. Primeri statusa mogu biti primljena, potvrđena, u obradi, poslata, završena i otkazana, ali konkretan model treba da prati stvarni operativni proces. Ako se porudžbine ručno proveravaju pre obrade, to mora biti jasno naznačeno.
5. Integracije i razmena podataka
Integracija nije samo naziv servisa koji treba povezati. U specifikaciji opišite smer podataka, učestalost razmene, vlasnika podatka i ponašanje kada razmena ne uspe. To je posebno važno za ERP, knjigovodstvo, skladište, payment gateway, kurirsku službu, CRM i analitiku.
| Sistem | Podaci koji se razmenjuju | Važna odluka |
|---|---|---|
| Skladište ili ERP | proizvodi, cene, zalihe, porudžbine | koji sistem je izvor istine i kada se podaci ažuriraju |
| Payment servis | iznos, status transakcije, identifikator porudžbine | kako se obrađuju uspeh, greška i ponovljeni pokušaj |
| Dostava | podaci primaoca, paket, status slanja | ko kreira pošiljku i gde se prati status |
| Analitika | pregledi, dodavanje u korpu, kupovina | koji događaji su potrebni za poslovno izveštavanje |
Nemojte navesti samo „potrebna je integracija sa ERP-om“. Navedite da li se artikli unose u ERP-u ili u shopu, šta se događa kada se cena razlikuje i kako se prijavljuje greška. Ako postoji postojeći sistem, pre razvoja proverite njegovu dokumentaciju, dostupne pristupe i ograničenja.
6. Administracija, uloge i svakodnevni rad
Web shop nije završen kada kupac pošalje porudžbinu. Specifikacija treba da opiše kako tim upravlja proizvodima, sadržajem i narudžbinama. Definišite uloge, na primer administrator, urednik kataloga, osoba za obradu porudžbina i osoba sa pristupom izveštajima. Ne mora svaki korisnik da ima ista prava.
Opišite i svakodnevne zadatke:
- kreiranje i izmena proizvoda;
- upravljanje zalihama i statusima dostupnosti;
- obrada, izmena i otkazivanje porudžbine;
- upravljanje kuponima, akcijama i povezanim proizvodima;
- izmena navigacije, informativnih stranica i sadržaja;
- pregled osnovnih izveštaja koji su potrebni za rad.
Ako je unos kataloga obiman, unapred odredite da li se radi ručni unos, uvoz iz tabele ili automatska sinhronizacija. Ova odluka utiče na pripremu podataka, obuku i procenu projekta.
7. SEO, sadržaj, pristupačnost i analitika
SEO zahteve treba zapisati kao deo strukture, a ne dodavati ih nakon razvoja. Definišite koje stranice postoje, kako se formiraju naslovi i meta podaci, kako se rešavaju proizvodi bez zaliha i da li filteri stvaraju indeksabilne URL-ove. Takođe navedite pravila za interne linkove, preusmeravanja kada se menja URL i sadržaj koji mora biti jedinstven za važne kategorije.
Za sadržaj pripremite odgovore na praktična pitanja: ko piše opise, ko obezbeđuje fotografije, koje stranice su obavezne i ko ih odobrava. Uključite i zahteve za pristupačnost, čitljive forme, jasne poruke o greškama, navigaciju tastaturom i dovoljan kontrast. Ne treba obećavati određeni rezultat, ali treba definisati šta se proverava.
Za analitiku navedite poslovne događaje koje želite da pratite: pregled proizvoda, izbor varijante, dodavanje u korpu, početak checkouta, uspešna kupovina, korišćenje interne pretrage i neuspešno pronalaženje proizvoda. Posebno odredite koje podatke nije potrebno prikupljati i ko proverava tačnost implementacije.
8. Interne pretrage i prazna stanja
Pretraga često izgleda kao mala funkcija, ali njena specifikacija obuhvata više odluka. Zapišite da li pretraga radi po nazivu, šifri, atributu i opisu, kako tretira greške u kucanju, da li prikazuje predloge i šta se dešava kada nema rezultata.
Definišite i prazna stanja: nema proizvoda u kategoriji, nema rezultata pretrage, proizvod više nije dostupan, korpa je prazna i plaćanje nije prošlo. Svako stanje treba da ima razumljivu poruku i koristan sledeći korak. Za detaljniji pregled ovog dela pogledajte Pretraga u web shopu: autocomplete, sinonimi i zero-results scenario.
9. Tehnički, bezbednosni i operativni zahtevi
U specifikaciji navedite zahteve koji nisu pojedinačne funkcije, ali utiču na kvalitet isporuke. To mogu biti podrška za mobilne uređaje, kompatibilnost sa dogovorenim pregledačima, upravljanje pristupima, rezervne kopije, logovanje grešaka i način objavljivanja izmena.
Ne treba unapred propisati tehnologiju ako za to ne postoji poslovni razlog. Umesto toga, definišite očekivano ponašanje: stranice treba da budu upotrebljive na relevantnim ekranima, greške integracija treba da budu vidljive odgovornoj osobi, a pristup administraciji ograničen prema ulozi. Platforma i arhitektura zatim mogu da se biraju na osnovu obima, integracija i dugoročnog održavanja.
10. Kriterijumi prihvatanja i testni podaci
Svaka važna funkcionalnost treba da ima kriterijum prihvatanja. To je konkretan opis po kojem se proverava da li je zahtev ispunjen. Na primer: „Kada kupac izabere dostupnu varijantu, cena i slika se ažuriraju, a izabrana opcija se prenosi u korpu.“ Takva formulacija je korisnija od zahteva „varijante treba da rade“.
Napravite listu testnih scenarija za:
- uspešnu i neuspešnu kupovinu;
- različite varijante, zalihe i cene;
- mobilni prikaz i validaciju formi;
- pretragu sa rezultatima i bez rezultata;
- sinhronizaciju sa spoljnim sistemima;
- otkazivanje, povraćaj i promenu statusa porudžbine.
Pripremite realne, ali bezbedne testne podatke. Pre lansiranja proverite i sadržaj, linkove, preusmeravanja, obaveštenja, analitiku i proces obuke. Ako vam je potrebna procena obima, korisno je razdvojiti obavezne, poželjne i odložene stavke; na cenu najviše utiču upravo obim, integracije i način rada, što je objašnjeno u tekstu Izrada web shopa: koje stavke najviše utiču na cenu projekta.
Kako da specifikacija ostane upotrebljiva
Dokument održavajte kao radnu osnovu projekta, sa jasno označenim verzijama i otvorenim pitanjima. Zahtev koji nije odlučen označite kao otvoren, umesto da ga sakrijete u neodređenu formulaciju. Za svaku promenu zabeležite šta se menja, na koje tokove utiče i da li pomera prioritet ili obim.
Najpraktičniji format je kombinacija kratkog poslovnog konteksta, tabela, korisničkih scenarija, skica kada su potrebne i kriterijuma prihvatanja. Pre razvoja prođite kroz dokument sa osobama koje prodaju, obrađuju porudžbine i održavaju katalog. Njihova pitanja često otkriju operativne zahteve koje marketing ili dizajn sami ne mogu da predvide.
Ako vam je cilj i šira digitalna platforma, a ne samo prodajni katalog, zahtevi za sadržaj, više tipova stranica i druge funkcionalnosti mogu se razmotriti i u okviru izrade sajta. Za sam web shop, sledeći konkretan korak je da se specifikacija pretvori u prioritetizovan obim: šta mora da radi prvog dana, šta se meri i šta može da bude naredna faza.
