�ݺ�ߣ

Editor's Notes

• #2: Előadásom nagyvonalúan a design systemről fog szólni, ám munka és érdeklődési körömből adódóan inkább a UI oldalát igyekszem majd bemutatni, és mint a prezentáció végére látható lesz, ez csupán egy szelete az egész rendszernek.
• #3: A képen látható egy elemhalmaz. Távolról megvizsgálva ezekről eldönthető, hogy hasonló méretőek, hasonló funkciót töltenek be és több mint valószínüsíthető, hogy hasonló is a működésük. Egyébként ezek csavarok és anyák. Ezek képeznek egy halmazt. Ha csak ezeket az elemeket ismerem, akkor még nagyon sok mindent el tudok képzelni, hogy minek a részét képezhetik.
• #4: Ám ez csak egy része az egésznek. ha jobban vizsgálódunk és másfajta elemeket is elkezdünk keresni, rátalálhatunk ilyen kis csikóhal kinézetű távolról hasonlú, de közelebbről már eltérő tulajdonságokkal rendelkező elemekre is. Van aki esetleg már tudja, hogy ezek az elemek minek a részét képzik? Ha van, akkor milyen típusú írógép az? Ha rossz, akkor: nem, de menjünk tovább, mert vannak it még másfajta elem is.
• #5: No, itt már látható, hogy három nagyobb halmazt is el tudunk különíteni, és a második halmaznak először csak egy részét ismertük. A harmadik halmaznál pedig látható, hogy a tengericsikók megfordultak és a fejük is nagyobb lett. Ám ezekből is több féle létezik, viszont egymásmellé téve őket itt is valószínűsíthetjük, hogy működésében, funkciójában hasonló szerepet töltenek be. Itt már biztos kitaláltátok, hogy minek a részeit láthatjuk! igen, egy írógép. De milyen írógép? Mi a típusa? mikor készítették, aktuális még? Milyen a billentyűzet kiosztása, milyen rajta írni? Mekkora a súlya? Lehet még kapni? Ha igen, mennyibe kerül? És folytathatnák a kérdések sorát.
• #6: Íme, ez egy Adler Favorit típusú 1930-as években gyártott írógép részei, és mint látható jó pár elemmel rendelkezik még a korábban látottakon kívül. A kérdésekre pedig inkább aukciós oldalakon, vagy múzeumokban kereshetjük a választ. Magyar ékezetek viszont nem tartalmaz. Hogy mire volt jó ez a kis bemutató, arra kicsit később térek majd vissza, most inkább egy kis eredettörténet. 
• #7: Íme, ez egy Adler Favorit típusú 1930-as években gyártott írógép részei, és mint látható jó pár elemmel rendelkezik még a korábban látottakon kívül. A kérdésekre pedig inkább aukciós oldalakon, vagy múzeumokban kereshetjük a választ. Magyar ékezetek viszont nem tartalmaz. Hogy mire volt jó ez a kis bemutató, arra kicsit később térek majd vissza, most inkább egy kis eredettörténet. 
• #8: Egyre égetőbb kérdések fogalmazódtak meg. Hogyan lehet egy szerteágazó terméket konzisztensen megtervezni? Hogyan tudjuk az iterációkat értelmezhető határokon belül tartani, mind idő, mind erőforrás tekintetében? Hogyan lehet a megnövekedett tervezői csapatokat egy olyan mederbe terelni, ahol a termék is jól érzi magát, de nem vágjuk el a torkát a kreativitásnak sem? Egyre több cikk, majd könyv foglalkozott a problémával és egyre többen látták a megoldást a szabványosításban, a lefektetett, előredeffiniált munkafolyamatokban. Ezzel egyidőben a szoftvergyártók is kezdték ebbe az irányba fejleszteni programjaikat és próbáltak megoldást nyújtani a felhasználói felületeket tervező emberek számára. A Photoshopot szép lassan leváltották a célszoftverek. Így jutottunk el mi is, az fps-nél a Figmáig, mert láttuk, hogy mennyi felesleges erőforrás egy-egy psd, neadj isten ai elkészítésénél, azok módosításánál, nem beszélve a tervek fejlesztői környezetbe történő implementásáról. 
• #9: Emlékeztek az írógépes hasonlatra. Ott is sok-sok elem alkot egy egészet, amiket valahol valaki kitalált, finanszírozott, összerakott rá egy csapatot, valaki megtervezett, legyártott, valaki összerakta és valaki kipróbálta, aztán valakik használták azt. Ha a képeken látott elemek közül egy hiányzik, vagy épp hibás, máris nem működött volna jól, vagy nem úgy működött volna az írógép, ahogy azt szerették volna. Nincs ez máshogy a digitális termékek világában sem. Ha csak egy elemkészletet látunk, amit esetünkben hívhatunk UI kitnek, abból még sok mindent össze tudunk rakni, és ahány ház annyi szokás. Ahhoz, hogy úgy történjenek a dolgok a kezdetektől a felhasználói visszajelzésekig, és az ezekből történő módosításokig, ahogy azt szeretnénk, abban lehet nagy segítségünkre a design system. 
• #10: OK, de kell ez nekem? Spoilerezek egy kicsit és elmondom a válaszom. Több mint valószínű, hogy nem. Viszont maga a rendszer olyan elemekre bontható, és olyan megoldásokat tartalmaz, amik segíthetik a későbbi munkádat, még akkor is, amikor nem használod ki az egészet. Ha az alábbi listából a termékre, amivel foglalkozol ráismersz, akkor a válasz igen, innen tudsz mertítkezni és megéri belevágni bizonyos részekbe. Olyan terméken dolgozol…: amikor fontos a hasonló megjelenés és a hasonló viselkedés - konzisztens felület ahol ismétlődő UI komponenseket kell használni – akár egy komplex site ahol ismétlődő kevés funkcionalitás tartalmazó UI elemekkel dolgozol amikor white label, vagy template maga a termék amikor folyamatosan, visszatérve  módosítani kell a felületen – termékfejlesztés amikor különböző “tech stack”-ekkel dolgozol – akár már van a terméknek applikációja és weboldal is
• #11: Mik az előnyei? egy központi helyen kezeled a UI elemeket időt és ezáltal pénzt takarítasz meg nagyban növeli az egységességet csökkenti a karbantartási időt a tervezőknek: átláthatóbb és könnyeben kezelhető felületek gyorsabb globális módosítási lehetőség rövidebb iterációs hossz, ezáltal több megoldási javaslat, ami a végén nagyobb elégedetséget is szül, nem csak a felhasználóban, hanem a tervezőben is. a fejlesztőknek: kevesebb idő a UI elemek megismerése csökken a refaktorálásra fordított idő következetes implementáció lehetséges persze ezekhez szükséges a szoros együttműködés, és a megfelelő kommunikációs csatornák megléte, ami jelenthet akár egy dokumentációt, vagy élőbeszédet is üzleti oldalon: időt spórol→pénzt teremt ezt a folyamatot már nehéz lesz visszafordítani jó a felhasználónak és az ügyfélnek hisz egyre jobb terméket kap; jó a dolgozóknak, mert a munkafolyamatai átláthatóbbak és egyre több ideje marad a kreatív ötletelésre;
• #12: Fontos: Ami nagyon fontos, hogy ha egy teljes, átfogó design systemet próbálunk készíteni, akkor az nagyon költséges folyamat. A megfelelő emberek, a csapat felállítása. A tervezők meghatározzák a rendszer vizuális elemeit Front-end fejlesztők moduláris, hatékony kód létrehozásához Szántai Karcsi – legyen egy akadálymentes szakértőd hogy a rendszer megfeleljen nemzetközi szabványoknak Tartalomstratégák – akik segíthetnek a csapatnak a rendszer hangjának és hangjának megszólalásában Olyan kutatók, akik segítenek megérteni az ügyfelek igényeit Teljesítmény-szakértők, akik biztosítják a rendszer gyors betöltését minden eszközön A termék menedzserei biztosítják, hogy a rendszer megfeleljen az ügyfél igényeinek Vezetők (VP-k és igazgatók), hogy az egész vállalatot, beleértve a vezetői vezetést is, elsajátítsák és összehangolják a jövőképet Ennek a csapatnak az összeszokása, a megfelelő edukálás, a csapat számára  leginkább kézreálló módszertanok megtalálása, hogy segítsék és ne hátráltassák egymást. És persze maga a termék üzleti és felhasználói oldalról történő megismerése is időigényes. Erről lehetne bővebben beszélni, de az inkább már design menedzseri feladat lenne. Mi összpontosítsunk inkább a UI oldalára továbbra is. 
• #13: Hogyan kezdjünk neki? Nathan Curtis design system evangélista  szerint – Design system is not a project. It's a product, serving products. – Azaz ez nem egy projekt, hanem egy termék, Ez egy olyan termék, amely termékeket szolgál ki. Így is kell nekifogni. Meg kell tervezni magát a tervezést. Fontos, hogy mindig határozd meg a célokat, mit szeretnél elérni és milyen problémát akarsz megoldani. Ne vegyél bele olyan dolgokat, amik majd egy esetleges problémára adhatnak választ. Ennek persze vannak a UI részén kívül más vetületei is a rendszer tekintetében, de maradjunk fókuszban. 
• #14: UI audit Ha egy olyan helyzetet nézünk, amikor redesign szükséges, akkor mindig nagy segítségünkre lehet a CSS Stats oldala. Bocs srácok, de most a szallas.hu oldalát vettem alapul. Ahogy a képen is látható, 425 betűméret, 726 szín, 315 hátrészin… És persze tudom, hogy ez nem a valóság, és szerencsére nem ez látható az oldalon, de ha azt a feladatot kapnám, hogy tervezzem újra és ezeket a számokat látnám csak, menten sarkon fordulnék, vagy kérnék 1 évet a tervezésre. Természetesen, ha egy olyan termék tervezése a feladat, ami tiszta lappal indul, akkor sokkal szerencsésebb helyzetben vagyunk. Egy ilyen rendszernél az előző lépést kihagyhatjuk és egyből elindulhat a vizuális nyelv létrehozásához az új termékhez.
• #15: A vizuális nyelv megszületése UI tekintetben ez a mi feladatunk. Megalkotni egy termék vizuális nyelvezetét. Ha feldaraboljuk a vizuális rendszer elemeit, akkor a nyelvezetünket a következők alkotják: Színek Tipográfia (méret, vezető, betűtípus stb.) Méretezések, eltartások (margók, dőlések, igazodások, határmetszet) Ikonok (igazából képek, ikonok, illusztrációk) Egy szofisztikáltabb nyelvezet a következőket is tartalmazhatja: Vizuális formák (mélység, magasság, árnyékok, lekerekített sarkok, textúra) Mozgás Hang Ám mielőtt tovább mennénk, két dolgot is meg kell említeni. 
• #16: Az egyik a design tokenek. A tokenek a design system "szubatomikus" alapjai. Biztos sokatok hallotta, olvasta már Brad Frost Atomic design címú könyvét, mondhatni kiáltványát. Ezt az analógiát követve születtek a szubatomikus design tokenek is. Ezek azok a  legegyszerűbb elemek, amik tartalmazzák azokat az adatokat, amik egy atomi szintű elemnek az alaptulajdonságait tartalmazzák. Ilyenek a név, és azok az egyszerű változók, amik meghatározzák majd a későbbi elem egyes részeit. Például a lekerekítés nagysága, a vonalvastagság, annak stílusa stb. Fontos, hogy ezeket az elejétől egy helyen kell alkalmazni és a későbbi komponensekbe be kell építeni, hogy megmaradjon a konzisztencia és csökkentse a design system kezelésének terhét. 
• #17: Dokumentáció A másik ami nem szoros része a vizuális nyelvnek, az pedig a dokumentáció előkészítése. Ebben már nagyon hasznos, ha egy követ fújtok a front-endessel, mert akkor már az elejétől közösen tudtok egy olyan listát készíteni, amiben felvezethetitek a elemeket, azok neveit és egyedi tulajdonságait. Ki-ki majd kitölti a maga celláját, de a lényeg, hogy legyen egy élő lista, amit segíti mindkettőtök munkáját.
• #18: Színek Olyan nagy újdonságot nem kell azért várni, inkább csak a rendszerhez igazított momentumokat emelem majd ki. Természetesen jó, ha foglalkoztál színelmélettel, így könnyeb dolgod van. A színharmóniák mellet viszont mindig figyelj a kontrasztokra. Építsd be és használd a UI elemek részeként a brand színeit és úgy általánosságban az eddig használt módszerek működni fognak. Alkalmazz hierarchiát és alkoss csoportokat a színeknek, hogy később egy könnyeben tudjál rá hivatkozni. Válaszd külön az elsődleges, másodlagos színeket, a informális színeket és a szürke skálaidat is határozd meg. Felül ha ,már az elején felkészülsz az árnyalatokra, akkor később meg lehet akadályozni a színek elszaporodását is. Már ekkor kezdj el a lehetőségekhez mérten állapotokat rendelni a színekhez, amik a nevükben is megjelenhetnek. Ami újdonság, hogy a digitális termékek korában is elérkeztünk ahhoz az állapothoz, mint amit a tördelőprogramok a kezdetektől alkalmaznak. Definiálj és alkoss stílusokat! Ez nagyon megkönnyíti az egység egyben tartását, és a későbbi globális módosítást is. Ezen felül segít neked is, hogy fókuszban maradj a tervezés során. Amikor pedig a fejlesztő próbálja a munkádból kiolvasni a a színeket, akkor végre nem találja magát szemben a 30 féle kékek állapotával.
• #20: Tipográfia Ahogy a színeknél itt is a tipográfiai ismeretek használata révén olyan nagy újdonságokat nem fogunk tapasztalni. Sőt! Sokkal inkább egy tördelő program adta lehetőségek kezdenek itt is megjelenni. Skálázz! –az egyik a méretezési rendszerek bevezetése. Itt is találhatsz számos mintát és kiválaszthatod a termékedhez a megfelelőt. Erre számos mintát lehet a neten találni, az aranymetszéses méretezéstől a négyes alapúig. Erre egy jó kiindulási pont a type-scale.com oldala, ahol előre beállított arányokkal kísérletezhetsz. Reszponzív – az előbb említett méretezési standardoknak köszönhetően a reszponzívitással kapcsolatos problémák is leegyszerűsödnek Segédvonalak – ahogy a színeknél is, itt is eljönnek a tördelőprogramok vertikális segédvonalai, amikhez igazíthatod a sortávolságot, és ezzel is könnyeben megtudod teremteni a vizuális egyensúlyt. Fent-lent – ami még fontos egy rendszer építésekor a tipográfia tekintetében, hogy már az elején igyekezz meghatározni, az eltartásokat. Sokat tudsz spórolni amikor már oldalakon használod a és nem csak a Shift+nyíl nyomkodásával tolod el a betűtörzs, vagy betűszár aljától, tetejétől a következő szövegblokkot. Ez egyébként egy örök dillemma, hogy mely betűk, mettől-meddig határozzák meg a vertikális méretüket. Tapasztalataim alapján úgy jársz a legjobban, ha inkább a lelógó és felnyúló betűszárakat veszed alapul, aljának, illetve tetejének. Stílusok – és az elmaradhatatlan stílusok. Ezt inkább nem is magyarázom, hanem egy videóban gyorsan bemutatom, hogy miért működik végre ez remekül a Figmában.
• #21: Ahogy látható, ha az elején nem spóroltuk ki a stílusok elkészítését, akkor nagyon könnyen tudunk olyan módosításokat elvégezni, ami globálisan is hatással lehet az aktuális munkákra.
• #22: Méretezés és eltartások Keresd meg – Erre is sok direktíva létezik és akár már a fejlesztésben is alkalmazott keretrendszereket is alapul veheted. Következetes – A lényeg, hogy az elején tedd le a voksod egy mellé, mert ez mind a fejlesztésben, mind a további tervezésben lényeges méreteket fog meghatározni. Kivételek – Amit én mostanság előszeretettel használok az a 8-as, vagy 4-es osztás. Amikor ki kell lépnem a 8-as bűvköréből, akkor is igyekszem azt elszigetelt és egyedi esetnek megtartani és törekszem külön jelezni egy kommentben a fejlesztő felé, hogy itt a standarizált méretektől eltérő esettel van dolga.
• #23: Ikonok Ez az elmúlt években egy külön elszeparált munkakörré fejlődött. Olyan szabályokat kezdenek alkalmazni, amikbe jómagam már nem biztos, hogy biztonságban érezném magam, így még nem merészkedtem bele. Az evidens értelmezhetőségi, felismerhetőségen túl vannak designerek, akik a következőket is igyekeznek egységesíteni: Optikai gridek – a befoglaló és maga az ikon elhelyezkedésé azon belül Pixel gridek – itt nem csak a pixelpontosság, hanem a körvonalak igazodását is előre meghatározzák A méretezési standardok bevezetése → 24 → 36 → 48 →72 És ami a legfontosabb, a tiszta SVG-k készítése. Ez már olykor inkbb front-endes feladatba csúszik át, mert a grafikai programok még mindig szemetelnek exportálás közben. De mondom ilyen mélységekig még én se merészkedtem. Ahogy a képen látható igyekszem úgy építeni az ikonokat, hogy azért megfeleljenek a standardoknak, de inkább a felhasználói és nem az ikon tervezői oldaláról szoktam közelíteni. Amikre figyelek az ikonoknál Egységes méretezések és azok skálázása. Az elnevezések, és azok helyes használata. Komponensbe ágyazás, a könnyebb kezelhetőség miatt. A befoglaló és maga az ikon külön választása. A képen egyébként a Material Design 2 legújabb ikonkészletének elemei láthatóak egy éppen folyamatban lévő termék tervezése során.
• #24: Az alábbi videó azt szemléltetem, hogy mennyire könnyíti meg a komponens alapú tervezés a szükséges módosításokat. Ebben az állapotban 3 méretben láthatjátok ugyanazt az ikont, aminek a legnagyobb mérete a mesterkomponensem, így amikor változtatást kell végeznem, elég csak egy helyen módosítanom, és az mindenhol megtörténik. Most képzeljétek el, hogy mennyi helyen használhattok egy ikon, és mennyi változtatást kellene végezni egy ilyen egyszerű ügyfél igénynél.
• #25: És amikor végig mentetek ezeken akkor itt kezdődik maga a Pattern Library. Különböző mélységekben és eltérő megoldásokkal lehet találkozni, ha elkezded bele ásni magad a témába. A lényeg, hogy kezdjétek el strukturálni azokat a munkafolyamataitokat, aminél a legnagyobb erőforrás veszteséget érzitek és aztán majd ha tényleg szükségességét érzitek, belevághattok a saját Design Systemetekbe. Remek kis gyűjtühely a napokban megjelent designsystemsrepo.com, ahol a már megvalósult és kódszintre átültetett felületek listáját találjátok.
• #26: Az utolsó videón pedig már egy olyan komponens alapú elemeket láthattok, amik alacsonyabb szintű elemekből épültek fel. Itt már előre lettek definiálva az eltartások és igazodások, ám így is sokkal könnyben tudod a fejlesztő, vagy ügyfél felé prezentálni egy beviteli mező reszponzívitását. Íme.
• #27: És hogy mennyi minden tartozik egy valódi design system alá? Az az alábbi képen látható, hogy a UI miért csak egy apró szelete az egész rendszernek.