Kde vlastně začíná dobrý návrh?
V předchozích dílech jsme došli k důležitému závěru – neprojektujeme web jen proto, že firma „potřebuje nový web".
Navrhujeme nástroj, který má vyřešit konkrétní problém.
Někdy je problémem slabý prodej. Někdy příliš málo poptávek. Někdy zákazníci nemohou najít informace. Jindy obchodníci každý den odpovídají na stejné otázky, protože web nepředává základní informace. Stává se také, že firma jen vyrostla a dosavadní web už neodpovídá její skutečné velikosti.
Proto prvním krokem by neměl být Photoshop, Figma nebo volba frameworku.
Prvním krokem by měl být rozhovor.
Nejprve poznáme byznys
Dobrý UX designér nemusí být expert ve všech odvětvích, pro která navrhuje. Musí ale dostatečně pochopit klientův byznys, aby věděl, jaké problémy se snaží řešit.
Proto se ptáme na věci, které se na začátku mohou zdát nesouvisející s designem;
- Odkud přicházejí klienti?
- Proč si vyberou právě tuto firmu?
- Proč odcházejí?
- Na co se nejčastěji ptají před nákupem?
- Jak vypadá prodejní proces?
- Kdo odpovídá na dotazy?
- Co se děje s leadem po odeslání formuláře?
- Které produkty jsou nejdůležitější?
- Které služby mají největší potenciál?
- Chce firma zvýšit počet poptávek, hodnotu objednávek, počet zákazníků, nebo především zlepšit svůj image?
Teprve odpovědi na takové otázky umožní určit, co vlastně máme navrhnout.
Discovery – než vznikne první maketa
V digitálních projektech se často používá pojem Discovery.
Je to fáze poznávání problému, uživatelů, byznysových cílů, omezení a technologických možností před zahájením vlastního návrhu a vývoje.
Není to „ztráta času před zahájením práce“. V dobře vedeném projektu má Discovery omezit riziko vytvoření něčeho, co bude vypadat dobře, ale nevyřeší skutečný problém.
Můžeme objevit například, že klient vlastně nový web nepotřebuje.
Může potřebovat lepší informační architekturu.
Nebo zjednodušení nákupního procesu.
Nebo integraci webu s CRM.
Nebo automatizaci zpracování dotazů.
Nebo úplně jiný způsob prezentace nabídky.
A právě proto se někdy vyplatí zastavit se před zahájením produkce.
UX nezačíná vzhledem
UX, tedy User Experience, znamená zkušenost uživatele při používání produktu nebo služby.
U webu zahrnuje mnohem víc než pouhý vzhled rozhraní.
Je to také:
- způsob pohybu po stránce,
- snadnost nalezení informací,
- srozumitelnost sdělení,
- nákupní proces,
- formuláře,
- hierarchie obsahu,
- rychlost plnění úkolů,
- reakce systému na akce uživatele,
- přístupnost,
- pocit bezpečí a důvěry.
Proto UX začíná ještě dřív, než někdo nakreslí první obrazovku.
Nejdřív je třeba pochopit, co se uživatel snaží dosáhnout.
User Flow – kudy má uživatel dojít k cíli?
Jedním ze základních nástrojů UX je User Flow. Je to popis cesty, kterou uživatel projde, aby provedl konkrétní úkol.
Například v e‑shopu může vypadat takto: reklama → stránka produktu → výběr varianty → košík → doprava → platba → potvrzení objednávky.
Ve službách: Google → stránka služby → reference → kontaktní formulář → kontakt s obchodníkem.
U výrobce: vyhledávání → produkt → technické parametry → dokumentace → poptávka.
Každá z těchto cest vyžaduje jiná projektová rozhodnutí.
Pokud je hlavním cílem uživatele nákup, nesmíme ho nutit číst desítky obrazovek textu. Pokud je produkt drahý, složitý a vyžaduje konzultaci, příliš rychlé směřování k formuláři může být také špatné řešení.
UX je mimo jiné o nalezení správné úrovně vedení uživatele.
Wireframe – než začneme „krášlit"
Dalším krokem může být wireframe, tedy zjednodušené schéma obrazovky ukazující rozložení obsahu a funkcí.
Wireframe nemusí být hezký. A to je dobře. V této fázi nejde o to, zda bude barva tlačítka správná.
Jde o odpovědi na otázky:
- Co uživatel uvidí jako první?
- Co bude nejdůležitější?
- Co by mělo být výše?
- Kde umístíme doplňující informace?
- Jak uživatel přejde do dalšího kroku?
- Co se stane po kliknutí?
Je to trochu jako navrhování bytu.
Nejdřív určíte, kde budou stěny, dveře a místnosti. A až později přemýšlíte o barvách stěn.
Design system – aby projekt nebyl slepenec náhodných prvků
U větších projektů se objevuje další důležitý prvek – Design System.
Je to uspořádaná sada pravidel, komponent a vzorů, které definují způsob budování rozhraní.
Může zahrnovat mimo jiné:
- barvy,
- typografii,
- tlačítka,
- formuláře,
- karty,
- tabulky,
- oznámení,
- ikony,
- mezery,
- zásady responzivity,
- chování komponent.
Proč? – Aby bylo rozhraní konzistentní.
Pokud na jedné podstránce tlačítko funguje jedním způsobem a na jiné úplně jinak, uživatel se musí pokaždé učit rozhraní znova.
Design System také pomáhá vývojovému týmu. Místo aby komponentu stavěl pokaždé od nuly, může využít předem definované prvky.
To vede k větší konzistenci, snadnějšímu vývoji a často i nižším nákladům na údržbu projektu.
A kde v tom všem je technologie?
Technologie by měla přijít včas, ale neměla by diktovat celý projekt. To je důležité rozlišení.
Designér může vymyslet skvělou funkci, která z byznysového hlediska dává smysl. Vývojář ale může upozornit, že její implementace bude velmi nákladná nebo způsobí problémy s výkonem.
Na druhou stranu může vývojář navrhnout technologické řešení, které se snadno zavádí, ale z pohledu uživatele problém dostatečně neřeší.
Proto vznikají nejlepší projekty tam, kde UX, design, vývoj a byznys spolu od začátku komunikují.
Ne podle principu: „Nejprve designéři, potom programátoři.“
Ale: „Společně přemýšlíme, jak nejlépe vyřešit problém“.
Technologii by neměla určovat móda
React, Vue, Next.js, Laravel, Symfony, .NET, WordPress, headless CMS, nativní aplikace, PWA... lze dlouho vyjmenovávat technologie.
Klient ale nekupuje technologii. Kupuje řešení.
Proto otázka: „Který framework použijeme?“
často bývá méně podstatná než: „Jaké problémy má systém řešit?“ A teprve potom lze zvolit vhodnou architekturu.
Jinou technologii potřebuje jednoduchý firemní web, jinou obchod zvládající tisíce objednávek a zase jinou B2B platforma s rozsáhlými integracemi a individuálními oprávněními uživatelů.
Technologie by měla vycházet z požadavků, ne požadavky z technologie.
Backend, frontend a místo, které uživatel nevidí
Je také dobré pamatovat, že web není jen to, co vidíme v prohlížeči.
Frontend zajišťuje část aplikace, se kterou uživatel přímo interaguje.
Backend zodpovídá za logiku na straně serveru – zpracování dat, komunikaci s databází, procesy a integrace.
A mezi nimi často stojí celá řada dalších prvků;
- CRM.
- ERP.
- Platební systém.
- Mailingová platforma.
- Skladový systém.
- API.
- Analytika.
- Automatizace.
- Systém zákaznické podpory.
Pokud navrhneme nový web bez zohlednění tohoto ekosystému, můžeme vytvořit krásný frontend, který bude fungovat jako osamělý ostrov.
A cílem by mělo být něco úplně jiného.
Dobrý web může dělat mnohem víc než „sbírat formuláře"
Moderní web může být součástí širšího byznysového procesu;
- Uživatel pošle poptávku.
- Systém rozpozná její téma.
- Lead putuje do CRM.
- Obchodník dostane notifikaci.
- Klient obdrží automatické potvrzení.
- Data jsou přiřazena do příslušné kategorie.
- Systém může zkontrolovat dostupnost produktu.
- Může připravit informace pro obchodníka.
- Může spustit konkrétní workflow.
V e‑shopu může objednávka automaticky projít dalšími kroky realizace. V B2B může mít klient přístup k individuálním cenám, dokumentům a historii objednávek.
Pak web přestane být jen „vizitkou“. Stane se součástí byznysové infrastruktury.
Co s AI?
AI také může být součástí takového systému. Ale opět – neměla by být přidána jen proto, že „teď všichni mají AI".
Pokud chatbot neřeší žádný reálný problém, bude jen dalším okénkem na stránce.
Pokud ale uživatel díky AI rychleji najde správný produkt, nakonfiguruje službu, dostane odpověď na dotaz nebo projde procesem volby, technologie dává smysl.
Totéž platí pro personalizaci.
Můžeme uživateli zobrazovat jiný obsah podle jeho chování, zdroje příchozí návštěvy nebo fáze nákupního procesu. Můžeme analyzovat data a lépe předvídat potřeby zákazníků.
Ale vždy bychom měli začít otázkou: „Jaký problém řešíme?“
A teprve pak: „Je AI nejlepším způsobem, jak ho vyřešit?“
Testujeme nejen to, zda funguje
Jednou z nejčastějších chyb je testovat web až na konci. Pak zjistíme, že formulář je příliš dlouhý, nákupní proces neintuitivní a uživatel nenašel klíčovou informaci.
Čím později takový problém objevíme, tím dražší bude jeho oprava.
Proto je dobré testovat fázi po fázi. Můžeme ověřovat prototyp. Můžeme pozorovat chování uživatelů. Provádět testy použitelnosti. Analýzy z Google Analytics nebo jiných analytických nástrojů. Můžeme využívat nahrávky sezení nebo heatmapy, pokud jsou nasazeny v souladu s pravidly ochrany soukromí. Můžeme se také prostě zeptat obchodníků.
To poslední je často podceňované.
Obchodník denně slyší dotazy zákazníků; ví, čemu nerozumějí, čeho se obávají a jaké informace musí být před nákupem předány.
To je obrovské projektové know‑how.
MVP neznamená ledajaký produkt
V digitálních projektech se často mluví o MVP – Minimum Viable Product.
Jde o první verzi produktu s minimálním souborem funkcí potřebných k ověření předpokladů a doručení hodnoty uživatelům.
MVP by nemělo znamenat: „Uděláme něco ledabyle a uvidíme později".
Dobré MVP by mělo odpovědět na otázku: „Jaká je nejmenší verze řešení, která nám umožní ověřit, že míříme správným směrem?“
To je důležité i u webů a aplikací.
Místo budování hned třiceti funkcí je někdy lepší spustit pět nejdůležitějších a zjistit, jak je uživatelé používají. Potom systém rozvíjíme na základě reálných dat, ne jen předpokladů z prvního setkání.
Web nekončí publikací
To je další věc, na kterou se často zapomíná.
Den publikace je vlastně začátkem jeho skutečného života. Teprve tehdy přicházejí reální uživatelé. Teprve tehdy vidíme, které obsahy fungují. Teprve tehdy zjistíme, které prvky jsou ignorovány. Teprve tehdy můžeme ověřit, zda se zvýšil počet poptávek, prodeje, doba strávená na webu nebo jiné metriky, které jsme si dříve stanovili.
Proto by se projekt měl dále rozvíjet;
- Analýza.
- Závěry.
- Změna.
- Test.
- Nová analýza.
To je spíše cyklus než jednorázová událost.
Co vlastně měřit?
To závisí na cíli projektu.
Pro e‑shop to mohou být:
- konverzní poměr,
- průměrná hodnota objednávky,
- opouštění košíku,
- tržby,
- hodnota zákazníka v čase.
Pro firmu poskytující služby:
- počet kvalitních leadů,
- konverzní poměr formuláře,
- počet domluvených konzultací,
- náklad na získání leadu,
- kvalita dotazů.
Pro informační server:
- nalezení konkrétních informací,
- zapojení uživatelů,
- počet návratů,
- stažení materiálů.
Není nutné měřit všechno. Je ale nutné vědět, co je důležité.
Protože pokud firma chce zvýšit počet hodnotných poptávek, samotné zvýšení návštěvnosti nemusí znamenat úspěch. Můžeme mít desetkrát více zobrazení a žádného nového zákazníka.
Největší chyba? Navrhovat bez odpovědi na otázku „proč?"
Lze vytvořit vizuálně skvělý web.
Lze použít moderní technologický stack.
Lze připravit dokonalé animace.
Lze pečovat o každý pixel.
A přesto projekt nemusí přinést očekávané byznysové výsledky. Proč?
Protože chyběla odpověď na nejdůležitější otázku: Proč to děláme?
Pokud odpověď zní: „Protože starý web je ošklivý",
to je trochu málo.
Pokud ale zní: „Chceme zvýšit počet poptávek od B2B klientů, zkrátit proces nalezení správné služby a odlehčit obchodnímu oddělení od odpovídání na opakované dotazy",
najednou máme konkrétní problém k vyřešení.
A můžeme navrhnout řešení.
Ve Web24 nechceme jen předávat web
Je rozdíl mezi splněním zakázky a technologickou spoluprací.
Když klient přijde s konkrétním nápadem, neznamená to, že máme bezmyšlenkovitě realizovat vše, co navrhne.
Naším úkolem je také říct: „To dává smysl“.
Nebo: „Dá se to udělat lépe“.
Nebo: „Technicky to můžeme postavit, ale nevidíme byznysové odůvodnění“.
Nebo: „Než to uděláme, ověříme, zda to uživatelé skutečně potřebují“.
Někdy je nejlepší rozhodnutí přidat funkci. Někdy ji odstranit. Někdy změnit celé předpoklady.
A právě v tom spočívá zkušenost týmu – ne v tom, že umíme postavit všechno, ale v tom, že umíme rozpoznat, co skutečně má smysl postavit.
Neexistují dva stejné projekty
Vracíme se k východiskovému bodu.
Můžeme mít dva klienty ze stejného odvětví. Dva výrobce. Dva e‑shopy. Dva právnické firmy. Dva softwarové domy.
Jejich weby mohou vypadat podobně. Neměly by ale být stejné jen proto, že působí ve stejné kategorii.
Protože liší je lidé. Strategie. Prodejní proces. Nabídka. Rozpočet. Technologie. Zákazníci. Cíle.
A právě proto každý projekt vyžaduje vlastní rozhodnutí.
Ne vždy velkolepá. Ne vždy průlomová. Ale vědomá.
Web jako nástroj, ne dekorace
Dobře navržený web by měl být pro firmu něčím víc než digitální vizitkou.
Měl by pomáhat uživateli rozhodnout se. Měl by usnadňovat prodej. Měl by odpovídat na otázky. Budovat důvěru. Podporovat zaměstnance. Integrovat se s ostatními systémy tam, kde to dává smysl.
A především by měl naplňovat konkrétní byznysový cíl.
Proto neexistuje jedna odpověď na otázku: „Jak by měl vypadat dobrý web?“
Lepší otázka zní: „Jak by měl fungovat web této konkrétní firmy, aby jí pomáhal dosahovat cílů?“
A právě od této otázky by měl začínat každý dobrý projekt.
Na závěr – nejdůležitější pravidlo
Nenavrhovat web proto, aby klient mohl říct: „Ale hezké".
Navrhovat ho proto, aby po několika měsících klient mohl říct: „To nám opravdu pomáhá dělat byznys".
Protože rozdíl mezi hezkým webem a dobrým digitálním produktem často není vidět na první obrazovce.
Uvidíte ho až ve výsledcích.
Shrnutí celé série
V této sérii jsme se zabývali tím, proč nevyvíjíme dva stejné weby.
Začali jsme jednoduchým předpokladem: stejné odvětví neznamená stejný byznys.
Dále jsme ukázali, jak firemní strategie, prodejní proces, cílová skupina a potřeby uživatelů ovlivňují UX, informační architekturu a funkce.
V posledním díle jsme prošli návrhový proces – od Discovery a poznání byznysu, přes User Flow, wireframy a Design System, až po technologii, integrace, testování, analytiku a další rozvoj.
Proto individuální návrh neznamená jen „jiný vzhled".
Znamená jiná rozhodnutí vyplývající z jiného problému.
A právě proto by každá firma měla dostat řešení navržené pro ni, ne pro „průměrnou firmu z odvětví".
