Na hraně mezi UX a PO
Vývojář, UX designér, Product Owner. Tři role, které zásadně ovlivnily můj pracovní růst. Tři role, které mi pomohly nahlížet na procesy a produkty z nespočtu pohledů. Tři role, díky kterým vám nyní můžu poskytnout rady a tipy do života UX designéra a Product Ownera. Ale proto se musíme vrátit na začátek mého příběhu.
Jak jsem začal v Blueberry?
Kluky z Blueberry jsem znal dlouho předtím, než jsem s nimi začal pracovat. V těchto historických časech sídlilo Blueberry v kancelářích na Štěpánské a přes léto pořádali na terase vyhlášené grilovačky. No a pak to přišlo. Jednou jsem se zde dozvěděl o chystaném hackathonu, a protože mě zajímalo, jak to vypadá ve vývojové firmě, přihlásil jsem se. Byl jsem zde jako jeden ze dvou lidí mimo Blueberry (spolu s Jindrou Fáborským z Marketing Festivalu). Krátce po hackathonu jsem dostal nabídku na pozici Junior kodéra, kterou jsem přijal. V té době se Blueberry zaměřovalo výhradně na vývoj v Ruby on Rails a jak je zde zvykem, důraz se kladl na kvalitu kódu, na což se v Blueberry rozhodně nikdy neopomnělo. A co se stane když po nějakou dobu aplikujete hodně code review na juniorního kodéra? Stane se z něho kodér.
Jak ale s oblibou říká spolu-zakladatel Pavel Vachek, nejhorší je osvědčit se. Takže postupem času jsem dostal roli team leadera.
Když pak přišla příležitost dále rozšířit moje zkušenosti o User Experience Design v intenzivním ročním kurzu, moc dlouho jsem neváhal. Koneckonců jsem si říkal, že UXD je designování rozhraní pro uživatele a to je něco, s čím mám přece zkušenosti, jelikož jsem před drahnou dobou navrhl rozhraní pro několik mobilních telefonů a MP3 přehrávačů. Je ovšem pravdou, že dané platformy byly značně omezené a mohl jsem upravit prakticky jen použité ikony, barvu pozadí a textaci. I přesto to osobně považuji za svůj první krok k pozici UX designéra.
Jednalo se o intenzivní roční kurz UX Designu v akademii, která je nyní přejmenovaná na UX Well. Pod vedením Berky a Petra Štědrého jsem spolu z dalšími účastníky objevoval kouzla a taje tohoto oboru. Za to bych chtěl nejen jim, ale i všem ostatním lektorům a mentorům ještě jednou poděkovat. Nemyslím si, že by pro začínající designéry existovala lepší volba. Na víc jsem měl to štěstí, že se mi Petr Štědrý věnoval jako mentor celý rok.
Musím na tomto místě zmínit i jeden přelomový okamžik, kdy jsem si uvědomil o čem vlastně User Experience Design je.
Jednalo se o jeden z prvních víkendů kurzů a za úkol jsme dostali nadesignovat hotelový kiosek. Na tom by nebylo nic zvláštního, co však zvláštní (alespoň pro mne) bylo, je fakt, že všechny týmy poslali do blízké Galerie Vaňkovka získat feedback na svoje papírové prototypy. Tahle informace ve mně z počátku vyvolala zděšení. Chvíli jsem uvažoval, zda raději neuteču zadním východem, ale nakonec jsme to všichni zvládli a pro mě osobně to byl jeden z největších aha momentů v rámci studia.
Dnes je mi již jasné, že výzkum je neoddělitelnou součástí User Experience Designu. Je to vlastně podstatná část škatulky jménem UX. Protože je toho v této škatulce opravdu mnoho a člověk se v množství aktivit snadno ztratí, připravil jsem si několik tipů, ke kterým jsem došel ze své praxe v UX.
1. Dělejte to, co přinese maximální užitek
Jak jsem zmínil výše, aktivit je v UX škatulce opravdu mnoho. I když vám pravděpodobně většina s projektem nějakým způsobem pomůže, doporučuji využívat pouze ty, které vám u daného projektu budou prospěšné. Pokud pomineme, že jen samotná snaha využít hodně aktivit, vám zabere extrémně hodně času, a ve výsledku tedy i peněz, narazíme na další problém. Jestliže se budeme několik měsíců věnovat jen výzkumu, znamená to, že dostat náš produkt na trh bude trvat nejméně rok. A to je příliš dlouhá doba. Proto je lepší soustředit se na aktivity, které nám co nejrychleji pomohou. Dále pokud vidíme, že nám daná aktivita nepřináší to, co očekáváme, měli bychom ihned zkusit něco jiného.
Já jsem si například uvědomil, že dostatečně nevyužívám potenciál klientských workshopů. Po několika interakcích s klienty jsem považoval jejich strukturu za doladěnou a to až do doby, než jsme získali zcela jiný typ projektů (redesign konferenčního webu). Místo toho, abych obsah přizpůsobil potřebám a požadavkům nového typu klienta, jsem naivně aplikoval předchozí strukturu workshopu. I když nedošlo k žádnému problému, věděl jsem, že jsem dostatečně nevyužil investovaného času a potenciálu schůzky. Nyní workshopy přizpůsobuji specifickým potřebám a požadavkům klienta pro dosažení maximálního užitku a úspory času na obou stranách.
2. Přemýšlejte proč danou aktivitu děláte
Zaměřte se na výstupy z dané aktivity. Možná to zní jednoduše a u některých aktivit jakými jsou například wireframy tomu tak skutečně je. U nich snadno vymyslíme mnoho způsobů, jak nám mohou v procesu designu pomoci. Lze je použít pro uživatelské testování, určitě je vhodné je také použít pro komunikaci se klientem a jejich případné schválení. A v neposlední řadě poslouží jako základ pro vizuální design.
Pak jsou ale aktivity, u kterých to není tak jednoduché. Jednou z nich jsou proto-persony neboli archetypální uživatelé bez výzkumu. Jejich tvorba je časově velmi náročná a pokud nechceme skončit pouze s jejich pověšením na zeď, které sice vypadá cool, ale velice pravděpodobně nám to příliš nepřinese jak v designovém, tak ve vývojovém procesu, je důležité promyslet jejich další využití předem. A to se bavíme o proto-personách, pokud ale strávíte desítky až stovky hodin výzkumem na tvorbě person, pak by to jíž bylo extrémní plýtvání zdroji.
Uvedu opět příklad z projektu na zelené louce, na kterém jsme se spolu-podíleli. Jednalo se o mobilní aplikaci pro správu osobních financí. Pilot byl určen pro Velkou Británii. Celý projekt jsme začali právě u proto-person a jediné na čem byly založené, byly statistické údaje od Bank of England.
Demografické údaje mohou být určitě užitečné, ale mnohem důležitější jsou zejména její potřeby (zařídit bydlení), překážky (žádné úspory), existující alternativy (např. 100% hypotéka) a očekávaný výsledek (nový domov).
Jak tyto data využít? Můžeme je například použít pro formulaci hypotéz.
Souhrn existujících alternativ i výsledků od jednotlivých proto-person, můžeme přímo použít ve stejně pojmenovaných částech Lean Canvasu, který nám pomůže s definováním business modelu.
Pokud by vás to zajímalo podrobněji, určitě doporučím knihu Value Proposition Design, která velmi hezky rozebírá podobný proces od definice business modelu, až po jeho ověřování.
3. Zákazníka zapojte, co nejdříve
Můj poslední tip z oblasti UX se může zdát opět vcelku logický. Myslím si ale, že i zde je mnoho prostoru pro zlepšení. V Blueberry se nám osvědčilo zapojit zákazníka do procesu co nejdříve (o tom se více můžete dočíst v článku Jirky Brhla). Činíme tak formou workshopu, který následuje prakticky ihned po prvotním kick off meetingu s klientem. Často do tohoto workshopu s klientem zapojujeme Design Studio, což je kolaborativní metoda, která efektivně využívá práci jednotlivců i skupin spolu se zpětnou vazbou.
Mějte ale na paměti, že ji nemůžete použít s každým klientem. Pokud vám na workshop dorazí skupina velmi korporátních businessmanů, pravděpodobně jim nemůžete dát do ruky tužku a papír a očekávat aktivní zapojení. V takových případech lze potom najít u klienta zástupce, který bude mít zájem vzít si workshop na starost.
Začátky jako Product Owner
Na počátku kariéry jsem měl technické znalosti. Pozice UX designéra mi poté dala možnost nejenom poznat, jak se uživatelé chovají, ale i navrhovat produkty založené na zpětné vazbě od uživatelů. Jediné, co mi tedy chybělo, abych se mohl stát Product Ownerem, byly znalosti z oblasti businessu. Ty si postupně rozvíjím, ale jak mi jistě dáte za pravdu, je to nikdy nekončící proces. Rád bych vám zde alespoň uvedl dva příklady z praxe, jak aplikuji své designerské dovednosti v roli Product Ownera.
User Story vs. Job Story
Například člověk s designérským myšlením a neustálou potřebou ptát se proč, začne redesignovat postupy a metody. Když jsem vytvářel svou první User Story, měl jsem s ní značné potíže. Nerozuměl jsem příliš tomu, proč se pořád píše as a user, as a proxy server, stále dokola. Až jsem objevil jednoduché vylepšení formátu, které odstraňuje některé nedostatky User Stories, ale zachovává jejich výhody.
Tím vylepšením jsou Job Stories, které na rozdíl od User Stories omezují počet domněnek a ty nahrazují za určení situace a motivace pro dosažení určitého cíle. Zkuste si to, mně se to osvědčilo. Pokud vás zajímají podrobnosti, doporučuji vám článek od Alana Klementa Replacing the User Story with Job Story.
Definujeme MVP featury
Druhým problém, kterému jsem jako Product Owner čelil, byla mýtická zkratka MVP. Když ji vidím, automaticky se mi v hlavě rozsvítí varovné světlo. V čem je podle mě problém? Ten se ukrývá ve slově Viable neboli česky života schopný. Tohle konkrétní slovo je zdrojem četných nepochopení celého výrazu Minimum Viable Product. Setkal jsem se s tím na mnoha různých frontách, jak u klientů, tak v našich interních projektech. Definování MVP neznamená, že z našeho vysněného produktu ořežeme všechno to, co dělá produkt produktem. Jelikož když takto ořezaný produkt představíme veřejnosti, nezjistíme, zdali je opravdu života schopný.
Uvedu příklad. Pokud je našim produktem hamburger, a teď myslím opravdu vymazlený šťavnatý kousek, pořádně napěchovaný, MVP verzí by pak byl menší hamburger, který nemá úplně vše, co ten vymazlený, ale je to stále hamburger. Jestliže v tomto případě nabídneme potenciálním zákazníkům housku, dost dobře neověříme, zda existuje dostatečná poptávka po tomto typu produktu (tedy po obyčejném hamburgeru, ze kterého se později může stát ten šťavnatý). Stejně tak pokud svou MVP variantu budeme rozdávat zcela zdarma, dost těžce ověříme, zda nám jednou někdo bude ochoten za hamburger platit.
Videozáznam z mé prezentace si můžete prohlédnout zde.
