Řekneme vám, jak a proč se Paradigm, jeden z prvních návrhových systémů v Rusku, změnil.
Fórum 
O nás návrhových systémů již bylo mnoho řečeno a napsáno. Návrháři prošli dlouhou cestu od projednávání šablon v aplikaci Sketch ke komponentám v kódu a od komponent k návrhovým rámům a hranicím konzistence. V tomto článku nebudeme hovořit o tom, jak vytvářet návrhové systémy, ale o tom, jak s nimi žít: co dělat, když systém již nefunguje, jak jej přestavět a jak jej „prodat“ kolegům.
Návrhový systém skupiny Mail.ru se objevil v roce 2015. Naším cílem bylo optimalizovat aktualizace produktové řady a původně jsme právě pro tento úkol vylepšili Paradigm.
Zaměřili jsme se na maximální univerzálnost: přizpůsobivost, opakovaně použitelné komponenty, design a připojení kódu. K tomu byly vytvořeny základní principy konstrukčního systému, základní dokumentace, sady uživatelského rozhraní, designové tokeny a komponenty. Yura Vetrov o tom mnohokrát hovořil a Andrey Sundiev, který byl v těchto letech zodpovědný za vývoj designového systému, napsal článek.
Hlavním principem paradigmatu na začátku byla myšlenka, že konzistence nad místní optimalizací . Na začátku fungovala skvěle, když jste museli přepracovat hodně produktů najednou. Jakmile se však produkty začaly aktivně vyvíjet samostatně, každý v souladu se svými schopnostmi a strategií a svou vlastní rychlostí, princip nám přestal pomáhat. Schopnosti paradigmatu již nestačí: podmínky se změnily a máme nové požadavky.
Problémy se sjednocením
V první verzi návrhového systému se jakákoli změna dotkla několika produktů najednou. Například změna řádkování ve Zprávách by mohla zničit typografii v nastavení e-mailového účtu.
Zpočátku byla přísná pravidla vynikající při udržování chaosu na uzdě, ale postupem času se stala předmětem vášnivých debat návrhářů. Produkty se vyvíjely různou rychlostí a mnoho z nich má specifické potřeby. Produktoví manažeři navíc stále častěji slyšeli, že jejich nápady a návrhy nelze implementovat, protože nedodržují pravidla designového systému. To přirozeně vedlo ke zvýšení nedůvěry v paradigma.
Stále častěji jsme se začali potýkat se situacemi, kdy tým vypracoval dobré lokální řešení, ale není možné jej rychle zavést do návrhového systému. Aby bylo řešení univerzální, bylo nutné jej otestovat pro všechny projekty a položky, kde existuje podobný scénář. Trvalo to hodně času: schůzky se zpozdily a rozhodování se stalo obtížnějším. Myslím, že každý, kdo má zkušenosti s designovým systémem, který existuje již několik let, se s něčím podobným alespoň jednou setkal.
Problémy s technologií
Do jednotná knihovna komponent pro frontend , ale postupem času jsme si uvědomili, že tato myšlenka má také několik hmatatelných nevýhod.
Všechny projekty měly různé potřeby: Novinky vyžadovaly přizpůsobivost a schopnost pracovat s různými formáty médií, Mail – témata a nástroje pro vytváření panelů nástrojů a formulářů. K rychlému vývoji a údržbě tak složitého rámce byl zapotřebí velký vývojový tým, ale nebyly pro něj k dispozici žádné prostředky.
Kromě toho v té době vývojové týmy používaly různé technologie, měly specifická technická omezení a procesy.
Dobrým řešením pro nás pak byly návrhové tokeny , které nám stále pomáhají synchronizovat parametry návrhového systému pro různé produkty.
Problémy s důvěryhodností
Navzdory všem technickým a procesním obtížím byl hlavním problémem paradigmatu < b> nedůvěra k ní . Produktoví manažeři se zdráhali systém používat, protože způsoboval mnoho omezení a znemožňoval pomalé a obtížné navrhování nových rozhraní. Návrháři ne vždy používali paradigma, protože bylo obtížné schválit nová řešení.
Produkty postupně začaly vytvářet svá vlastní lokální řešení, aniž by o nich diskutovaly s ostatními členy designového týmu. Postupem času se tato řešení stávala stále více.
Zdá se, že se jedná o dlouhý seznam problémů, ale ve skutečnosti všechny vznikly ze stejného předpokladu: na všechny otázky jsme se snažili odpovědět jedním univerzálním nástrojem .
Od taktiky ke strategii
Abychom definovali novou strategii pro návrhový systém, obrátili jsme se k zásadní otázce: Co pro nás dnes znamená paradigma?
Po provedení všech technických výhod spojených s optimalizací jsme si uvědomili, že designový systém by měl být uživatelsky přívětivý pro designéry, flexibilní pro manažery a jejich produkty, srozumitelný pro vývoj – a inspirativní .
Je to pro nás důležité:
-
vytvořit bezproblémovou uživatelskou zkušenost,
-
poskytnout návrhářům pohodlný nástroj pro práci,
-
rychle experimentujte v rozhraní,
- zefektivnit vývoj a návrh běžných úkolů.
Když sami návrháři nejsou tímto nástrojem nadšení, jeho význam zmizí. Návrhový systém by měl být pohodlný a srozumitelný pro lidi, kteří s ním pracují. Pokud pravidlo vypadá teoreticky logicky, ale v praxi s ním nelze pracovat, opustíme toto pravidlo nebo jej lokalizujeme.
Takto jsme vytvořili nové principy designu.
Na prvním místě jsou zájmy produktů. Existuje designový systém, který vylepšuje výrobky. Principy sjednocení by neměly být v rozporu s produktovými řešeními a obchodními potřebami.
Obecná pravidla pro značku, místní pravidla pro skupiny produktů. Obecná pravidla pomáhají udržovat povědomí o značce a místní pravidla pomáhají rychle řešit typické úkoly.
Flexibilní možnosti přizpůsobení. Parametry by měly zohledňovat potřeby produktů a jedinečná řešení by měla být lokalizována v rámci produktu nebo skupiny produktů a neměla by být vyloučena z návrhového systému.
Nový vizuální jazyk
Buďme upřímní, taková technická věc, jako je designový systém, ne každého zajímá. Někdy je třeba jej „prodat“, mimo jiné vizuálním jazykem. Jedním ze zjevných poznatků bylo, že „hezké obrázky“ inspirují nejen designéry, ale také manažery a vývojáře. Proto jsme se rozhodli aktualizovat vizuální styl a veškerou komunikaci pro návrhový systém.
Například konceptuální umění na obálkách sady UI Kit v komunitě Figma je volitelné, ale sloužilo jako estetický odkaz pro designové týmy a manažery. Návrhový systém není vždy o kráse, ale díky kráse jsme začali navracet důvěru Paradigmu .
Kromě standardů kvality grafiky bylo pro nás důležité položit ve vizuálním jazyce náš přístup k designu produktu. Hodně jsme to promítli do technických ilustrací a aktivně jsme využili vývoj z hackathon na webu design.mail.ru, který jsme spustili minulý rok. Takto paradigma získalo svůj vlastní jedinečný vizuální jazyk.
Úrovně synchronizace
Díky uvolnění kontroly nad změnami jsme dali návrhářům a manažerům kreativní příležitosti a shromáždili mnoho požadavků a poznatků. Pokud by však tato praxe pokračovala dále, bylo by nemožné udržet v chaosu integritu.
Abychom tento problém vyřešili, zavedli jsme úrovně synchronizace mezi produkty.
Globální: pravidla, která pomáhají udržovat konzistenci značky.
- Branding
- Paleta
- Fonty
- Ikony
- Červené zásady
Je pro nás důležité vytvořit jednotný zážitek ze značky. Když uživatel přechází z jednoho firemního produktu na jiný, neměl by vidět různé weby se stejným logem. Logo nekončí u loga, takže vizuální jazyk a pravidla pro práci s ním jsou společné všem.
Místní: pravidla relevantní pro skupiny produktů.
< ul>
Produkty jsme rozdělili do dvou skupin – „Produktivita“ a „Média“ – a zavedli jsme pro ně lokalizovaná pravidla. Například vzorce spotřeby obsahu na různých mediálních projektech skupiny Mail.ru jsou podobné, takže je logické je navrhovat podle stejných principů.
Unikátní: pravidla pro konkrétní produkt.
- Místní ilustrace
- Místní typografie
- Rozšířená paleta
- Místní sada uživatelského rozhraní
Každý produkt je jedinečný a existuje ve svém vlastním kontextu. Na webových stránkách automobilů a na charitativním portálu nemůžeme použít stejný grafický styl. Proto dáváme svobodu tam, kde to produkt potřebuje, ale vždy se snažíme, aby místní pravidla byla konzistentní.
Paradigma mělo dobrou technickou základnu, perfektní pro provedení těchto změn. Neopustili jsme zásady, které byly stanoveny v návrhovém systému od samého začátku – pouze jsme je učinili pružnějšími.
Dobrá a špatná pravidla
Hlavní výzvou při práci na změnách v konstrukčním systému bylo nalezení rovnováhy mezi omezeními a možnostmi. U každého pravidla musíme mít odpověď na otázku „Jak nám to pomáhá?“ Pokud není odpověď, pak takové pravidlo není nutné. Například měřítko jednoho písma pro „Média“ a „Produktivita“ nebude fungovat u poloviny produktů a nepřinese nám žádné výhody, proto jsme ji opustili.
Návrhový systém by neměl omezovat vývoj produktu – naopak, by měl poskytnout nástroje pro řešení problémů.
tým návrhového systému
Vytvořili jsme malý, ale flexibilní tým, který formuluje obecná pravidla a v případě potřeby synchronizuje produkty. Takový proces by měl být postaven na důvěře návrhářů.
Přechod od rigidního rámce k flexibilnímu systému byl obtížný. Jakmile bylo více svobody, vizuální jazyk a vzory v rozhraních se začaly „plazit“. Ale tato fáze byla zásadní pro budování důvěry mezi designéry a Paradigmem. Pro nás bylo důležité, aby každý pochopil, že do systému návrhu mohou a měla by být zavedena nová řešení.
Úkolem týmu návrhového systému není vytvořit dokonalou sadu nástrojů, ale synchronizovat a optimalizovat. Někdy je snazší nastavit procesy a pomoci ostatním návrhářům vytvářet vlastní řešení.
Sady uživatelského rozhraní jsou dobrým příkladem agility týmu Paradigm. Tým návrhového systému vytváří základní sady uživatelského rozhraní s hlavními komponentami a zpracovává nejen jejich obsah, ale také strukturu a rovnoměrný design. To vám umožní vytvořit jednotné designové standardy a zachovat integritu i v dokumentaci.
Na základě těchto šablon pak každý projekt vytvoří své vlastní sady uživatelského rozhraní a tým Paradigm je podle potřeby synchronizuje. Například Paradigm obsahuje sadu uživatelského rozhraní se základní paletou, zatímco Mail obsahuje sadu uživatelského rozhraní s buňkami písmen, přílohami dopisů atd.
V průběhu času tým návrhového systému nashromáždil velké množství znalosti o různých produktech a stal se centrem pro odborné znalosti produktů.
Oznámení o změnách
Dalším poznatkem pro nás bylo, že musíme pravidelně informovat své kolegy z projektů, které pracují se systémem návrhu, o práci na Paradigmu. Koneckonců, bez ohledu na to, jak propracovaný je systém, nebude fungovat, pokud o něm nikdo neví.
Zavedli jsme kanály, kterými informujeme kolegy o aktualizacích a spuštěních. Aktivně se věnujeme změnám v paradigmatu na ukázce Mail Design (událost pro všechny designéry ve skupině Mail.ru Group) a na kanálu v našem korporátním messengeru Myteam. Píšeme o velkých novinkách v seznamu adresátů a příspěvcích na intranetu. Pro všechny tyto činnosti používáme stejný vizuální jazyk návrhového systému.
Znalostní databáze
Návrhový systém by měl pomáhat řešit problémy, někde určovat standardy, někde být Wikipedií pro designéry. Aktivně rozvíjíme znalostní základnu ve stejném prostoru jako návrhový systém. Na webových stránkách Paradigm najdete jak pokyny, tak sady uživatelského rozhraní, stejně jako doporučení pro postup a řešení konkrétních problémů. Díky tomu je návrhový systém jasnou součástí pracovního postupu a pomáhá návrhářům neztrácet čas hledáním informací.
Ponecháváme interní dokumentace v Notionu a některé její části jsou automaticky publikovány na webu paradigm.mail.ru.
Závěr
Jakýkoli systém dříve či později začne zastarávat, ale to není znamenat, že je třeba ho opustit. Vývoj designového systému je proces, který by se neměl zastavit. Změna pravidel, která jsme si sami vytvořili a vyvinuli, je obtížná, ale nutná, protože nám umožňuje zachovat v každém nástroji to nejdůležitější – jeho relevanci.
Na našem pracování pracovalo mnoho silných specialistů a dobrých lidí návrhový systém. seznam, který jsme zde shromáždili.
Pravidelně aktualizujeme návrhovou dokumentaci v komunitě Figma, oznamujeme události a zveřejňujeme volná místa na design.mail.ru, udržujeme facebookovou stránku našeho týmu a samozřejmě , zveřejněte celou tuto krásu, kterou jste viděli výše, na Dribbble.
