Miért nem sikerült a tervezési rendszerek Una Kravets által

2018. június 25

Az An Event Apart Bostonban vagyok, ahol Una a tervezési rendszerekről fog beszélni, a Yesenia kiváló tervezési rendszerekről szóló beszélgetésének folytatásaként. Megpróbálom élőben blogolni ...

Una a Bustle Digital Group-nál dolgozik, amely rengeteg különböző tulajdonságot tesz közzé. Korábban a Watsonnál, a Bluemixnél és a Digital Oceannél dolgozott. Mindegyikben van valami közös (azon kívül, hogy kék van a logójukban). Mindegyiküknek meghibásodott tervezési rendszere volt.

A tervezési rendszerek jelenleg olyan forróak. Lehetővé teszik számunkra az összetett gondolkodást és a gyors növekedést. Rengeteg példa van, például a Shopify Polaris, a Salesforce Lightning design rendszere, a Zendesk Garden, a Gov.uk és a Code For America. További példákért tekintse meg Anna kitűnő styleguides.io-ját.

Mi is pontosan egy tervezési rendszer?

Ez egy tág kifejezés. Ez lehet stílusvezetõ vagy látványminta könyvtár. Ez lehet tervezőeszköz (például egy Sketch fájl). Ez lehet egy komponens könyvtár. Ez lehet a tervezés vagy a fejlesztés használatának dokumentálása. Lehet hang- és hangutasítások.

Styleguides

Amikor Una a főiskolán járt, nyomtatással foglalkozó márkázási munkája volt - fejléces, helyhez kötött stb. Ezt a tervezési útmutatót feltette az internetre. Voltak színei, címsorai, típusa, logókezelései stb. Nem egy alkalmazáshoz készült, hanem egy tervezési rendszer.

Tervező szerszámok

A Github alapozója jó példa erre. Letölthet előre elkészített ikonokat, színeket stb.

Alkatrészkönyvtár

Itt kapod meg a kódot. Una a Digital Oceannél dolgozott a BUI-n, amely leírta az egyes komponensek interakciós állapotait és azt, hogy miként lehet testre szabni az interakciókat a JavaScript-szel.

Kódhasználati irányelvek

Az AirBnB-nek erre nagyon jó példája van. Ez egy következetes kódstílus. Akár beépítheti az építési lépésbe az eslint-config-airbnb és a stylelint-config-airbnb segítségével .

Tervezési használati dokumentáció

Az IBM Carbon nagyszerű munkát végez ebben. Leírja a minta használatának eldöntésének kritériumait. A felhasználói élmény szempontjai vezérlik. Vannak általános irányelveik az alkatrészek betöltésére - üres állapotok stb. És tartalmaznak animációs irányelveket (külön a Carbon-tól), amelyek az IBM mágnesszalagos gépeinek és írógépeinek történetére épülnek.

Hang és hang iránymutatások

Természetesen itt a Mailchimp a klasszikus példa. Megszakítják a hangot és a hangot. A Voice nem csak az, ami a cég, hanem az is, ami a vállalat nem:

Szórakoztató, de nem buta,
Magabiztos, de nem beképzelt,
Okos, de nem kemény,
stb.

A Voiceandtone.com leírja a felhasználó érzéseit különböző pontokon és azt, hogy miként kommunikálhat velük. Vannak irányelvek az alkalmazást használók számára, valamint iránymutatások a vállalati hírlevél olvasói számára, valamint iránymutatások a blog olvasói számára stb. Még arra is van példa, hogy mikor mennek rosszul a dolgok. Az irányelvek tippeket adnak az emberek hatékony segítéséhez.

Miért buknak meg a tervezési rendszerek?

Una most azt kérdezi, hogy a szobában ki kezdett már diétát. És ki fejezte be valaha a diétát? (Sok kéz lemegy).

Senki sem használja

A Digital Ocean-nél volt egy Buoy version 1 nevű tervezési rendszer. Una segített a Float nevű tervezési rendszer felépítésében. Volt egy BUI 2. verzió is. A bója a termék, a Float a marketing oldal volt. Klasszikus példa a 927-re. Senki sem használta őket.

Una ellenőrizte a végső kimenet CSS-jét, és a tervezési rendszer kódja csak a kódbázis 28% -át tette ki. A CSS nagy része túlterhelte a CSS-t a tervezési rendszerben.

A boldog tervező rendszerek skálázzák a jó színvonalat, egységesítik az alkatrészstílusokat és a kódot, és csökkentik a kódolódást. Miért tették fel az emberek a meglévő rendszer használata helyett? Mert mindenkit különböző mutatók alapján ítéltek meg. Néhány csapatot a szállítási szolgáltatások alapján ítéltek meg, nem pedig tiszta kódot készítettek. Tehát a boldog tervezési rendszerek előnyei nem vonatkoznak rájuk.

Beruházás

Olyan, mintha edzőterembe járnánk. A kis növekményes változások hosszú távon nagy változást hoznak. Ha csak három hónapig edz, majd abbahagyja, akkor minden előrehaladását elveszíti. Ilyen a tervező rendszereknél. Szinkronban kell maradniuk az élő webhellyel. Ha nem tartja naprakészen, akkor az emberek csak nem fogják használni.

Nagyon fontos, hogy szilárd magja legyen. Az akadálymentességet kezdettől fogva be kell építeni. A tervezési rendszernek pedig tulajdonjogra és elkötelezettségre van szüksége. Ennek a szervezetnek kell származnia.

Valahol el kell kezdened.

Kommunikáció

A kommunikáció többdimenziós; ez nem egyirányú. A tervezési rendszer tulajdonosának (vagy csapatának) hídként kell működnie a tervezők és a fejlesztők között. Senki sem szereti, ha megmondják neki, mit kell tennie. Az embereket be kell vonni, és úgy érzik, hogy az igényeiket kielégítik. Éreztesse az emberekkel, hogy kontrollálják a folyamatot ... még akkor is, ha nem; olyan, mint az észlelt teljesítmény - ez az észlelt részvétel.

Kérdez. Hallgat. Érezd a felhasználókat, hogy hallják őket. Vegyen be visszajelzést.

Befizet

A jó kommunikáció fontos ahhoz, hogy a tervezési rendszert használó emberek vásárolhassanak. Szüksége van a terméktulajdonosok részvételére is.

A bemutatás erősebb, mint elmondani. A hackathanok olyanok, mint egy kezdő tervezési rendszer édessége - esély arra, hogy bemutassák a tervezési rendszer előnyeit (és visszajelzést kapjanak). A Digital Ocean-en történt hackathon után mindenki a tervezési rendszerről beszélt. Hetekkel később az egyik fejlesztő a Bootstrap-ot lecserélte a BUI-ra, 20 000 sornyi kódot eltávolítva! Miután megismerte egy tervezési rendszer hatását, a fejlesztők mindent elmondanak munkatársaiknak.

Szilárd építészet

Összeállíthatóságot és változást szem előtt tartva kell építenie. A Github által készített Primer tartalmaz egy alapcsomagot, majd kiegészítőket mondjuk marketinghez vagy termékhez. Az aggodalmak nagyszerű elkülönítése. A BUI hasonló modul-alapú megközelítést alkalmazott: egy mag kódbázist, külön az ikonográfiától és a rácstól.

A szemantikus verziózás a tervezési rendszer szilárd architektúrájának másik fontos része. A kisebb frissítéseket ki akarja állítani anélkül, hogy aggódnia kellene a változások megsértése miatt.

Használja ugyanazt a megállapodást a tervfájljaiban, mint például a Sketch.

Mi a helyzet a tech stack választással? Minden vállalatnak különböző igényei vannak, de egyet Una javasol: ne várja meg a névteret! Az összes összetevőjének tartalmaznia kell valamilyen előtagot az osztálynevekben, hogy ne ütközzenek a meglévő CSS-sel.

Una megemlíti a Solid by Buzzfeed-et, amely személy szerint szerintem rettenetes (számolja meg a! Fontos nyilatkozatok számát - hívhatja „változhatatlannak”, amire csak vágyik).

Az Atlassian AtlasKit mindent bejár a React-be. Megpróbálják integrálni a Sketch-et abba, de a tervezési eszközök még nincsenek megoldva (az AirBnB is ezen dolgozik). Még mindig megpróbáljuk kitalálni, hogyan lehet egyesíteni a design és a kódolás világát.

Csökkentse a súrlódást

Erről van szó. A tervezési rendszer használatának a legkisebb ellenállás útjának kell lennie. Ha az új tervezési rendszert nehezebb használni, mint amit az emberek már csinálnak, akkor nem fogják használni.

Biztosítson horgokat és eszközöket azok számára, akik használni fogják a tervezési rendszert. Lehet, hogy mixek a Sass-ban, vagy lehet egy CDN-szkript, amelyre az emberek csak linkelni tudnak.

Kezdje korán, frissítse gyakran. A tervezési rendszerek felépíthetők utólag, de könnyebb megtenni, amikor új terméket építenek.

A hibák és a tönkremenetelek az idő múlásával mindig növekednek. Szüksége van egy mechanizmusra, amely a tetején marad. Nem csak technikai hibák, hanem vizuális következetlenségek is.

Tehát a sikeres tervezési rendszer öt pillére:

Beruházás
Kommunikáció
Befizet
Szilárd építészet
Csökkentse a súrlódást

Amikor elkezdi, kezdje egy céllal:

Tervezési rendszert építünk, mert…

Ezután nézze át, mit kapott már (a meglévő kódbázist). Például, ha a tervezési rendszer célja az oldal teljesítményének növelése, a Weboldal teszt segítségével mérje meg az aktuális webhely teljesítményét. Ha a cél az akadálymentesítési problémák csökkentése, akkor használja a webaim.org oldalt az aktuális webhely akadálymentességének mérésére (lásd még: pa11y). Ha a cél a CSS mennyiségének csökkentése a kódbázisában, használja a cssstats.com webhelyet annak teszteléséhez, hogy a jelenlegi webhelye hogyan működik. Most, hogy megvan a statisztika, használja őket a vásárláshoz. Kezdheti úgy is, hogy elvégez egy interfész-leltárt. Nyomtassa ki az oldalakat és vágja fel őket.

Miután megvásárolta és elkötelezte magát (írásban), akkor technikai döntéseket hozhat.

Kezdheted atomelemeiddel. A gombok olyanok, mint a „Hello világ!” tervezési rendszerek. Színe, típusa és különböző állapota van.

Ezután komponálhat elemeket az alapelemek összerakásával.

Felveszi az elrendezést a rendszerbe? Ez kihívás, és a csapattól függ. Ha mégis tartalmaz elrendezést, milyen mértékben?

Az elrendezéstől függetlenül továbbra is gondolkodnia kell a térben: az alapelemek közötti tér egy komponensen belül.

Sütés akadálymentességben: minden lebegő állapotnak egyenlő (nem ellentétes) fókuszállapotúnak kell lennie.

Gondoljon az állapotokra, például a töltési állapotokra.

Ezután elkezdheti a dokumentálást. Ezután tájékoztassa a rendszer felhasználóit. A Carbon rendelkezik egy műszerfalon, amely megmutatja, hogy melyik alkatrészek újak, mely komponensek elavultak és mely komponensek frissülnek.

Tartsa a következetes kommunikációt. A tervezésnek és a fejlesztői kommunikációnak meg kell történnie. A folyamatos iteráció, támogatás és kommunikáció a legfontosabb tényező a tervezési rendszer sikerében. A kód csak 10% -a egy rendszernek.

Ezenkívül ne érezze úgy, hogy más tervezési rendszereket kell lemásolnia odakinn. Az Ön igényei valószínűleg nagyon különbözőek. Ahogy Diana mondja, a tervezési rendszer összehasonlítása a csiszolt nyilvánosakkal olyan, mintha az életét hasonlítaná valaki Instagram-fiókjával. Ebből a célból Una valami potenciálisan ellentmondásos dolgot mond:

Lehet, hogy nincs szüksége tervezési rendszerre.

Ha egyedül a szervezetében törődik a tervezési rendszer előnyeivel, akkor nem fog vásárolni, és ha nem vásárol be, akkor a tervezési rendszer kudarcot vall. Talán van valami megfelelőbb a csapatának? Végül is nem mindenkinek kell konditerembe mennie ahhoz, hogy fitt legyen. Vannak alternatívák.