Svetainės projekto užduoties šablonas: kaip pasiruošti dizaino ir programavimo darbams

Prieš kalbantis su dizaino agentūra nebūtina žinoti kiekvieno puslapio, funkcijos ar techninės detalės. Tačiau reikia būdo paaiškinti, ką norite pakeisti ir kur jums reikia pagalbos.

Svetainės projekto užduoties šablonas suteikia šiam pokalbiui pradžią. Jis sujungia tikslus, auditoriją, turinį, funkcionalumą, atsakomybes, terminus ir biudžeto klausimus, kad potencialus partneris galėtų tiksliau klausti ir pasiūlyti aktualius darbus.

Toliau rasite į dokumentą kopijuojamą šabloną ir užpildytą pavyzdį, parodantį, kaip atsakymai susiję. Nežinoti dalies atsakymų normalu. Svarbu tai aiškiai įvardyti.

Ką turi padėti padaryti svetainės projekto užduotis

Užduotis padeda jūsų komandai ir potencialiam partneriui vienodai suprasti projektą. Ji turėtų paaiškinti, kodėl darbai svarbūs, kas jau žinoma ir kuriuos sprendimus dar reikia išsiaiškinti.

Joje nebūtini galutiniai maketai ar kiekvieno reikalavimo techninis sprendimas. Aprašyti užduotį dažnai naudingiau nei nurodyti įrankį. „Pardavimų komanda turi gauti užklausą su pasirinkta paslauga“ paaiškina poreikį. „Pridėti įskiepį“ palieka daugumą svarbių klausimų neatsakytus.

Užduotis taip pat suteikia bendrą atskaitos tašką pasiūlymams. Vienas gali apimti tekstų rašymą ir programavimą, kitas — tik dizainą. Kai šios atsakomybės matomos nuo pradžių, skirtumus lengviau aptarti.

Užduotį laikykite pagrindu darbų apimčiai nustatyti. Sutartas pasiūlymas ir projekto planas turėtų patvirtinti rezultatus, neįtrauktus darbus, atsakomybes ir pakeitimų tvarką.

Kaip parašyti svetainės užduotį neturint visų atsakymų

Surinkite tai, kas jau yra: dabartinę svetainę, prekės ženklo medžiagą, klientų klausimus, turimus veiklos duomenis ir preliminarų puslapių sąrašą. Pridėkite patinkančių pavyzdžių su sakiniu, paaiškinančiu, kas kiekviename naudinga.

Tuomet reikalavimus pažymėkite kaip patvirtintus, siūlomus arba atvirus. Prie atvirų punktų įrašykite, kas padės juos išspręsti ir kada reikės sprendimo. Tuščią lauką lengva praleisti; aiškus klausimas gali tapti plano dalimi.

Ypač atidžiai įvertinkite turinį. Pokalbiuose apie projektus dažnai neaišku, kas rašys tekstus, kada jie bus paruošti ir ar esama medžiaga dar tinka. „Viską panaudosime iš naujo“ lieka pradine prielaida, kol kas nors peržiūri tikrus puslapius ir vaizdus.

Galite pradėti trumpais atsakymais. Konkretumas svarbiau už ilgį, ypač įvardijant norimą rezultatą, laukiamus darbus ir dar nepriimtus sprendimus.

Nukopijuokite svetainės projekto užduoties šabloną

Toliau esančias dalis nukopijuokite į darbinį dokumentą. Laužtiniuose skliaustuose esančius tekstus pakeiskite atsakymais. Neatsakytą punktą palikite ir pažymėkite kaip atvirą, užuot spėję. Kai dalis jūsų projektui netinka, rašykite „netaikoma“.

1. Projekto apžvalga

• Įmonė ir dabartinė svetainė: [Pavadinimas, URL ir trumpas veiklos aprašymas.]
• Projekto kontaktas: [Kas koordinuoja užduotį ir atsako į klausimus?]
• Projekto priežastis: [Kas pasikeitė arba kas neveikia?]
• Darbų tipas: [Nauja svetainė, dalinis atnaujinimas ar platesnis perdarymas; patvirtinta ar atvira.]

2. Tikslai ir sėkmės vertinimas

• Pagrindinis rezultatas: [Kas turėtų pagerėti verslui ir lankytojui?]
• Kiti rezultatai: [Antriniai tikslai prioriteto tvarka.]
• Turimi įrodymai: [Klientų atsiliepimai, tyrimai, analitika ar vidiniai pastebėjimai; nurodykite spragas.]
• Kaip vertinsime pažangą: [Kas bus matuojama ar tikrinama, kas tai atliks ir su kokia pradine situacija lygins?]

3. Auditorija ir pagrindinės užduotys

• Pagrindinė auditorija: [Kam svetainė pirmiausia skirta ir kokia situacija čia atveda?]
• Kitos auditorijos: [Kam dar reikia aiškaus kelio svetainėje?]
• Pagrindinės užduotys: [Ką kiekviena auditorija turi rasti, suprasti ar atlikti?]
• Rinkos ir kalbos: [Kas būtina paleidžiant, kas galėtų atsirasti vėliau?]

4. Apimtis ir puslapių struktūra

• Reikalingos paslaugos: [Poreikių išsiaiškinimas, prekės ženklas, UX, vizualinis dizainas, tekstų rašymas, programavimas, perkėlimas, mokymai ar priežiūra.]
• Preliminarus svetainės medis: [Puslapiai ar skyriai, kur įmanoma — sugrupuoti. Pažymėkite neaiškius.]
• Būtina paleidimui: [Kas privalo patekti į pirmąją versiją?]
• Vėlesni arba neįtraukti darbai: [Ko nereikėtų automatiškai laikyti apimties dalimi?]
• Ką išsaugoti: [Aktualus turinys, URL, funkcijos ar failai.]

5. Turinys ir atsakomybės

• Esamas turinys: [Ką galima palikti, atnaujinti, sujungti ar pašalinti? Kas peržiūrės?]
• Nauja medžiaga: [Reikalingi tekstai, vaizdai, projektų aprašymai, vaizdo įrašai, vertimai ar atsisiunčiami failai.]
• Atsakingas už parengimą: [Kas rašo ar pateikia kiekvienos rūšies medžiagą?]
• Tvirtinimas ir laikas: [Kas patvirtina ir kada medžiaga gali būti paruošta?]
• Perkėlimas ir suvedimas: [Kas perkelia, įkelia, suformatuoja ir patikrina turinį?]

6. Funkcionalumas ir techniniai poreikiai

• Reikalingos funkcijos: [Aprašykite naudotojo užduotį, numatomą rezultatą ir svarbias išimtis.]
• Integracijos: [Susijusios sistemos, perduodama informacija ir kontaktas reikalavimams patikslinti.]
• TVS ir redagavimas: [Dabartinė platforma, ką redaktoriai turi keisti ir ar platformos pasirinkimas dar atviras.]
• Kokybės reikalavimai: [Aktualūs įrenginiai, prieinamumo poreikiai, spartos lūkesčiai ir kaip bus sutarta dėl priėmimo.]
• Techninės atsakomybės: [Kas atsakingas už prieglobą, domeną, priežiūrą ir prieigas? Slaptažodžių į užduotį nedėkite.]

7. Prekės ženklas ir dizaino kryptis

• Turima prekės ženklo medžiaga: [Gairės, logotipo failai, tipografika, vaizdai ir jų būsena.]
• Ką išlaikyti ar keisti: [Įtraukite, ar reikalingi prekės ženklo darbai.]
• Pavyzdžiai: [Nuorodos su konkrečiu paaiškinimu, kas kiekviename naudinga.]
• Ko vengti: [Žinomi apribojimai ar auditorijai netinkamos kryptys.]

8. Terminai ir sprendimai

• Siekiamas paleidimas: [Data ar laikotarpis; fiksuotas ar pageidaujamas, kodėl.]
• Priklausomybės: [Turinys, prekės ženklas, vidinės peržiūros, informacija apie integracijas ar kiti darbai.]
• Pastabos ir tvirtinimas: [Kas surenka komentarus ir kas priima galutinį sprendimą?]
• Atviri sprendimai: [Klausimas, atsakingas žmogus ir etapas, iki kurio reikia atsakymo.]

9. Biudžetas ir pasiūlymo lūkesčiai

• Biudžeto būsena: [Patvirtinta suma ar intervalas, viršutinė riba arba aiškus įrašas, kad biudžetą dar reikia nustatyti.]
• Ką jis turi padengti: [Paslaugos ir ar mokesčius, licencijas, prieglobą bei tęstinę priežiūrą reikia išskirti.]
• Lankstumas: [Kas gali keistis, jei norima apimtis netelpa į biudžetą?]
• Prašymas pasiūlymui: [Paprašykite įtrauktų ir neįtrauktų darbų, prielaidų, priklausomybių ir atskirai įvardytų papildomų variantų.]

10. Paleidimas ir tolesnė atsakomybė

• Darbų priėmimas ir leidimas paleisti: [Kas patvirtina darbus ir pagal kokias sutartas patikras?]
• Perdavimas: [Reikalingi mokymai, dokumentacija ir prieigos.]
• Po paleidimo: [Kas atnaujina turinį, prižiūri svetainę ir sprendžia problemas?]
• Peržiūra: [Kas tikrina rezultatus po paleidimo ir sutaria dėl patobulinimų?]

Užpildytas svetainės projekto užduoties pavyzdys

Toliau aprašoma išgalvota B2B konsultacijų įmonė. Tai nėra Flair kliento projektas. Atkreipkite dėmesį: užpildytoje užduotyje vis tiek gali likti atvirų sprendimų — svarbu, kad jie turėtų atsakingą žmogų ir kitą žingsnį.

1. Projekto apžvalga

Įmonė ir svetainė: išgalvota įmonė, konsultuojanti veiklos valdymo komandas. Ji turi įmonės svetainę; dabartinis URL būtų pateiktas pasirinktiems partneriams.

Projekto kontaktas: rinkodaros vadovas.

Priežastis: verslas pertvarkė pasiūlymą į tris paslaugas. Svetainė vis dar pristato ankstesnį pasiūlymą, todėl gavusi užklausas pardavimų komanda nuolat turi aiškinti skirtumus.

Darbų tipas: rinkodaros svetainės perdarymas. Techninio perprogramavimo apimtis lieka atvira iki dabartinio sprendimo peržiūros.

2. Tikslai ir sėkmės vertinimas

Pagrindinis rezultatas: padėti potencialiems klientams pasirinkti aktualią paslaugą ir pateikti pakankamai konteksto naudingam pirmajam pokalbiui.

Antrinis rezultatas: leisti rinkodarai publikuoti projektų aprašymus be programuotojo pagalbos atliekant įprastus pakeitimus.

Turimi įrodymai: pardavimų komandos pastebėjimai ir neaiškių užklausų pavyzdžiai. Patikrintos pradinės konversijos reikšmės dar nėra; prieš galutinai sutariant tikslus rinkodara patikrins esamą matavimą.

Vertinimas: prieš paleidimą auditoriją atitinkančių potencialių klientų bus prašoma rasti tinkamą paslaugą ir paaiškinti pasirinkimą. Po paleidimo pardavimai vertins užklausų aktualumą pagal sutartus kriterijus. Rinkodara taip pat išbandys projekto aprašymo publikavimą. Vertinimo laikotarpį komanda sutars planuodama projektą.

3. Auditorija ir pagrindinės užduotys

Pagrindinė auditorija: veiklos vadovai, lyginantys išorinę pagalbą konkrečiam verslo iššūkiui.

Kita auditorija: pirkimų kolegos, tikrinantys patirtį ir įmonės informaciją.

Užduotys: suprasti paslaugos tinkamumą, peržiūrėti aktualius darbus ir susisiekti. Pirkimų komandai reikia lengvai pasiekiamų įmonės duomenų ir kontaktų.

Rinkos ir kalbos: paleidžiant — anglų kalba. Papildomos kalbos į pirmąją versiją neįtrauktos.

4. Apimtis ir puslapių struktūra

Reikalingos paslaugos: poreikių išsiaiškinimas, informacijos struktūra, UX ir vizualinis dizainas, programavimas, turinio suvedimas ir redaktorių mokymai. Tekstus pateikia rinkodara; partneris dizaino metu turėtų pažymėti spragas.

Preliminarus svetainės medis: pagrindinis puslapis; paslaugų apžvalga su trimis paslaugų puslapiais; projektų sąrašas su pakartotinai naudojamu projekto šablonu; apie įmonę; kontaktai; esami politikų puslapiai.

Būtina paleidimui: aiškus paslaugų palyginimas, projektų publikavimas ir veikiantis užklausos pateikimas kompiuteryje bei telefone.

Neįtraukta: prekės ženklo keitimas, klientų portalas ir papildomos kalbos. CRM integracija — atskiras variantas, ne paleidimo reikalavimas.

Išsaugoti: aktualų projektų turinį ir naudingus esamus URL. Partneris turėtų įvardyti pakeitimus, kuriems reikės perkėlimo plano.

5. Turinys ir atsakomybės

Esama medžiaga: rinkodara peržiūri visus tekstus bei vaizdus ir pažymi, ką palikti, atnaujinti ar pašalinti. Iki peržiūros pakartotinis naudojimas nelaikomas sutartu.

Nauja medžiaga: paslaugų aprašymai, atnaujinta komandos informacija ir projektų tekstai. Esamų nuotraukų tinkamumas bus įvertintas; nauja fotografija būtų atskirai apibrėžti darbai.

Parengimas: rinkodara rašo tekstus ir surenka vaizdus. Paslaugų vadovai pateikia faktinę informaciją.

Tvirtinimas ir laikas: vadovas tvirtina pozicionavimą ir teiginius apie paslaugas. Vienas tipinis paslaugos puslapis bus parengtas prieš tvirtinant jo detalų maketą; likusio turinio datos bus sutartos projekto plane.

Suvedimas ir patikra: partneris įkelia patvirtintą medžiagą; rinkodara prieš paleidimą patikrina tikslumą.

6. Funkcionalumas ir techniniai poreikiai

Funkcijos: lankytojas pasirenka paslaugą, pateikia kontaktus ir aprašo projektą. Sėkmingai pateikus formą rodomas patvirtinimas, o užklausa siunčiama į paskirtą pardavimų pašto dėžutę. Klaidų apdorojimas ir pristatymo patikros įtraukiami į priėmimo kriterijus.

Integracijos: pristatymas el. paštu būtinas. Pardavimai patvirtins, ar būsimai CRM integracijai reikės papildomų laukų; šiems darbams prašoma atskiros kainos.

TVS: dabartinė svetainė naudoja WordPress. Pageidaujama ją išlaikyti, jei peržiūra patvirtins, kad galima naudoti paslaugų ir projektų šablonus. Rinkodara turi galėti keisti tekstus, vaizdus ir projektų aprašymus.

Kokybė: poreikių išsiaiškinimo metu komanda sutars palaikomas aplinkas, spartos patikras ir prieinamumo tikslą. Partneris turi aprašyti įtrauktą peržiūrą ir testavimą, ne vien pažadėti prieinamą svetainę.

Atsakomybė: įmonės IT kontaktas valdo domeno ir prieglobos prieigas. Pasiūlyme tęstinė priežiūra turi būti atskirta nuo projekto įgyvendinimo.

7. Prekės ženklas ir dizaino kryptis

Medžiaga: turimas logotipas, spalvų paletė ir tipografikos gairės. Identiteto keitimo neprašoma.

Kryptis: aiški, pasitikėjimą kelianti ir žmogiška. Pagrindinis pokytis — paslaugų ir patirties paaiškinimas.

Pavyzdžiai: prieš vizualinės krypties paiešką rinkodara pridės pavyzdžius su komentarais: vieną paslaugų palyginimui, kitą projektų pristatymui. Konkrečios svetainės dar nepasirinktos.

Vengti: dekoratyvaus judesio, nukreipiančio dėmesį nuo paslaugų, ir maketų, kuriuose kiekvienam trumpam turinio blokui reikia vaizdo.

8. Terminai ir sprendimai

Paleidimas: pageidaujama prieš kitą planuojamą kampaniją. Kampanijos data dar nepatvirtinta; rinkodara ją patikrins prieš sutariant grafiką.

Priklausomybės: paslaugų tekstai, vadovo tvirtinimas ir techninė WordPress peržiūra.

Pastabos: rinkodara sujungia komentarus. Vadovas galutinai sprendžia dėl apimties ir dizaino.

Atviri sprendimai: partneris vertina TVS poreikių išsiaiškinimo metu; rinkodara planuojant patvirtina turinio datas; pardavimai patvirtina CRM reikalavimus prieš užsakant šiuos papildomus darbus.

9. Biudžetas ir pasiūlymo lūkesčiai

Biudžetas: patvirtinto projekto biudžeto dar nėra. Vadovas nustatys išlaidų ribą po pradinio apimties aptarimo ir prieš leidžiant pradėti įgyvendinimą.

Padengiami darbai: pasiūlyme turi būti prašomos paslaugos, atskirai įvardyti mokesčiai, išorinių paslaugų įmokos ir tęstinė priežiūra. Nauja fotografija ir CRM darbai — atskiri variantai.

Lankstumas: paleisti būtinuosius paslaugų ir užklausos kelius; prireikus atidėti papildomas integracijas.

Pasiūlymas: nurodyti prielaidas, neįtrauktus darbus, turinio priklausomybes ir klausimus poreikių išsiaiškinimui. Jei patikimam įgyvendinimo vertinimui pirmiausia reikia techninės peržiūros, ją išskirti atskirai.

10. Paleidimas ir tolesnė atsakomybė

Tvirtinimas: vadovas leidžia paleisti, kai rinkodara ir partneris atlieka sutartas turinio, pagrindinių kelių, užklausų pristatymo ir perkėlimo patikras.

Perdavimas: rinkodara gauna redaktorių mokymus ir trumpą įprastų atnaujinimų vadovą. IT perduodama aktuali techninė dokumentacija ir prieigos.

Po paleidimo: rinkodara atsakinga už turinį; priežiūros paslaugų teikėjas bus pasirinktas iki paleidimo. Pasiūlyme turi būti paaiškintas pradinis pagalbos laikotarpis, jei toks siūlomas, ir jo apimtis.

Peržiūra: rinkodara ir pardavimai vertina sutartus rezultatus bei tvarko prioritetinį patobulinimų sąrašą.

Prieš išsiunčiant užduotį

Perskaitykite ją kaip žmogus iš šalies. Ar būtų aišku, ką siūlote, kodėl pradedate projektą ir kokių darbų tikitės iš partnerio?

Patikrinkite prieštaravimus. Jei tekstus pateikia rinkodara, nelaikykite jų rašymo savaime įtrauktu į dizaino pasiūlymą. Jei paleidimo data fiksuota, paaiškinkite, kas nuo jos priklauso. Jei integracija pasirenkama, neįtraukite jos į paleidimui būtinus darbus.

Lyginamiems partneriams siųskite tą pačią versiją. Paprašykite įvardyti prielaidas ir trūkstamą informaciją. Pasikeitus apimčiai, atnaujinkite užduotį ir pasidalykite pataisymais, kad visi vertintų tą patį projektą.

Naudinga užduotis nepašalina visų klausimų. Ji padeda kitą pokalbį padaryti produktyvesnį.

Jei ruošiatės svetainės projektui, pasidalykite tuo, ką žinote ir kas dar atvira. Padėsime patikslinti apimtį ir sprendimus, reikalingus judėti pirmyn.

Dažniausi klausimai

Kokio ilgio turi būti svetainės projekto užduotis?

Tokio, kad paaiškintų projektą neužgoždama svarbiausių sprendimų. Trumpi atsakymai tinka. Išsamius sąrašus ar papildomą medžiagą pateikite nuorodomis, užuot viską perkėlę į pagrindinį dokumentą.

Ką daryti, jei nežinome biudžeto?

Tai pasakykite, paaiškinkite prioritetus ir paklauskite, kokios informacijos reikia jam nustatyti. Nuspręskite, kas ir kada jį patvirtins. Kol apimtis ir apribojimai neaiškūs, pirminiai vertinimai priklausys nuo prielaidų.

Ar reikia galutinio svetainės medžio?

Ne. Preliminarus puslapių sąrašas padeda pamatyti tikėtiną apimtį. Pažymėkite neaiškius skyrius ir paaiškinkite auditorijos poreikį, kad struktūrą būtų galima tikslinti poreikių išsiaiškinimo metu.

Ar agentūra gali padėti parengti užduotį?

Taip. Paklauskite, ar siūlomas poreikių išsiaiškinimas arba užduoties rengimas, kas į tai įeina ir ar tai atskiri darbai. Pateikite verslo kontekstą ir paskirkite žmogų, galintį išspręsti vidinius klausimus.