{"loaderData":{"0":null,"0-2":{"posts":[{"slug":"figma-tokeny","title":"Export variables z Figmy do design tokenů v JSONu","date":"2026-01-23","description":"Jak jednoduše dostat z Figmy design tokeny (variables) ve formátu JSON?","year":"2026","contentHtml":"

Potřeboval jsem vyexportovat variables z Figmy u našeho design systému.

K velkému překvapení jsem zjistil, že Figma k tomu nemá žádnou exportní funkci.

Překvapivé je to minimálně proto, že Figma figuruje mezi jmény zmíněnými na webu oficiální pracovní skupiny od W3C pro design tokeny. Když jsem je tam viděl předtím, než jsem se o to začal zajímat, tak jsem se automaticky domníval, že to znamená, že ten export podporují (ten JSON formát je hlavně o interoperabilitě).

Takže back to square one.

Po chvilce googlení jsem zjistil, že jestli to nechcete dělat manuálně po jednom jako otrok přes nativní panely nástrojů (nebo třeba dev mode), nejlepší bude využít některý z pluginů.

A pluginů existuje fakt hodně!

Potřeboval jsem jen JSON s design tokeny, nic víc. Proto mi pluginy jako Tokens Studio nebo Design Tokens přišly až moc robustní.

Nic jednoduchého jsem zkrátka nenašel. Buď ten plugin neexistuje, nebo jejich autoři to neumí marketovat, nebo jsem až moc netrpělivý v hledání.

Jelikož ke skillům dnešního moderního muže patří používání AI, nažhavil jsem Clauda a vystřelil prompt:

\n
hey man! i need a dead simple export plugin for design tokens (variables) from Figma to JSON format as defined by W3C design tokens working group. develop it for me.
\n

...a dřív než se mi uvařilo kafe, jsem měl v ruce plugin. A ten fungoval na první dobrou.

Mindblowing!

Nebyl bych to ale já, abych s tím nestrávil další čas a ladil detaily. Takové ty drobnosti, které nikdo neuvidí ale přece to tak nemůžete nechat.

Výsledkem bylo asi 20 dalších iterací, až to vypadalo tak, jak jsem chtěl.

Teď mám svůj plugin, kde si nastavíte výstup:

podle paperu k design tokens podle W3C
1:1 podle vaší organizace ve Figmě

Pro každou možnost kromě JSONu nabízím i vizuální HTML, kde se dá rychle vše zkontrolovat. (Každej není takovej nerd, aby se mu líbil JSON, ne?)

$\"Good$

Plugin si můžete zdarma stáhnout na Figma Community.

\n
Edit: Zpětně jsem objevil ještě Figma Variables to JSON plugin, který je relativně jednoduchý a pokud někdo potřebuje mít možnost před exportem ovlivnit, co se mu objeví v datech, doporučuju. Ti, kdo chtějí one click solution, ať stáhnou to moje 😎
\n

\n"},{"slug":"skoleni","title":"Školení (nejen) pro design týmy","date":"2026-01-01","description":"Sezna školení pro design a produktové týmy","year":"2026","contentHtml":"

Hledáte způsob, jak rozvíjet schopnosti a kompetence členů svého týmu v oblasti návrhu digitálních produktů, ale narážíte na nedostatečnou nabídku relevantních a přínosných školení, workshopů a kurzů na trhu?

Ozvěte se mi, připravím školení na míru vaším konkrétním potřebám. Tak jako designerům (a jiným produktovým rolím) z mnoha firem před vámi!

$\"Firemní$ \nŠkolení pro designery Deloitte Digital v rumunské Bukurešti

Témata, která pokrývám

Inovace, digitální transformace
Rapidní prototypování a ověřování nápadů
Design-thinking a design sprint workshopy
Příprava a vedení workshopů
Uživatelské testování (psaní scénářů, rekrutace, vedení testů, vyhodnocení)
Design systémy (tvorba, management, rozvoj)
Design reviews a zpětná vazba
Osobní produktivita a efektivita pro designery
Nástroje: Figma, FigJam, Miro, Mural, Axure,...

Poptáváte-li dlouhodobější a komplexnější vzdělávací program, příp. chcete-li pokrýt i jiná než výše uvedená témata, přizvu k sobě další specialisty na danou problematiku.

Reference

\n
V minulosti jsem pořádal a vedl školení pro designery z firem jako IBM, SAP, PwC, KBC, Deloitte, O2 nebo třeba Orange.
\n
\n
Prošel jsem tréninkovým bootcampem společnosti Adobe a několik let působil v týmu certifikovaných trenérů Adobe XD v regionu EMEA.
\n
\n
Tréninky, školeními a webináři, které jsem vedl, za posledních 5 let prošlo přes 1 000 lidí.
\n

Formát a cena

Osobně nebo online. Záleží na vás. Osobní formát je mnohem intenzivnější a některá témata se dají vysvětlit, vyzkoušet a naučit snadněji než na dálku.

Cena celodenního týmového školení začíná na €2 000.

Všechna školení naceňuji a připravuji individuálně po absolvování úvodní schůzky a seznámení se s vašim konkrétním kontextem (cíle, aktuální výzvy, účastníci školení a jejich zkušenosti,....

$\"Firemní$

Chcete školení?

Ozvěte se mi na e-mail nebo na +420 777 018 287.

Společně probereme, co aktuálně řešíte, jaká máte očekávání od školení a čeho byste rádi dosáhli.

Pokud vás oslovilo co dělám, ale aktuálně nepoptáváte školení, přidejte si mě na LinkedIn a zůstaňme ve spojení.

\n"},{"slug":"agilni-vyvoj","title":"Agilní vývoj","date":"2024-11-06","description":"Co je to agilní vývoj?","year":"2024","contentHtml":"

Za svou kariéru jsem prošel spoustou různých firem, spolupracoval s desítkami týmů a viděl různé přístupy k vývoji a řízení vývoje softwarových produktů.

Když jsem začínal, svatým grálem bylo mít projekt správně naplánovaný od začátku do konce. Nejcennější dovedností v týmu bylo projektové řízení a tvorba promyšleně vypadajících Gantt diagramů, které žádného klienta nenechaly na pochybách, že víte co děláte a že projekt doručíte tak, jak je to potřeba. Přece na to máte plán!

Většina firem ale časem zjistí, že plány a odhady jsou jen teorie, která se často míjí s dennodenní praxí a fungováním softwarových týmů.

Osvícení manažeři a šéfové softwarových týmů tak začnou pošilhávat po tom, jak dělat svou práci jinak, lépe. Tak, aby byli více spokojení oni, členové jejich týmů, zákazníci a samozřejmě také uživatelé, kteří budou s vyvíjenými produkty pracovat.

Pomyslné prozření přijde, když objeví agilní vývoj.

Všechno najednou začne dávat smysl:

nemusejí se dávat dohromady několikasetstránkové specifikace produktu, který vymysleli manažeři odtržení od zákaznické reality
vývojáři netráví desítky hodin při odhadech časové náročnosti funkcí, u kterých vlastně nemají představu, jak budou ve finále fungovat
díky fungování v krátkých iteračních cyklech jsou schopni mnohem lépe reagovat na změny
zákazník uvidí funkční výsledek dříve než na konci projektu
produkt můžou testovat a vylepšovat v průběhu vývoje (a nikoliv až na konci projektu)
na vývoji produktu budou více spolupracovat se zákazníkem a jeho uživateli, díky čemuž výrazně sníží riziko toho, že doručí nefunkční paskvil
produkt budou vytvářet všichni společně, zlepší týmovou komunikaci a pocit odpovědnosti za výsledek

A tak dále a tak dále.

Na první pohled je agilní vývoj oproti tzv. vodopádu no-brainer.

Postulát dnešní doby je jasný: Agilní vývoj je jediná správná metodika podle jaké by moderní softwarové týmy měly vyvíjet produkty.

Rigidní plánování a vodopádový vývoj patří ve spoustě firem na seznam zakázaných praktik.

A přesně tyhle firmy se také budou navenek bít do prsou a tvrdit vám, jak k vývoji přistupují moderně a pracují agilně. Jasně, co jiného by měly říkat?

Ovšem nic není černé nebo bílé.

Mezi oběma extrémy existují stupně šedi. A vězte, že jejich paleta je pěkně široká. Skoro se nabízí říct, že těch odstínů je víc jak hvězd na obloze...

Když se firmy ale zeptáte, jestli je její vývoj vodopádový nebo agilní, dostanete jednu odpověď (agile) a málokdo bude zabíhat do detailů, které by vám o jejím fungování napověděly více.

Chápu, lidi mají rádi zkratky.

A pokud máte o agilním vývoji něco málo načteno (a ideálně také na vlastní kůži prověřeno), odpověď na tuhle otázku vám s sebou nese i jistá očekávání.

A tady se podle mé praxe teorie rozchází s realitou. Častokrát více, než je zdrávo.

Co tím myslím?

Inu – i když vám firma skálopevně bude tvrdit, jak agilně funguje, ve chvíli kdy se zanoříte do denní operativy a přičichnete k některým interním procesům a praktikám, bude vám nad slunce jasné, že agilní vývoj ve své ryzí podobě je pouze zbožné přání a praxe má mnohem blíže k vodopádu...

Pojďme se mrknout na ty nejčastější prohřešky, s nimiž jsem se za 20 let mé praxe setkal:

\n
Nedoručení hodnoty – jedním ze základních principů agilního vývoje je generování hodnoty pro zákazníka as soon as possible. Většina agilních týmů jede scrum (protože mají Jiru…:) s dvoutýdenními sprinty, během nichž by se mělo dodat něco, co rozšíří to, co jste měli předtím. Podle slabikáře byste tu věc měli také zpřístupnit zákazníkům. Ne nutně všem, ale tolika, abyste získali zpětnou vazbu. To se u většiny větších týmů neděje a vytvořená hodnota se drží lokálně na jejich prostředí a čeká se na naplánovaný release. Čest výjimkám, které do svých procesů adoptovaly principy continuous delivery a vývojáři jsou schopni pushovat změny do produktu, jakmile jsou hotové.
\n
\n
Plánování výsledku a reagování na změny – je OK mít plán toho, co chcete dosáhnout. Není OK plánovat na měsíce dopředu přesné termíny, úkoly a aktivity. Ze své podstaty by měl být agilní vývoj flexibilní a reagovat na změny a informace, které se v průběhu procesu objeví. A slovy maršála Moltkeho „žádný plán nepřežije setkání s nepřítelem“. Je fakt zbytečné (a týmově kontraproduktivní) se připravovat na všechny možné scénáře dopředu. Přijměte nejistotu jako součást cesty. Důležité je umět reagovat na věci, které se objeví. Vývojáři tohle pochopí celkem rychle; složitěji se to vysvětluje klientům. Ti logicky požadují záruky a jistoty, které jim na první pohled iterativní vývoj nedává. Tohle by bylo na samostatný článek, ale v principu musejí pochopit, že stěžejní výhodou tohoto přístupu je minimalizace rizika potenciálního selhání produktu. (Předpokladem je, že nejste jen order-taker, ale máte s klientem společný zájem na jeho úspěchu).
\n
\n
Zapojení uživatelů – dalším z pilířů agilního vývoje je kromě častých iterací i zapojení uživatelů. Ti by vám měli dávat zpětnou vazbu na vaše řešení a validovat práci. A i když je vývoj iterativní, není ve firmách pravidlem, aby vygenerovaná hodnota během sprintu skutečně viditelně vylepšila softwarový produkt. A pokud nemáte novinky, není se s uživateli o čem bavit. Nemluvě o tom, že uživatelské testování je i pro spoustu jakožeagilních firem stále pouze krok v celém vývojovém procesu, k němuž se přistupuje častokrát až na konci. Celý problém je spojená nádoba s plánováním: pokud adoptujete princip \"já ani zákazník nejsem uživatel\", zákonitě budete potřebovat odpovědi od lidí. A kdyby se vám jich dostalo až na konci, budete mít setsakramentský problém.
\n
\n
Nekompletní týmy pracující v silech – podle agilních principů byste v týmu měli mít zastoupené všechny role, které se na uvedení produktu na trh podílejí. V realitě častokrát jsou součástí core týmu pouze vývojáři a veškeré další role (produkt, testování, design, obchod, brand, marketing,...) sedí někde jinde. To se děje nejčastěji proto, že dané role musejí obhospodařovat i jiné produkty nebo pracovat i na dalších firemních aktivitách. Pokud nemáte všechny potřebné role pro vývoj daného produktu v jednom týmu, exponenciálně narůstá komplexita v otázkách plánování, synchronizace a spolupráce. I malý hodinový úkol se může klidně řešit týdny.
\n
\n
Polovičaté adoptování metodik – tohle se týká především týmů fungujících podle frameworku scrum: i když scrum existuje zhruba od poloviny 90. let (a jeho fungování a procesy jsou dobře popsané), setkal jsem se s mnoha organizacemi, které jej adoptují jen částečně (a ne, nemyslím si, že za tím bývá zralá úvaha jako spíš neznalost). Snad každý agilní tým má pravidelné stand-upy. Už méně týmů si ale osvojilo další agilní ceremonie jako jsou třeba retrospektivy. Toto vnímám hlavně u týmů, které se agilní vývoj nenaučily formálně, tj. chyběl tam opravdový scrum master nebo jiný průvodce procesem adopce.
\n

Celé to píšu hlavně proto, že nemám rád absolutní pravdy.

Ani v politice nikdy nejste úplně nalevo nebo úplně napravo.

Ve skutečnosti vlastně neoperujete ani na přímce, ale v ploše.

Je tedy vlastně jedno, jakým ~~buzzwordem~~ slovem svůj proces označujete, protože jím bez dalšího kontextu nejste schopni popsat svoje fungování a předat tuto informaci v celé její komplexitě někomu dalšímu.

Nejvypovídající reprezentací vývoje digitálních projektů by byl spider chart, na kterém byste jednoduše viděli, kde přesně se daná firma v jednotlivých oblastech nachází. (Příklad pro ilustraci níže - doporučuju projít tímto jednoduchým cvičením v týmu a potom porovnat výsledky s dalšími týmy; budete překvapeni, jak moc se to může lišit i v rámci jedné firmy 🙂)

$\"Graf$

Na závěr ještě přihodím tabulku porovnání scrumu a kanbanu, což jsou dva nejčastější frameworky využívané v agilním vývoji. Třeba to někomu pomůže, protože i zde spousta lidí mylně zaměňuje jeden za druhý (anebo prostě mixují jednotlivé aspekty obou dohromady - i to už jsem zažil...).

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Aspekt	Scrum	Kanban
Struktura	Časově ohraničené iterace (sprinty, obvykle 1–4 týdny)	Kontinuální tok práce
Role	Definované role: Product Owner, Scrum Master, vývojový tým	Žádné povinné role; adaptabilní pro jakoukoliv strukturu týmu
Plánování práce	Na začátku každého sprintu se vytváří plán z backlog	Žádný přísný backlog; úkoly se přidávají na tabuli dle potřeby
Scope práce	Zaměřuje se na dokončení cílů sprintu; nová práce se přidává až v dalším sprintu	Další úkoly se přidávají podle potřeb a toho, jak se odbavuje předchozí práce
Prioritizace úkolů	Product Owner určuje priority nebo cíle pro každý sprint	Prioritizace je dynamická; úkoly jsou definovány dle kapacity týmu
Schůzky	Pravidelné ceremonie: plánování, denní standupy, sprintu review, retrospektiva	Denní standupy jsou volitelné; Kanban má pouze ad-hoc meetingy
Cíl	Dokončit sadu úkolů do konce každého sprintu pro doručení hodnoty	Udržovat plynulý tok úkolů, zkracovat dobu dokončení a eliminovat překážky
Přizpůsobivost změnám	Změny úkolů v rámci sprintu nejsou možné, což přispívá k dosažení naplánovaných cílů	Vysoce flexibilní; úkoly lze kdykoli přeřadit či přidat
Metriky	Rychlost, tzv. velocity (počet dokončených bodů za sprint)	Lead time, cycle time, WIP (sleduje čas a efektivitu úkolů)
Vhodné pro	Týmy, které chtějí strukturu, předvídatelnost a jasně definované role a cíle	Týmy potřebující flexibilitu, nepřetržitou dodávku a zaměření na efektivitu toku práce

$\"Meme$

A něco málo o tom, proč je vlastně kanban nejlepší framework pro agilní projekty

\n"},{"slug":"continuous-discovery-framework","title":"Continuous discovery framework","date":"2024-02-19","description":"Co je continuous discovery framework?","year":"2024","contentHtml":"

Continuous discovery framework je nástroj, za kterým stojí Teresa Torres:

obvykle zahrnuje malé výzkumné aktivity vykonávané na týdenní bázi, kdy se produktový tým potkává se zákazníky
produktový tým je ve složení: produktový manažer, design lead a tech lead
smyslem frameworku je docílit, aby všechna produktová rozhodnutí byla tvořena na základě reálné zpětné vazby od zákazníků a byznysové hodnoty
obvykle má continuous discovery framework tyto kroky:\n
1. Formujte continuous discovery tým, který utvoří product manager, design lead a tech lead
2. Definujte očekávaný výstup a navázanou metriku
3. Prozkoumejte možné příležitosti na základě potřeb zákazníků, pain pointů a obchodní hodnoty
4. Navrhněte ideální řešení optikou zákazníka pro každou z příležitostí a ideálně jej do procesu zapojte (co-creation)
5. Zvykněte si se zákazníky na týdenní bázi provádět různé výzkumné aktivity, jako třeba rozhovory, kontextové dotazování nebo uživatelské testování
\n
framework je nejvíce přínosný v agilních týmech, kde se výzkum dá dělat jako malá, ale pravidelná aktivita během vývojového cyklu produktu.

\n"},{"slug":"customer-development-model","title":"Customer Development Model","date":"2024-01-23","description":"Co je customer development model?","year":"2024","contentHtml":"

Za autora customer development modelu je považován Steve Blank, který je jeden z předních expertů v oblasti podnikání a start-upů.

Jeho přístup k vývoji produktu a podnikání se soustředí na aktivní zapojení zákazníků od samého začátku.

Místo abychom jen vytvořili produkt a doufali, že najdeme zákazníky, Blank zdůrazňuje potřebu průběžné komunikace a testování s cílovou skupinou, což by mělo vést k lepšímu porozumění trhu a efektivnějšímu vývoji produktu.

Je překvapující, kolik společností při tvorbě nového produktu nebo produktových inovacích některé kroky z customer development modelu úplně přeskakuje nebo cíleně ignoruje („my přece své zákazníky známe a nemusíme se jich na něco ptát...“).

Výsledkem bývají proinvestované miliony korun do produktů, po kterých není poptávka a brzy zaniknou. Anebo (v tom lepším) případě jdou podobné částky na různé drobné úpravy, což si můžete přeložit jako podcenili jsme product discovery, výzkum a analýzy, zjistili to až po spuštění a teď naše IT musí podstatnou část dodaného řešení přepracovávat... :-)

Takže jaké kroky najdete v customer development modelu od Blanka? Tady je jeho kuchařka:

1. Customer discovery

V této fázi se snažíte zjistit víc o zákazníkovi a jeho problémech, představit řešení produktu a ověřit prvotní business model.

Definujte svou hypotézu o

produktu
zákaznících a problému
distribuci a cenotvorbě
tvorbě poptávky
trhu, na který vstupujete
konkurence

Otestujte hypotézu \"problému\"

nejdřív na těch, co znáte
představte \"problém\"
získejte pohlede zákazníků
získejte znalost o trhu

Otestujte hypotézu \"produktu\"

získejte první zpětnou vazbu
představte \"produkt\"
opětovně se setkejte se zákazníky
získejte další zpětnou vazbu
vybudujte tzv. \"poradní sbor\"

Ověření

ověřte problém
ověřte produkt
ověřte business model
iterujte nebo skončete

2. Customer validation

V této fázi zahajujete prodej prvním zákazníkům a podporovatelům a ověřujete své řešení a hledáte pozicování produktu a firmy na trhu.

Připravte se na prodej

popište produktovou propozici
připravte prvotní obchodní a marketingové materiály
připravte prvotní obchodní roadmapu
najměte člověka na dokončování obchodů
slaďte se v týmu

Prodejte \"earlyvangelistům\"

kontaktujte earlyvangelisty
zahajte prodej earlyvangelistům
upravte obchodní roadmapu
zahajte prodej přes partnerské kanály
upravte roadmapu pro partnerské kanály

Napozicujte produkt na trhu

napozicujte produkt
napozicujte firmu
odprezentujte vše analytikům a influencerům

Ověřte

ověřte produkt
ověřte obchodní roadmapu
ověřte roadmapu partnerských kanálů
ověřte business model
iterujte nebo skončete

3. Customer creation

V této fázi uvádíte celý produkt, získáváte nové zákazníky a začínáte škálovat na trhu díky správné komunikaci a dalším kanálům, přes které oslovujete zákazníky.

Připravte se

Dotazník pro nalezení nejlepšího trhu
Vyberte správný trh (existující / jiný / nový)
Definujte si cíle na 1 rok

Pracujte na pozicování

Vyberte PR agenturu
Audity pozicování
Zajistěte, aby pozicování odpovídalo typu vybraného trhu

Spusťte produkt

definujte, jak chcete produkt spustit
vyberte správná publika
vyberte ambasadory
připravte sdělení ke komunikaci
seznamte se s aktuálním kontextem
seznamte se s médii
měřte výkon

Vytvořte poptávku

vybrte správnou strategii
slaďte se na tom, co měřit
iterujte nebo skončete

4. Company building

V této fázi se z vašeho startupu stává regulérní společnost s definovanými procesy a obchodním modelem. Vaším cílem je oslovení co nejširšího spektra zákazníků a vybudování silného týmu, aby společnost byla dobře připravena pro dlouhodobý úspěch.

Oslovení mainstreamu

namísto earlyvangelistů oslovujete mainstreamové zákazníky
obchodní proces se upravuje podle cílových trhů, které oslovujete

Management a kultura

nastavení management procesů
vytvoření kultury okolo vaší mise

Tvorba oddělení

vytvořte misi pro jednotlivá oddělení
vytvořte jednotlivé role podle cílových trhů

Reagujte na změny

implementujte management procesy okolo vaší mise
vytvořte \"kulturu informovanosti\"
vytvořte \"kulturu leadershipu\"

(Jo a samozřejmě doporučuju pořídit Blankovu knihu The Four Steps to Epiphany, kde je celý model v detailu popsán.)

\n"}]}},"actionData":null,"errors":null}

Poznámky