Minimali gyvybinga projektavimo sistema

Auganti UXPin projektavimo sistema, saugoma UXPin projektavimo sistemos bibliotekoje

Per pastarąsias kelias savaites man buvo malonu pasikalbėti apie UXPin požiūrį į dizaino sistemos kūrimą keliuose susitikimuose ir internetiniuose seminaruose (vieną iš jų galite žiūrėti čia). Man buvo smagu pasidalyti savo patirtimi, kurios sužinojau per visus malonius pokalbius po mano pokalbių.

Vienas klausimas, kuris man buvo užduotas kelis kartus, kuris iškilo ir per mano pokalbius su „UXPin“ komanda, buvo toks:

Kiek laiko užtrunka projektavimo sistemos sukūrimas?

Nėra klaidingų klausimų ir aš mielai atsakinėjau kiekvieną kartą. Tačiau kiekvieną kartą išgirdęs šį klausimą jaučiu, kad jis atkreipia dėmesį į gilesnę problemą: projektavimo sistemos vis dar yra nesuprantamos ir painiojamos su senu požiūriu į stiliaus vadovo kūrimą.

„Zombie Style Guide“ palikimas

Dieną nelaimingam projektavimo ar kūrimo komandos nariui bus patikėta užduotis dokumentuoti visas komandos patvirtintas konvencijas. Spalvų paletės, teksto stiliai, kodo standartai, kartais net vartotojo sąsajos modeliai.

Skamba kaip projektavimo sistema? Tu teisus. Tai tikrai skamba kaip projektavimo sistema, bet taip nėra.

Šis senas požiūris į stiliaus vadovo kūrimą buvo skirtas sukurti artefaktą. Tai turėjo būti dokumentavimo proceso išvestinė. Ir kiekvieną kartą ...

Prieš pradedant stiliaus vadovą, jis jau virto zombiu.

Kodėl? Tiesiog todėl, kad dinamiškas produktų kūrimo pasaulis, kuriame nuolat vyksta pokyčiai, nelabai reaguoja į statinį turtą, kurio kūrimas užtrunka kelias savaites. Nors projektavimo / tobulinimo kankinys stengėsi dokumentuoti kiekvieną konvenciją, konvencijos nuolat keitėsi. Sukurti stiliaus vadovą buvo sizifų užduotis.

Neįmanoma sukurti ir išlaikyti stiliaus vadovų. Mūsų pramonė paskatino pergalvoti patirties ir kodo nuoseklumo palaikymo procesą. Įveskite projektavimo sistemą.

Projektavimo sistema yra procesas

Skirtingai nuo statinio stiliaus vadovų, projektavimo sistemos yra dinamiškos. Ką tai reiškia? Stiliaus vadovas yra artefaktas, projektavimo sistema yra procesas.

Artefaktai yra statiniai, procesai - dinamiški.

Užuot pavedę vienam asmeniui kurti dokumentaciją, projektavimo sistemos pasaulyje mes planuojame naują darbo eigą, kurioje nuolat pridedama, atimama ir keičiama visa informacija, kad būtų galima sukurti vartotojo patirtį.

Užuot galvoję apie pristatymo datą, projektavimo sistemų komandos (paprastai vadinamos projektavimo operacijų komandomis) planuoja padėti organizacijoms palaipsniui pagerinti vidinę sąsajos nuoseklumą ir greičiau pristatyti didelius projektus rinkai.

Entropijos valdymas naudojant stiliaus vadovą ir projektavimo sistemą

Vieninga prieš entropiją

Kaip ir bet kurioje uždaroje sistemoje, skaitmeninio produkto entropija ir toliau didėja, nebent jis būtų sąmoningai valdomas. Kiekviena nauja savybė, kiekvienas naujas komandos narys, kiekvienas naujas valdymo lygmuo arba suinteresuotųjų šalių ir klientų sąveika padidina patirties entropiją.

Gaminio patirtis palaipsniui nustos į chaosą.

Entropijos augimas yra pastovus ir gali būti kontroliuojamas tik nuolat veikiant. Štai kodėl „Dizaino operacijų“ komandos pabaigos žaidimas nėra statiškas artefaktas, tai yra darbo eiga, kurioje vieninga dizainerių, kūrėjų, premjerų ir kitų komandos narių organizacija sukuria projektavimo sistemą, kuria naudodamasi vartotojo patirtimi.

Niekada nesibaigia minimalus gyvybingas produktas

Klausiant apie projektavimo sistemos pristatymo datą, atrodo, kad yra paslėpta prielaida, kad yra tam tikras momentas, kai projektavimo sistema yra „pagaminta“. Procesinis projektavimo sistemos pobūdis panaikina šią prielaidą.

Projektavimo sistema yra procesas, todėl ji visada yra paruošta ir niekada nepadaryta.

Projektavimo sistema yra pastovi ir yra mažiausiai perspektyvus produktas. Laikas, kai staiga įgyja projektavimo sistemos vertę, neegzistuoja. Sukūrus ir suderinus projektavimo sistemos procesą, pasiekiama mažiausia vertė. Su kiekvienu vėlesniu išleidimu projektavimo sistema tampa galingesnė, tačiau niekada nepasiekia didžiausios vertės. Entropija toliau auga, sąsaja toliau keičiasi ir projektavimo sistema turi vystytis kaip procesas, be pabaigos.

Pradėkite mažą laivą dažnai

Projektavimo sistema atsiranda tada, kai organizacija pripažįsta, kad vis didesnis UI nenuoseklumas turi būti išspręstas naudojant naujas darbo eigas.

Entropija nustoja plėstis įgyvendinus pirmąją konvenciją, dėl kurios susitarė ir įgyvendino projektavimo organizacija. Skirtingai nuo stiliaus vadovo, projektavimo sistemos vertę galima patirti iškart. Projektavimo sistema beveik iš karto pradeda kurti pridėtinę vertę, net jei pirmoji konvencija yra tik 5 pagrindinių spalvų rinkinys su atitinkama pavadinimų konvencija. Tiesą sakant, aš tvirtinčiau, kad:

Projektavimo sistema su viena spalva apibrėžta, tinkamai įvardinta, įdiegta ir priimta organizacijos spalvų yra geriau nei pilnas statinio stiliaus vadovas.

Kodėl? Kadangi ši spalva iš karto mažina entropiją, priešingai nei statiškas stiliaus vadovas, kuris visada pasenęs ir niekada neįgyvendinamas.

Užuot nesijaudinę dėl projektavimo sistemos pristatymo datos, priimkite jos procesinį pobūdį, pradėkite mažas ir gabenkite dažnai. Jūs kariaujate su chaosu ir kiekviena maža kova yra svarbi.

Sėkmės.

Ar norite pamatyti, kaip mes kuriame mūsų projektavimo sistemą? Sekite mūsų „Dizaino operacijų“ sprintus:

  • „Design Sprint 0“: „Sidabrinė gaminio kūrimo kulka“.
  • „Design Sprint 1“: sąsajos aprašas
  • „Design System Sprint 2“: Visų spalvų paletė, kad būtų galima juos valdyti visus
  • „Design System Sprint 3“: pagrindų tvarkymas
  • „Design System Sprint 4“: projektavimo principai
  • „Design System Sprint 5“: tipografijos tvarkymas
  • „Design System Sprint 6“: sparčiausios piktogramos žemėje

Čia yra platesnė projektavimo sistemų perspektyva:

Dizaino sistemos yra kalba. Ir tai keičia programinės įrangos kūrimą amžiams.

Prisijunkite: https://www.uxpin.com/design-systems-early-access