Jak týmy designu a vývoje ve společnostech rostou, je potřeba lepší organizace a standardizace procesů a nástrojů. Nováčci začínají pracovat na klientských projektech, pro které potřebují dobře fungující designový systém.
Ukázalo se, že přeměna návrhového systému na jiný projekt nefunguje příliš dobře. Ale proč ne? Více o tom v našem článku.
Zdroj
Vytvoření týmu návrhového systému
< p> Proč designový systém vůbec potřebuje tým? Týmy ve společnostech jsou obvykle rozděleny do konkrétních oblastí: kreativita, rozvoj a marketing. Každý tým je veden vedoucím týmu, kterému v případě potřeby pomáhá plánovací manažer.
Existují také projektové týmy. Každý z nich se skládá z několika designérů, vývojářů a obchodníků a je veden projektovým manažerem. Týmové sestavy se mohou časem měnit.
Výsledkem je, že návrháři, vývojáři a obchodníci musí podávat zprávy svému vedoucímu týmu a vedoucímu projektu .
Tento model ztěžuje týmům sdílení zdrojů. Často nevíme, na čem ostatní lidé pracují, pokud se jich nezeptáme nebo o tom neslyšíme na schůzce. To je důvod, proč se stejná práce provádí několikrát.
Proto potřebujeme více standardizovaných komponent pro efektivní práci týmů. Musíme také mít v těchto příkazech více očí a uší, abychom věděli, které komponenty nejvíce potřebují.
V průměru může být vyžadováno více komponent, než by jedna osoba mohla vytvořit a sdílet sama. Aby bylo možné vytvořit více komponent, je spuštěn projekt.
Návrh systému designu, kterému se v tomto článku věnujeme, zdědil konvenci běžných týmů návrhářů. Sestavování komponent vyžaduje projektové řízení, výzkum, design a kód. Projekt tedy začal manažerem, výzkumníkem, návrhářem a vývojářem uživatelského rozhraní.
Náš první projekt
Naším prvním úkolem jako týmu návrhového systému bylo vytvořit záhlaví webu a navigační komponentu. Projektový manažer od nás požadoval odhad a vypočítal návratnost investic na základě času ušetřeného v budoucích projektech. Chtěl použít tento projekt jako případovou studii, aby přesvědčil vrcholový management, aby investoval do větší standardizace.
Chápal, že vrcholový management nám nedovolí pracovat na další standardizaci, dokud nebude tento projekt úspěšný. Ukázalo se, že až do dokončení tohoto projektu nebudeme pracovat na dalších komponentách.
Výzkum
Hledání spočívá ve shromažďování různých vzorů navigace, záznamů na stránkách konkurence a na našich. O týden později byly výsledky prezentovány týmu, abychom mohli jít dál.
Po představení výsledků bylo plánováno společně s týmem vypracovat pokyny. Ne každému se tento nápad líbil. Podařilo se nám vytvořit několik pokynů, ale hodně se diskutovalo o tom, které možnosti pro novou komponentu by byly nejdůležitější. A které budou vytvořeny jako první.
Design
Vizuální návrhář zahájí práci. O dva měsíce později ukázal ve Figmě skvělý interaktivní prototyp.
Tento vývoj našemu systému trochu neseděl. Návrhář vytvořil navigační komponentu v novém souboru s duplikátem našich šablon návrhového systému. Jiní začali přemýšlet, který soubor by měli použít.
Objasnil, že dokáže naslouchat názorům jiných designérů, rychle implementovat zpětnou vazbu a pochopit, jak systémy fungují. Bylo rozhodnuto archivovat soubory návrhového systému a nechat jej podporovat jeho vizuální část. Díky tomu návrháři vždy věděli, kde najít náš návrhový systém.
Vývoj
Chtěli jsme zahájit vývoj co nejdříve a rychle přidat navigační komponentu do naší kódové základny. Během této doby jsme také změnili úložiště aktiv na Webpack a optimalizovali rychlost načítání stránek Google, což také nějakou dobu trvalo.
O dva měsíce později, po čtyřech měsících práce na projektu, jsme si stále nemohli najít čas na vývoj navigace. Nakonec jsem přispěl převzetím tohoto úkolu.
Navigační komponenta byla napsána v Storybooku. Můžete to otestovat, sdílet se svým týmem a připojit automatickou dokumentaci.
Kniha pohádek se v našem pracovním postupu ukázala jako problematická. Lidé nerozuměli všem jeho ovládacím prvkům. A tito lidé nejsou zvyklí testovat komponenty izolovaně.
Ale co je důležitější, Storybook se nevejde do našeho zásobníku kódů. Použili jsme vestavěné šablony společnosti Vue k optimalizaci SEO a kompatibility s naším serverovým rámcem Laravel s naším CMS. Storybook nepodporuje vložené šablony Vue s Laravelem, ale vyžaduje pouze jednotlivé komponenty souboru.
Navigační komponenta byla vytvořena tak, aby podporovala jednotlivé komponenty souborů i integrované vzory. Ale ani to nepomohlo. Nelze změnit měřítko stejné funkce na dvou různých místech, což byla jen kost v krku. Bylo rozhodnuto držet se vestavěných vzorů a upravit pomocí nich navigační komponentu.
Osm měsíců po zahájení projektu náš front-endový vývojář spojil kód s hlavní větví naší codebase, což znamenalo, že navigace byla zcela připravena.
Problémy s projekty pro návrhové systémy
Když jsme spustili náš první projekt designového systému, doufali jsme, že bude vydán docela brzy. To se ale nestalo, protože projekt jednoduše ztratil prioritu. V důsledku toho bylo jeho vydání několikrát odloženo.
Nás to nešokovalo. Objednávky zákazníků byly pro nás vždy prioritou. Abyste mohli správně poskytovat své služby, musíte jednat rychle. Upřednostňování velkých interních projektů před projekty klientů často není možné.
Skutečným problémem bylo, že se náš projekt stal překážkou. Nesměl jsem znovu konstruovat nové komponenty. A náš designér musel počkat na výsledky těchto samotných vyhledávání, protože jsme použili proces známý jako Waterfall. Bylo to jednoduše proto, že tým cítil, že nám není dovoleno pracovat na nových součástech.
Letos jsem se zúčastnil přednášky Sandera Hougendorna, agilního trenéra, řečníka a spisovatele. Mluvil o Agile, Scrumu a o tom, jak pronikají do moderního vývojového prostředí softwaru. Podle něj musíme přestat dělat projekty. Tato práce mě zaujala, i když pracuji pro agenturu, která vydělává peníze právě na těchto projektech.
Řešení navržené Sanderem bylo nepřetržité provádění. Nejedná se o nový koncept a v poslední době se mu dostává stále větší pozornosti. Zejména v DevOps, kde jsou spouštěcí cykly aktuálně většinou automatizované. Kontinuální provádění rozděluje funkce na menší části, které lze uvolnit, až budou připraveny.
Důvod Tato metoda se mi líbila, byla to naše design design systému se nezastaví. A zároveň máme stále více komponent čekajících na výzkum, design a vývoj.
Naše zdroje byly omezené a navigační komponenta byla příliš těžkopádná, což zastavilo vývoj dalších prvků. Bylo jasné, že zde nefunguje konstrukční systém.
Zlepšení procesu vývoje designového systému
Když jsme dali dohromady tým, chtěl jsem, aby byl proces vývoje designového systému trochu jako hádanka. To by poskytlo jasnou představu o tom, co bychom měli skončit.
Když jsme narazili na slepou uličku, skládačka byla skvělou příležitostí znovu navštívit náš proces Waterfall/SCRUM a určit, zda můžeme těžit z nepřetržitého provádění. Současně pracuje současně na velkém počtu komponent.
Nenašel jsem žádnou podporu týmu. Lidé neviděli potřebu změnit status quo a byli si jisti, že mají pravdu podle předem schváleného harmonogramu. Abych je rozveselil, promluvil jsem s jedním z našich ředitelů.
Pracoval jsem s ním na našem prvním konstrukčním systému a věděl jsem, že můj nápad schválí, pokud nám pomůže standardizovat. Když jsem mu řekl, že náš designový systém se stal překážkou, naplánoval schůzku s týmem, aby diskutoval o vytvoření dalších komponent.
Na stejném setkání jsem se pokusil vysvětlit, co je podstatou skládačky. Řekl jsem vám přesně, jak to funguje a co může nakonec dát, a poskytl jsem všechny potřebné materiály. Řešení však bylo nalezeno velmi rychle. Spočívalo to v nedostatku společného chápání našeho stávajícího procesu.
Někteří nevěděli o existenci cyklu vydávání iniciovaného naším webovým vývojářem. Jinými je způsob, jakým byly nainstalované balíčky v základně kódů použity při vydání komponent. A další dokonce ani netušili, že jsme zpožděni a že ve Figmě už máme startovací sadu.
Nakonec jsme hádanku nevyřešili, ale pouze jsme diskutovali o tom, jak můžeme věci dostat ze země. Počáteční zadání našeho projektového manažera bylo rozšířeno přidáním výzkumu, designu a vývoje dalších komponent. Bylo rozhodnuto shromáždit tyto stejné komponenty v nevyřízených položkách a na kanbanové desce.
Abych zdokumentoval tato rozhodnutí, rozložil jsem na stůl hádanku. Tímto způsobem jsem získal zpětnou vazbu od týmu, aniž bych musel organizovat další schůzku.
Proces vykreslování
Náš proces začíná standardizací týmu návrhových systémů. Máme obecný nevyřízený obsah obsahující seznam komponent, které chceme vytvořit. Tyto komponenty jsou předmětem výzkumu, aby poskytly pokyny, osvědčené postupy nebo požadavky. Poté nastane návrh a vývoj těchto prvků. Po každém kroku kontrolujeme každý krok procesu.
Druhým krokem v tomto procesu je vydání. Během vývoje musíme vybrat balíček Composer pro instalaci pro každou komponentu. Položky jsou poté v těchto balíčcích vydány vedoucím vývojářem.
Když je komponenta vydána v balíčku, můžeme ji zpřístupnit „k dispozici v kódu“ na obr. Toto je sděleno našemu designovému a vývojovému týmu na schůzkách, technických schůzkách nebo e-mailem.
Dokud se komponenty používají, můžeme pochopit, jak fungují. Zkušenosti designérů a vývojářů lze měřit pomocí průzkumů. Můžete měřit čas strávený přizpůsobováním komponent pro klienty pomocí protokolů. Uživatelská zkušenost se měří pomocí testů použitelnosti, průzkumů nebo webové analýzy.
Každý z těchto parametrů může způsobit buď vytvoření nové komponenty, nebo aktualizaci existující. Tyto požadavky by měly být zaslány našemu vývojovému týmu systému.
V tuto chvíli ještě nebyly tyto metriky nakonfigurovány speciálně pro náš návrhový systém. Ale už šetříme čas prováděním testů použitelnosti a shromažďováním analytických údajů. Tyto metriky lze v budoucnu převést na zpětnou vazbu pro náš tým.
Nakonec jsme vyrobili desku Trello, abychom sledovali postup těchto komponent. Tato rada by měla být veřejně dostupná všem v naší agentuře. Děláme to tak, aby každý mohl zadávat požadavky v našem nevyřízeném stavu. V budoucnu bychom mohli tyto požadavky směrovat nastavením automatického formuláře obecných otázek, který by pak převedl všechny odeslané formuláře na karty Trello.
Dynamicky se rozvíjející proces
Přechod na nepřetržitý a flexibilní pracovní postup není snadný. Zvláště když jsou vaši kolegové zvyklí pracovat vodopádovým tempem. U klientských projektů používáme scrum a kanban jako nástroje pro hodnocení úkolů a protokolování problémů, ale design a vývoj se často v modelu vodopádu navzájem ztrácejí.
Když jsme přicházeli s novými komponentami, upřednostňovali jsme každou z nich. Poté náš projektový manažer vytvořil nový projekt, ve kterém jsme znovu a znovu prováděli výzkum, design a vývoj modelu vodopádu.
Když začal vývoj, backender načrtl nějaký kód, se kterým jsme mohli pracovat. Ale jeho práce neměla žádný design. Dokázali jsme, že dokážeme pracovat flexibilně a nepřetržitě, zapojením našeho návrháře a backendu.
V ostatních případech se priority změní a my musíme opustit předem stanovený plán. Začátkem tohoto roku jsem požádal tým, aby použil Webpack jako výchozí sběratel prostředků. Nebyl to úplně náš plán, ale potřebovali jsme modernizovat zásobník kódů a zajistit jeho kompatibilitu s moderními front-end nástroji.
O několik měsíců později se tato změna ukázala jako přínosná při hodnocení rychlosti načítání stránek na našich webových stránkách. Byli jsme schopni provést upgrady, které by bez webového balíčku nebyly možné. To zpomalilo naši práci na návrhovém systému, ale díky těmto upgradům jsme mohli vytvořit lepší komponenty.
Nejnovějším příkladem vývoje pracovního postupu je výměna nástrojů. Začal jsem používat Storybook k samostatnému vytváření a testování více variant komponent. Později jsem zjistil, že Storybook není vhodný pro zásobník kódu a pracovní postup. Stále jsem ale potřeboval místo, kde bych mohl vytvářet a testovat různé varianty naší komponenty.
Proto jsem vytvořil Storybase. Toto je balíček pro aplikace Laravel, kompatibilní s jakoukoli html komponentou, včetně vestavěných šablon Vue. Storybase zobrazuje naše komponenty na serveru, abychom je mohli během testování optimalizovat pro SEO. Také nám umožňuje simulovat data v Laravelu pro každý příběh. A konečně lze každý z nich přidat do naší dokumentace.
Když jsem vytvořil Storybase, naše komponenta pro navigaci na webu byla již v závěrečné fázi vývoje. Ale začali jsme klientský projekt s některými komponenty Snowflake, které přinesly mnoho variací. Instaloval jsem Storybase do projektu, zdokumentoval a otestoval všechny komponenty. Hodně to pomohlo přesvědčit mé kolegy vývojáře o hodnotě těchto nástrojů. Nyní plánuji použít Storybase nejen k vývoji našeho designového systému, ale také pro každý projekt klienta.
Shrneme-li to
– Nevytvářejte svůj designový systém s vodopádovým modelem nebo skrumážovými sprinty. To je pro ně příliš velký úkol. Vytvořte frontu s komponentami a zajistěte, aby úlohy pro tyto komponenty byly malé. To je nezbytné, abyste na nich mohli nepřetržitě pracovat.
– Připravte s týmem proces brzy, abyste se na jedné stránce dozvěděli, jaké kroky je třeba podniknout před vydáním součásti, kdy vytvořit nové nebo aktualizovat staré.
– Pomocí nástroje jako Storybook můžete dokumentovat a testovat varianty svých komponent. Nebo si k tomu vytvořte vlastní nástroj.
Vyhledejte další zajímavé a relevantní články v našem blogu a telegramovém kanálu.
