LMC Práce za rohem

Představte si možnost, že byste do práce nemuseli hodiny dojíždět, ale mohli byste snadno najít práci kolem místa, kde bydlíte … a ideálně někde za rohem. O tom byl tento projekt, na kterém jsem pracoval jako designér.

Společnost LMC hledala nový způsob, jak lidem pomoc najít práci. Vyvinula tedy mobilní aplikaci Práce za rohem. Aplikace byla nová a bylo potřeba na ní pracovat a zlepšovat ji.

Cíle projektu

V cílovém kvartálu doručit 30 000 odpovědí na vystavené pozice
Spustit iPhone verzi aplikace

Výsledek

Vytyčený cíl 30 000 odpovědí jsme dosáhli již za 2 měsíce
Díky striktnímu plánování byla verze pro iPhone vyvinuta za 2 týdny, celkem během 1 měsíce.
iPhone verze měla lepší konverzní poměr v řádech desítek %.

Má role

Návrh vzhledu a fungování aplikace
Příprava a exekuce výzkumu
Příprava a analýza výsledků z experimentů

Postup

Projekt byl založen na kontinuální Product Discovery. Pravidelně jsme tedy:

Měřili používání pomocí analytických nástrojů.
Analyzovali data o používání a data o fungování a obsahu.
Prováděli kvalitativní výzkum, ale také kvantitativní formou dotazníků.
Experimentovali s funkcionalitou, kde jsem experimenty pomáhal definovat našemu Product Managerovi.

Paralelně s rozvojem jsme zkoušeli i nové koncepty, jak by mohla aplikace vypadat a fungovat. Výsledky jsme zpětně implementovali do existující aplikace. Ale také jsme na jejich základech tvořili novou iPhone verzi.

O začátcích aplikace

Pro doplnění kontextu o aplikaci si dovolím zmínit, že aplikace byla spuštěná, ještě než jsem přišel do LMC. Aplikace byla již navržená a částečně vyvinutá s tisíci aktivními uživateli (MAU).

Už od začátku zde byly určité problém s odpovídáním na nabídky práce, zobrazováním nabídek a dalšími částmi. Některé problémy byli kritické, protože lidé často odpadávali a aplikaci odinstalovali. Byl jsem tedy najat, abych pomohl s vylepšením aplikace ve spolupráci s týmem 2 vývojářů, Product Managerem a Business Ownerem.

Na základě původních návrhu (viz 3 obrázky výše) jsme měli určité hypotézy na základě mých zkušeností s návrhem mobilních aplikací. Měli jsme ale omezené zdroje, proto jsme museli rychle identifikovat a opravit největší problémy a stále přidávat chybějící funkce.

Příklady – Výzkum a discovery

V rámci kontinuálního zlepšování aplikace jsme se snažili přijít na to, jak lidem pomoci s odpovídáním na nabídky a jak je udělat spokojenější a zároveň jak dosáhnout vytyčených byznysových očekávání a cílů.

Protože se zpočátku nedařilo dosahovat požadovaných čísel, hodně jsme zkoumali a zkoušeli různé možnosti. Využívali jsme pro to tzv. Dual-Track Scrum, kdy jsme měli týdenní plánování a statusy ohledně toho, jak se nám daří, co plánujeme a připravujeme.

Pro tyto případy jsem využíval tyto metody:

Rozhovory
Testování použitelnosti v laboratoři či formálnější meeting room.
Guerilla Usability Testing
Dotazníky
Google Analytics
Interní SQL data úložiště a logy
Recenze aplikace
Zpětnou vazbu od zákaznické podpory
Experimenty typu AB testů, před/po test, tzv. Fake door a další.

Data jsme při price na toto aplikaci využívali opravdu hodně. Zde je například pohled na naše „bádání“ o tom, kolik inzerátů si zobrazilo kolik uživatelů.

Často jsem dělali tzv. explorativní nebo deskriptivní analýzu dat, nebo ověřování hypotéz s využitím skic a prototypů. Například jsme zkoumali otázky typu:

Proč lidé neodpovídají na nabídky práce?
Můžeme v odpovědích na nabídky najít nějaké vzory?
Jaká kritéria lidé při hledání práce využívají?
Kdy a proč lidé hledají pozice?
Kdo jsou současní uživatelé aplikace a co od ní očekávájí?

Poznámka – Testování použitelnosti jsme kvůli větší efektivně iterování návrhů dělali ve formě RITE, tedy Rapid Iterative Testing Evaluation, kdy jsme se inspirovali přístupem výzkumníků ve společnosti Microsoft.

A nyní bych rád ukázal pár konkrétních příkladů.

Penetrace nabídek a zájmu lidí

V rámci výzkumu (při rozhovorech a dotaznících) nám lidé často říkali, že by ocenili více nabídek. Nebyli jsme si jistí, co to znamená, neboť jsme nabízeli více než 10 000 inzerátů, na které se mohli přihlásit.

Aplikace fungovala na následujícím principů – chcete dojíždět maximálně 5 km od svého bydliště, takže:

Nastavíte si adresu kde bydlíte.
Nastavíte si, co chcete dělat za práci.
Řeknete, že chcete dojíždět (tedy zobrazit nabídky v rozsahu) maximálně 5 km.

Na základě toho vybrala aplikace vhodné inzeráty.

Abych daný problém lépe pochopil, pokusil jsem se danou situaci vizualizovat přímo na mapě – tedy jak skutečně vypadá penetrace nabídek s lidmi a jejich nastaveným hledáním a rozsahem zájmu, jak daleko chtějí maximálně dojíždět.

Díky této vizualizaci jsme mohli vidět dané nastavení a zároveň i to, zda lidé vidí nějaké inzeráty, kolik jich vidí a které. (Data jsem měl přímo z interní PostgreSQL databáze díky spolupráci s naším Lead Engineerem).

Konkrétní fakta:

83 % of uživatelů měli nastavenou pouze jednu lokalitu
25 % of uživatelů měli nastavený radius 50 km

Výsledek

Na základě daných zjištění a vizualizaci jsme přemýšleli nad tím, že bychom mohli například:

Nabídnout inzeráty i mimo tento rozsah/radius.
Upravit fungování nastavení rozhahu (bude v dalším příkladu)
Zcela odebrat radius a zobrazit všechny inzeráty, samozřejmě seřazené podle vzdálenosti.
Přidat více inzerátů.

Dalším zkoumáním jsme přišli na to, že lidé vidí dostatečný počet nabídek, ale problém je v tom, že pro ně nejsou všechny dostatečně relevantní, nebo řekněme kvalitní. Tento výzkum byl tedy základem například pro vylepšení systému doporučování.

Poznámka – Zlepšení relevance nabídek vedlo k vyšší spokojenosti uživatelů jak na straně zájemců o zaměstnání, tak i zaměstnavatelů. Lidé totiž měli možnost odpovědět na více relevantních nabídek a zaměstnavatelé tak získávali relevantnější kandidáty.

Nastavení rozsahu pro zobrazování inzerátů

Zde je další příklad z aktivit, které jsme v rámci aplikace podnikli. Našli jsme total problém v nastavení okruhu „zájmu“, tedy jak daleko bude aplikace hledat nabídky práce. Byly zde totiž dvě velké skupiny lidí:

Lidé s malou vzdáleností.
Lidé s maximální vzdáleností, tedy 50 km.

Fungování tohoto nastavení bylo částečně automatizované a limitované počtem inzerátů. Lidé si tedy nemohl nastavit úplně cokoliv. Pokud nebylo dost inzerátů v rámci jejich lokality, rozsah se samozřejmě zvyšoval.

Uvažovali jsme nad tím, zda nebude problém s daným nastavením a jak funguje – tedy že je nastavení příliš svazující. Původní záměr totiž byl, že 10 nabídek bude pro lidi dostatečný počet a poté se nastavení nebude moct dát změnit.

Jak nastavení maximální vzdálenosti vypadalo

Nastavení maximální vzdálenosti, tedy rozsahu, ve kterém bude aplikace hledat inzeráty, fungovalo přibližně takto:

Posouvačem jste mohli pohybovat doprava pro zvýšení vzdálenosti.
Na základě nastavené vzdálenosti to ukázalo počet inzerátů.
Nebylo možné nastavit větší vzdálenost, pokud v daném okruhu bylo nalezené 10 nabídek.

Škála vzdálenosti neměla žádný systém, ale počítala se na základě počtu inzerátů. Takže někteří lidé mohli získat 8 km, ale někdo jiný například 12,3 km.

V předchozím příkladě jsem ukazoval analýzu počtu inzerátů, které jednotlivý uživatelé mohli vidět. Často nám totiž říkali, že by jich chtěli víc. Problém totiž byl, že by chtěli (nebo očekávali) více inzerátů, které by odpovídaly jejich kritériím.

Než jsme se tedy pustili do případných dalších změn a bádání, zkusili jsme udělat menší experiment se změnou chování tohoto nastavení:

Nebudeme posunovač zamykat na omezený počet inzerátů.
Přidat definovanou škálu, například inspirovanou Fibonacciho posloupností.

Měli jsme hypotézu, že právě toto automatické chování a zamykání uživatele aplikace značně omezuje. Proto jsme udělali AB test, na kterém jsme chtěli ověřit dopady jiného fungování. Výsledkem bylo relativní zvýšení konverze odpovědí o 15 %.

Více o testu

Pro výše zmíněný test jsme měli následující hypotézu – pokud lidem umožníme nastavit si vzdálenost více flexibilně, lidé uvidí více nabídek a spíše si najdou nějakou, která je zaujme a my tak zvýšíme konverzí poměr. (10 nabídek není dost, pokud nejsou všechny relevantní.)

Výsledek

p-value = 0.0173

S 95% pravděpodobností můžeme říct, že výsledek byl zapříčiněn danou změnu.

Upravenou variantu posunovače jsme tedy přijali a implementovali pro všechny.

Další nápady pro lokalitu a vzdálenosti

Jelikož šlo o mobilní aplikaci, tak místo nepříliš přímého posuvníku by lidé mohli lokalitu a vzdálenost nastavit pomocí GPS, interakcí s mapou pomocí gest.

Přemýšleli jsme nastavení vzdálenosti odebrat, pustit je do aplikace co nejrychleji a na základě lokality zobrazit nabídky co nejblíže.

Využití GPS pro nastavení lokality bylo kapitolou samo o sobě. Hodně jsme o tom přemýšleli, zkoumali a testovali různé varianty.

Snadno nastavit polohu pomocí GPS a uložit ji na později.

Ukázka týmového brainstormingu ohledně GPS. Bohužel jsme našeho Product Managera nikdy nepřesvědčili tuto možnost vyzkoušet, protože jsme také uvažovali o možnosti odebrat veškeré nastavení lokality z úvodního nastavení aplikace.

Přemýšleli jsme ale také nad více flexibilním nastavením vzdálenosti. Třeba pokud v rámci mého rozsahu neuvidím nic relevantního, co kdybych se podíval co je o kousek dál pouhou interakcí s mapou?

Pokud bych chtěl podívat „za rozsah“ mého nastavení, stačilo by jen oddálit mapu a ukázali bychom náhled, co je o kousek dál. Třeba jen po 100 inzerátech.

Rozmýšleli jsme i nad tím, ukazovat lidem vzdálenost podle preferovaného způsobu dopravy. Vzdálenost by se pak lišila podle toho, zda to bude autem, veřejnou dopravu nebo pešky. Dozvídali jsme se totiž různé příběhy a potřeby lidí, které by takové možnosti podporovaly.

Využití notifikací pro větší zapojení

Práce za rohem byla vždy už od začátku koncipována jako mobilní aplikace. Tím se otvírala spousta možností pro využití nativních notifikací (tedy zasílaných upozornění) uživatelům. Například je upozornit na:

Nové pracovní nabídky
Vybrané potenciálně zajímavé nabídky
Oblíbené nabídky, na které ještě neodpověděli

V notifikacích jsme viděli velkou příležitost. Data ale ukázala, že notifikace mají ve skutečnosti mnohem menší dopad na konverzi a zapojení uživatelů než jsme očekávali. Proto jsme se podívali na to, jak notifikace fungují trochu více do detailu.

Podívali jsme se na srovnání doby odeslání notifikace a doby odpovědi na inzerát, a zda je zde nějaká souvislost.

Na základě různých zjištění jsme zkusili rozesílat různé zprávy, testovat různé varianty formou AB testů, atp. Zároveň jsme přidali efektivnější měření interakcí s notifikacemi – tedy zda je lidé dostanou, otevřou, atp. V podstatě jsme pokryli celé flow pro sledování vlivu na odpověď.

Co se týče dat, zjistili jsme například následující:

50 % uživatelů otevřelo notifikaci do 2 dnů
Přibližně 80 % uživatelů otevřelo notifikaci do 2 týdnů
Pouze 0,33 % odpovědí bylo přímou reakcí na notifikaci

Díky internet datům v rámci odesílání a měření dat jsme poté mohli sledovat vliv notifikaci a v jakých případech lidé notifikaci smažou, otevřou, jak dlouho trvá než notifikaci otevřou, atp. Pomohlo nám to v efektivnější tvorbě a plánování odesílání notifikací.

V rámci jednoho experimentu jsme sledovali, kdy lidé otevřeli danou notifikaci.

Tvorba notifikací

Připravit efektivní notifikace byla docela výzva z důvodů omezení délky jak titulku, tak i zobrazeného sbaleného textu. Aby se nám tedy notifikace lépe připravovaly a byly více úderné, udělal jsem pro nás jednoduchý vizuální nástroj – díky němu jsme viděli, jak bude notifikace vypadat a zda lidé uvidí vše důležité.

Nástroj je stále k dispozici na adrese https://www.manakmichal.cz/playground/notification-builder/.

Jak vypadal náš jednoduchý nástroj pro tvorbu notifikací.

Jak lidé rozumí ikonám v navigaci

Jak jsme na aplikaci neustále pracovali, hledali jsme i způsoby, jak ovládání a navigaci v rámci aplikace zlepšit. Například v rámci měření cest v Google Analytics jsem viděl, že mohou být v rámci navigace jisté problémy.

Proto jsme připravili několik konceptů toho, jak by mohla navigace fungovat. Například:

Záložky v hlavičce aplikace (tehdy to byl vzor v rámci Material Designu)
Záložky na spodní hraně obrazovky
Přepínání možností přes hlavní menu

Vyzkoušeli jsme také různé ikonky a zjišťovali jsme, zda budou „samovysvětlující“ budou moct být bez popisku, nebo bude bezpečnější doprovodit ikonky popiskem. Nejprve jsme chtěli ale pochopit, které ikonky případně využít, protože zde bylo více alternativ.

Postup byl následující:

Pro jednotlivé kategorie a entity jsem shromáždil možné varianty ikon.
Vybral jsem několik slibných ikon pro každou kategorii.

Kategorie byly následující:

Mapa, aneb nabídky zobrazené na mapě
Seznam nabídek
Oblíbené nabídky
Seznam upozornění

Zde jsou varianty navigace s různými ikonkami, které jsme zkoumali.

Pro ověření ikon jsme chtěli spíše kvantitativní data. Proto jsem ve spolupráci s naším výzkumníkem připravili dotazník, ve kterém jsme:

Zkoumali jednotlivé ikony a jejich význam pro lidi.
Zkoumali různé kombinace ikon a jejich umístění přímo v rámci navigace.

Například jsme se tak ptali na otázky:

Co pro vás znamená tato ikona?
Představte si, že byste chtěli vidět nabídky zobrazené na mapě, kterou možnost v navigaci byste si vybrali?

Po každé otázce jsme se ještě zeptali pro další dílčí kontext, abychom dané volbě správně porozuměli.

Příklad č. 1 – Ikona mapy

Otázka
Co pro vás tato ikona reprezentuje?

Výsledek
Více new polovina lidí tuto ikonu znala, ale dost lidí si nebylo zcela jisto, co ikonka představuje.

Dívali jsme se právě i na doplňující komentáře a bylo zde riziko, že lidé ikonce bez vysvětlení nemusí porozumět.

Příklad č. 2 – Ikona seznamu

Otázka
Co pro vás tato ikona reprezentuje?

Výsledek
Lidé z možností vybrali více variant – například menu nebo seznam nabídek.

V komentářích nám také někteří lidé řekli, že se tato ikona běžně používá pro menu.

Ikonky jsme poté ověřili také s interními zaměstnanci, ale také v rámci Guerilla Usability Testování na blízkém vlakovém nádraží.

Na základě zjištění jsme vybrali určitou kombinaci ikon. Pro větší ujištění, že budou ikony srozumitelné, jsme nakonec vybrali možnost spodních záložek, kdy jsme ikony doplnili popiskem.

Varianta navigace a ikon, kterou jsme vybrali pro další zlepšování aplikace.

Jak odpovědět na nabídku

Protože spousta lidi vůbec neodpovídala na nabídky, rozhodli jsme se zjistit, proč se tak děje a co bychom s tím mohli udělat – zda je problém v aplikaci nebo někde jinde. Proto jsme dělali mnoho rozhovorů, vypustili spoustu dotazníků a testovali aplikaci na použitelnosti. Snažili jsme se zjistit, kde je problém.

Jak už jsem zmínil výše, jedním z problémů bylo, že lidé neměli dost relevantních nabídek. Zároveň jsme ale častěji zjišťovali, že psaní odpovědí pro lidi není na mobilu z různých důvodů úplně komfortní. Například:

Lidé nemají v rámci telefonu uložený životopis.
Lidé nechtějí na telefonu psát motivační dopisy bez jakékoliv kontroly pravopisu.
Lidé preferují jiný způsob odpovědi než pomocí zprávy.

Říkali jsme si tedy, co kdyby mohli lidé vedle standardní textové odpovědi možnost do firmy zavolat? Což by bylo další skvělé využití přidané hodnoty mobilní aplikace.

Pod tlačítkem odpověď by se „skrývali“ 2 možnosti, abychom příliš nekomplikovali UI a rozhodování v začátku.

Pokud budete chtít do firmy zavolat, chtěli jsme, ať víte komu budete volat.

Jeden z nápadů jak možnost zavolat umístit do detailu nabídky s tím, komu budete případně volat.

Další z nápadů na zobrazení možnosti volat do firmy.

Tuto možnost jsme testovali v rámci použitelnosti a získávali jsme hlavně kvalitativní informace. Proveditelnost jako takovou jsme konzultovali s vývojáří a dalším pracovním portálem, který s danou funkcionalitou experimentoval přímo a pomáhal nám sbírat data.

Rozmýšlení fungování odpověď na nabídku pomocí telefonického hovoru.

Detailní návrh aplikace

Zde jsou příklady obrazovek, které jsme navrhli pro upravenou a vylepšenou variantu aplikace. Vznikly na základě mnoha testů a zkoumání (viz příklady výše). Navrhli jsme je v rámci nástroje Adobe Experience Designer, který byl tehdy v BETA verzi a my chtěli otestovat jeho možnosti oproti nástrojům Sketch a Photoshop.

Animace a přechody

Návrhem obrazovek to samozřejmě nekončilo. Během testování použitelnosti jsem viděl, jak moc užitečné jsou různé animace a přechody mezi obrazovkami – například ty pomohly lidem chápat fungování aplikace a navigaci v ní. Proto jsem navrhl a protypovalit různé možnosti, které jsme následně dali k implementaci.

Zde jsou nějaké příklady, jak jsem nad animacemi přemýšlel.

Kvůli výkonu a rychlosti aplikace jsme přemýšleli o postupném načítání dat, proto jsem přemýšlel tento proces animovat tak, že by nabídky postupně „padaly“ na mapu jak by se načítali místo „obyčejného“ zobrazení nabídky.

Protože bylo možné listovat nabídkami pomocí gest – navrhl jsem doplnit tuto interakci také tzv. slide animací, kdy by se tedy další/předchozí nabídky objevovali přímo a přijely by.

Nabídka ze seznamu by se pouze neotevřela nebo nepřijela ze strany, ale pomocí animace by se roztáhla a bylo tak jasné, že je vlastně nad seznamem.

Návrh verze pro iPhone

Na začátku byla pouze verze aplikace pro Android, ale v plánu bylo připravit aplikace i pro ostatní platformy – především pro iOS.

Protože jsme měli docela striktní časový harmonogram, navrhl jsem základní verzi pro telefony iPhone. Abychom to stihli, udělali jsme spoustu ústupků, se kterými Product Manager a Business Owner souhlasili. Díky tomu jsme ušetřili hodně času a mohli se tak soustředit na to nejdůležitější. iPhone verze tak byla vyvinuta za pouhé 2 týdny s tím, že už od začátku měla vyšší konverzí poměr než verze pro Android.

Zobrazení nabídek jsme značně zjednodušili.

Detail nabídky pouze s možností odpovědět a jít zpět na seznam nabídek.

Klíčovou myšlenkou bylo dát lidem nabídl co nejrychleji v přehledné podobě a v rámci celé cesty zachovat pouze klíčové prvky. Využili jsme k tomu znalosti z Android verze a například jsme:

Umožnili met pouze 1 lokalitu per uživatele (přibližně 83 % uživatelů Android verze mělo jen jednu lokalitu).
Odebrat posuvník pro nastavení vzdálenosti.

Největší výzva byla přesvědčit lidi, že:

Nemůže verzi pro Android pouze přenést, protože designové vzory a zvyklosti jsou na zařízeních iPhone odlišné.
Nepotřebujeme zobrazení mapy s nabídkami. V rámci výzkumu jsme zjistili, že lidé ji pro procházení nabídek stejně nepoužívají a přepínají na seznam, který je seřazený podle vzdálenosti.

Poznámka – Zjednodušením fungování aplikace samozřejmě vznikly některé další problémy, například přikládání životopisu. To ale bylo součástí dalšího řešení.

Koncept aplikace

Jak jsem již zmínil výše, základní myšlenkou iPhone verze bylo mít jednoduchou aplikaci a umožnit lidem dostat se na nabídku price co nejrychleji. Pro lepší ilustraci nápadu jsem navrhl základní flow, které jsem diskutoval s Business Ownerem a vývojáři pro plánování dalších kroků.

Jak by přibližně fungovala iPhone verze a které části by ji mohly tvořit.

Na základě tohoto flow jsem poté zkoumal různé možnosti pro jednotlivé části celého flow. Na následujících náčrtcích ukazuji různé nápady, využití anotací, jak jsem navrhoval interakce, flows, atp. které jsem následně komunikoval s vývojáři pro flexibilnější vývoj.

Pouze na detailu nabídky bychom zobrazili mapu, se kterou by lidé mohli v případě potřeby pracovat – zvětšit si ji, přiblížit, atp. Zamýšleli jsme ji totiž zobrazit v menší podobě, tak ať se lidé podívají, kde by to přibližně bylo.

Ve verzi pro iPhone by byl pouze jeden seznam, ale ve více různých starch. Zkoumal jsem tedy, jak efektivně zobrazit nové nabídky, jak odlišit přečtené od nepřečtených, jak zobrazit chyby, načítání, atd.

Obrazovky

Zde je několik vybraných obrazovek, které jsme následně využili pro vývoj iPhone verze. Poznatky pro návrhy jsme těžili z výzkumu pro Android verzi. A stejně jako Android, tak i obrazovky pro iPhone verzi jsme navrhli s využitím nástroje Adobe Experience Designer, který byl tehdy v BETA verzi a my chtěli otestovat jeho možnosti oproti nástrojům Sketch a Photoshop.

Nastavení lokality a jak daleko chtějí lidé dojíždět

Kam se obrátit

Pokud vás během pročítání této ukázky cokoliv napadlo, neváhejte se na mě obrátit na adrese email@manakmichal.cz, případně mi napište pomocí tohoto formuláře: