Design mezi agilními kameny

Agilní způsob řízení se osvědčuje, přináší výsledky a začíná být pomalu standardem, že se ve firmách uplatňuje nejen pro vývoj software. Nejen my designéři se tedy neustále učíme, jak být efektivním kolečkem v takovém soukolí.

Na Agile se mi líbí ta dynamika, neustále řešení, spolupráce v týmu a možnost se rychle poučit. A to i přes to, že to někdy není jednoduché.

Různá nastavení, různý přístup

Občas na různých místech zaslechnu, jak by měl designér fungovat v Agile. Například slýchám, že:

Designéři nestíhají dodávat.
Vše se dělá hodně narychlo a vše není dokonale vyřešené.
Není prostor rozmýšlet vizi.

Většinu své designérské „kariéry“ jsem strávil v Agile a s něčím podobným se občas také potýkal. Například jsem si zkusil vývoj řízený pomocí:

Kanbanu,
Milníků, které byly dělené do 14denních sprintů Scrumu,
Dual-Track Scrum,
Kombinaci Scrum a Lean (takový pokus, dodnes vlastně nevím, co to bylo).

Všechny přístupy se od sebe samozřejmě liší. Někdy má designér více prostoru na vymýšlení, někdy musí rychleji dodávat a s týmem hledat kompromisy. Samozřejmě záleží i na tom, jak je daný přístup uchopen a jak v něm lidé fungují.

Jak tedy může role designéra v různých přístupech fungovat? Zkusil jsem se nad tím trochu zamyslet na třech příkladech.

Dělení milníků do Scrum sprintů

Základem je plánování a příprava větších celků (milníků). Ty jsou založené na Byznysové a Produktové Discovery – co zákazníci potřebují a proč způsobem, aby na sebe vše smyslupně navazovalo.

Jako designér jsem se zapojil víceméně od začátku a dělal návrhy na naplánované věci (řešené problémy), například ve formě Jobs to be done.

Milníky jsem diskutoval s Product Managery a Product Ownery. A díky plánům jsem měl:

Dostatek času na Design Discovery.
Prostor na rozmýšlení vize.
Možnost být a spolupracovat s týmem.

Milníky přináší do vývoje dlouhodobější plán na rozvoj produktu. V podstatě fungují jako „specifikace”, co by se mělo řešit. Designér a Product Manager připraví zadání, které postupně předávají do vývoje.

Nejen že jsem připravoval návrhy, ale také jsem aktivně spolupracoval s týmem, který řešení vyráběl, aby vše pochopil a dalo se vše rozumně vyrobit.

Na tomto přístupu se mi líbilo, že jsem:

Měl dost času na přípravu návrhu a řešení.
Hodně spolupracoval na přípravě, ale také exekuci.
Byl hodně s týmem a pomáhal plánovanou hodnotu doručit.

Zároveň měl tento přístup na design jisté dopady, například:

Abychom vše rozmysleli (i v souvilosti s dalšími milníky), dělali jsme řešení více ze široka a dost práce šlo do šuplíku.
Jako designéři jsme nebyli zapojeni do všeho byznysového a neměli jsme tak plný kontext.

Vývoj produktu se tak fázoval do částí, které se postupně dávaly zákazníkům. Což mohlo být během týdnů, ale i měsíců. Což mně osobně přišlo někdy až příliš dlouho.

Dual-Track Scrum

Jako designér jsem vždycky chtěl neustále řešit, jak produkt zlepšit, aby lidem přinesl určitou hodnotu co nejrychleji. V tom se mi právě hrozně líbí Dual-Track přístup.

Místo velkého plánování jsme před sebou měli konkrétní a měřitelný cíl – například zvýšit nějakou metriku. Pomocí soustavné Discovery jsme pak hledali smysluplná řešení, abychom cíle dostáhli.

Jako designér jsem byl hodně aktivně zapojen do Discovery. Například jsem:

Pomáhal hledat příležitosti.
Ověřoval různé nápady a hypotézy.
S týmem neustále komunikoval a hledal způsoby, jak nalezené příležitosti vyrobit.

Dual-Track Scrum je hodně dynamický způsob, který je založený na neustálé Discovery, která slouží pro rychlé a neustále zvyšování hodnoty produktu.

Hodně jsme tedy experimentovali. A často jsem byl ponořen v datech nebo uživatelském výzkumu – z čehož jsem poté čerpal inspiraci a nápady pro návrhy řešení (i když ne vše vždy fungovalo).

Líbilo se mi, že jsem:

Byl neustále v kontaktu s celým týmem, zákazníky a obchodníky.
Neustále zkoumal různé možnosti.
Iteroval mnoho napadů a možností.

Zároveň jsem ale neměl tolik prostoru na Design Discovery nebo rozmýšlení vize. Všichni jsme byli zaměření primárně na náš cíl.

Kombinace Lean a Scrum

Jako designér jsem hodně úzce spolupracoval především s vývojem. Dostávali jsme věci k řešení v rámci naplánovaných sprintů, občas jsem některé větší věci řešil s předstihem. Ale do byznys Discovery jsem nebyl téměř vůbec zapojen.

Typicky to vypadalo tak, že:

Product Manager na plánování představil User Story, které by rád vyřešil.
Tým je s velkým „polštářem“ odhadl na základě diskuze.

A stories se pak zahrnuly do sprintu, kde jsme je pak řešili.

Tento přístup mi příliš nevyhovoval, osobně jej vnímám jako špatný způsob řízení ze strany Produktu. Nicméně designér tráví hodně času pod časovým presem a musí dodávat řešení, aby vývoj zbytečně nebrzdil.

Jako designér jsem pak primárně pomáhal řešit, jak:

Bude vypadat uživatelské rozhraní.
Využít existujících možností a realizovat požadovanou User Story.

Samozřejmě si myslím, že podobný způsob není zrovna šťastný – vývoj trpěl tím, že dost věcí nebylo připravených a nemohli je tak správně odhadnout. Sprinty se tedy nestíhaly a dost věcí se muselo „osekat”. (Upřímně, Product Manager z mého pohledu vývoj neuřídil.)

Role designéra

Pro vývoj produktů a služeb se dá využít různých způsobů. Například ty, které jsem popisoval výše a u kterých jsem byl jako designér v odlišných rolích.

Lidé se dnes na design dívají z různých úhlů, pro někoho je to způsob, jak vyřešit nějaký problém nebo jak udělat něco hezké. Nevnímají to tak pouze lidé mimo obor, ale i sami designéři. (Což není špatně, design je prostě hodně široký pojem.)

Ona se od toho pak často může odvíjet naše pozice (nebo spíš role), kterou jako designéři máme. Tedy zda například:

Pomáháme definovat jednotlivé problémy, které se mají řešit a řešení navrhujeme.
Dostáváme určité zadání problémů, pro které budeme tvořit návrhy řešení.
Máme pouze kreslit obdélníky pro již připravené User Story.

I když víme, že design často není jen o kreslení boxíků, spousta lidí to tak má a nepřipadá jim tedy důležité (nebo smysluplné), aby se designér zapojil do Discovery a pomáhal s definicí produktu. Je to ale pro designéra to pravé a bude využit jeho potenciál?

Jako designér jsem v rámci Discovery zkoumal drobnosti, které měly přispět k lepšímu používání produktu, ale i větší koncepty, které značně měnily jeho fungování.

Osobně si myslím, že jako designéři můžeme s Discovery hodně pomoct. Z vlastní zkušenosti mohu říct, že můžeme přinést spoustu zajímavých a neotřelých nápadů, které produkt hodně posunou.

Zároveň i designový proces má svá specifika. Designér bude potřebovat:

Čas, aby mu nápady uzrály.
Zkoumat více možností, ze kterých se bude moct vybírát.

Nebo se někdy bude muset umět rozhodnout a prostě to zkusit.

V tom samozřejmě hrají velkou roli schopnosti, zkušenosti a vyzrálost. V Agile hodně pomůže, pokud například:

Mám zkušenost s různými přístupy.
Si umím dobře organizovat práci.
Se nebojím rozhodovat a proaktivně přistupovat k řešení.
Umí přijmout fakt, že nemůže být vše hned dokonalé.

Podle mě bychom to měli řešit z pohledu samotného designéra a ptát se, zda:

Se chce do zkoumání problému zapojit.
Je schopen řešit to, co po něm chceme a co od něj očekáváme.
Má s tím, co od něj očekáváme, dost zkušeností.
Baví ho způsob, jakým pracuje (a má pracovat).

A v neposlední řadě, zda na to má vůbec prostor. V Agile je totiž potřeba nelenit a někdy trochu víc „máknout”.

Designér zvládne hodně, ale bude to něco stát

Designový proces má svá specifika. Už jsem se několikrát zamýšlel nad tím, jak v designu postupuji. Například jsem se zamýšlel, jak se snažím zapojovat ostatní do přípravy, proč je výzkum důležitá součást designového procesu nebo proč se snažím vyhrazovat omezený čas na řešení.

Můžeme využít různé postupy, ale bue se to lišit podle toho, co řešíme, s kým a v jakém stavu aktuálně jsme. Abychom tedy svou kapacitu využili co nejlépe, měli bychom brát v potaz několik faktorů.

Kolik vývojářů na jednoho designéra?

Společnosti se snaží své designéry samozřejmě efektivně využít, ale zbytečně nepřetěžovat. Některé proto přemýšlí v intencích poměru počtu vývojářů na designéra – třeba aby na jednoho designéra nebylo více než 10 vývojářů.

Některé věci lze poměrně rychle realizovat, někdy je potřeba trochu víc času. A představte si, že byste měli navrhovat pro týmy s 200 vývojáři. Podle mě tím musí design docela utrpět, protože nebudeme:

U všech věcí, které se řeší – protože by vývoj mohl „blokovat”, lidé si to raději vyřeší po svém.
Mít dost času promyslet všechny možnosti a přijali bychom tak spoustu zbytečných kompromisů.

Protože jsem si zkusil práci i ve větším týmu, dává mi to smysl. Jenže to podle mě není pouze o počtu vývojářů. V týmu hraje velkou roli například i to:

V jak vyspělém a sehraném týmu designér působí.
Jak seniorní lidé v týmu jsou.
S čím a jak daný tým pracuje (některé pokročilejší věci prostě trvají dlouho).

Zažil jsem si, že menší tým složený z fakt dobrých programátorů mi dával někdy mnohem více „zabrat“ než větší tým, ve kterém bylo pár juniorů nebo „komplexnější“ technologie.

Problém je potřeba pochopit

Abychom mohli doručovat kvalitní návrhy, vidím důležité i to, v kolika doménách jako designéři působíme, tedy zda řešíme:

Pouze jednu věc – např. nahrávání dát nebo hledání práce?
Více souvisejících věci – např. nahrávání dát a jejich zpracování nebo analýzu?
Více nesouvisejících věci – např. správu náborového procesu a vzdělávání lidí?

Jak už jsem zmínil, design není jen o hezky nakreslených obdelnících. Může to být o tom, aby řešení dobře fungovalo. Pro což je potřeba pochopit daný problém a mnohdy vyzkoušet spoustu možností a nápadů. Takže je potřeba, aby designér:

Strávil v dané problematice danou dobu.
Měl prostor vše nasát a využít.
Vyzkoušet alespoň nějaké nápady a postupy.

A hlavně zapojit kreativitu, získal dostatek empatie a tu poté uplatňoval. Což při mnoha řešených problémech bude velice složité a zdlouhavé.

V jednom týmu se to lépe táhne

Můžeme být součástí různorodých týmů a řešit více věci. Co kdybychom ale byli součástí více týmů nebo dokonce i v různých rolích?

Sám jsem si například vyzkoušel, jaké je to pracovat na:

Jednom produktu s jedním týmem – nejen jako designér, ale i jako Product Owner.
Na více produktech v rámci jedné domény s jedním týmem.
Na více produktech v rámci různých domén s více týmy.

Když si to vezmu, práce v agile je hodně o spolupráci a „týmovém žití“ (nebo rituálech, jak občas někdo řekne). Zkuste si představit, že byste měli:

Chodit na X stand-upů, retrospektiv nebo groomingů.
Být týmům neustále při ruce, pokud bude něco potřeba dořešit.
Probírat různá řešení s různými lidmi.
Dělat neustálou Discovery příležitostí.

A tak dále.

Lidé si mnohdy neuvědomí, že by to mohlo být problematické (zvlášť ti, kteří nemají s designem zkušenosti). Podobná nastavení na designéra vytváří docela velký tlak a snižují tak prostor na skutečně dobře odvedenou práci.

Sám jsem si to zkusil a jde to zvládnout – víceméně stačí zatnout zuby a makat. Jenže to si dříve nebo později si to vybere svou daň. Například:

Designér může snadno vyhořet (sám jsem byl už 2× na hraně).
Kvalita designu nebude taková, protože designér nebude u všeho.
Spolupráce v rámci týmu nebude tak efektivní, protože nebudou zde vybudované vztahy, důvěra, atd.

A když designér stíhat, bude muset někde ubrat. Což ostatní těžce ponesou a s velkou pravděpodobností budou problém eskalovat a řešit – jako chybu designéra.

Mně osobně nejvíc bavilo a fungovalo, když jsem byl součástí jednoho týmu a mohl se věnovat jedné problematice, protože:

Jsem si mohl s týmem vybudovat určité vztahy.
Chápal jsem řešenou problematiku a postupem času jsem byl efektivnější.
Přinášel jsem (nejen podle mě) zajímavé nápady na řešení.

I přes to, že se možná opakuji, to musím zmínit – nejen design v Agile je podle mě týmová hra a tahání za jeden provaz. A opravdu hodně záleží na tom,
s kým tu hru hrajeme.

Je to o lidech

Jsem opravdu rád s kým jsem mohl doposud spolupracovat (až na pár výjimek). Šlo o super lidi nejen po profesní stránce, ale i osobní. Mohl jsem se o ně opřít, pomáhali jsme si a fungovali opravdu jako tým.

V Agile je to hodně důležité. Podle mě rozhodně víc, než kolik umíme klávesových zkratek ve Sketch. Budeme totiž potřebovat:

Efektivně spolupracovat a komunikovat s ostatními.
Být dostatečně proaktivní.
Vybudovat porozumění a souhru.

A tak podobně.

Jako designér často něco řeším s ostatními lidmi. Například s:

Product Managerem se bavím o tom, co řešíme a proč.
Vývojáří zkoumáme, co můžeme udělat a jaké jsou možnosti.
Ptám se ostatních designérů na jejich názor, abych měl i další pohled.

Zároveň ostatní lidé mají svou zodpovědnost, roli a podle toho se samozřejmě chovají. Velkou roli v tom hraje i jejich osobnost, zkušenosti, atp. Zažil jsem například lidi, kteří:

Měli jasnou představu o tom, jak mělo řešení vypadat a kteří si přesně řekli, co chtějí, aniž by dali prostor ostatním vyjádřit svůj názor.
Rádi ostatní zapojili a dali ostatním prostor se do vymýšlení řešení zapojit.

Od čehož se pak na mě odvíjeli požadavky – někdy jsem prostě jen kreslil boxíky, někdy jsem ale pomáhal určovat směr produktu.

Jako designéra mě baví, pokud:

Se mohu účastnit tvorby zadání a pouze nekreslím obdelníky.
Mohu přinášet nápady na řešení (např. zvýšení hodnoty produktu, přínosu pro zákazníky).

Jednou jsme například řešili implementaci nové platební brány. Sedl jsem si s vývojářem Michalem, probrali jsme možnosti a přišli za Produkťákem, jak bychom to mohli udělat – a udělali jsme to tak. Měli jsme totiž od něj důvěru, že to uděláme dobře.

Jsem rád součástí toho, co se řeší – rád chápu, proč to mám řešit, pro koho a rád pomohu rozhodnout, co je důležité. A věřím, že umím přinést i zajímavé nápady, které produkt zase o kus posunou.

Vždy jsem se ozval, pokud mi něco nedávalo smysl nebo nevyhovovalo. Třeba to, jak moc jsem byl (nebo nebyl) zapojen do vymýšlení a proč bych se chtěl zapojit. Někdo to přijal a více mě zapojil, někdo mi ten prostor dát nechtěl.

Můžeme fungovat v prostředí, kde nám to moc nevyhovuje? Může to podle mě uškodit nejen nám (a časem to asi vzdáme), ale bude to mít dopady i na tým a produkt, na kterém pracujeme – z čehož pak utrpí akorát lidé, pro které to děláme.

Je potřeba se v týmu respektovat a důvěřovat si. Sám mám problém pracovat s lidmi, kterým nemohu věřit nebo které je těžké z různých důvodů respektovat. Někdy je ale potřeba si důvěru a respekt vybudovat, k čemuž je potřeba trávit čas s týmem a efektivně řešit svěřené úkoly.

Poznámka: zároveň si musíme uvědomit, že vždy jako designéři budeme pod palbou kritiky – jak by šlo něco vyřešit, jak moc mají být dané věci modré, atp. A je naší úlohou, abychom našli společnou shodu.

Chce to čas

Moc si nedokáži představit, že bych měl dnes fungovat jinak než v Agile. Jak jsem se již zmínil, líbí se mi ta dynamika, potřeba spolupráce a že se i poměrně rychle dozvíme, co příště udělat lépe.

Myslím si, že se dá zvládnout jakýkoliv přístup. Ať už už je to Scrum nebo Kanban, zda řešíme 1 nebo 10 produktů a nebo zda děláme pro více týmů. Vše má svá pro a proti a hodně záleží na tom, co od designu a designéra chceme a očekáváme a v čem je designér schopen a ochoten fungovat.

Ať už tedy děláme v jakýkoliv podmínkách, měli bychom přijmout fakt, že vše nebude hned perfektní a že se budeme muset rozhodovat, co je pro nás důležité – zda chceme vše vypiplat do posledního detailu a nebo lidem doručovat hodnotu a hledat příležitosti pro zlepšení.

Vždy to bude chtít čas, abychom si našli to, co nám vyhovuje a funguje. Myslím si, že pokud něco skřípe, měli bychom to probrat se svým týmem a snažit se najít vhodné řešení. Agile je prostě týmová hra a mělo by to fungovat po všech stránkách.