jan korbel

Weby už se u nás dělají nějaký ten rok a ačkoli všichni vědí, že „content is the king,” jsme stále mile překvapení, když narazíme na stránku, kde si úsilí autora(-ů) textů všimneme s tím, že někdo odvedl dobrou práci.

Texty — microcopy, mikro-texty chcete-li — jsou ve web aplikacích asi ještě důležitější než u webů. Náš uživatel často začíná v „prázdné aplikaci”, protože většinu obsahu musí sám vytvořit. Chceme ho provést řadou kroků, ve kterých mu vysvětlíme nejdříve základy fungování naší aplikace a postupně z něj vychováme profíka, který s pomocí naší aplikace válí, a proto ji miluje.

Společné body s copywritingem

Pro psaní mikro-textů si můžeme vypůjčit pár východisek z „normálního” copywritingu.

• Mluvte jazykem čtenáře
• Udržte si vlastní styl
• Pište tak, abyste si chtěli výsledek sami přečíst
• Vynechte zbytečná slova

Web aplikace ale vytváří zvláštní prostředí, které před nás staví jiné výzvy.

Specifika mikro-textů ve web aplikacích

Předně je tu ještě větší tlak na stručnost. Tam, kde můžeme v prezentaci nebo článku vysvětlovat něco odstavcem textu, musíme v aplikaci vystačit s pár slovy. Jednak proto, že jsme omezeni uživatelským rozhraním, které není nafukovací, ale také proto, že potřebujeme uživatele rychle zaujmout, nebo ho rychle provést nějakým úskalím, aby se dostal ke svému cíli.

Pokud se nám nedaří něco stručně vysvětlit, může to být dobrý ukazatel toho, že máme problém se samotným návrhem dané části aplikace.

Potíž je také v tom, vědět, kdy vůbec něco psát, nebo kdy a jak se nutnosti něco psát vyhnout. Určitě znáte situaci, kdy z nějakého seznamu mažete položku a celá stránka se znovu nahraje, koukáte se na vršek stránky, ať jste třeba byli odskrolovaní někde uprostřed a v lepším případě vidíte zelný obdélník s kreativní zprávou „Položka byla smazána.” Místo toho bychom mohli po kliknutí na tlačítko Smazat zavolat AJAX, zanimovat zmizení řádku, nevypisovat nic a uživatel by měl naprosto plynulý zážitek.

Pak si musíme dát pozor na konzistentní slovník. Nazýváme části naší aplikace vždycky stejně? Používáme ke stejným akcím stejné výzvy? Dobrý tip je vytvořit si seznam všech textů, abychom měli přehled o tom, jaké výrazy používáme a taky se tam lépe odhalují překlepy a jiné chyby.

S tím souvisí i třešnička na vývojářově dortu – myslet při tom všem ještě na charakteristický hlas naší aplikace, styl, jakým k uživatelům mluví. Ve Fakturoidu se třeba snažíme, aby vše říkal robot za sebe, v první osobě. Jsem přesvědčen, že to pomáhá na několika rovinách, jednak je to netradiční a odlišuje nás to, pak to dává prostor k různým vtípkům, které se podílí na lepším dojmu uživatele a v neposlední řadě, to posiluje vztah lidí k Fakturoidu. Největší radost nám pak dělá, když uživatelé hrají tu hru s námi a emaily na podporu se obrací přímo na robota. My se pak podepisujeme třeba: „Za robota z nul a jedniček přeložil…” :-)

Vybral jsem pár typických míst, která vyžadují největší pozornost a na ty se podíváme příště.

Prázdné obrazovky

Prázdné stránky (blank slate) jsou obrazovky aplikace, kde uživatel ještě nevytvořil žádná data a není tedy, co vypisovat.

Příklad z Fakturoidu: Po prvním přihlášení se objevíte na úvodní obrazovce, kde později budou statistiky vašich příjmů za poslední tři měsíce, posledních šest vystavených faktur, nejbližší pravidelné faktury, přehled posledních události ve vašem účtu a pár dalších věci. Nic z toho tam ale není, protože jste ještě nevystavili žádnou fakturu. Jako tvůrci aplikace máme v tomto okamžiku protichůdné cíle.

Chceme čerstvému uživateli ukázat, co tady později bude, ale jak na to? Nejčastější způsob je screenshot zaplněného rozhraní. Výhodou tohoto řešení je, že ho vytvoříme velmi jednoduše. Nevýhodu vidím v tom, že může být poměrně matoucí. Zaplněná úvodní obrazovka, kde nepoznáváte názvy firem, částky, datumy… Navíc screenshot není interaktivní a musíme ho nějak „zašednout” nebo jinak odlišit od skutečného obsahu, aby se uživatelé nesnažili klikat na nefunkční obrázek a nebyli hned na začátku malinko frustrovaní.

Zároveň potřebujeme nasměrovat uživatele do Nastavení, kde musí ještě vyplnit jedno políčko a když už tam jsou, chceme, aby si nastavili výchozí hodnoty pro splatnost, DPH a to si vyžádá odstaveček textu, který musí být dobře vidět.

A nezapomínejme na to, že uživatel není zrovna nadšený a plně soustředěný na naši aplikaci. Dorazil přes nějaký odkaz na Facebooku, otevřel si naši prezentační stránku v tabu a pokračoval v prohlížení fotek přátel. Pak se mrknul na prezentaci a z nějakého důvodu patřil k těm, kteří nám zvedají konverzní poměr a vytvořil si účet. Právě prošel registrací a zrovna mu někdo volá. O pět minut později se přihlásí, ale zároveň myslí na to, že mu volala manželka, co má koupit, až půjde z práce a do toho potřebuje ještě rychle vystavit fakturu.

OK, možná to nebude úplně typický příklad, ale víte, kam tím mířím.

Jako v tolika jiných věcech při budování aplikací, je příprava obsahu pro prázdné obrazovky o hledání správného přístupu a vyvažování mezi protichůdnými požadavky.

Chybové a jiné hlášky

Hlášky jsou vopruz. Vypsat hlášku skoro vždy znamená přerušit plynulý uživatelský zážitek. Pokud můžete vyhněte se tomu.

Tak třeba, pokud uživatel vidí výsledek své akce, dost možná mu nemusíme nic psát. (Alá scéna „Stěrače stírají.” z Vrchní, prchni.)

Příklad: Když ve Fakturoidu odešlete vyplněný formulář s novou fakturou, který neobsahuje chyby, nahraje se obrazovka právě vytvořené faktury a to je všechno. Žádná hláška se nevypíše.

Myslím, že vypisovat „Faktura byla úspěšně vytvořena” nebo něco takového, je ukázkové zbytečné rušení, protože uživatel vidí, že byla vytvořena a je na stránce, kterou zná z jiných vytvořených faktur a může plynule přejít na to, že v sidebaru klikne na Poslat emailem.

Přístup „show, don’t tell” dal vzniknout Yellow Fade Technique (Bože, to už je to 7 let!… tyjo…), kdy se zvýrazní aktualizované části obsahu.

Když se hlášce nemůžete vyhnout, zkuste vymyslet, jestli by se nedala nějak zvednout její „hodnota”. Pro ilustraci opět do Fakturoidu: Když vytvoříte nový kontakt vypíšeme hlášku, která vám kromě oznámení, že byl vytvořen, nabídne, jestli nechcete vložit další kontakt, nebo mu rovnou vystavit fakturu.

Ještě krátce k chybovým hláškám, které by také samy o sobě vydaly na článek. Pokud to jde, zvýrazněte celý chybný input, ať uživatel nemusí hledat místo, kde se chyby dopustil, a někde blízko stručně vysvětlete, co je špatně a jak to má napravit. A nebojte se dát do toho trochu kreativity a vtipu – uživatel se právě „praštil do hlavy”, zkuste mu bolístku trochu „pofoukat”.

Tlačítka

Texty na tlačítkách jsou mikro-texty svlečené do naha. Musíme být maximálně struční. Víc než dvě slova už jsou často problém jak z hlediska toho, co nám dovolí uživatelské rozhraní, tak proto, že nechceme zbytečně zatěžovat mozek uživatele.

Ze všeho nejvíc tu platí: Myslete z pohledu uživatele. Při hledání vhodného výrazu se snažím představit, co bych jako uživatel sám očekával a hledal.

Příklad: Ve formuláři nové faktury jsme chtěli nabídnout možnost přepnout se na proforma fakturu. Jaký text zvolit? „Přepnout na proformu”? Tři slova, moc dlouhé. Jen „Proforma”? To je zase málo. Co se mi honí hlavou, když chci vystavit proformu? No, „Chci proformu”!

Je jasné, že tohle jsou hodně domněnky a pokud děláte na aplikaci, kterou sami nepoužíváte, rozhodně byste měli všechny své závěry testovat na skutečných uživatelích, což ostatně platí pro všechno výše uvedené.

Když jsem ho začínal psát, myslel jsem, že to bude kratší článek, teď je mi tak akorát jasné, co jsem všechno nezmínil. Ale proto zase připravuju to školení, kde bude víc času hlavně na praktická cvičení. Budete mít někdo zájem, žejo? ;-)