Jak zadat nový web, aby dodavatel nemusel hádat

Nezačínejte počtem stránek ani seznamem funkcí

Když se firma rozhodne pro nový web, snadno začne řešit věci, které jsou vidět: barvy, animace, menu, kontaktní formulář nebo redakční systém. To všechno přijde na řadu. Samo o sobě to ale nevysvětluje, jaký problém má nový web vyřešit.

Dodavatel potřebuje nejdřív pochopit souvislosti. Proč současný web nestačí? Co dnes návštěvníci obtížně hledají? Které dotazy zbytečně končí na telefonu? Změnila se firma, nabídka nebo způsob prodeje? A je opravdu potřeba nový web, nebo by největší problém vyřešily lepší texty a úprava několika cest?

GOV.UK Service Manual doporučuje začít poznáváním lidí, kteří budou službu používat, jejich cílů, současného chování a překážek. Pro firemní web to platí stejně. Návštěvník obvykle nepřichází obdivovat strukturu webu. Chce porovnat nabídku, ověřit důvěryhodnost, najít technický údaj, objednat službu nebo zjistit, zda mu vůbec dokážete pomoci.

Brief není technická specifikace hotového řešení. Je to společný výchozí bod pro rozhovor. Dodavatel by po jeho přečtení měl vědět, na co se doptat a která rozhodnutí je potřeba udělat společně.

Popište změnu, kterou má web přinést

Věta „cílem je nový web“ pouze opakuje název projektu. Užitečnější je popsat, co má být po spuštění snazší pro návštěvníka a co se má zlepšit uvnitř firmy. Vyberte jeden hlavní cíl a několik vedlejších. Když je všechno stejně důležité, při rozhodování o obsahu a rozpočtu nepomůže nic.

Úspěch nemusí znamenat velké finanční číslo. Pokud dnes nemáte analytiku nebo přesnou výchozí hodnotu, nevymýšlejte ji. Zapište, co lze měřit od spuštění, a první období použijte jako základ pro další porovnávání. GOV.UK u informačních webů doporučuje nespoléhat jen na návštěvnost, ale sledovat, zda lidé zvládnou svůj úkol. Vedle analytiky proto dává smysl několik krátkých uživatelských testů, zpětná vazba z obchodu nebo evidence častých dotazů.

• Hlavní úkoly lze na mobilu dokončit bez zbytečného hledání a chyb.
• U poptávky poznáte, ze které služby a stránky přišla, pokud je to přiměřené a v souladu s ochranou soukromí.
• Firma sleduje kvalitu poptávek, nejen jejich počet.
• Je určeno, kdo a kdy výsledky vyhodnotí. Termín zvolte podle návštěvnosti a délky rozhodovacího procesu.

Do briefu přidejte také věci, které nejsou cílem. Například že první etapa nebude obsahovat zákaznický portál, vícejazyčnost ani napojení na sklad. Taková hranice chrání rozpočet a zároveň dodavateli umožní připravit řešení tak, aby pozdější rozšíření zbytečně neblokovalo.

Mluvte o konkrétních lidech a situacích

Široké označení „naší cílovou skupinou jsou malé a střední firmy“ pro návrh webu nestačí. Jednatel, nákupčí a technik mohou zastupovat stejnou firmu, ale každý hledá něco jiného a rozhoduje se jinak. Popište proto několik skutečných situací, ne katalog obecných person.

1. 01

   Kdo přichází

   Jakou roli člověk má, co už o vás ví a z jakého zařízení nebo prostředí web pravděpodobně používá?

2. 02

   Co potřebuje udělat

   Chce rychle ověřit vhodnost služby, porovnat varianty, stáhnout dokument, najít kontakt nebo dokončit objednávku?

3. 03

   Co mu dnes překáží

   Nerozumí terminologii, nezná potřebné parametry, nenajde cenu, bojí se závazku nebo web špatně ovládá na telefonu?

4. 04

   Co má následovat

   Jak pozná, že úkol dokončil, a co se stane po odeslání formuláře, rezervaci nebo stažení podkladů?

Podklady už často ve firmě existují: dotazy z e-mailů, poznámky obchodníků, hledané výrazy na současném webu, reklamace nebo hovory zákaznické podpory. Oddělte ale pozorování od domněnek. Věta „lidé chtějí chatbota“ může být jen nápad z porady. Věta „zákazníci se opakovaně ptají, kdy bude objednávka připravena“ popisuje ověřený problém, pro který může existovat více řešení.

Vymezte rozsah podle obsahu a cest, ne jen počtem URL

Seznam plánovaných stránek je užitečný, ale dodavatel z něj nepozná jejich náročnost. Jednoduchý kontakt, filtrování stovek produktů a kalkulátor jsou tři různé úkoly, i kdyby každý zabíral jedinou URL. U každé důležité části napište, komu slouží, jaký obsah zobrazí, odkud se data vezmou a co na ní lze udělat.

Nemusíte předem navrhnout celé menu. Připravte raději seznam současného a plánovaného obsahu a tři až pět situací, které musí návštěvník zvládnout. Nový zákazník například vybírá službu a posílá poptávku. Stávající zákazník hledá dokumentaci. Uchazeč si prohlíží volná místa a odpovídá. Dodavatel pak může navrhnout strukturu podle těchto potřeb a ověřit ji, místo aby pouze překreslil dnešní web.

• Sepište typy obsahu: služby, reference, články, lidé, pobočky, dokumenty nebo produkty.
• Uveďte přibližné množství a výjimky: jedna služba může mít tabulku, jiná konfigurátor.
• Označte, co je nutné pro první spuštění, co může počkat a co je mimo projekt.
• Popište role v administraci: kdo smí publikovat, schvalovat, mazat a spravovat uživatele.
• U starého webu rozhodněte, které adresy se zachovají, přesměrují nebo ukončí.

Pokud poptáváte cenu od více dodavatelů, dejte všem stejný základ a dovolte jim pojmenovat předpoklady. Dvě cenově velmi rozdílné nabídky mohou zahrnovat úplně jiný rozsah textů, výzkumu, migrace, testování a podpory. Porovnávejte, co je skutečně součástí práce, ne pouze poslední řádek rozpočtu.

Určete, kdo dodá obsah a kdo jej dokáže schválit

Věta „texty a fotografie dodá klient“ bývá začátkem velkého zdržení. Obsah není výplň hotového designu. Ovlivňuje strukturu, rozsah komponent, přístupnost i termín. Už v briefu napište, co existuje, co lze převzít a co je potřeba vytvořit znovu.

Jmenujte jednoho člověka, který připomínky sesbírá, vyřeší rozpory a předá dodavateli jedno stanovisko. Odborná nebo smluvní rozhodnutí mohou mít jiné vlastníky, dodavatel ale musí vědět, kdo má v daném tématu poslední slovo. Jinak se projekt snadno změní v hlasování o osobním vkusu místo práce pro návštěvníka.

Součástí zadání má být i migrace. Automatické překopírování všeho starého přenese i neaktuální texty, rozbité dokumenty a nejasnou strukturu. U každé skupiny obsahu rozhodněte: zachovat, přepracovat, sloučit, archivovat nebo odstranit. Podrobný pracovní postup najdete v navazujícím průvodci přípravou obsahu a podkladů. Pro odstraněné stránky se připraví odpovídající přesměrování, pokud existuje smysluplná náhrada.

Technické požadavky popište věcně a bez módních zkratek

Nemusíte vybírat programovací jazyk ani redakční systém, pokud k tomu nemáte provozní důvod. Popište omezení, návaznosti a očekávaný provoz. Dodavatel má vysvětlit, jak navržená technologie těmto potřebám odpovídá, jak se aktualizuje a kdo ji po spuštění dokáže spravovat.

Integrace a data

CRM, sklad, rezervace, platební brána, newsletter, mapy nebo externí katalog. Uveďte vlastníka systému, dostupnou dokumentaci a prostředí pro testování.

Soukromí a bezpečnost

Jaké osobní údaje web přijímá, proč jsou potřeba, komu se posílají a jak dlouho se uchovávají. Citlivá data neposílejte zbytečně běžným e-mailem.

Přístupnost

Požadovaná úroveň, způsob průběžného ověřování a odpovědnost za přístupnost komponent i budoucího obsahu.

Výkon a zařízení

Důležité typy stránek, zařízení a podmínky použití. „Rychlý web“ převeďte na způsob měření a reálné testovací scénáře.

Analytika

Jaké události potřebujete znát, kdo data vyhodnocuje a jak se řeší souhlas. Nenasazujte měření jen proto, že bylo na starém webu.

Provoz

Hosting, domény, certifikáty, zálohy, monitoring, aktualizace, reakční doby a postup při výpadku nebo bezpečnostním problému.

Přístupnost se týká návrhu, textu, kódu, videa, dokumentů i redakční práce. W3C proto doporučuje určit cíle, odpovědnosti, rozpočet, kontrolní milníky a způsob průběžného sledování. Jedna věta „web bude přístupný podle WCAG“ bez testování a odpovědnosti je příliš neurčitá.

Dohodněte průběh, rozhodování a převzetí dřív, než začne práce na webu

Termín „web musí být hotový do veletrhu“ je důležitý, ale bez včasných podkladů a rozhodování ho samotný dodavatel neudrží. Popište pevné datum, důvod termínu, dostupnost lidí na vaší straně a mezníky, ve kterých budete schvalovat směr. Nechte si také říct, co se stane, když se zpozdí podklady nebo přibude nový požadavek.

1. 01

   Společné ujasnění zadání

   Tým ověří cíle, uživatele, obsah, technická rizika a skutečný rozsah. Výstupem může být zpřesněné zadání a plán první etapy.

2. 02

   Návrh a průběžné ověřování

   Nečekejte na jeden velký návrh celého webu. Procházejte důležité cesty, reálný obsah a funkční prototypy v dohodnutých okamžicích.

3. 03

   Vývoj, obsah a testování

   Obsah se připravuje současně s webem. Kontroluje se funkčnost, přístupnost, různá zařízení, integrace, výkon a chování při chybě.

4. 04

   Spuštění a stabilizace

   Předem existuje kontrolní seznam, záloha a postup návratu. Po spuštění se sledují chyby, formuláře, měření, indexace a reálné používání.

Přejímací kritéria pište tak, aby šla ověřit. „Web bude intuitivní“ je přání. Ověřitelné je například to, že návštěvník odešle formulář i pouze pomocí klávesnice, po chybě neztratí vyplněná data a dostane jasné potvrzení. Dalším kritériem může být, že oprávněný redaktor zvládne publikovat článek podle předaného návodu.

• Je jasné, kdo vlastní doménu, hostingové a analytické účty, zdrojové kódy, designové podklady a licence.
• Máte vlastní správcovské přístupy a seznam použitých služeb včetně pravidelných nákladů.
• Je dohodnuto, kdo zajišťuje zálohy, jak se obnova ověřuje a kdo ji při problému provede.
• Je dohodnutá záruční podpora, následná údržba a způsob zadávání další práce.
• Licenční a smluvní podmínky zkontroloval člověk, který za ně ve vaší organizaci odpovídá.

Brief smlouvu nenahrazuje. Cena, licence, odpovědnosti, nakládání s daty, způsob kontroly a převzetí i ukončení spolupráce patří do odpovídajících smluvních dokumentů. Zadání však pomůže odhalit tato témata včas, kdy se o nich dá jednat bez tlaku před spuštěním.

Osnova, kterou můžete rovnou vyplnit

Na první rozhovor většinou stačí dvě až čtyři poctivě vyplněné strany a přílohy. Pokud něco nevíte, označte to jako otázku k ověření. Dodavatel pak může do nabídky zahrnout i práci, která k odpovědi povede.

1. O firmě a projektu
   Co děláme, proč projekt vzniká a co dnes nefunguje.

2. Cíl a úspěch
   Hlavní změna pro návštěvníka a pro firmu.
   Jak výsledek po spuštění ověříme.

3. Lidé a jejich hlavní úkoly
   Kdo web používá, v jaké situaci, co potřebuje dokončit
   a co mu dnes překáží.

4. Rozsah první etapy
   Typy obsahu, hlavní cesty a funkce.
   Co je nutné, co může počkat a co do projektu nepatří.

5. Obsah a podklady
   Co existuje, co vznikne nově, kdo to dodá a schválí.
   Rozsah migrace, fotografie, překlady a oprávnění k použití.

6. Technologie a provoz
   Integrace, data, přístupnost, analytika, hosting,
   bezpečnost, zálohy, aktualizace a podpora.

7. Spolupráce
   Kontaktní a rozhodující lidé, dostupnost, termín,
   rozpočet nebo jeho rozmezí a způsob schvalování změn.

8. Předání a přijetí
   Ověřitelná kritéria, účty, licence, zdrojové podklady,
   dokumentace, školení a podpora po spuštění.

9. Přílohy a otevřené otázky
   Data ze současného webu, inventura obsahu, ukázky,
   omezení a věci, které se musí teprve zjistit.

Rozpočet není nutné předstírat jako přesné číslo. Rozmezí nebo pevný strop ale dodavateli pomůže navrhnout přiměřenou první etapu. Stejně otevřeně popište termín. Pokud jsou cena, rozsah a datum všechny pevné, musí být jasné, podle čeho se bude rozhodovat při nečekané komplikaci.

Hotový brief dejte přečíst člověku, který projekt nezná. Pokud po přečtení dokáže vlastními slovy vysvětlit, pro koho web vzniká, co má zlepšit, co se dodává a kdo rozhoduje, splnil svůj účel. Podrobnosti se budou dál měnit, ale tým bude mít společný směr.