Vedení terénního UX výzkumu ve 3 městech

Ve zkratce


Tým	3 terénní výzkumníci, každý v jiném městě (já mezi nimi koordinoval zadání, metodiku a analýzu)
Metoda	Terénní shadowing + rozhovory v terénu, cross-case analýza
Vzorek	6 zdravotních sester ve 3 městech různé velikosti
Zadavatelé	Dodavatelská agentura (byznys výstup) + výrobce softwaru (produktový výstup) – se dvěma rozdílnými prioritami
Výstup	Jeden report se dvěma liniemi zjištění, prioritizovaná doporučení, klientská prezentace

Kontext

Zdravotnická organizace v terénní domácí péči přecházela ze starší desktopové/webové aplikace na novou nativní mobilní appku. Zdravotní sestry v ní tráví velkou část dne – zapisují zdravotní úkony přímo u klientů doma, mezi návštěvami jezdí autem po městě nebo po okrese.

Zadání jsem dostal od agentury, která pro klienta (výrobce softwaru) vedla redesign. Rychle se ukázalo, že to není jedno zadání, ale dvě:

Agentura potřebovala obhájit byznysový case – co appku táhne k adopci a co ji brzdí.
Výrobce softwaru potřeboval vědět, kde appka v praxi „škobrtá” – konkrétní usability problémy a feature requesty.

Tyhle dvě potřeby se přirozeně tahaly každá jinam. Agentura chtěla slyšet o hodnotě a adopci, výrobce chtěl seznam chyb k opravě. Sladit obojí do jednoho terénního výzkumu, aniž by jedna strana dostala jen zlomek pozornosti, byla první a asi nejdůležitější rozhodovací výzva na projektu.

Moje role

Projekt jsem vedl od zadání po finální prezentaci. Konkrétně jsem měl na starosti:

Rámování zadání – přeložil jsem dvě částečně protichůdná zadání do jednoho výzkumného plánu se dvěma paralelními liniemi analýzy (adopce/hodnota × usabilita/feature requesty), aby žádná strana nedostala „ořezanou” verzi výzkumu.
Vedení tříčlenného týmu – tým tvořili tři terénní výzkumníci, každý pokrýval jedno město. Nastavil jsem jednotnou metodiku (co pozorovat, jak vést rozhovor, jaká kritéria vzorku), aby data z různých měst šla vůbec smysluplně porovnávat.
Vztah se zadavateli – komunikoval jsem omezení (dovolené na straně klienta, citlivost přítomnosti výzkumníka u pacienta, GDPR) a vyjednával reálný harmonogram sběru dat.
Analýzu a syntézu – po sběru dat jsem vedl vlastní třífázový analytický proces (níže) a byl zodpovědný za finální doporučení a jejich prioritizaci.
Prezentaci výstupů – připravil a odprezentoval jsem výsledky oběma zadavatelům současně, v jednom sdíleném artefaktu.

Přístup

Proč terénní shadowing, ne jen rozhovory. Sestry appku používají v pohybu – v autě, ve výtahu, u klienta s rukama v rukavicích. Rozhovor u stolu by ukázal, co si sestry myslí, že dělají, ne co dělají reálně. Zvolili jsme půldenní shadowing (výzkumník jede se sestrou na část její běžné trasy) doplněný krátkým rozhovorem před a po výjezdu.

Proč jsme se ptali na potřebu, ne na to, jestli sestra umí appku ovládat. Do zadání jsem zavedl explicitní pravidlo: neptat se „umíte v appce najít funkci X”, ale „vznikla vám vůbec potřeba X udělat”. Rozdíl je zásadní – první otázka testuje paměť a školení, druhá odhaluje skutečné mezery v produktu.

Proč šest lidí ve třech městech, ne šestnáct lidí v jednom. Vzorek byl záměrně malý, ale strukturovaný napříč pobočkami různé velikosti a různé „vyzrálosti” v používání appky – od pobočky, kde appku používali půl roku, po pobočku, kde se sestry teprve učily základní přihlášení. To nám umožnilo místo jednoho průměrného obrazu vidět, jak se stejný produkt chová v různě organizovaném provozu.

Jak jsem zajišťoval, že šest rozhovorů unese vážné rozhodnutí. Místo jednoho kola „posbírej citáty a udělej shrnutí” jsem zavedl třífázový postup:

Granulární extrakce – z každého rozhovoru zvlášť jsem vytáhl konkrétní data (ne dojmy) do předem daných kategorií: co appku brzdí, co ji žene dopředu, kde ji sestry obcházejí, jaké jsou reálné vs. deklarované use casy.
Stres test / verifikace – u každého respondenta jsem záměrně hledal vnitřní rozpory (např. „appka mi nevadí” vs. o pět minut později vyjmenované tři konkrétní problémy) a zjištění, která se nezávisle potvrzují napříč více lidmi nebo městy, jsem odlišil od těch, co stojí na jednom hlase.
Syntéza a prioritizace – teprve zjištění, která prošla verifikací, jsem seřadil do doporučení podle dopadu a podle toho, kolika nezávislými zdroji byla potvrzená.

Tenhle mezikrok (verifikace) není v terénním výzkumu samozřejmost, ale ukázal se jako klíčový: minimálně u poloviny respondentů obecná otázka na spokojenost zamlčela problémy, které se objevily až u konkrétnějšího dotazu. Bez toho kroku by report obsahoval slabší, méně podložená doporučení.

Co jsme zjistili (výběr)

Jedna chybějící funkce blokovala celou adopci appky. Napříč dvěma nezávislými městy a bez vzájemné domluvy sestry i vedoucí pracovnice pojmenovaly úplně stejnou bariéru – appka neuměla převzít text z předchozího zápisu. Odhad ztraceného času: 1,5–3 hodiny denně na sestru. Nešlo o jeden z dvaceti požadavků v seznamu – šlo o podmínku, bez které sestry racionálně zůstávaly u starého systému bez ohledu na to, co appka uměla nově a lépe.
Appka byla silná v orientaci, slabá v administrativě. Rychlé dohledání informací o klientovi appku táhlo dopředu; zápis, řazení klientů a řešení výjimek se ve všech třech městech dělo většinou mimo ni – na papíře, v jiné appce nebo na desktopu.
Praxe se lišila i uvnitř jedné organizace. Stejný typ dokumentace psaly sestry ve stejné firmě s různou pravidelností – něco, co jsme mohli srovnáním napříč městy vůbec odhalit, protože žádný jednotlivý rozhovor by to sám o sobě neukázal.

Proč na tom záleželo byznysu, ne jen UX

Standardní chyba terénního výzkumu je zůstat u UX jazyka – „appka má nízkou spokojenost” nebo „sestry appku neumí ovládat”. Tomu ale žádný byznysový rozhodovatel nerozumí a nedá se podle toho investovat. Proto jsem zjištění při reportování přeložil do řeči, které rozumí i vedení:

Náklad, ne UX drobnost. Chybějící kopírování jsme nerámovali jako „vylepšení komfortu”, ale jako opakovaný provozní náklad – hodiny práce navíc denně, na každou sestru, každý den, dokud appka tuhle mezeru má.
Riziko, ne jen nekonzistence. Zjištěné rozdíly v tom, jak pravidelně se dokumentace vyplňuje, jsme spojili s tím, že pojišťovny při kontrole neproplácejí neúplné záznamy – tedy s reálným finančním rizikem pro klienta, ne s „nejednotným zvykem”.
Rychlost, ne jen zpoždění. Cílem bylo dostat tohle zjištění před tým dřív, než investuje další sprinty do menších vylepšení, a dřív, než se appka rozjede na zbytek pobočkách – opravit blokující problém před plošným nasazením je řádově levnější než po něm.
Adopce, ne spokojenost. Ambicí zadavatele bylo appku plošně nasadit a starý systém vypnout. Dokud appka drží sestry v hybridním provozu se starým systémem kvůli jedné chybějící funkci, firma dál platí za provoz dvou systémů místo jednoho – to jsme použili jako přímý argument pro prioritizaci.

Výstup a doporučení

Výstupem byl jeden sdílený report se dvěma čitelnými liniemi (byznysová pro agenturu, produktová pro výrobce appky), cross-case srovnání mezi pobočkami, inventář reálných workaroundů a doporučení rozdělená do čtyř úrovní priority – od jedné podmínky nutné pro adopci až po delší vylepšení. Report jsem odprezentoval oběma zadavatelům společně a šel do jejich standardního schvalovacího procesu.

Co bych příště udělal jinak

Vzorek dvou lidí na město nám dal bohatá data, ale málo prostoru rozpoznat, jestli je nález specifický pro daného člověka, nebo pro celou pobočku – u jednoho zjištění (nejednotná praxe dokumentace) jsme se museli spolehnout na to, že si to zadavatel sám ověří. Příště bych trval na aspoň jednom doplňkovém rozhovoru s vedoucí pracovnicí za každé město už v rámci sběru dat, ne až jako doporučení pro další kolo.