Fáze 1: Z hlavy na papír
Ačkoliv se možná jedná o klišé, omílanou pravdu o tom, že na začátku každé dobré aplikace stojí dobrý nápad, se občas přece jen vyplatí zopakovat. Před všemi ostatními fázemi vývoje stojí totiž faktický problém, který se daná aplikace snaží vyřešit. Při pohledu na stávající nabídku aplikací v Google Play či App Store se sice může zdát, že na každý problém už několik aplikací existuje, to by ale vývojáře nemělo zastavit. Místo otázky Jak by se to dalo vyřešit?
se můžeme zeptat Jak by se to dalo vyřešit lépe, rychleji nebo efektivněji?
a přijít právě s řešením některé zdánlivě dílčí vlastnosti problému.
V případě mobilního bankovnictví se vždy musíme dívat skrze hledisko koncového klienta a ptát se, jak mu usnadnit nebo zpřístupnit práci s účtem kdekoliv se nachází. Zde je samozřejmě maximálně důležitá spolupráce se zákazníkem (tedy bankou), který by měl zrealizovat hloubkovou analýzu současné verze bankovnictví a zjistit, jak a k čemu její bankovnictví klienti využívají.
Mezi takováto klíčová data patří například poměr využívání bankingu ve verzi pro desktop a mobilní zařízení, typ žádostí a problémů, které klienti nejčastěji řeší přes různé komunikační kanály banky (internet banking, mobilní bankovnictví, infolinka, pobočka atd.), nebo požadavky a zpětná vazba přímo od klientů. Data o tom, co by klienti rádi přes které kanály řešili, se získávají nejlépe prostřednictvím dat z linky zákaznické podpory nebo sociálních sítí.
U vývoje velkých projektů mají v dalším kroku hlavní slovo právě zákazníci. V praxi to vypadá tak, že specialisté (může jich být i několik desítek) vývojářské společnosti, kteří jsou na projekt alokováni, dostanou od zákazníka konkrétní zadání. Do celého procesu se zapojuje hned několik různých oddělení banky. Musí se například zajistit, že zadání bude právně odpovídat současným standardům. Marketingové oddělení zase může chtít, aby nová aplikace či funkce pomáhala v propagaci nových produktů atd.
Poté, co jsou známy tyto požadavky, si vývojářská společnost vypracuje analýzu, kterou následně prezentuje zákazníkovi. Do analýzy je zahrnuto mnoho prvků jako cena projektu, doba dodání nebo riziko pro budoucí rozvoj segmentu. Jedním z nejdůležitějších je samozřejmě i pohled na konkurenci. Tím se jednak získává dobré povědomí o trhu, na který zamýšlená aplikace vstupuje, ale především se dá mnohé vytěžit jak z úspěchů, tak neúspěchů jiných tvůrců. Jednou z metod, kterou se dá docílit dobrých výsledků, je například brainstorming nad českými i zahraničními aplikacemi, které v segmentu bankovnictví již existují. Dělat vlastní chyby může být hodně drahé, tak proč nejprve nevyužít chyb někoho jiného?
Nápady, které nosíte v hlavě, mohou být převratné, ale těžko o tom někoho přesvědčíte, když v hlavě zůstanou. Proto je velmi důležitou součástí na začátku celého vývoje fáze modelování. Občas není potřeba nic víc než tužka a papír, popřípadě fixa a tabule. Zásadním krokem v přerodu myšlenky v plán projektu je tzv. wireframe neboli skica. V ní je zachyceno vše, co má aplikace umět, jaký obsah se v ní má objevovat atd. Tady právě začíná samotný design aplikace.
Druhým stádiem je vypracování workflows. Řekněme, že už víme, co všechno bude aplikace umět. V tom případě je načase navrhnout, jak spolu jednotlivé funkce budou propojeny a které z nich budou mít prioritu před ostatními. Nutně nevadí, když se k některým akcím musí uživatel proklikat, ale neměl by se v aplikaci ztrácet. Každý klik musí být intuitivní a vést tam, kam uživatel očekává. Pro otestování workflow se vyplatí mít už digitální model, čímž se dostáváme k dalšímu přelomovému momentu ve vývoji.
Technologická společnost Cleverlance má mezi svými zákazníky několik významných finančních domů působících v České republice. Ve spolupráci s těmito bankami přivedla na svět hned několik produktů internetového a mobilního bankovnictví, které je denně využíváno doslova miliony Čechů.
Jako první uvedly banky v ČR prostřednictvím technických řešení od Cleverlance například možnost plateb skenováním QR kódů nebo napojení na Google Pay.
Krása a funkčnost jedno jsou…
Toto tvrzení zcela určitě platí v kvalitním UX designu. Mnoho lidí přesto dokáže ocenit dobrý design bohužel až poté, co narazí na příklad nějakého špatného. Návrh aplikace tak vychází z umění designérů dívat se na svět očima uživatelů ještě předtím, než vznikne funkční produkt. Výběr velikosti, typu či barvy písma, organizace jednotlivých tlačítek a prakticky všechno, co si koncový uživatel nakonec doopravdy osahá, má původ právě ve fázi UX designu.
Úkolem UX designéra je ve své podstatě překlad základního nápadu do řeči uživatele. Nepochopení kontextu, v jakém bude uživatel s aplikací pracovat, pak může vést k chybám, které pohřbí i jinak vynikající produkt. Pár příkladů za všechny: Budou uživatelé aplikaci používat především v noci? Zářivě bílý design zaručí, že je téměř oslepíme těsně předtím, než si aplikaci odinstalují z telefonu. Stěžejní faktor pro fungující (a tedy krásný) design představuje především konzistence. Jestliže má tlačítko pro potvrzení jinou barvu při každé akci, kterou aplikace umožňuje, velmi rychle se z nich uživateli zatočí hlava a nikdy nedosáhne intuitivního používání.
V průběhu vývoje aplikace si při jejím designu vývojáři pomáhají celou řadou kreativních metod. Jednou z nich je například tvorba tzv. „person“. Jedná se o příklady a vymyšlené modely lidí, kteří náš software nakonec budou opravdu používat. Vezměme si Pepu, ženatého čtyřicátníka s hypotékou, jehož dvě děti mají v bance založená dětská konta. Jak mu můžeme pomoci s naší novou funkcí nebo aplikací? Tyto příběhy pak pomáhají zasadit práci do širšího kontextu a zároveň neztratit nit původního nápadu, který se designéři snaží udržet.
V klikatém vývoji je flexibilita nade vše
Jestliže UX/UI designéři překládají zadání a nápady do řeči uživatele, musí se zase jejich práce přeložit do jazyka jedniček a nul. Vývoj aplikací se ale téměř nikdy nepodobá přímočaré cestě z bodu A do bodu B a během kterékoli etapy se může objevit problém nebo změna zadání. Tým, který na takovou situaci není připravený, se pak může velmi rychle sesypat a s ním celý projekt. Proto je důležité, aby vývoj probíhal flexibilně a aby se vývojáři dovedli přizpůsobit problémům. Je to podobné, jako když překladatel musí občas měnit kontext myšlenky vyřčené v cizím jazyce, aby byl její smysl zachován. Z tohoto důvodu si na oblíbenosti získal tzv. „agilní vývoj“, který má mnoho podob, ale jeho podstata spočívá ve schopnosti týmů lépe a rychleji reagovat na potřebné změny. Pokud má na konci stát produkt, na který budou všichni hrdí, musí se občas začít několikrát i úplně od začátku a nespokojit se jenom s tím, že to „nějak“ funguje.
Agilní vývoj je rozdělen na tzv. sprinty. Většinou se jedná o přibližně dvoutýdenní období, při němž celý tým urputně pracuje na jedné z funkcí tak, aby vznikl perfektně šlapající prototyp, jenž je předán zákazníkovi k otestování. Neznamená to ale, že se mezitím například testeři koušou nudou. Během vývoje je nezbytné průběžně testovat celou řadu aspektů aplikace. Základem je test funkčnosti. Pokud aplikace nedělá to, k čemu je navržena, nemá smysl testovat dál. Vývojáře zajímá ale také to, jestli je uživatelsky příjemná a zda nejenom funguje, ale funguje bez problémů. Aplikace může obsahovat vše potřebné pro mobilní bankovnictví, ale v případě, že je mezi stisknutím tlačítka a provedením akce minutová prodleva, je nezbytné vrátit se zpátky k programování.
Za rok proběhne takových sprintů mnoho a kupí se v tzv. releasy neboli předání většího množství nových funkcí a produktů. V Cleverlance máme za rok na jednom projektu přibližně tři velké předávky, ke kterým jsou dvě až tři menší předávky s opravami chyb nebo doladěním funkcionalit. Před samotným vydáním se ještě kontrolují další faktory, např. jestli akce v mobilním bankovnictví vedou ke změnám i v internetové verzi.
Vydáním to nekončí
Vydáním aplikace samozřejmě práce nekončí, možná spíše naopak. Na základě zpětné vazby, ať už od interních testerů, nebo beta-testerů z řad veřejnosti, ji vývojáři musejí téměř okamžitě začít pilovat, upravovat původní vize a přidávat nové funkce podle potřeb klienta. Celý proces se pak může opakovat znova, někdy i několikrát za rok.
U našich zákazníků máme na starosti někdy dílčí část projektu, často ale komplexní vývoj aplikace. Zajišťujeme projektové řízení, softwarovou architekturu, analýzu, implementaci i testování nových prvků. Naše spolupráce probíhá efektivně a komunikace mezi Cleverlance a jejími zákazníky se odráží i ve výsledcích, se kterými jsme rozhodně spokojeni. Myslíme si, že to platí pro našeho Pepu i reálné klienty bank, kteří mobilní bankovnictví využívají.
