Formuláře pro firmy: Zadání, validace a měření dokončení

01Začněte výsledkem, který má formulář zajistit

Poptávkový formulář není malý dotazník o všech potřebách vaší firmy. Má zákazníkovi umožnit požádat o konkrétní pomoc a vašemu týmu dát podklady pro další krok. U jednoduché konzultace může stačit kontakt a popis problému. Reklamace naopak potřebuje dohledat objednávku. Stejná sada polí pro oba případy obvykle znamená zbytečné otázky na jedné straně a chybějící informace na druhé.

Před návrhem napište jednu větu: po dokončení člověk získá co a pracovník může udělat co. Doplňte odpovědnost, místo přijetí a skutečnou navazující činnost. Potvrzení na obrazovce má jinou roli než založený požadavek v systému nebo odpověď obchodníka. Pokud mezi těmito kroky není jasná návaznost, ani hezčí políčka problém nevyřeší.

Rozlišujte také motivaci návštěvníka. Žádost o ukázku produktu, nezávazný dotaz a závazná objednávka potřebují jiná vysvětlení i kontrolu před odesláním. Do zadání přiložte očekávaný průchod a příklad použitelného výsledku. Obchodník tak posuzuje konkrétní podklady pro odpověď, designér srozumitelnost otázek a vývojář návaznost na systém. Jejich připomínky mají společný základ.

02Každé otázce přidělte účel a okamžik použití

GOV.UK používá question protocol: seznam důvodů, proč se na jednotlivé údaje ptáte a jak je využijete. Pro firmu je to praktický podklad k jednání mezi obchodem, podporou a vývojem. Nezačínejte seznamem polí z konkurenčního webu. Začněte rozhodnutími, která potřebujete po přijetí udělat.

Ke každé otázce doplňte vlastníka, komu se zobrazí odpověď, jak poznáte použitelnou hodnotu a kdy přestává být potřebná. Označení „možná se bude hodit“ je signál k diskusi. Není ale správné bezmyšlenkovitě vymazat všechny kvalifikační otázky. Když stručný údaj ušetří zákazníkovi následné přepisování celého zadání, může být užitečný už na začátku.

Dobrovolné pole musí zůstat skutečně dobrovolné také při odeslání a v navazujícím systému. Ověřte, že chybějící telefon nezpůsobí skryté odmítnutí v CRM. Jinak jste pouze přesunuli požadavek z viditelného formuláře do chyby, které zákazník nerozumí.

03Seřaďte otázky podle úkolu a omezte zbytečné větvení

Začněte tím, co zákazník chápe bez přípravy. Technický parametr nebo přesný rozpočet může být pro první kontakt předčasný. Pokud na odpovědi záleží další průchod, nabídněte srozumitelnou možnost „Ještě nevím“, jestli s ní vaše služba umí pracovat. Vynucený odhad vytváří zdánlivě úplná data, která jsou při přípravě nabídky málo užitečná.

Krátký formulář může zůstat na jedné stránce. Více kroků dává smysl, když odděluje odlišná rozhodnutí nebo umožňuje přeskočit nerelevantní otázky. Počet kroků sám nezaručuje lepší výsledek. Při větvení musí být jasné, proč se nová otázka objevila, a změna předchozí volby nesmí ponechat povinné pole v neviditelné části.

Navrhněte cestu zpět. Uživatel má zkontrolovat odpověď a pokračovat bez opakování práce. Pokud změna typu žádosti zneplatní starší odpovědi, vysvětlete to a rozhodněte, co se odstraní. Ukazatel postupu musí odpovídat skutečnému průchodu; neslibujte poslední krok, po kterém se objeví další povinná stránka. U delšího procesu řekněte předem, zda lze práci přerušit a za jakých podmínek se k ní vrátit.

04Oddělte popisek, nápovědu a příklad

Popisek říká, co zadat. Nápověda vysvětluje neobvyklý požadavek. Příklad ukazuje přijatelný formát. V návrhu mají tyto role zůstat čitelné i po vyplnění. U pole „Číslo objednávky“ lze doplnit, kde ho zákazník najde. Samotný vzor uvnitř prázdného políčka po začátku psaní zmizí a člověk ztratí kontext.

W3C doporučuje propojit popisky s ovládacími prvky. Vizuální blízkost nestačí: čtečka obrazovky musí poznat správný název a kliknutí na popisek má aktivovat příslušný prvek. U skupiny voleb potřebujete společnou otázku i názvy jednotlivých odpovědí.

Označujte povinné a nepovinné položky jednotně a pravidlo stručně vysvětlete. Důležité instrukce nevkládejte jen do bubliny při najetí myší. Použijte běžný jazyk zákazníka místo názvů databázových sloupců. „Popis situace“ může být jasnější než „Specifikace požadavku“, ale rozhodující je, zda lidé poznají očekávanou míru podrobnosti. Pomůže krátký pokyn, co do zprávy zahrnout a které citlivé informace neposílat.

05Usnadněte zadání na telefonu a automatické doplnění

Na mobilu vyzkoušejte formulář se skutečně otevřenou klávesnicí. Aktuální pole, chyba a možnost pokračovat musejí zůstat dosažitelné. Zbytečně úzký prostor pro delší zprávu ztěžuje kontrolu textu. Telefonní číslo potřebuje vhodnou klávesnici, ale také možnost zadat předvolbu. PSČ nebo zákaznický kód není automaticky číslo pro výpočet: může začínat nulou nebo obsahovat písmena.

Atribut autocomplete podle MDN popisuje účel údajů, například jméno, e-mail nebo poštovní směrovací číslo. Vývojář má zvolit odpovídající hodnoty a rozlišit například doručovací a fakturační údaje. Vy ověřte, že doplnění funguje a že člověk smí výsledek opravit.

Nevypínejte vkládání ze schránky jen proto, aby zákazník údaj ručně přepsal. U předvyplněné firmy nebo adresy nabídněte opravu a postup při nedostupném registru. Návrh, který právě dorazil ze serveru, nesmí přepsat novější ruční změnu. Testujte dlouhá jména, diakritiku, mezinárodní čísla i zvětšený text. Širší souvislosti malého displeje vysvětluje průvodce mobile first.

06Ovládání klávesnicí patří do zadání

Formulář musí jít dokončit bez myši. Projděte pole, volby, nahrání souboru, návrat a odeslání klávesnicí. Pořadí má sledovat smysluplnou cestu a aktuální pozice musí být vidět. Pokud rozbalovací nabídka funguje jen kliknutím, není hotová jen proto, že graficky odpovídá návrhu.

Zkoušejte i čtečku obrazovky: jak oznámí povinnost, nápovědu, skupinu odpovědí a chybu. W3C popisuje přístupné připojení instrukcí, například pomocí aria-describedby. V zadání není třeba předepsat každý atribut; je však potřeba požadovat prokazatelné chování s relevantními asistivními technologiemi.

Neschovávejte zásadní informace jen do barvy, ikony nebo krátce zobrazeného oznámení. Stav „odesílá se“ i potvrzení musejí být dostupné také člověku, který změnu nevidí. Po přesunu na další krok veďte pozornost k jeho začátku. Po zavření dialogu ji vraťte na rozumné místo. Praktický test přechodů odhalí víc než samotný seznam atributů ve zdrojovém kódu.

07Načasování validace přizpůsobte skutečné práci

Červená chyba po prvním písmenu e-mailu přichází dřív, než člověk dostal možnost odpověď dokončit. Jako výchozí pracovní variantu kontrolujte údaje při pokusu pokračovat nebo odeslat. Průběžnou zpětnou vazbu přidejte tam, kde pomáhá konkrétnímu úkolu, například při blížícím se limitu délky. Chybu již oznámenou při odeslání můžete po opravě průběžně odstranit.

Vzor GOV.UK doporučuje kontrolu při pokračování či odeslání a výslovně nedoporučuje automatickou validaci při opuštění každého pole. Berte to jako promyšlený výchozí bod, který lze změnit na základě testů s vašimi uživateli. Opuštění pole totiž nemusí znamenat hotovou odpověď.

Při vzdálené kontrole rozlišujte „ověřujeme“, „ověřeno“ a „ověření nyní není dostupné“. Výpadek služby není neplatný údaj. Zelené potvrzení formátu e-mailu neprokazuje existenci schránky ani oprávnění s ní pracovat. Pokud proces potřebuje ověření doručeným kódem nebo odkazem, navrhněte i jeho opoždění, opakované zaslání a opravu adresy. Nespojujte tato odlišná ověření do jediné neurčité fajfky.

08Chybová zpráva má umožnit konkrétní opravu

Předem sepište zprávy pro prázdný údaj, nesprávný formát, překročený limit a konflikt s aktuálním stavem. „Neplatná hodnota“ k opravě nestačí. Pojmenujte údaj stejnými slovy jako v popisku a řekněte, co je potřeba změnit. U modelového limitu přílohy napište třeba „Soubor je větší než 10 MB. Vyberte menší.“ Číslo musí odpovídat skutečnému nastavení.

GOV.UK u chybových zpráv doporučuje zachovat správné i chybné odpovědi. Problémy u polí doplňte přehledem s odkazy, zejména u delšího formuláře. Člověk se tak nemusí posouváním stránky snažit najít jediný červený rámeček. Při opravení jednoho pole se nesmějí ztratit ostatní hodnoty.

Výpadek systému popište samostatně. Zákazník jej neopraví změnou telefonu. Pokud znáte pouze přerušení spojení, netvrďte bez ověření, že nic nebylo přijato. Návrh má obsahovat i cestu pro tuto nejistotu. Chybová hláška není místo pro vtip na účet zákazníka ani technický výpis, který by odhaloval vnitřní údaje aplikace.

09Server rozhoduje o přijetí a bezpečnost má další vrstvy

MDN zdůrazňuje, že kontrolu v prohlížeči lze obejít. Server proto znovu ověřuje povinné údaje, přijatelné hodnoty a pravidla dané operace. Požadujte soulad obou vrstev: formulář nemá nabídnout hodnotu, kterou server bez vysvětlení odmítne.

Validace formátu ale nenahrazuje oprávnění, bezpečné ukládání ani ochranu před zneužitím. Správně zapsané číslo objednávky není důkaz, že člověk smí zobrazit její obsah. Omezení četnosti požadavků, přístup k záznamům a bezpečné zpracování textu patří do samostatné technické kontroly. Nepřenášejte tyto úkoly na zákazníka složitými pravidly pro běžná jména.

S vývojářem domluvte přiměřenou ochranu proti automatizovanému spamu a způsob řešení falešných zásahů. Ověření nesmí běžného člověka poslat do neřešitelné smyčky. Při přidání nové ochrany znovu projděte klávesnici, asistivní technologie a mobilní připojení. Technicky přísnější řešení, které zastaví i relevantní zákazníky, potřebuje opravu stejně jako děravý filtr spamu.

10Přílohy a soukromí řešte před prvním odesláním

Než člověk vybere soubor, ukažte podporované formáty, počet příloh a velikostní limit. Po výběru zobrazte název, stav nahrání a možnost odebrání. Přetažení souboru může být zkratka, musí ale existovat použitelná alternativa. Při chybě jedné přílohy zachovejte zbytek práce a popište, zda se musí soubor vybrat znovu.

OWASP doporučuje více vrstev kontroly nahrávaných souborů. Přípona ani typ poslaný prohlížečem nejsou samy důkazem bezpečného obsahu. Podle použití potřebujete omezení velikosti, kontrolu skutečného typu, bezpečné uložení a řízení přístupu. Přijímané formáty odvoďte od toho, co tým skutečně dokáže zpracovat.

Zákazníkovi stručně vysvětlete, kdo údaje použije a kde najde podrobné informace. Nevyžadujte citlivý dokument jen pro jistotu. Rozpracované údaje neukládejte bez rozmyslu na sdíleném zařízení a určete jejich životnost. Oddělte vyřízení žádosti od případného dalšího marketingu; konkrétní právní režim posuďte podle účelu. Zde jde o návrhový princip minimalizace a srozumitelnosti, nikoli o univerzální právní vzor souhlasu.

11Odeslání musí skončit známým stavem

Tlačítko popište podle následku: „Odeslat poptávku“ sděluje víc než „OK“. Před odesláním umožněte kontrolu údajů tam, kde má chyba významný dopad. Během zpracování ukažte průběh. Zablokování opakovaného kliknutí může pomoci v rozhraní, ale ochranu před duplicitním přijetím musí podle povahy operace řešit i server.

W3C doporučuje oznámit výsledek podání včetně úspěšného dokončení. Potvrzení zobrazte až po odpovídajícím přijetí, ne po samotném kliknutí. Uveďte, co se stane dál, případný identifikátor a způsob kontaktu. Slibovaný termín odpovědi musí být dohoda s provozem, nikoli líbivý text převzatý ze vzoru.

Požadavek může být přijatý, i když se zákazníkovi ztratila odpověď serveru. Navrhněte kontrolu stavu nebo bezpečné opakování stejného podání. Opožděný potvrzovací e-mail je další samostatná situace. Interně sledujte, že se požadavek dostal ke správnému člověku; samotná děkovací stránka nedokládá doručení do schránky ani vyřízení zákazníkovi.

12Měřte dokončení a převezměte formulář podle scénářů

Zapište definice událostí: zobrazení, první skutečná interakce, pokus o odeslání, chyba a potvrzené přijetí. Obnovení děkovací stránky nesmí vytvořit novou poptávku v reportu. Rozlišujte formulář a jeho verzi, zařízení a obecný typ chyby. Do analytiky neposílejte hodnoty polí, obsah zpráv, názvy citlivých příloh ani osobní údaje v URL.

Pro diagnostiku obvykle stačí identifikátor pole a předem definovaný kód problému. Prověřte také automatický sběr a nahrávání relací, které mohou text zachytit mimo zamýšlené události. Ilustrační výpočet: ze 100 měřených zahájení vznikne 60 potvrzených přijetí, tedy 60 %. Bez znalosti omezení měření, kvality požadavků a zdrojů návštěvnosti to není důkaz kvality formuláře ani příslib tržeb.

Nechte úkol dokončit i člověka, který návrh nezná, a pozorujte váhání bez napovídání. Při porovnání verzí sledujte vedle přijetí také použitelnost kontaktů, spam a následné doplňování informací. Náhodně rozdělený experiment pomůže odhadnout dopad změny; prosté porovnání před a po může zkreslit jiná kampaň.

Formulář přidělte konkrétnímu vlastníkovi. Kontrolní sadu opakujte po změně polí, integrace, analytiky i ochrany proti spamu. Provozní kontrolu začleňte do měsíční péče o web. Zjištění převádějte na konkrétní opravy se zpětným ověřením, ne pouze na graf počtu návštěv.

13Časté otázky k návrhu a validaci formulářů