V 2FRESH se věnujeme produktovému designu a navrhujeme weby, aplikace, zákaznické portály nebo třeba nemocniční informační systémy. A v našem podcastu si povídáme s produktovými a designovými lídry o tom, jak funguje design u nich ve firmách. Povídáme si hodně o tom, jak design může pomáhat byznysu. Snažíme se najít nějakou inspiraci v tom, co funguje a nefunguje.

Ahoj, vítejte u dalšího dílu našeho 2Fresh Design Podcastu. Dnes si budu povídat s Honzou Tomanem ze Supernovy o budoucnosti designu, a především o tom, jak u nich v praxi funguje koncept "Designers Who Ship" – tedy designéři, kteří nekončí ve Figmě, ale často zasahují i do implementace. Protože tohle je teď asi nejžhavější téma mezi designovými a produktovými lídry.

Honzo, ahoj.

Ahoj, Kubo. Díky za pozvání.

Já děkuji, že jsi k nám dorazil. Ty máš za sebou pestrou kariéru – prošel jsi firmami se zvučnými jmény jako Livesport, Kiwi, ProductBoard, teď jsi Director of Design v Supernově, ale začínal jsi jako vývojář. Uděláš nám rychlý úvod? Jaký je tvůj background a co vlastně dělá Supernova?

Jasně. Mám za sebou přibližně dvacet let v profesionální kariéře. Nikdy jsem neuměl kreslit, takže design jsem původně neviděl jako cestu pro sebe. I protože školy v Česku tehdy digitální design moc nepodporovaly – byl to hlavně o umění a kresbách. Já umím maximálně něco načrtnout na whiteboard, ale tam to končí.

Začal jsem se věnovat frontendovému vývoji a přes deset let jsem pracoval jako frontendový vývojář a vedl týmy. Postupně jsem ale začal být frustrovaný z toho, že jsme byli poslední v celém procesu. Všechno k nám padalo se zpožděním, a pak jsme to doháněli za celý řetězec. Řekl jsem si, že to musí jít dělat lépe.

Bylo mi kolem 25–28 let a procházel jsem si takovou fází, kdy jsem si myslel: "Já ty věci umím udělat líp než všichni ostatní." Šel jsem tedy do projektového a produktového managementu v mediálním průmyslu, konkrétně v Czech News Centru, kde jsem strávil asi deset let.

Tato změna mi dala šanci změnit perspektivu, za což jsem velmi vděčný. Ze seniorního vývojáře jsem se najednou stal absolutním začátečníkem v produktu a projektovém managementu. Když jsme pracovali na projektech, komunikovali jsme s uživateli těch produktů – stavěli jsme fantasy hry pro různé sporty, takže jsme komunikovali s hráči.

Zjistil jsem, že nevím, jak se jich správně ptát, jak z nich dostat informace o jejich potřebách, jak formulovat otázky. Hledal jsem zdroje a objevil jsem, že existuje něco jako UX a že bych se do toho chtěl víc ponořit. Přihlásil jsem se do UX Well, který byl tehdy ještě asociace Akademie UX.

Byl to roční program, kde jsme prošli celým oborem UX – od výzkumu, workshopů, facilitace, UI designu, přes prototypování až po další oblasti. Dostal jsem skvělý přehled o tom, co v oboru existuje, takže jsem si mohl vybrat, co mě baví víc a co míň, a přišel jsem k designu.

Vždycky jsem měl problém se rozhodnout, jestli chci dělat vývoj, produkt nebo design, takže jsem dělal všechno na přeskáčku. Pak se objevily design systémy, které potřebují generalisty – lidi, kteří jsou dobří ve všem. Často nedostávají vlastní produktové manažery, takže tuto část musíme dělat jako designéři nebo vývojáři. Mohl jsem si vyzkoušet všechno.

V Kiwi.com jsem se věnoval design systémům, předtím jsem měl zastávku v Livesportu, pak jsem šel do ProductBoardu řešit design systémy a dnes v Supernově stavíme produkt na automatizaci a dokumentaci design systémů.

Je zajímavé, že jsem z člověka, který staví design systémy a komunikuje s interními designéry a vývojáři, přešel na metu pozici – teď stavíme nástroj pro tvorbu design systémů.

Možná ne všichni ví, co je Supernova.

Supernova je firma, která existuje asi 6–7 let. Byla jednou z prvních v Y Combinatoru. Původně to byl nástroj na konverzi design souborů ze Sketche do kódu pro mobilní aplikace. Jenže technologie před 6–7 lety nebyla tam, kde je dnes s AI a generováním kódu, takže trh byl komplikovanější. Proto firma kompletně pivotovala do nového B2B produktu zaměřeného na dokumentaci design systémů.

To je hlavní důvod, proč k nám firmy chodí. Můžou si napojit Figma soubory s jejich design tokeny, komponentami, ikonami a podobně, a pak je nejen dokumentovat, ale i automaticky konvertovat do kódu. Aspoň některé věci – komponenty ještě ne, ale design tokeny a ikony už umíme konvertovat do Tailwindu, CSS nebo třeba ikony do React komponent. Tohle už funguje docela dobře a spousta týmů nám za to platí.

V Supernově jsem začínal jako konzultant a advisor, pomáhal jsem s pivotem do světa design systémů. Asi před třemi lety jsem se přidal full–time jako staff designer a dnes vedu jak designový, tak produktový tým. Společně s CEO řídíme produktovou roadmapu a rozhodujeme o dalším směřování firmy.

Jak vlastně vypadá váš produktový tým? Supernova je česká firma nebo má české kořeny, což mi přijde zajímavé – že tady vznikají technologicky zajímavé věci, které ovlivňují designový obor. Jak je Supernova dnes velká a jak vypadá ten produktový a designový tým?

Ano, Supernova je česká firma, i když oficiální sídlo je v Americe kvůli Y Combinatoru – musela to být americká firma, aby mohla do programu vstoupit. Celkově nás je asi třicet. Jsme hodně remote, máme pár lidí v Praze, máme i kanceláře na Invalidovně, kde se občas scházíme, ale většina týmu pracuje vzdáleně. Máme lidi v Holandsku, náš founder a CEO Jirka je občas v San Franciscu, další jsou v různých koutech Evropy, v Polsku a tak dále.

Produktová organizace – produkt, design a engineering – tvoří zhruba polovinu firmy. V produktu a designu jsme čtyři. Máme tři formální produktové týmy, dva produktové designéry, jednoho design engineera a pak máme ještě jeden ad hoc tým pro random nápady, který je trochu mimo proces.

Tento speciální tým existuje proto, že spousta z nás jsou velmi techničtí lidé schopní vyvíjet. Máme spoustu nápadů a říkáme si: "Proč to nezkusit?" Často z těchto ad hoc nápadů vzniknou malé funkce v produktu nebo zajímavé prototypy a koncepty, na kterých můžeme dál pracovat. Ten tým stranou je taková kulturní věc Supernovy – myslím, že tam bude existovat vždycky, bez ohledu na to, jak moc vyrosteme.

Lidé chtějí hodně experimentovat, zkoušet inovace a nečekají nutně na proces a naplánované roadmapy. Inženýrů máme asi dvanáct až patnáct – backend, frontend, QA.

Takže ten poměr máte docela dobře vyvážený, což je asi i povahou firmy, že se věnujete design systémům.

Přesně tak. A také tím, že naší hlavní cílovou skupinou jsou designéři. Hodně nám záleží na tom, aby nástroj vypadal dobře a aby se dobře používal. To by sice mohla říct každá firma, ale ne vždycky to tak v praxi doopravdy funguje.

Těším se, že se podíváme na to, jak přesně pracujete, jaké máte procesy a nastavení. Je mi blízké, že jsi původem vývojář – já jsem také začínal jako vývojář a oba nás přitáhl design. To rozhodně není ojedinělý příběh. Myslím, že v dnešní době, kdy se budeme bavit o tom, o čem se budeme bavit, je to velmi dobrý background. Člověk rozumí konceptům, jak funguje architektura systémů, a i když jsem třeba já od toho už hodně daleko, pořád mi přijde, že o tom člověk dokáže relativně dobře přemýšlet. Má kontext, který se hodí. Myslím, že pro některé designéry to dnes bude výzva.

Ještě jsem chtěl zmínit, když jsi mluvil o UX Well – chtěl bych udělat reklamu Petrovi Štědrému, protože podle mě je to skvělý vzdělávací program. Vždycky když se bavíme s designérem nebo designovým lídrem, který tímto programem prošel, je to pro nás známka kvality. Když se k nám hlásí designer, který prošel UX Well, víme, že je to dobrý kandidát. A když se bavíme s lídry produktových nebo designových týmů, kteří tím prošli, velmi dobře si rozumíme. Chtějí dělat design dobře. Petr to dělá opravdu dobře.

Souhlasím. Myslím, že v Česku není nic podobného. Petr je člověk z praxe, jsou tam lidé z praxe, což tomu dává obrovskou hodnotu.

Tak pojďme teď na to, jak u vás pracujete. Popiš nám, jak přesně funguje váš designový a produktový proces a jakou roli v něm hrají designéři.

Rád bych se zaměřil na delivery část našeho procesu, pak se můžeme dotknout discovery fáze. Pojďme se bavit o tom, že máme designéry, kteří se nebojí vyvíjet – to je pro nás teď zajímavější.

Řekněme, že máme projekt s určitými požadavky. První fáze je, že se potkáme – já, CEO, designer a CTO kvůli technické expertize. Bavíme se o tom, co od produktu očekáváme – obchodní cíle, které chceme dosáhnout, ale také architektonické aspekty. Některé věci v produktu se nesmí změnit, musíme pracovat s určitými proměnnými nebo konstantami. To probereme v této menší skupině.

Pak má designer čas na prototypování. Začne vytvářet různá řešení a nápady. Následuje několik iterací čistě v design týmu, kde si to hodně procházíme mezi sebou. Protože jsem velmi integrovaný do design týmu a jsme malí, funguju i jako stakeholder. Dokážu formovat směr podle toho, co potřebujeme jako byznys.

Každý týden máme dvě designové kritiky, což nám dává spoustu prostoru pro diskuzi. Obvykle to trvá hodinu až hodinu a čtvrt, často přetáhneme. Je to pro nás strašně důležitý element naší designové kultury. Protože jsme remote, potkáváme se jen na callech, a právě designová kritika, kdy se bavíme o designu, je klíčová součást naší práce.

Někdy se stane, že nemáme téma – jsme ve fázi projektů, kdy se buď vyvíjí, nebo testuje, a připravujeme se na další projekty. V takových případech uděláme kritiku cizí aplikace. Je spousta hezkých a zajímavých aplikací. Můžu zmínit Figmu, Linear nebo onboarding různých aplikací. Díváme se, co se z nich můžeme naučit, co je tam zajímavé, co by nás zaujalo.

Například když řešíme members management – pozvánky a změny rolí – podíváme se, jak to řeší různé nástroje, a bavíme se o tom v týmu. To je velmi zajímavý aspekt. Minulý týden jsme se dívali na aplikaci, kterou nikdo z nás moc nepoužívá, kromě mě. Je to jako Vercel, ale pro deployment PHP aplikací na servery.

Zaujaly mě tam nějaké designové detaily a chtěl jsem je ukázat týmu – jak o nich přemýšlejí, protože hledáme paralely a analogie, jak bychom je mohli použít v našem produktu. To je super, protože to působí jako inspirativní element pro tým. A protože se lidé nebojí dotknout kódu a otevřít PR na GitHubu, často říkají: "Zkusil jsem proof of concept této věci. Co si o tom myslíte?" Je to implementované přímo v našem produktu – možná ne perfektně a možná to není ještě produkční kvalita, ale můžeme si to osahat a vidět, jestli to bude fungovat.

Druhá věc je náš "report frustration channel", který do toho také zapadá. Používáme náš vlastní produkt, což je velmi důležitá část naší práce. Vidíme, kde jsou věci, které nám nesedí – něco trvá moc dlouho, něco chce moc kliků.

Často jsme to reportovali jako bugy, ale v prioritizaci to pak spadne někam do backlogu a nikdo to moc neřeší. Tak jsme si vytvořili vlastní větev a říkáme tomu "frustrations". Prostě tam reportujeme – většinou designer napíše: "Tohle mě frustruje" nebo "Tohle jsem viděl na Fullstory, pojďme se na to zaměřit." Někdo z nás to většinou vezme a fixujeme nebo upravíme, aby to fungovalo lépe. To je první fáze prototypování, která je hodně iterativní.

Zaujalo mě, že si děláte designovou kritiku jako inspiraci. Obvykle designéři dělají rešerši, když dostanou zadání – projdou Dribbble, nebo možná už dnes ne Dribbble, ale různé nástroje, konkurenci a hledají inspiraci. Vždycky jsem o tom slyšel v souvislosti s tím, že jdu něco budovat a na konkrétní věc hledám konkrétní věci.

Tohle mi přijde, že tím trošku tříbíte vkus lidí, tříbíte produktové přemýšlení, přinášíte inspiraci. To mi přijde fakt zajímavé. Díky za sdílení, protože to jsem nikde ještě nezaznamenal. Těším se, že se podíváme i blíž k tomu, co jsi zmiňoval – že se designéři nebojí dotknout kódu, že ty frustrations, které by vám zapadly v backlogu, se sami pokusíte opravit.

Rád bych se vrátil k tomu, co jsi říkal o vytříbení vkusu. Přesně proto jsme to zavedli. Bavíme se nejen v našem týmu, ale v celé komunitě o konceptu kvality. Co je vlastně kvalita? Čím je definovaná? Je to strašně abstraktní koncept.

Pro mě jsou designéři ambasadoři kvality. Pokud má někdo tlačit na všechny ve firmě, že věci mají být lepší, tak to má jít od nás. A postupně to učit všechny ostatní, že na tom záleží.

Pro mě jako designového lídra je strašně důležité, abychom byli v týmu vyladění na tom, co vnímáme jako kvalitu. Právě tyto momenty na kritice – ukazování a rozebírání jiných aplikací, které jsme nedesignovali, o kterých jsme víc odpojení (není tam ta emoční rovina) – nám pomáhají vytříbit si, které patterny jsou zajímavé a které ne pro to, co děláme.

Měli jsme nějakou dobu zpátky off–site v Lisabonu s design týmem a já jsem tam měl prezentaci o různých aplikacích, které používám – i B2C aplikací. Mám zvyk zkoušet spoustu nových aplikací a hledat zajímavé věci. Dal jsem tam asi 15 příkladů zajímavě řešených věcí. Byly často vytržené z kontextu – něco v settings nebo při vytváření eventu v kalendáři. Ani nebyly nutně použitelné pro náš kontext, ale byla to ukázka toho, že se nad tím někdo zamyslel. Bylo to o tom designovém kraftu.

Pro mě je to důležitá část experience. Takže bych dodal, že je to přesně pro to, abychom si vyladili vkus. Abychom v týmu měli benchmark toho, co vnímáme jako dobrý design, i když to samozřejmě nemusí být pro všechny stejné.

Hodně se to teď řeší s nástupem AI toolů, které ještě dnes neumějí tu kvalitu dotáhnout těch posledních 20 % – nebo možná je to víc než 20 %. Nedokážou to dotáhnout do odladěného zážitku, což je logické, jsme na začátku.

Řeší se, že jedna z důležitých věcí u designérů bude právě ten vkus – aby byli arbitři toho, co je dostatečně dobré a co není. Na tom, co říkáš, mi přijde skvělé, že tam můžeš mít klidně i juniorního designéra v týmu. Tím, že tohle nasává intenzivně a pravidelně, dokážeš mu budovat tuto schopnost, aby se i juniorní lidé dostali na úroveň sdílené kvality a vkusu týmu.

To je dobrá odpověď na otázku, co s juniory a jak s nimi pracovat v době, kdy ty juniorní práce pravděpodobně AI tooly do nějaké míry nahradí.

Ano, tohle je strašně zajímavé téma juniorů. Myslím, že se neshodujeme celkově, jak to bude, a vlastně se to nedá úplně předvídat. Budeme se bavit o budoucnosti designu a myslím, že se tohoto tématu dotkneme. Jsem zvědavý na ohlasy posluchačů, jak to vnímají oni, protože to může být velmi zajímavá diskuze.

Vrátím se ještě k tomu procesu. Máme nějakou verzi prototypu – není to velmi polished verze designu, je to spíš směr, kam bychom chtěli jít. Máme pak dvě další části v procesu, které jsou strašně důležité.

První je Project Kickoff, kde je celý tým, který na tom bude pracovat – vývojáři, designéři, QA. Projdeme si prototyp, směr, kterým to chceme tlačit dál, vydefinujeme potenciálně rizikové věci, věci, u kterých si nejsme jistí v designu. Velmi často jsou to high–fidelity interakce, u kterých si nejsme jistí, jestli budou fungovat v praxi, protože Figma prototypy jsou prostě limitované a vždycky budou limitované, dokud to výrazně nezmění.

První část našich projektů je proof of concept fáze. V rámci této fáze, která někdy trvá dva dny, někdy týden, někdy čtrnáct dní – záleží na komplexitě projektu – máme za cíl odstranit a vyjasnit všechna rizika.

Jsou to věci kolem feasibility, věci kolem dat – jestli jsme schopni vytáhnout data z Figmy, z GitHubu nebo z jiných integrací. Je to o tom dostat co nejdřív do aktuálního produktu na dev první verzi některých interakcí. Třeba výběr elementů z databáze – to se strašně blbě designuje ve Figmě, protože tam jsou data na určité úrovni, nefunguje tam search a podobně.

Protože máme hodně stabilní design systém, prototypování těchto prvních interakcí je velmi rychlé. Často se to změní – abych byl férový. V proof of conceptu zjistíme: "Tohle zabere o klik více, než bychom chtěli." Je to častá akce někde v dokumentačním editoru. Pojďme to ještě domyslet znova. I vývojáři ví: "Aha, super, tato část se bude ještě měnit, my mezitím doimplementujeme zbytek."

Tato proof of concept fáze je strašně důležitá pro všechny featury, protože je to iterativní fáze, něco, co nejsme schopni rozhodnout z Figma prototypu a potřebujeme si osahat funkcionalitu. Je to naprosto kritické pro jakoukoliv AI funkcionalitu, protože AI není stále úplně předvídatelná. Nevíme, co nám nutně vrátí za výstup. To často formuje, jak AI funkcionalita sama má fungovat, jak ji komunikujeme v UI, jak ji pozicujeme v produktu.

Myslím, že proof of concept fáze u různých AI funkcionalit je naprosto klíčová. Nedokážu si představit, že bychom bez těchto prototypů byli schopni fungovat a vůbec něco vyvinout.

My teď pracujeme pro jeden startup ze Silicon Valley, který dělá generativní AI aplikaci, a přesně tam se nedá prototypovat ve Figmě moc. Něco málo ano, ale strašně málo. Spíš potřebuješ zkuchtit prototyp v Boltu, v Loveable nebo něčem takovém, kde se to hýbe. Vidíš, že to generuje, protože přes API si napojíš AI model, pošleš tam uživatelský prompt, on ti něco vrátí, něco to vytvoří – a to ve Figmě prostě neuděláš.

Problém nástrojů jako Bolt a v0 je, že jsou ještě hodně mladé a nefungují s tvým produktem. Je to vždycky na zelené louce. Můžeš si tam něco osahat, ale pokud potřebuješ iterativní vylepšení svého produktu, jsou stále limitované.

Přesně. My tady jsme úplně na zelené louce, takže to jsou fakt proof of concept věci a spíš taková ideace, kterou dokážeš zhmotnit a zároveň ji můžeš dát někomu osahat. Ale na druhou stranu, zaplať pánbůh, že tyhle věci jsou. Kdyby nebyly, všechno by ti musel vyvinout vývojář, což může trvat násobně víc.

I když to není tak jednoduché, že by k tomu člověk sednul a řekl: "Udělej mi takovýhle prototyp" a bylo to hotové. Naši designéři se ty nástroje teď učí. Rozběhat si ty věci, pochopit integrace – je to fakt hodně práce. Včera Lukáš Pitter, náš founder, sdílel na našem interním sezení architekturu, která zatím je, a tu technologickou komplexitu. To není jednoduché.

Ale pokud do toho designer nainvestuje a naučí se ty basics, tak to začne fungovat. Navíc si myslím, že pro designéra je důležité, že vidí trochu tu architekturu a co se děje. Sám si to osahá, nepřipraví mu to jen vývojář, který pošle výsledek. Uvědomuje si: "Aha, to teď někam chodí, to trvá, není to hned." Co budeme dělat s uživatelem, když to trvá? Ten samotný zážitek stavění prototypu dokáže vylepšovat výsledný zážitek. Ovlivní designéra v tom, jak věci navrhuje.

To je strašně zajímavé, co říkáš. My všichni, co používáme ChatGPT, znáte ten moment, kdy se to postupně vypisuje na screen. Říká se tomu streaming. Nevím, jak to nutně vzniklo, ale přijde mi to jako designové řešení pro to, že generování odpovědi trvá. Člověk má pocit, že může konzumovat odpověď průběžně. Většina lidí nečte tak rychle, aby to nestihali.

U kódu je to trochu jiné, specifické. Je zajímavé to vidět z pohledu user experience – ten tok slov.

Všiml jsem si toho třeba u Grok Deep Research. Samozřejmě to vůbec nestíháš číst, ale začneš číst první nebo druhý odstavec, to tě trochu zabaví, a mezitím to proběhne a má to za minutku až dvě hotové.

U v0 a Boltu to není tak super, protože tam to generuje kód po řádcích a člověk čeká, až to vygeneruje všechno. Dokud není všechno, neumí to udělat preview, a preview je to, co nás zajímá víc než samotný kód. Ale to je otázka času, je to ve vývoji.

Pak máme další milestones v procesu, nic speciálního, možná kromě jednoho – v každém projektu trackujeme do posledního milestone po releasu něco jako "post release improvements". Během projektu se objeví spousta malých věcí a říkáme si: "Tohle by bylo fajn udělat ještě, tohle by zlepšilo experience." Ale nejde to do core featury nebo to vyškrtneme ze scopu během delivery, tak to posuneme do post release improvements.

Často se z toho transformují tikety, které jsou třeba i designéři schopni implementovat, protože jsou to malé věci – nějaký styling – ale nebyl na to čas během developmentu. To je náš proces ve zkratce – velmi kolaborativní, velmi komunikativní, s mnoha iteracemi, než se dostane do produkce.

Podíváme se teď na tu část, kde se designéři dostávají do kódu. Jak tohle u vás funguje? Na to předpokládám musíš mít nastavené prostředí. Zajímaly by mě obě oblasti – jak vypadá prostředí, ve kterém fungují, jaké nástroje k tomu potřebují, i jak to prakticky probíhá.

Zmiňoval jsi tvorbu prototypů. Zajímalo by mě, jaké nástroje na to teď používáte a jestli už jste tak daleko, že máte váš design systém v těch nástrojích nalitý. Jestli už jste schopní generovat věci ve vašich designech nebo zatím ne. Kde začít a jak to uchopit?

Začnu tím, jak se stalo, že naši designéři nemají problém nebo jsou ochotní implementovat různé věci přímo v kódu. Nespokojí se s tím, že jen vytvoří ticket pro někoho dalšího a nechají to ležet.

Jako lídr chci věřit, že to vychází z toho, co po designérech chci – velkou proaktivitu. Chci, aby byli velmi proaktivní v tom ptát se, jestli věci můžou vyřešit sami nebo jestli potřebují někoho dalšího. Aby přebírali tento typ iniciativy. V angličtině je pro to termín "high agency".

Nevím, jestli máme český překlad, takže říkám vysoká proaktivita. Neznal jsem ten pojem, než jsme se o tom bavili před natáčením. My u nás to chceme po designérech taky a říkáme tomu "designers lead the way". Myslíme tím vlastně tyhle věci.

Já to chci od všech, nejen od designérů. I když vy jste designová agentura, takže máte hlavně designéry. Rád bych, aby když vývojář vidí bug, tak ho prostě fixnul. Ať ho nenareportuje QA, které pak udělají ticket a někdo ho bude projektovat. To jsou čtyři kroky, které se nemusí stát. Pokud něco zabere pět, deset minut fixnout, tak to prostě fixněte.

Pojďme to zlepšit instantně. Ne že vytvoříme ticket, který dostane pravděpodobně malou prioritu, protože je to nějaký malý bug, a nikdy se na něj nedostane. Tohle ani nemusíme reportovat. Tenhle mindset chci i od designérů.

Když se pak člověk ptá "můžu to řešit sám?", tak typicky věci, které u nás designéři fixují, jsou třeba špatný copy. Může to být překlep, nevhodný copy, nebo jsme zjistili, že jiný copy funguje lépe než ten, co jsme původně navrhli. To nepotřebuje ticket.

Z mé zkušenosti ty tickety stejně nikdo neřeší. Za půl roku přijde design tým a říká: "Tady máme 40 ticketů na úpravu copy, pojďme je mergnout do jednoho a dáme to do nějakého sprintu." V lepším případě. Ale za ten půl rok už by všechno mohlo být fixnuté a v produkci, a uživatelé by nemuseli vidět tyto drobné problémy.

To samé platí pro fix UI bugů. Zmínil jsem, že používáme Fullstory, nahráváme sales cally. Je tam vidět spousta drobností, které třeba přehlédneme. Je snadné fixnout nějaký border radius, špatný spacing. To jsou věci, které nejsou komplikované opravit, pokud člověk trochu umí CSS a je ochotný se ho naučit.

Čím víc copy issues fixnou, čím víc malých UI issues opraví, tím víc znají codebase, aspoň její části, a tím víc jsou ochotní dělat větší věci. Třeba design systém je krásný příklad, protože je hodně separovaný. Často tam není velká logika. Člověk se nemusí bát, že rozbije login nebo velkou funkcionalitu.

Pokud fixne nějaký spacing nebo chybějící stín, nebo zjistí, že kontrast je špatný, tak to může upravit nejen ve Figmě, ale rovnou v kódu. Nemusí se bát, že něco rozbije, protože to vždycky projde procesem. Je tam code review od vývojáře, je tam QA, které to otestuje, a dostane se to do produkce, jako by to implementoval jakýkoliv jiný vývojář.

Čtvrtá kategorie jsou quality of life improvements. Třeba něco zabere zbytečný klik a ten problém nemusí existovat. Nebo je tam nějaký copy, který něco vysvětluje, možná tam nemusí být. Možná nejlepší způsob, jak fixovat copy, je jeho odstranění. To jsou věci, které se můžou dělat přímo v kódu bez čekání na prioritizaci.

Zmínil jsem, že máme v týmu design engineera Matěje. Matěj je původně brand designer, což je zajímavý kariérní příběh. Dělal bannery, landing pages, a náš web je ve Webflow, takže postupně začal víc věci fixovat přes UI, přes no–code nástroje.

Často byl frustrovaný – podle mě je to důležitý motivátor, proč by designéři mohli chtít začít věci fixovat sami – že něco není tak, jak to nadesignovali. V brandu se to vidí ještě víc, protože některé animace nefungují přesně. Odladit animace s vývojářem v tandemu často trvá déle než to udělat sám, pokud člověk ví jak.

Tak do toho začal sahat víc a víc. Dnes, po asi roční cestě hraní si s kódem ve Webflow a trochu v Reactu, je schopný vyvíjet izolovanější funkcionalit sám s podporou vývojářů.

Krásný příklad je, že jsme dlouho řešili přidání dark mode a high contrast mode pro accessibility do aplikace. Protože máme design systém, chtěli jsme ukázat lidem, jak se dá dělat advanced theming. I jako inspirace pro naše uživatele.

Aktuálně máme v produktu v settings tři políčka, kde člověk vybere barvu pozadí, barvu primary nebo accent a vybere contrast level. Na základě těchto tří hodnot vygenerujeme celý theme aplikace – light, dark, všechny kontrasty správně, všechny barvy, všechny úrovně.

Tohle je typ funkcionality, kterou vývojář, který není blízko designu, neudělá. Zároveň to designer neudělá ve Figmě, protože tam je algoritmus na počítání. A když se bavíme o proof of conceptech, tak tohle to potřebuje, protože nevíme, jestli to jde vygenerovat, jestli jsme schopní dosáhnout kvality, kterou chceme.

Matěj jednoho dne přišel na kritiku a říkal, že se na to podíval. K překvapení nás všech neotevřel Figmu ani explorace, ale localhost naší aplikace. Říkal: "Zkusil jsem to vyvinout, tady jsou ty tři barvy a celá aplikace se přebarví na černou, bílou nebo růžovou."

Všichni byli wow. Jasně, ten kód možná nebyl perfektní, museli jsme udělat iterace, než jsme to dostali do produkce. Ale bylo to dost na to, abychom si ověřili, že je to možné.

On s tím svým přístupem a detailním přemýšlením strávil čas iteracemi nad vylepšováním algoritmu. Aby sekundární barva nebyla příliš daleko od background barvy, nebyla příliš daleko od primary background barvy. Vyladil to ne nad jedním nebo dvěma themes, ale nad jakoukoliv kombinací barev.

To je něco, co se bez kódování neudělá. Ani s AI nástroji jako v0 to dnes nejde úplně snadno. On používal konkrétně Cursor, který má integrovaný Claude. Zabralo mu to čas, ale byl schopný a nadšený z toho, že vytvořil nejen obrázek ve Figmě, ale funkční věc.

Pak s dalším vývojářem to doiterovali do produkční kvality a dnes je to v produktu, máme na to skvělý feedback uživatelů. Je to něco, co by se velmi komplikovaně projektizovalo v kontextu dalších funkcionalit.

Zajímavé je, že aby to Matěj mohl udělat, musel se doučit teorii barev. Musel víc pochopit formáty jako RGB, HSL nebo OKLCH – různé formáty barev, každý dobrý pro něco jiného. Musel pochopit, jak fungují, jak tam funguje lightness, saturace. Bez toho by nebyl schopný ten algoritmus napsat.

Takže na základě toho, že vyvinul něco v kódu, se stal ještě lepším designérem, protože pochopil teorii kritické věci jako skládání barev – technické skládání barev. To není jen o tom, že dokončí něco, co vyvinul, ale ten člověk se stále zlepšuje i jako designer, protože dostává inputy z různých zdrojů.

Dvě témata mi přišla zajímavá. Nejdřív bych chtěl říct, že kolem sebe teď vidím velké nadšení z toho, že můžeš něco vyrobit, co se hýbe, funguje, můžeš si to osahat. Všude se mluví o AI kódování a lidi to baví, jsou z toho nadšení.

Samozřejmě po nějaké době přijde vystřízlivění z toho, že to není tak jednoduché. Není to jen "dám prompt a vygeneruju aplikaci". Je s tím dost dřiny, což jsi sám říkal – dostat to do funkčního stavu není zatím triviální. Ale to nadšení tam podle mě přetrvává.

Slyším i hodně kritiky, že AI kódování je pro děti a nikdy to nebude něco, co můžeš použít v produkci. Já si myslím, že se to tam dostane. Nenahradí to vývojáře, ale některé procesy to zrychlí, zautomatizuje a ušetří rutinní práci. K tomu se ještě dostaneme.

Co jsem chtěl akcentovat, je to nadšení. Líbí se mi, že to i nám, designérům, dává do rukou nástroj, kterým můžeme začít budovat hmatatelné věci. Mimochodem, v minulosti designéři utíkali od digitálního designu k truhlařině a podobně. Vždycky je tam trochu chuť zanechat za sebou něco víc hmatatelného než jen Figma file.

U truhlařiny je možná ještě motivace vypadnout od počítače, ale...

To je samozřejmě ještě o krok dál. Ale hraje to trochu na podobnou notu. Pak jsem se chtěl zeptat – Matěj se musel naučit HTML, CSS, JavaScript, mluvil jsi i o Reactu, o komponentách. Máte něco, co říkáte lidem "na tohle se podívejte, abyste se v tom mohli rozvíjet", nebo to necháváš hodně na těch lidech?

Osobně to nechávám hodně na těch lidech. Základní technologie byla vždycky stejná – vždycky to produkuje nějaké HTML a CSS. Myslím si, že znalost těchto technologií by měla být u všech designérů, protože je to nástroj, kterým pak vývojáři staví to, co oni nadesignují. Povědomí o těchto technologiích by tam být mělo.

React už je specifičtější. To bylo vidět v kódu, který byl vygenerovaný Cursorem. Algoritmus pod theming fungoval dobře, ale při implementaci do produktu už to trochu haprovalo v tom, jak se dělají věci v Reactu koncepčně – jak se věci rozdělují, jak se strukturují soubory. To jsou už takové harder vývojářské věci, které se musely doladit. Ale věřím, že při čtvrtém projektu už i designer bude mít lepší znalosti a bude potřebovat méně iterací.

Výhoda dnešních AI nástrojů je, že si vezmou na starost syntax. Já jako někdo, kdo hodně vyvíjí, znám věci jako hooky v Reactu a další core koncepty už docela dobře. Ale pokud designer v životě neslyšel o Reactu nebo je to pro něj vzdálená technologie, tak věci jako React hook, useEffect, rendering, to jsou pro něj komplikované. Nebo state a jak ho udržet. To jsou věci, které se člověk musí naučit.

S AI to ale nemusí, protože AI to často udělá za něj. Možná to není perfektní, ale od toho tam pak je vývojář, který může pomoct to posunout. Pro vývojáře to vlastně není nic jiného než práce s juniorním vývojářem. Mentorují ty designéry podobně, jak by mentorovali juniornějšího kolegu.

Je to o tom nehrát si na škatulky – tohle je designer, tohle vývojář, tohle produkťák – ale být otevření tomu, že všichni můžou tyhle věci dělat. Stejně jako my jsme otevření tomu, že přijde vývojář a řekne: "Tenhle design vůbec nedává smysl." My chceme, aby to dělali.

Jako designéři nemáme recept na pravdu. Někdy se tak chováme, že víme, jak věci mají fungovat, ale často je to jen odhad. Možná jsme něco řešili ve spěchu, multitaskovali, dostali tam chyby. Proto chceme od celého týmu zpětnou vazbu – dává to smysl, nebo ne?

Kolikrát se stalo, že vývojář přišel během vývoje a řekl: "Tahle interakce vůbec nedává smysl." Já říkám: "Přijď nám to říct hned. Předěláme to, pojďme se o tom bavit." Proces se stal mnohem kolaborativnější, iterativnější a ve výsledku jsme doručili kvalitnější věc uživateli.

Podle mě je strašně důležité neškatulkovat a být otevřený učení. Vývojáři se učí věci o designu, my se učíme o kódování, a tam to směřuje dlouhodobě. Budeme se bavit o generalistech, o něčem, čemu se říká "collapsed talent stack". Lidé budou dělat víc věcí a bariéry mezi rolemi se budou rozostřovat.

Líbí se mi přirovnání designéra, který zasahuje do kódu, k juniornímu vývojáři. Je to dobrý pragmatický přístup. V diskuzích na internetu teď vidím dva extrémy – buď "designéři nahradí vývojáře", nebo "AI je jen hračka pro děti a nikdy z toho nevznikne nic funkčního". Myslím, že realita bude někde mezi.

Je tam ještě třetí úroveň – že AI nahradí designéry i vývojáře. Mají pravdu v mnoha věcech. Ta pravda leží někde mezi.

Ta AI prý nahradí všechno – designéři jsou mrtví, vývojáři jsou mrtví, produkťáci. Budeme mít čas na truhlařinu potom.

Ještě k tomu, co je potřeba, aby to bylo možné. Ta kultura v týmu, aby se lidé cítili – anglicky bych řekl empowered – aby se neptali na svolení, nebo spíš, aby to svolení měli. To je strašně důležité mít ve firmě, nebo aspoň v týmu.

Je důležitá otevřenost a pomoc odstranit bariéry, které by mohly bránit. Například u nás pomáhá, že rozjet lokální development je otázka 20 minut. Stačí naklonovat repozitáře z GitHubu, nainstalovat npm packages, což jsou basics, spustit jeden lokální command ve VS Code nebo Cursoru a máte rozjetou lokální aplikaci.

Není potřeba strávit půl dne konfigurací backendu, tři hodiny konfigurací nějakých AWS serverů. To by byla obrovská bariéra, která by lidi znechutila, než by se dostali k zajímavým věcem.

Další drobnosti: máme napojený Vercel, který automaticky generuje previews do PRs. Člověk to může automaticky deployovat bez práce – jen poslat na GitHub a všechno ostatní se děje automaticky. Designéři mají přístup do GitHubu, ne jen view only, ale editing přístup.

Možná nejsou všichni ochotní nainstalovat VS Code nebo Cursor, ale GitHub umožňuje editovat kód přes UI. Fixy copy se dějí přes UI na GitHubu a není potřeba znát git, command line nebo VS Code.

Taková možná hloupá věc, ale důležitá – zajistit lidem licence na Claude, na Cursor, aby to nemuseli platit ze svého budgetu. Říct: "Pokud jako designéři chcete, máme pro vás licenci na Cursor, bude vám to platit, hrajte si s tím, zkoušejte to. Tady máte licenci na v0, prototypujte."

Pro ty, kdo se bojí gitu, jsou UI nástroje na commitování. Spousta vývojářů je používá, protože ne všichni mají rádi command line. Pro mě je command line děsivá, radši se naklikám v UI a pošlu to tam přes tři buttony.

Tohle všechno pomáhá nastavit kulturu: "Jsme ochotní, abyste kontribuovali do kódu. Tady máte GitHub, tady licence, klidně hodinové školení pro celý design tým – takhle to funguje, tohle jste schopní dělat. Jděte to zkoušet, fixujte věci v kódu, zkoušejte prototypy mimo Figmu." Ta škála možností je obrovská.

Mluvili jsme hodně o přínosech této změny. V 2Fresh se snažíme budovat kulturu, která dává lidem co největší svobodu v tom, co můžou dělat – nehlídat, nekontrolovat, samozřejmě dohlížet na kvalitu, ale věřit, že budujeme prostředí, které už standardy kvality definuje. To ve mně rezonuje. Narazili jste na nějaké limity, větší rizika, kdy jste si řekli: "Tady je hranice, kam zatím nepůjdeme"?

Neformálně. Myslíme si, že lidé pochopí, do čeho nesahat. Když upravují UI, vědí, že nebudou sahat do komunikace s databází. I kdyby to udělali, je tam code review, takže se to nedostane do produkce. Riziko, že člověk něco rozbije, je nízké, pokud má firma dobře nastavené procesy.

Co se nám stále děje a s čím se trápíme jako tým, je scope. Scope věcí, na kterých se pracuje. Ve Figmě se nám stane, že nám uletí scope a najednou řešíme tři další problémy, které bychom řešit nemuseli. To se nabaluje při implementaci – najednou už neřešíme jen theming, ale musíme změnit čtyři další věci nebo všechny ilustrace.

Musíme být velmi intencionální ohledně scopu. Hlídat si to, být opatrní, říkat si: "Je tohle, co musíme vyřešit teď, nebo to můžeme vyřešit později?" Je to spíš mentální riziko než technologické – chceme vyřešit příliš mnoho věcí najednou.

To mi přijde, že se designem prolíná historicky.

Samozřejmě.

Znám designéry, kterým jsme říkali: "Chceš po nich, aby ti vyrobili židli, a oni ti přestaví celou kuchyň včetně linky." To známe.

Je to komplikované v tom, že v určité fázi procesu chceš, aby lidé šli do šířky, zkoušeli různé přístupy. Ale v jednu chvíli se musíš začít fokusovat na výsledek. Občas zapomeneme, že už nejsme v té explorační fázi a stále rozšiřujeme řešení.

Pojďme se podívat na budoucnost designu, kam to směřuje. Mně přijde, že vy jste trochu napřed. Kam myslíš, že se posuneme?

Nevím, jestli jsme napřed. Možná v některých oblastech. Design ale není jen delivery, takže to si zaslouží samostatnou diskuzi o discovery procesu. Kam směřuje design? To je dobrá otázka.

Je to strašně komplikované predikovat a myslím, že se na to nedá dívat pouze z kontextu, kam směřuje design jako takový. Potřebujeme to trochu rozšířit – kam směřuje produktový development. Pocházím z produktu, v agenturách to bude možná trochu jiné, ale nedá se na to dívat izolovaně jen v rámci designu. Pokud se díváme jen na design, neuvidíme za tu hranici.

Zmínil jsem, že vidím a jsem rád, že se rozostřují hranice mezi rolemi. Nejde jen o to, kdo má jakou roli, ale spíš o zkušenosti. Když se budeme bavit o T–shaped skillu, tak o to, kdo má jakou hloubku znalostí versus šířku skillsetu.

Obecně si myslím, že se dlouhodobě vyvíjí role produktových manažerů. Už to nejsou project managers všude, nejde jen o proces delivery. Empowered product managers, o kterých mluví lidé jako Marty Kagan nebo Teresa Torres v Silicon Valley, se hodně věnují discovery. Tím trochu berou práci designérům, kteří byli vždycky o discovery. Teď se řeší, kdo dělá discovery – pokud produktový manažer dělá discovery a řeší problémy, není nutně designer jen o delivery.

Zmínil jsem proof of concept. Pro nás je to stále součást discovery, ale už je v tom i engineering. Řešíme společně ze všech tří hlavních vertikál, co chceme dělat a jak to chceme dělat. Myslím, že tam budoucnost směřuje – role nebudou tak striktně definované jako dnes nebo v minulosti, ale budou se prolínat v různých fázích.

Věřím, že to povede k lepší kolaboraci, protože jednotlivec bude schopný udělat víc různých věcí. Lidé se budou schopni bavit o stejných tématech napříč týmem a nemusí se to řešit lineárně – produkťák v discovery, designer ve Figmě a vývojář v implementaci.

Vidím to hodně podobně. V komunitě rozvířil diskuzi článek Martyho Kagana "A Vision For Product Teams", který tímto směrem také míří. Hodně se mluví o tom, že produktové týmy se zmenší a budou blíž spolupracovat.

Trochu mi to připomíná dobu, kdy vznikly Design Sprinty od Google Ventures. Cílem bylo dostat tým na jedno místo, kde spolu intenzivně spolupracuje. Bylo to v překotném rytmu, což mělo své nevýhody, ale skvělé bylo, že tam bylo pět lidí, kteří spolu opravdu mluvili a řešili věci společně.

Často tam chyběli vývojáři – možná povahou našich 2Fresh projektů – měli jsme tam spíš lidi z businessu, designéra a případně lidi ze sales nebo customer care. Ale principiálně mi přišlo, že malý tým rychle něco vytvoří a jde dopředu.

Mám pocit, že tohle se stane standardem, ale nemusíš běžet v tom hyper rychlém týdenním formátu, který byl u nás vždycky dost vyčerpávající. Rozloží se to v čase a bude z toho běžná spolupráce. Otázka je, jestli tam bude designer, produkták, vývojář, nebo jak budou skills a zodpovědnosti rozdělené.

Myslím, že to bude dobré. Malý tým má strašně výhod oproti velkým týmům se spoustou komunikace navíc, která vnáší komplexitu, nejasnosti a často změny rozhodnutí od někoho, kdo tam zrovna nebyl. Lidé budou v těch týmech šťastnější.

To je premisa toho článku – týmy budou menší. Dnes máme 8–9 lidí v produktovém týmu – produkťák, designer, tech lead a další vývojáři. Je tam strašně zajímavý aspekt jedné změny.

Jako industrie bojujeme s waterfallem, řešíme agile nebo iterativnost. To má důvod – některé věci trvají déle než jiné, některé jsou dražší. Historicky byl vývoj, engineering, dražší než design ve Figmě. Iterace ve Figmě je relativně levná.

Proto jsme trávili čas u designu, pilovali řešení, aby bylo skvělé a neměnilo se, když se dostane k vývojářům. To souvisí s tím, co říkáš o sprintech – vývojáři tam často nebyli, protože se o nich takto nepřemýšlí. Až to máme vymyšlené, dáme jim to a oni to implementují. Bohužel to tak stále je v mnoha prostředích.

Co se ale mění, je že kód zlevňuje. Bavili jsme se o tom, že designéři by měli nebo mohli kódovat. Já bych to trochu otočil – nejde o kód jako takový, ale o implementaci, o mindset, o to dostat se někam. Nepíšeme kód proto, abychom psali kód. Stejně jako se uživatel nepřihlašuje do aplikace proto, aby byl přihlášený. Má nějaký cíl.

Vytvořit něco v kódu je teď mnohem levnější a rychlejší než před třemi roky. Často je rychlejší jít rovnou do kódu. Děje se nám to – některé věci uděláme rovnou v kódu, pak je pilujeme, zkoušíme různé směry. AI v tom high–fidelity stále trochu strádá, takže tam je prostor. Ale často není důvod něco designovat a pak to posílat do developmentu. Kód už není nejdražší komodita.

Náklady to často ovlivňují. Když se řekne náklad, lidé si představí peníze. Ale náklad je i v čase, možná i ve frustraci lidí, kteří čekají. Má to spoustu dopadů.

Vidím jako zajímavé – budu generalizovat, což v diskuzích svádí, ale vychází to ze zkušenosti – že zahodit kód je pro mnoho lidí něco nemyslitelného. Ale zahodit frame ve Figmě, který jsem vyzkoušel, v designu není problém. Zduplikuju frame a udělám další. Říkám "tohle je lepší, super", starou verzi zapomenu.

Ale udělat flow v prototypu, který zabral 14 dní práce, a pak ho zahodit, protože máme lepší nápad – do toho nikdo nechce jít. To je ta drahá část, v čase i penězích.

Growth týmy mají trochu jiný mindset – experimentální. Myslím, že tento growth mindset se bude víc šířit do produktových týmů. Zahodit něco nebude problém. Když mi v0 vygeneruje něco za 8–10 minut promptingu, pár iterací, klidně to zahodím. Je to zajímavé, zkusím něco jiného. Netrápí mě to. Kód je jen prostředek k tomu, aby něco bylo vyjádřeno na screenu a fungovalo, jak chci.

Myslím, že se změní vnímání toho, že je v pohodě zahodit kód po proof of conceptech, iteracích, prototypech.

Už to na sobě pozoruji. Zkouším generovat věci i pro klienty. Dřív bych to neudělal, protože bych musel strávit hodně času vyklikáváním ve Figmě nebo sehnat designéra, který moji představu zhmotnit. Teď to můžu nahodit za deset minut. Je jedno, že je to vlastně blbé – ukážu to klientovi, on mi řekne, že je to blbé, tak to zahodím. No a co?

Ale mám něco hmatatelného, co jsem ukázal. Možná mi řekne, proč je to blbé, nasměruje mě a já pak jdu za designérem a řeknu: "Tady už jsme to trochu zarámovali, pojďme dál." Už nejsem k tomu emočně připojený. Neváhám to udělat a nebráním se to zahodit. Bylo to pár minut, možná hodina. Hodinou strávím čímkoliv.

Hodina prototypování ve Figmě často zabere mnohem víc. Dostáváme se do fáze, kdy klientům říkáme: "Klikni sem, protože ostatní nefunguje." Ty tři kliky jsou jediné správné, které nás posunou do bodu, kam chceme. Kam jsme se posunuli v toolingu od doby InVisionu? Pořád je to klikání nad obrázkem. Možná obrázek umí hover effect buttonu, ale je to ten 10x improvement? Není.

Teď se to začíná dít. Potřebuji formulář, checkout form pro e–shop, potřebuji v něm změny a testovat ho. Ve Figmě v současných nástrojích to neudělám. Jakýkoliv uživatelský input a končím. Lidé šli do Axure, ale to není cesta, je to komplikované.

Dnes to prostě vygeneruju. Klidně tam pošlu Figma link jako základ a vygeneruju to z toho. Nástroje jsou dost dobré, aby to převedly do použitelného HTML. Stačí to ukázat klientovi, tu interakci. Nemusí to být high–fidelity design.

Další diskuze, která se musí změnit – co jde od designérů, nemusí nutně být high–fidelity. V našem týmu je důležité, že cokoliv tam je, není finální a je otevřené ke změně. Pokud si myslíš, že by to mělo fungovat lépe, řekni to a pojďme to vyřešit. Zpátky k vysoké proaktivitě a high agency.

Je zajímavé, že v oblasti prototypů a jejich fidelity jsme vlastně trochu zakrněli. Když si vzpomenu, před 12 lety v Axure se daly dělat poměrně sofistikované věci. Dalo se tam skriptovat, pracovat s formuláři, ukládat stavy do sessions – docela sofistikované věci.

S nástupem Figmy tohle o level zdegradovalo. V odvětví si nevšiml jsem, že by probíhala velká diskuze o tom, že to možná bylo good enough. Lidem buď nechybělo, nebo to nějak obešli jinak. Z mého pohledu to trochu zdegradovalo, teď se to možná vrátí zpátky.

Jak jsi mluvil o dodávání low–fidelity věcí – s Figmou mám ambivalentní vztah. Ten multiplayer je obrovský game changer a schopnost delivery pro UI je skvělá. Ale možná to přineslo i to, že low–fidelity věci jsou ve Figmě docela složité udělat. Tudíž se hodně věcí skládá z nějakých design systémů. I když nemáš vlastní design systém nebo komponentovou knihovnu, prostě tam natáhneš Material UI a z toho skládáš. Je to rychlé, ale už to není tak hrubé jako v Balsamiqu.

Zkoušel jsem přes v0 převést a vypromptovat nějaký design. Mají tam Shadcn library nebo Radix, říkal jsem si, že by bylo super v low–fidelity to převést přes Balsamiq prompt. Byl to spíš experiment for fun než reálný use case, ale narazil jsem na strašně zajímavou věc – design systémy.

Design systémy hrají obrovskou klíčovou roli v budoucnosti prototypování a shipování věcí. Ve své podstatě jsou to data – data o komponentách, UI, patterns, které používáme v týmu, data o theme aplikace, tokenech. Všechno jsou to strukturovaná, relativně vyčištěná data, protože někdo udělal tu práci, aby to vyčistil – designer, vývojář, nebo jeden člověk, který dělal obojí. Vyčistil to tak, aby věci byly plus minus stejné mezi Figmou a kódem.

Tohle jsou perfektní data pro AI. Dokážeš AI naučit fungovat s tvým design systémem. Možná ještě není tooling, který by to uměl out of the box, ale je to otázka tří čtvrtě roku, možná roku. Všechny nástroje jako Bolt, v0 začínají s design systémy a rozšiřují se tak, aby tam lidé dokázali napojit vlastní design systém.

Redefinujeme pojem low–fidelity. Pro mě low–fidelity už teď ve Figmě je, že používám design systémové komponenty z knihovny. Už to není o tom, že to vypadá jako Balsamiq. V diskuzi to moc není, ale podle mě se redefinovalo, co znamená low–fidelity. Aspoň v mé hlavě to tak je.

Když vidím, že někdo designoval interakci jen s design systémem, beru to tak, že to bylo relativně levné udělat a pracovat s tím. Fáze polishingu přijde až potom. Ta designová kreativní fáze může přijít až nad design systémem nebo nad některými konkrétními interakcemi. Ne každá interakce musí být super high–polished a specifická.

Jsou ale interakce, které si to zaslouží – třeba jsou velmi brzy v onboardingu, takže jde o první dojem uživatele s aplikací. Nebo je to interakce, kterou používáš 40krát denně, a je potřeba se nad ní zamyslet a možná ji reoptimalizovat. Tam je prostor pro design, aby přidal těch svých 20 % nebo 10 %.

Ve zkratce – prototypování s design systémem bude velmi brzy možné v těch nástrojích. Je možné, že to udělá Figma. Měli by, pokud chtějí přežít. Musí se vyvinout, jinak je někdo převálcuje. Figma je dobře postavená na to, aby byla skvělý prototypovací nástroj pro kód. Jejich produktová rozhodnutí jsou všelijaká, možná dopad Adobe dealu, různé externí impakty, ale věřím, že to chytnou. Mají takovou pozici na marketu, že můžou mít zpoždění a nebýt první.

Oni mají ty data. Ve Figmě to je. Potřebuješ jenom najít most do těch jazykových modelů.

Mají data nejen z Figmy jako designu, ale loni představili něco, čemu říkají Code Connect, kde lidé mapují komponenty design systému na jejich counterpart v kódu. Mapují, které property jsou kde. To je datový základ pro to, aby dokázali generovat perfektní prototypy z designu do kódu. Už na tom pravděpodobně makají, jen to ještě nevidíme.

Stoprocentně.

Viděl jsem různá vyjádření – Figma koupila Diagram před dvěma lety, takový AI startup. Skoro nikdo z toho Diagramu už ve Figmě není. Ale i ti lidé, co tam nejsou, v Twitter threadech typu "Figma je mrtvá, Figma skončí", reagují: "Ale to si myslíte, že to nevidí?" Market se posouvá, dělá se na spoustě věcí, jen to ještě není venku.

Snad to nebude jako u Applu, kde se spekuluje, že jim AI ujela. Dneska třeba něco chtít po Siri je frustrující zážitek.

Stále se může stát, že Figmě ten vlak ujede. Jen mají takovou saturaci na trhu a adopci, že mají víc času než ostatní. Ale i tak je toho času relativně málo v tom, jak rychle se technologie vyvíjí.

U Applu se mluví o problému v leadershipu – průměrný věk člena boardu je 67 let, Steve tam není a možná tam chybí někdo, kdo by to posouvalo dopředu. Ale to už jsme trochu odbočili.

Honzo, děkuji za fantastické povídání. Věřím, že se to bude líbit. Myslím, že bychom měli udělat pokračování – máme témata, která jsme nestihli probrat.

Děkuji za pozvání, bylo to fajn. Máte hezké studio v 2Fresh a díky, že děláte ty podcasty. Je super slyšet to v češtině, ty lidi, co mluví o svých týmech, a že nemusíme koukat jen do zahraničí.

Děkuji, proto to dělám. Jsem rád, že to někdo takhle říká. Člověk si občas říká, jestli to má smysl a jestli to dělá dobře. Vždycky se to dá dělat líp, ale je skvělé slyšet takovou zpětnou vazbu.

Díky našim posluchačům, že si udělali čas. Jestli jste to doposlouchali až do konce, tak fantazie. Budu se těšit zase příště. Ahoj.

2FRESH Design podcast

2FRESH Design podcast tvoříme v designovém studiu 2FRESH. Pokud potřebujete pomoct s designem vašich produktů a služeb, nebo chcete poradit, jak posunout UX vyspělost vaší firmy dopředu, ozvěte se nám.