blog

MUI asosidagi dizayn tizimi VUI

NEXTREE.

• 11 min read
MUI asosidagi dizayn tizimi VUI

Kiruvchi so'zlar

O'tgan bir necha oy davomida kompaniya dizayn tizimi boʻlgan VUI (Vizend UI) ni amalga oshirib kelmoqdamiz. VUI dizaynerlar va dasturchilarning mahsulotni bir xil usulda yaratishlari uchun bog'lovchi umumiy til va va'dadir, dizayn tokenlari, komponentlar, naqshlar, ilk printlar va bularni kod bilan bog'laydigan avtomatizatsiyani bir joyga jamlovchi dizayn tizimidir. Buning asosiy mexanizmi sifatida MUI (Material UI) dan foydalanamiz. Dizayn tizimini qanday qilib yaratayotganimizni qisqacha tanishtiramiz.

Tartib bunday.① Nega dizayn tizimiga ehtiyoj bor edi, ② MUI ni asos sifatida ishlatganimizning sababi, ③ Dizayn tizimida ishlatiladigan dizayn tokenlari, ④ MUI mavzusining ishlash printsipi, dizayn tokenlari MUI mavzusi tomonidan qanday iste'mol qilinishi va haqiqiy komponentlarga tokenlarni qanday tatbiq etish usuli, ⑤ Mobil/desktop va yengil/qora kabi modda bo'yicha mavzularni ajratib tuzish usuli, oxirida ⑥ Hali hal qilinmagan muammolar.

1. Nima uchun dizayn tizimi kerak edi

Dizayn tizimini ko'pincha “qayta foydalanish mumkin bo'lgan UI komponentlari to'plami” deb o'ylaymiz. Ammo men his qilgan dizayn tizimining mohiyati mahsulot yaratish usuli uchun umumiy til va va'da edi. Misol uchun, agar UI Kit “Lego bloklarining bir savati” bo'lsa, dizayn tizimi bloklarni ishlab chiqaruvchi fabrika + yig'ilish ko'rsatmalari + blokning o'zi hammasini o'z ichiga oladi.

Boshlanish nuqtasi AI edi. AI orqali frontend kodni avtomatik ravishda yaratish harakatida bo'lganimda, AI tushunishi uchun yaxshi tartibga solingan va amalga oshirilgan tizim kerak edi. Shuningdek, tizim yasalgandan so'ng, ozroq inson bilan dizayn/nashr jarayonini davom ettirish mumkin bo'lgan ikkinchi sabab edi. Inson xotirasiga va fidoyilikka tayanish usuli kamroq inson bo'lganda tezda qulashi va AI dan foydalanish imkoniyati pasayadi. VUI ning printsipi sifatida “tizimning majburiyligi va avtomatlashtirish” ga qo'yib, dizayn aktivlarini eng katta maqsad sifatida belgiladim.

Dizayn tizimi yo'qligida xarajatlar aniq edi.

  • Parchalangan tajriba:Bir xil ‘tugma’ bo'lsada, har bir ekranda yumshatuvchi burchak, rang va balandlik ancha farq qiladi. Buni nazorat qilmasangiz, har bir mahsulot boshqa yuzga ega bo'ladi.

  • Aloqa xarajatlari:“O'sha moviyni biroz kuchaytirishingiz mumkinmi?” degan aniqligi yo'q so'rov dizayn va ishlab chiqish o'rtasida ping-pong kabi o'tadi.

  • Qayta ish (Toil):Har bir ekranga uslubni qo'l bilan qo'shish oddiy takrorlanish biznes mantiqiga sarflangan vaqtni sarflaydi.

Shuning uchun VUI qidirgan narsa oddiy bir xil emas, balki muhandislik bir xil (Engineered Consistency)dir. Semantic Token (ma'noli token) degan umumiy til bilan muloqot qilishni ta'minlashdir. “Foni qora rangda kuchaytirmang” deyilsa, balki “Background-Default tokenini Background-Darkga o'zgartiring” desangiz, dizayn qarori darhol ma'lumotga aylanadi va kuzatish, qaytarish mumkin bo'ladi.

2. MUI tanlovi

Dizayn tizimi yaratmoqchi bo'lsangiz, birinchi navbatda Build vs Buy bo'yicha to'qnashasiz. Barcha komponentlarni to'liq o'zimiz yaratamizmi yoki tasdiqlangan kutubxonani olib, o'zimizga moslaymizmi? Men ikkinchisini tanladim va uning asosini MUI (Material UI) ni tanladim.

2.1 To'g'ridan-to'g'ri qurish

Bitta tugmani qiyinchiliksiz yasash mumkin. Muammo shundaki, o'sha tugma Klaviatura fokusi, ekran o‘qish asbobi (ARIA), faol bo‘lmagan holat, RTL, kross-brouzeringgacha hamma narsani hisobga olish “mahsulot sifatiga” olib boradi. BungaDataGrid, DatePicker, Autocompletekabi murakkab komponentlarni to‘g‘ridan-to‘g‘ri yaratish va texnik xizmat ko‘rsatish bilan, kichik jamoaning resurslari biznes mantiqiga emas, “g‘ildirakni qayta ixtiro qilishga” iste’mol bo‘ladi. Kirish va moslik sifati ham jamoa malakasiga qarab o'zgaradi.

2.2 Nomzodlarni solishtirish — bizning mezonimiz bo‘yicha MUI g‘olib bo‘lishining sababi

Kutubxonani tanlayotganda men qo‘ygan mezonlar uchta edi: ① Brend yaratish uchun mavzuni qanday chuqur va xavfsiz sozlash mumkin, ② Kichik korxonalar uchun murakkab komponent ekotizimi yetarli darajada bormi, ③ Figma bilan moslashuv (dizayn-rivojlantirish sinxronizatsiyasi) mumkinmi.

Nomzod

Kuchli tomonlar

Zaif tomonlar

To‘g‘ridan-to‘g‘ri qurish (headless kombinatsiyasi)

To‘liq erkinlik

Qurish, kirish va texnik xizmat ko‘rsatish xarajatlari eng katta — kichik jamoaga noqulay

Ant Design

Mukammal darajadagi korporativ komponent

Dizayn tili qat’iy tuzilgan — brendni qayta aniqlash va chuqur mavzular qiyinchilik tug‘diradi

Chakra UI

Yengil va tokenga do'starli

Jadval / sana kabi yuqori murakkab komponent ekotizimi nisbatan yengil

MUI (tanlov)

createTheme o'zgartirishning chuqurligi + x-data-grid·x-date-pickers ekotizimi + Material Figma Kit javobgarligi + ulkan jamoa

Material dizayni ranglari qolmoqda → token·qoplama bilan yopilishi kerak

Muqaddimaviy bo'lgan narsa MUI ningrasmiy tema o'zgartirish API (createTheme)edi. Brend uslubini 'sozlash (Configuration)' qatlamida faqat bir joyga joylashtirish imkoni, darhol quyidagi printsipni mumkin qildi.

2.3 Natural Upgrade — “No Forking” printsipi

Ochiq manbali dasturlarni ishlatishda eng katta xavf, maxsuslashtirish uchun asl nusxani fork (o'zgartirish) qilish paytida yuzaga keladi. Fork qilgan paytda yuqoridagi yangilanishlardan abadiy uzoqlashadi, shuning uchun VUIMUI manbasi yoki node_modules ni o'zgartirmaydidegandi qoida. Barcha maxsuslashtirishlar faqat MUI tomonidan rasmiy taqdim etilgan Tema O'zgartirish API orqali amalga oshiriladi. Natijasi esa “saqlash erkinligi” —npm updatebir marta bilan xavfsizlik patchlari va yangi funktsiyalar tabiiy ravishda keladi, va bizning brend o'zgartirishimiz mavjud holda qoladi.

VUI tugmasi MUI tugmasini faqat o'rab oladi va rang, radius, masofa kabi ko'rinishlar butunlay Token → tema yo'l bilan beriladi. Asl nusxani biftek qilib isloh qilish o'rniga buni yupqa o'rab qo'ysangiz, MUI versiyasi ko'tarilganda qabat buzilmaydi.

3. Figma SSOT sifatida — dizayn tokenlarini kodlash

VUIning 6-qavatli arxitekturasi eng pastda (Qavat 1) dizayn tokenidir. Tokenlar rang (#Hex), masofa (px), tipografiya, radius kabi barcha vizual qarorlarni platformadan mustaqil ma'lumotga abstrakt qilgan. Qattiq kodlash va tokenlar o'rtasidagi farq “ma'no” da.

// Bad — 이 색이 무슨 의미인지 코드만 봐선 모른다
background-color: #2196F3;
// Good — '브랜드의 메인 컬러'임이 이름에 드러난다
background-color: tokens.color.brand.primary.main;

Asosiy prinsip Figma yagona haqiqat manbai (SSOT)dir. Rangni o'zgartirmoqchi bo'lsangiz, kodda emas, Figma'da o'zgartiring, kod faqat o'sha qarorni “qabul qiladi”. Buni amalga oshirish uchun tokenlarni qo'lda ko'chirish jarayonini yo'q qilganmiz va pipeline orqali avtomatlashtirilgan.

3.1 Token kodlash pipeline'i (Figma → JSON → TS)

Pipelining uch bosqichdan iborat. Avval dizayner Figma Variables'da belgilangan rang, masofa, tipografiya qiymatlarini Figma maxsus plaginidan foydalanib W3C DTCG standart JSONShaklga chiqaradi. Keyinchalik Style Dictionary nomli kutubxonadan foydalanib, tokenlar orasidagi ma'naviy zanjirni (component → semantic → primitive) yechib, haqiqiy qiymatni aniq belgilaymiz. Nihoyat, bu natija TypeScript faylida saqlanadi va MUI ushbu dizayn tokenidan foydalanadi. Figma ning vizual qarorlari inson qo'lidan o'tmagan holda kod tokenlariga tushib keladi. Uzilgan havolalar bo'lsa ham,buildni muvaffaqiyatsiz qilmaydi va logda qayd etadibuni amalga oshirdim, dizayn o'zgarayotgan paytda CIni to'xtatmaslik uchun edi. Standart formatda (W3C DTCG) bir marta chiqarib qo'ysak, keyin har qanday vosita o'qishi mumkin bo'ladi va avtomatlashtirish mumkin bo'ladi.

3.2 Token qatlamlari, havola munosabatlari (Semantic Naming — primitive → semantic → component)

Tokenlar nomi bilan foydalanishini bilish uchun 3 qatlamda tayyorlanadi. primitive(bo'yoqning o'zi: blue-500), semantic(ma'no·rol: primary-main), component(ma'lum bir qismlarning ishlatilishi: button-contained-bgOxirgi rangni o'zgartirsangiz, yuqoridagilar ham barchasi o'zgarishi uchun bir tomonlama bog'liq (primitive ← semantic ← component) bo'lishiga ruxsat beriladi.

// primitive — 물감 자체 (실제 색 값)
color/blue/500          = #2196F3
// semantic — 의미·역할 (primitive 를 가리킴)
color/primary/main      = {color.blue.500}
// component — 특정 부품의 쓰임 (semantic 을 가리킴)
button/contained/bg     = {color.primary.main}
// → blue-500 한 곳만 바꾸면 primary, button 까지 연쇄 반영된다

4. MUI Theme tokenlarni qanday iste'mol qiladi

Agar token ma'lumot (Layer 1) bo'lsa, bu ma'lumotni haqiqiy komponentning “kiyimi”ga o'zgartiruvchi dvigatel MUI Theme (Layer 2)dir. Bu yerda MUI mavzusining ishlash tamoyilini tushunish muhimdir.

4.1 MUI Theme Configuration ning ishlash tamoyili — 3-kanal

MUI komponenti ThemeProvider kontekstdan olingan theme ob'ektini o'qiydi va uslublarni hisoblaydi. Inyeksiya kanallari asosan uchta kanalni o'z ichiga oladi.

  • Global dizayn qiymatlari: palette / typography / spacing / shape va boshqa barcha komponentlar tomonidan baham ko'riladigan global qiymatlar

  • Asosiy props: components.MuiX.defaultProps — komponentning asosiy harakati·turi

  • Usulni o'zgartirish: components.MuiX.styleOverrides — variant·rang·holat kombinatsiyasi bo'yicha uslub

image1.png

VUI bu uchta kanalni to'liq tokenlarga aylantiradi. Shunday qilib, bir joyni(ThemeOptions) o'zgartirsangiz, barcha komponentlar bir vaqtning o'zida o'zgaradi. Mavzu yaratish brend·rejimni parametr sifatida qabul qiladigan yordamchi bilan o'ralgan.

4.2 token-adapter — “qiymat avtomatik, tuzilma esa qo'lda”

Avtomatik yaratilgan tokenning yo'li (masalan, component.button['md-radius'])ni komponent uslubiga bevosita yozsangiz, dizayner token tuzilmasini bir marta o'zgartirganda kod buziladi. Shuning uchun token-adapter.tsni qo'yishavtomatik yaratilgan tokenning yo'lini ishonchli slot nomiga 1 martalashqilgan. Keyinchalik token qiymatio'zgarganda yo'l o'zgarishsiz avtomatik tarzda yangilanadi, token tuzilishi (yo'l)faqat adapterning bitta qatorini o'zgartiradi.components.tsushbu adapterning ochganbuttonTokens / chipTokens / alertTokenskabi tushunadi va MUI styleOverrides ni yozadi.

// components.ts — token-adapter 의 슬롯을 MUI styleOverrides 로 연결
import { buttonTokens, chipTokens, alertTokens } from './token-adapter';

// MUI Theme 객체에 선언된 MUI Button 스타일 선언코드
MuiButton: {
  styleOverrides: {
    contained: ({ theme, ownerState }) => ({
      backgroundColor: buttonTokens.variant.contained.bg[ownerState.color],
      borderRadius: theme.shape.radiusControlSm,
    }),
  },
}

MUI standart palitrada yo'q VUI ga xos slotlar (masalan, surface / field / border / icon / overlay)modul kengaytirishtipni kengaytirish uchun, theme.vui yoki kengaytirilgan palitr slotlariga kirishni ta'minladi(mui-augmentation.ts). IDE avtomatik to'ldirish orqali ko'plab tokenlarni chalkashtirmay olishimiz mumkin — tip tizimi darhol murojaat qilinadigan hujjatbo'ladi.

4.3 Figma MCP orqali dizayn tokenlari mosligini tekshirish

dizayn tizimini qurishda muhim bo'lgan ishlarning biri “Figma'da aniqlangan komponent spetsifikatsiyalarini haqiqiy token·tema bilan bog‘lash” va ular bir-biriga mos kelmasligini tekshirishdir dizayn mosligini tekshirishish edi. So‘nggi paytlarda bu taqqoslash jarayonida AI Agentfoydalanamiz.

Asosiy ikki bosqichdan iborat. AvvalFigma MCP orqali AI Agent Figma freymida ma'lum komponentga haqiqatan ham qo'llanilgan dizayn tokeni ma'lumotini(rang, tipografiya, masofa, radius va boshqalar kabi o'zgaruvchilarning qaysi joyga bog'langanini) bevosita o'qib tahlil qiladi. Keyin bu Figma tomonidagi token ma'lumotlarini komponent bilanhaqiqatan ham amalga oshirilgan Storybookbilan solishtiradi.

<Storybook>

image2.png

<Figma>

image3.png

Ikki natijani yonma-yon qo'yib AI Agent solishtiradi, amalga oshirilgan koddan dizayn tokenlari yo'q bo'lgan joylaryoki Figma bilan qiymatlar mos kelmaydigan joylarni tekshira oladi. Har safar ko'z bilan solishtiradigan ishni AI Agent birinchi navbatda filtr qilib beradi. Bunday tekshirishni amalga oshirish mumkinligining sababi tokenlar degan umumiy til tufaylidir — Figma va kod bir xil mezon (token) asosida ifodalanadi, shuning uchun avtomatik solishtirish mumkin bo'ladi.

5. Rejimlarga ko'ra tema tuzilishi — komponentlar o'zgarishsiz, faqat tema o'zgaradi

Haqiqiy mahsulotlar faqat bitta ekran bilan cheklanmaydi. Katta monitorlarda ham, kichik mobil telefonlarda ham, yoritilgan ekranlarda ham, qorong'u ekranlarda ham, hamda bir-biridan farq qiluvchi brend mahsulotlarida ham bir xil darajada yaxshi ko'rinishi kerak. VUI bunday o'zgarishlarni bir vaqtda hal qiladi, asosiy e'tibor esa Komponent kodi o'zgarishsiz qoladi, faqat 'tema'ni almashtirish kerakbu nuqtadir. Hozirgi o'tish uchta asosiy yo'nalishga ega.

  • Ekran o'lchami (dekstop / mobil) — Xuddi shu komponent bo'lsa-da, ekran kichrayganda shrift o'lchami va masofalari avtomatik ravishda sichqoncha ko'proq zichlashadi. Ekran kengligini ko'rib, tema avtomatik ravishda dekstop va mobil qiymatlariga o'zgaradi.

  • Yengil / qora rejim — Fon va shrift ranglari rejimga mos ravishda butunlay o'zgaradi. Foydalanuvchi qora rejimni yoqsagina komponentlar o'zgarishsiz qolib, ranglar to'plami faqat qoraytiriladi.

  • Brend (masalan: vizend / devlime) — Mahsulotlar uchun brend ranglari va muhitini har xil qilish mumkin. Yangi brend kerak bo'lsa, dizaynda ranglarni qaytadan belgilab qo'shsa bo'ladi.

Muhim jihat shundaki, bu uchta yo'nalishni qanday birlashtirishingizidan qat'i nazardasturchi komponent kodini bir qator ham o'zgartirmaydibu samimiyatdir. Ekranning yuqori qismida 'qanday brend, qaysi rejim ekanligi'ni bir marta belgilasangiz, pastdagi barcha komponentlar o'zlariga mos tema qabul qiladi. Murakkab taqsimotlarni har bir komponentga yuklash o'rniga, bu murakkablikni tema deb ataladigan bir qavatga ko'tarib, pastki qismini soddalashtirib qo'ygansiz.

// 맨 위에서 '브랜드 / 모드'만 정하면 끝 — 컴포넌트 코드는 그대로
<VuiThemeProvider brand="vizend" mode="dark">
  <App />
</VuiThemeProvider>

6. Hali hal qilinishi kerak bo'lgan muammolar

Loyihalash va amalga oshirish jarayonida aniq bo'lib qolgan, hali hal qilinmagan vazifa.

6.1 Dizayn tokenlarini xaritalash muammosi — MUI Tema yordamida barcha uslublarni boshqarish mumkin emas.

VUIning ma'noga asoslangan ranglari MUI standartlaridatheme.palette MUI paletiningprimary/secondary/text/background darajasini faraz qilamiz, bizning semantic tokenlarimizdan ko'proq to'qimalar mavjud. Natijada vuiColors.bg.surface kabi yordamchi va CSS o'zgaruvchi orqali murojaat imkoniyatlari ko'paydi. “Figma'da text.muted deb belgiladik, lekin MUI paletidagi text slotida bu ma'noni to'liq ifodalash uchun joy yo'q” muammosi modul kengaytirilishi bilan qisman yumshatilgan, ammo standartlar va kengaytirishlarning birga mavjudligi noqulayliklar yaratmoqda.

6.2 tuzilma o'zgarishini aniqlashning asymmetriyasi va komponentlar simlarining tugallanmaganligi

token-adapter tufayli token qiymatO'zgarish avtomatik cheksiz, tokentuzilishi (yo'l)O'zgarish inson tomonidanbuild.logto'g'ridan-to'g'ri o'qilishi va adapterni tuzatishi kerak — avtomatik/qo'lda asimmetriya noqulay. Bundan tashqari, token adapterida slotlar mavjudcomponents.tsning styleOverrides hali bog'lanmagan komponentlar ko'p qolmoqda, bu komponentlar foydalanuvchisxbilan to'g'ridan-to'g'ri tokenlarni olishlari kerak.Ma'lumotlar mavjud, lekin simlar to'liq tenglashmaganholda, bir marta ish bajarilganda kelajakdagi parvarish uchun xarajat deyarli yo'q, lekin hozirda to'liq emas.

6.3 Dizayn prinsiplari asosini yaratish va hujjatlashtirish zarurati

hozirgacha “tokenlarni kodlash” ga e'tibor qaratdik, lekin asosan ustiga inson asoslanishi kerak bo'lgandizayn prinsiplariva Komponentdan foydalanish qoʻllanmasihali yetarlicha tartibga solinmagan. Tizim mavjud, lekin “buni qachon va qanday ishlatish kerak”ni ko‘rsatadigan hujjatlar yetishmayapti.

ikki xil hujjat kerak. Biridizayn tamoyillari hujjati— nega semantic va komponent qatlamini ajratganimiz, qaysi talablar token sifatida qabul qilinishi va qaysi talablar rad etilishi haqida qaror qabul qilish mezonini qoldirishimiz kerak, 6 oydan keyin qoʻshilgan odam ham bir xil qaror qabul qilishi mumkin. IkkinchisiKomponentdan foydalanish qoʻllanmasi— har bir VUI komponentini qachon va qanday prop kombinatsiyasi bilan ishlatish kerakligini, odatiy xatolarni qanday oldini olish kerakligini tartibga solishi zarur, bu esa bir xil muvofiqlikni mahsulot bosqichidagi qarorlarimizda saqlaydi.

Tokenlarni kodga aylantirishgacha yetib bordik, endi esatamoyil va foydalanish usullarini hujjatlashtirishvaqti keldi. Bu yangi jamoa a'zolarining onboarding tezligini va tizimning barqarorligini belgilaydi.

Xulosa qilib

VUI ni yaratayotganda olingan bir ibora shunday: “Muvofiqlik mas’uliyatini odamning halolligiga emas, tizimga yuklaymiz.”MUI asosida tanlangan narsalar, Figma SSOT sifatida qabul qilingan, tokenlarni kodga aylantirib, mavzularda ishlatilishi uchun tayyorlangan va o'zgarishlarni o'rnatmalarga singdirilgan narsalar bularning barchasi bitta yo'nalishga ishora qiladi.

Ushbu ishning ma'nosi ikki qatlamli deb o'ylayman. Yaqqol, kichik jamoa kam odam bilan standart sifatli dizayn va nashrni birgalikda amalga oshira olish uchun leveragedir. Uzoqda esa, Bizend platformasining yo'nalishi — front-end kodini avtomatik ishlab chiqarish asosidir — tartibga solingan va tokenlar bilan standartlashtirilgan dizayn tizimi bo'lishi kerak, shunda AI ushbu tizim ustida bir xil ekran kodini yaratishi mumkin.

Brown

Site footer