Az app store-ok tele vannak technikailag hibátlan appokkal, amiket senki nem használ. A kód lefut, a szerver bírná a terhelést, a letöltésszámot szépen hozzák az első kampányok, aztán az aktív felhasználók grafikon két hét múlva a nulla felé kezdd el közelíteni.
Amikor azt keressük, miért bukik el egy app, ritkán találunk technikai hibát: a felhasználó egyszerűen nem jött vissza.
Ebben a cikkben azt szedtük össze, amit a saját termékfejlesztési projektjeinkben tanultunk arról, hogyan válnak a kíváncsi letöltések bosszankodássá, vagy hogyan vész egy amúgy jó app a feledés homályába. Megmutatjuk az öt leggyakoribb felhasználói élmény hibát, a jeleket, amikből felismered őket a saját appodban, és azt is, hogyan lehet mindezt viszonylag olcsón megelőzni.
A számok a visszatérésről szólnak, és kíméletlenek
A mobilos piac legkeményebb mutatója a megtartás. Az iparági mérések évek óta ugyanazt mutatják: a letöltők többsége az első néhány napban lemorzsolódik, és egy hónap múlva tíz felhasználóból jó esetben egy marad aktív. A letöltés tehát önmagában semmit nem ér: csak egy esély arra, hogy az első pár percben bebizonyítsd: érdemes veled maradni.
Ez a pár perc pedig nem a technológiáról szól. A felhasználót nem érdekli, milyen frameworkben készült az app és milyen elegáns az architektúra. Egyetlen kérdése van: megkapom-e gyorsan azt, amiért letöltöttem? Ha a válasz bizonytalan, a következő alternatíva egy kattintásra van.
Üzletileg ez azt jelenti, hogy a rossz UX minden marketingforintodat megadóztatja. Hiába hozol letöltést hirdetésből, ha a felhasználók kilencven százaléka az első héten eltűnik, a pénz egy lyukas vödörbe folyik. A megtartás javítása ezért szinte mindig olcsóbban hoz növekedést, mint feltekerni a marketing költéseket.
Az öt hiba, amin a legtöbb app elvérzik
Az alábbi lista nem elmélet: ezekbe futunk bele a leggyakrabban, amikor egy meglévő appot nézünk át. A sorrend nagyjából gyakorisági is.
1. Regisztrációs fal az első képernyőn
Az app még semmit nem adott, de már email-címet, jelszót, három engedélyt, rosszabb esetben még személyes adatokat is kér. A felhasználó fejében ilyenkor egyszerű a mérleg: még nem kaptam semmit, máris "fizetnem" kell az adataimmal. Előbb engedd a felhasználót, hogy megtapasztalhassa az értéket, amit nyújtasz, és
a) csak ott kérj regisztrációt, ahol az tényleg megkerülhetetlen (mentés, fizetés, szinkronizálás)
b) ha túljutott a kritikus ponton, finoman kommunikáld, milyen hozzáadott értéket nyújt, ha létrehoz egy fiókot.
2. Minden funkció egyszerre
A fejlesztés hónapjai alatt minden jó ötlet bekerült, így az első megnyitáskor húsz menüpont és négy felugró ablak fogadja azt, aki még azt sem tudja, hol kezdje. Az első használat egyetlen dologra való: a fő érték gyors átélésére. Egy "aha!" pillanat. Minden más ráér. Ez ugyanaz a fókusz, amiről az MVP fejlesztésről szóló cikkünkben írtunk: egy dolgot csinálj elsőre nagyon jól.
3. A navigáció a céget tükrözi, a felhasználót nem
A menüpontok a cég belső logikáját és szakzsargonját követik, a felhasználó viszont a saját feladata felől közelíti meg az alkalmazást. Ha a fuvarozásban utazó ügyfél a Diszpécsermodul címke alatt találja meg a címét, az neki rejtvény, nem modul. A folyosóteszt itt kegyetlenül gyors diagnózist ad: ha öt emberből három nem találja meg az alapfunkciót, a navigáció megbukott.
4. Néma app: se visszajelzés, se állapot
Betöltés pörgő jelzés nélkül, hibaüzenet, ami csak annyit mond, hogy valami hiba történt, és üres képernyő az első megnyitáskor, iránymutatás helyett. A felhasználó ilyenkor elbizonytalanodik, és a bizonytalanság a törlés előszobája. A jó app minden pillanatban jelzi, mi történik, mi sikerült, és mi a következő lépés.
5. Szép felület, döcögő user journey
A leggyakoribb tévhit, hogy a felhasználói élmény a képernyők csinosításán múlik. Közben a vásárlásig, foglalásig vagy beküldésig vezető út nyolc lépés, két félreérthető gombbal. A szép felület ilyenkor csak elodázza a törlést. Előbb a fő utat kell három-négy magától értetődő lépésre szűkíteni, a vizuális finomhangolás utána jöhet.
Honnan tudod, hogy a te appod is érintett?
Nem kell hozzá laboratórium, az árulkodó jelek jellemzően kéznél vannak:
- Az értékelésekben visszatérő mondatok: nem értem, hol van, nem működik, pedig technikailag minden működik.
- Az ügyfélszolgálati kérdések fele ugyanarra a két-három elakadásra vonatkozik.
- Az analitikában a fő folyamat egy pontján tömeges a lemorzsolódás, például a kosárig sokan eljutnak, a fizetésig kevesen.
- Sok az egyszeri felhasználó: a letöltés és az első munkamenet megvan, második, harmadik, negyedik már nincs.
Ha a fentiekből kettő is igaz, érdemes megnézni, mit csinál valójában a felhasználó. Egy képernyőfelvétel az első munkamenetről vagy öt élő, valós felhasználókkal folytatott teszt többet mond, mint bármennyi belső vita. Nálunk ez a leggyorsabb módja annak, hogy a csapat abbahagyja a találgatást.
A UX nem a fejlesztés végén kezdődik, hanem az elején
A fenti hibák közös gyökere, hogy az élményre a csapat a kódolás közben gondolt először. Ilyenkor a változtatás már költséges és a hirtelen meghozott döntés, szinte biztosan nem a jó döntés. A megelőzés ott kezdődik, hogy még fejlesztés előtt kattintható prototípuson teszteled a fő folyamatokat valódi felhasználókkal. Ez napok alatt kideríti, mit értenek félre, és töredékébe kerül annak, mint ugyanezt már az első release után megtanulni. Arról, hogyan érdemes egy ötletet olcsón próbára tenni, az app-ötletek validálásáról szóló cikkünkben írtunk részletesen.
Így dolgoztunk a Krewly appján, ahol a stábtagok napi munkáját kellett egyetlen egyszerű folyamatra fűzni, és a Bubbles önkiszolgáló mosodáinak alkalmazásán, ahol az volt a tét, hogy egy elsőre ismeretlen gép kezelése is magától értetődő legyen. Mindkét projektben a képernyők design-ja előtt dőlt el, mi kerül a felhasználó elé, és pontosan ettől lett egyszerű a kész app.
Mennyibe kerül a jó élmény, és mennyibe a rossz?
A korai UX-munka, a kutatás, a prototípus és a tesztelés a teljes fejlesztési büdzsének jellemzően kisebb hányada. A launch utáni mentőakció ezzel szemben duplán fizetős: újra kell tervezni és fejleszteni a kritikus képernyőket, miközben az elpártolt felhasználókat már nem hozza vissza semmilyen frissítés. A számokról és arányokról az applikáció fejlesztés költségeiről szóló cikkünk ad részletes képet.
A magunk részéről ebben határozottak vagyunk: ha a büdzséből vagy egy plusz funkcióra, vagy a fő út tesztelésére futja, szinte mindig a tesztelés a jobb befektetés. Egy funkcióval kevesebb ritkán buktat meg egy appot. Egy kényelmetlen fő út viszont rendszeresen.
Ha van egy appod, ami sok letöltést kap, de kevés visszatérőt, vagy most tervezel egyet, és szeretnéd az öt hibát kihagyni, nézd meg, hogyan épül fel a UX/UI design szolgáltatásunk. Egy rövid beszélgetés után őszintén megmondjuk, ha a te esetedben nem teljes áttervezés kell, csak néhány célzott javítás.
Gyakori kérdések
Elég egy szép felület a jó felhasználói élményhez?
Sajnos nem. A felület (UI) azt határozza meg, hogyan néz ki az app, a felhasználói élmény (UX) pedig azt, hogy a használat közben minden a helyére kerül-e: érthető-e a folyamat, gyorsan célba ér-e a felhasználó. Egy gyönyörű app is bukhat el azon, hogy a fizetésig vezető út zavaros.
Kész, élő app mellett is van értelme UX-szel foglalkozni?
Igen, sőt ilyenkor a leghálásabb, mert már vannak valódi használati adatok. Egy átvilágítás a meglévő analitikára és néhány felhasználói tesztre épül, és jellemzően a fő folyamat két-három kritikus pontjának javításával indul. Nem kell mindent újraírni: a kiesési pontok célzott javítása is mérhető eredményt hoz.
Hogyan mérjem, hogy tényleg az élményen múlik az appom teljesítménye?
Három forrásból nagyon gyorsan kiderül: a megtartási adatokból (hányan térnek vissza az első hét után), a fő folyamat lépésenkénti kiesési arányából, és öt valódi felhasználó teszteléséből. Ha a tesztelők ugyanott akadnak el, ahol az analitika kiesést mutat, megvan a tettes.
MVP-nél nem korai még a felhasználói élményre költeni?
Éppen az MVP-nél a legfontosabb, mert ott minden funkcióból csak a lényeg van benne, így az élményen múlik, hogy az első felhasználók visszatérnek-e. A jó hír, hogy kis scope-nál a UX-munka is kicsi: néhány napnyi prototípus-teszt általában elég ahhoz, hogy a fő út kerek legyen.
Mennyi idő egy UX-átvilágítás?
Az app méretétől függ: egy fókuszált audit a fő folyamatra néhány nap alatt elkészül, egy teljesebb, teszteléssel és javaslatokkal együtt jellemzően pár hét. A lényeg, hogy a végén ne vélemények, hanem rangsorolt, fejleszthető javaslatok legyenek a kezedben.