Web development brief je kratak, strukturiran dokument koji potencijalnom izvođaču daje dovoljno konteksta da razume šta treba izgraditi, za koga, sa kojim ograničenjima i po kojim kriterijumima će se isporuka procenjivati. Njegova svrha nije da unapred propiše svaku tehničku odluku, već da spreči da prva ponuda bude zasnovana na pretpostavkama.
Pre nego što zatražite ponudu za novi sajt ili veću rekonstrukciju, definišite najmanje: poslovni cilj, primarnu publiku, stranice i funkcije, postojeći sadržaj, integracije, tehničke zahteve, odgovornosti obe strane i način prihvatanja isporuke. Ako neke stavke još nisu poznate, označite ih kao otvorena pitanja umesto da ih prećutno izostavite.
Takav brief olakšava poređenje ponuda, ali i kasniju realizaciju. Za širi pregled same usluge i koraka izrade možete pogledati stranicu izrada sajta; ovaj tekst je uži i bavi se pripremom ulaza u projekat, pre nego što počne komercijalno i tehničko usaglašavanje.
Šta brief treba da postigne
Pre pisanja dokumenta razdvojite tri stvari koje se često mešaju:
- Brief objašnjava problem, cilj, kontekst i očekivani obim.
- Ponuda prevodi taj kontekst u predloženo rešenje, faze, cenu, pretpostavke i uslove.
- Tehnička specifikacija detaljnije definiše ponašanje sistema, arhitekturu, interfejse i kriterijume testiranja.
Za prvu ponudu brief ne mora da donese konačan izbor CMS-a, frameworka ili hostinga. Međutim, mora da bude dovoljno konkretan da izvođač ne procenjuje potpuno drugačiji projekat od onoga koji vi imate na umu. Ako tražite „moderan sajt“, dopunite to opisom sadržaja, tipova korisnika, potrebnih akcija, sistema sa kojima sajt treba da komunicira i ograničenja koja ne sme da prekrši.
Obavezne celine web development briefa
1. Poslovni kontekst i cilj projekta
Počnite sa kratkim opisom organizacije, ponude i razloga zbog kojeg projekat postoji. Nije potrebno prepisivati ceo marketinški plan. Dovoljno je objasniti šta sajt treba da podrži i šta trenutno ne funkcioniše.
Umesto cilja „potreban nam je novi sajt“, napišite, na primer: „Potrebna je nova prezentacija usluge koja jasno razdvaja tri ciljne grupe i omogućava kvalifikovan upit kroz strukturiran formular.“ Ako postoji više ciljeva, rangirajte ih. Primarni cilj može biti generisanje upita, dok su sekundarni ciljevi bolja organizacija sadržaja, lakše uređivanje stranica ili povezivanje sa internim sistemom.
Dodajte i kontekst postojećeg rešenja: šta ostaje, šta se menja, da li se zadržava domen i da li je važan kontinuitet URL adresa. Migracija bez jasnog plana može obuhvatiti preusmerenja, prenos sadržaja, medija i metapodataka, pa je to bolje navesti pre ponude nego tek tokom razvoja.
2. Publika, korisnički zadaci i prioritetne akcije
Izvođaču je korisnije da zna šta posetilac pokušava da uradi nego samo njegovu demografsku oznaku. Opišite glavne tipove korisnika i njihove zadatke:
- potencijalni klijent želi da razume uslugu, proveri relevantnost i pošalje upit;
- postojeći klijent traži dokument, kontakt ili podršku;
- interni urednik želi da objavi i ažurira sadržaj bez intervencije programera.
Za svaki važan zadatak navedite početnu tačku, očekivani sledeći korak i uspešan ishod. To ne mora biti kompletan UX dokument, ali pomaže da se razlikuje informativna stranica od aplikativne funkcije. Navedite i poznate probleme postojećeg sajta, kao što su nejasna navigacija, dupliran sadržaj, komplikovan formular ili teško održavanje.
3. Obim: stranice, tipovi sadržaja i funkcionalnosti
Najčešći izvor nesporazuma je neodređen obim. Napravite početni inventar stranica i grupišite ih po tipu:
| Oblast | Šta navesti u briefu |
|---|---|
| Osnovne stranice | Početna, o nama, kontakt, pravne informacije i druge obavezne celine. |
| Usluge ili proizvodi | Broj kategorija, da li imaju isti šablon i koje informacije sadrže. |
| Blog ili resursi | Tipovi objava, kategorije, autori, pretraga, filtriranje i arhiva. |
| Posebne funkcije | Formulari, kalkulatori, nalozi, rezervacije, preuzimanja ili korisničke zone. |
| Administracija | Ko uređuje sadržaj, koje uloge postoje i šta mora da bude podesivo. |
Ne morate znati konačan broj svih budućih stranica, ali navedite model koji se ponavlja. Razlika između „deset stranica usluga“ i „jedan tip sadržaja sa deset unosa“ utiče na način izrade, uređivanje i buduće širenje.
Odvojite must-have funkcije od nice-to-have ideja. Ako je obim još nejasan, korisno je razmotriti da li je za prvu fazu dovoljan MVP. Vodič MVP ili puna verzija sajta može pomoći pri odlučivanju šta zaista mora da bude spremno na početku, a šta može da ostane za narednu fazu.
4. Sadržaj, materijali i odgovornosti
Ponuda će biti preciznija ako jasno navedete ko obezbeđuje tekstove, fotografije, ilustracije, prevode, proizvode i pravne dokumente. Za svaku grupu materijala označite da li je:
- spremna za unos;
- potrebna redakcija ili copywriting;
- potrebno novo fotografisanje ili dizajn;
- preuzeta iz postojećeg sistema i podložna čišćenju;
- još u fazi planiranja.
Navesti „sadržaj obezbeđuje klijent“ nije dovoljno ako nije jasno ko ga priprema, ko ga odobrava i u kom formatu se dostavlja. U briefu definišite i ko daje konačno odobrenje. Bez te uloge, korekcije se često vraćaju kroz više ljudi i menjaju dogovoreni obim.
5. Dizajn, brend i referentni primeri
Priložite postojeće smernice brenda, logo u odgovarajućem formatu, paletu boja, tipografiju i primere materijala ako postoje. Reference sa drugih sajtova koristite da objasnite konkretnu osobinu: preglednost navigacije, način prikaza paketa, strukturu stranice ili ponašanje formulara.
Nemojte slati samo listu linkova uz zahtev da se „uradi isto“. Navedite šta vam se dopada, šta ne želite i koji deo reference nije primenljiv na vaš projekat. Tako se smanjuje rizik da vizuelni uzor bude protumačen kao zahtev za kopiranje cele strukture ili funkcionalnosti.
6. Integracije, podaci i spoljne zavisnosti
Popišite sve sisteme sa kojima sajt treba da razmenjuje podatke ili šalje obaveštenja. To može biti CRM, alat za newsletter, sistem za naplatu, kalendar, skladište proizvoda, mapa, servis za pretragu ili interni API. Za svaku integraciju navedite:
- naziv sistema i njegovu svrhu;
- da li podaci idu u jednom ili oba smera;
- koji događaj pokreće razmenu;
- ko obezbeđuje pristupe, dokumentaciju i testno okruženje;
- šta treba da se desi ako servis nije dostupan.
Integracija nije samo postavljanje dodatka ili unošenje ključa. Potrebno je definisati podatke, dozvole, greške i vlasništvo nad nalozima. Ako zavisite od treće strane, navedite poznata ograničenja i eventualne troškove licence, ali nemojte pretpostaviti da će izvođač sam moći da proveri nedokumentovani sistem.
7. Analitika, SEO i pristupačnost kao zahtevi
Ako se merenje ostavi za kraj, može se desiti da važni događaji nisu predviđeni u strukturi interfejsa. Navedite koje radnje treba pratiti: slanje formulara, klik na telefon ili email, preuzimanje dokumenta, izbor filtera, početak procesa ili završetak rezervacije. Za detaljniji spisak pitanja pogledajte analytics specification: koje evente definisati pre programiranja.
Za SEO u briefu navedite postojeće URL-ove, jezičke verzije, plan migracije, važne stranice i ko priprema sadržaj i metapodatke. To nije obećanje pozicija u pretrazi, već zahtev da se tehnička i sadržajna struktura ne projektuju bez uvida u postojeće stanje.
Za pristupačnost zapišite očekivanja u vezi sa tastaturom, kontrastom, fokusom, alternativnim tekstovima, naslovima i formularima. WCAG može poslužiti kao referentni okvir, ali u briefu je korisnije navesti konkretne korisničke potrebe i nivo usklađenosti koji se očekuje nego samo dodati reč „pristupačno“.
8. Tehnička ograničenja i održavanje
Navedite postojeći hosting, domen, CMS, server, repozitorijum, bezbednosna pravila i interne IT zahteve ako postoje. Ako tehnologija nije unapred određena, objasnite koji su kriterijumi važni: jednostavno uređivanje, mogućnost integracije, prenosivost, kontrola pristupa, brzina razvoja ili dugoročno održavanje.
Obuhvatite i period posle lansiranja. Ko ažurira sadržaj? Ko prati greške? Da li su potrebni backup, bezbednosna ažuriranja, tehnička podrška ili razvoj novih funkcija? Održavanje nije isto što i ispravka grešaka u garantnom periodu, pa tražite da ponuda jasno razdvoji te stavke.
Kako da brief učini ponude uporedivim
Svaki izvođač može drugačije tumačiti isti zahtev. Zato u briefu zatražite da ponuda posebno prikaže:
- pretpostavljeni obim i šta je iz njega isključeno;
- predložene faze i ključne tačke odobravanja;
- šta je uključeno u dizajn, razvoj, unos sadržaja, migraciju i testiranje;
- potrebne materijale i pristupe sa vaše strane;
- otvorena pitanja, rizike i zavisnosti;
- način obračuna dodatnih zahteva;
- uslove nakon objavljivanja sajta.
Nemojte porediti samo ukupne iznose. Jedna ponuda može uključivati unos sadržaja i migraciju, dok druga može pretpostaviti da sve materijale dostavlja klijent. Kada su pretpostavke napisane, razlika u ceni dobija objašnjenje, a ne ostaje samo razlog za izbor najniže ponude. Više o tome kako obim i arhitektura utiču na budžet možete pročitati u tekstu Budžet za izradu sajta: koje stavke najviše utiču na cenu.
Šta ne treba raditi u briefu
- Ne koristiti samo opšte prideve. „Brz“, „moderan“ i „user-friendly“ treba prevesti u proverljive zahteve i prioritete.
- Ne zaključavati tehnologiju bez razloga. Ako postoji opravdan tehnički zahtev, navedite ga; ako ne postoji, ostavite prostor za obrazloženi predlog.
- Ne skrivati nepoznanice. Otvoreno pitanje je korisnije od lažne preciznosti.
- Ne mešati sve faze u jednu listu. Istraživanje, UX, dizajn, razvoj, unos sadržaja, testiranje i održavanje imaju različite odgovornosti.
- Ne tražiti neograničene izmene. Definišite ko odobrava i kako se obračunavaju promene van dogovorenog obima.
Praktična struktura dokumenta
Za većinu projekata dovoljan je dokument sa sledećim redosledom:
- kratak opis organizacije i cilja;
- publika i prioritetni korisnički zadaci;
- obim stranica, tipova sadržaja i funkcija;
- postojeće stanje i plan migracije;
- sadržaj, dizajn i materijali;
- integracije, analitika, SEO i pristupačnost;
- tehnička ograničenja i očekivanja za održavanje;
- rokovi, interna dostupnost i proces odobravanja;
- otvorena pitanja i kriterijumi za poređenje ponuda.
Na kraju dodajte priloge: mapu sajta, postojeće URL-ove, primere sadržaja, tehničku dokumentaciju i linkove ka referencama. Ako se brief šalje više izvođača, svim stranama pošaljite istu osnovnu verziju i zabeležite naknadna pojašnjenja. Tako poređenje ostaje fer.
Sledeći korak posle briefa
Pre slanja dokumenta prođite kroz njega kao da ste izvođač koji prvi put vidi projekat. Da li je jasno ko koristi sajt, šta mora da bude moguće, ko priprema sadržaj i šta se smatra završenim? Ako nije, dopunite samo ono što utiče na obim, rizik ili način isporuke.
Zatim tražite da se nejasne tačke obrade kroz pitanja i pretpostavke, a ne da se automatski pretvore u dodatne funkcije. Dobar brief ne uklanja potrebu za razgovorom; on taj razgovor pomera sa opštih želja na konkretne odluke o obimu, odgovornostima i prioritetima.
