Přestal jsem klientům dělat ‚návrh v grafice ke schválení‘. Prototypuju rovnou v prohlížeči a tady je proč
Statické náhledy vedou ke schvalování barviček místo obsahu. Proč místo grafického návrhu stavím prototyp přímo v prohlížeči a co to změnilo.
Poslední statické PDF s náhledem webu jsem klientovi poslal někdy před dvěma lety. Vrátilo se mi s poznámkou: „Ta modrá je moc studená a logo bych dal větší.“ Web měl řešit, proč lidi ze stránky odcházejí, aniž by vyplnili poptávku. Místo toho jsme půl hodiny na callu řešili odstín modré.
Nebyla to chyba klienta. Byla to chyba formátu, který jsem mu dal do ruky.
Statický náhled vás nutí hodnotit to jediné, co je na něm vidět
Když někomu ukážete obrázek, bude hodnotit obrázek. Barvy, fonty, velikost loga, obrázek v hlavičce. To jsou jediné vlastnosti, které statický náhled vůbec má.
Co na něm vidět není:
- jak dlouho trvá, než se stránka načte
- co se stane, když je nadpis místo tří slov o dvanácti
- jestli se to na mobilu dá vůbec přečíst bez zoomování
- kde přesně končí první obrazovka na iPhonu SE a kde na 27″ monitoru
- jak se chová menu při scrollování
- jestli formulář dává smysl, když do něj člověk začne psát
To všechno jsou věci, které rozhodují o tom, jestli web funguje. A žádnou z nich v Figmě neschválíte.
Web se posuzuje v pohybu, ne na obrázku
Statický náhled je fotka. Web je video. Nebo přesněji: web je věc, se kterou někdo něco dělá – scrolluje, klepe, čeká, píše, otáčí telefon.
Mám případ z e-shopu s doplňky pro kavárny. V grafice vypadala produktová karta skvěle – velká fotka, cena, tlačítko. V prohlížeči se ukázalo, že na mobilu je tlačítko „Do košíku“ pod ohybem a mezi ním a fotkou je 400 pixelů popisu, který nikdo nečte. To v PDF nevidíte. To zjistíte, až vezmete do ruky telefon a zkusíte si něco koupit.
A ještě jedna věc: 70–80 % návštěv u většiny mých klientů přichází z mobilu. Náhled ale schvalujeme na notebooku, v prezentaci, zvětšený na celou obrazovku. Schvalujeme situaci, která u čtyř lidí z pěti nikdy nenastane.
Co dělám místo toho
Struktura první, na papíře nebo v textovém dokumentu. Co má stránka udělat, komu to má říct, v jakém pořadí. Tuhle fázi klientovi neukazuju jako design – ukazuju ji jako osnovu. Tam se bavíme o obsahu, protože jiná možnost není.
Potom stavím prototyp přímo v kódu, s reálnými texty a reálnými obrázky. Klient dostane odkaz. Otevře si ho na svém telefonu, ve svém prohlížeči, ve vlaku. A připomínky, které přijdou, znějí úplně jinak: „Nedošlo mi, že tohle je odkaz.“ „Chybí mi tady, kolik to stojí.“ „Na tomhle místě bych už chtěl formulář.“
To jsou připomínky, ze kterých se dá stavět.
Námitky, které slyším
„Není to dražší?“ Naopak. Grafický návrh je práce navíc, kterou pak stejně musíte přeložit do kódu – a při překladu vzniká další kolo připomínek. Prototyp v prohlížeči je zároveň základ finálního webu.
„Klient si to neumí představit bez pěkného obrázku.“ Klient si to neumí představit ani s ním. Proto pak přijdou překvapení po spuštění. Funkční prototyp je konkrétnější než jakákoli vizualizace.
„A co když má klient přísný brand manuál?“ Tím lépe. Barvy, typografie a logo jsou dané, není o čem diskutovat. Zbývá čas na to, co skutečně rozhoduje.
K čemu to vede
Schvalovací kola se zkrátila. Místo tří kol nad grafikou a dvou nad hotovým webem máme obvykle dvě kola nad živým prototypem. Debata se přesunula od „ta modrá je studená“ k „tenhle argument bych dal výš“.
A hlavně: klient v momentě schválení ví, co dostane. Protože už se toho dotkl.