တော်တော်များများတွေးကြလိမ့်မယ်၊ အကယ်၍ AI Agent တစ်ခုက Design System တစ်ခုလုံးနဲ့ အဲ့ system ကိုအသုံးပြုပြီး Product ကိုပါ အစအဆုံး ဆောက်ပေးနိုင်နေပြီဆိုရင်၊ ဘာလို့ Figma ထဲမှာကော Code ထဲမှာပါ ခွဲပြီး သိမ်းထားဖို့ လိုအပ်နေသေးတာလဲ?

အဲ့ဒါဆိုရင် ပြန်ပြီးမေးချင်တာက AI ရယ် ကိုယ်ရယ် 2 ကောင်ထဲနဲ့တင် ဒီ product က လမ်းဆုံးသွားမှာသေချာလား။ ကိုယ့် Product က one-off product၊ project လေးတစ်ခု ပဲလား။ Design Systems ဆိုတဲ့ နာမည်မှာ Design ကို ပဲ မြင်နေတာလား။ System ရဲ့ အဓိပ္ပာယ် ကိုနားလည်လား။ ဒီမေးခွန်းလေးတွေကိုပြန်ဆန်းစစ်စေချင်ပါတယ်။

Semantic duplication

AI က component library တွေ၊ UI Kit တွေကိုဆောက်နိုင်တယ်ဆိုတာမှန်ပေမယ့် သူက တစ်ခါခိုင်းတိုင်းတစ်ခါ ဆောက်နေမှာပါ။ Prompt တစ်ခုမှာ ဒီဟာဆောက်ပြီးပြီဆိုရင် နောက်တခု intent တူတဲ့ design မှာ ဒါပဲ ပြန်သုံးရမယ်ဆိုတာကို သူ့ကို မထိန်းကျောင်းပေးမခြင်း သူမသိပါဘူး။ နောက်တစ်ခုခိုင်းတိုင်း ရှိပြီးသားအရာအတွက် Component အသစ်တစ်ခု ထပ်ဖန်တီးမယ်၊ ရှိပြီးသား css class တွေကို နောက် နာမည်ဆင်တူရိုးမှားတစ်ခုနဲ့ ထပ်ထပ်ရေးပါလိမ့်မယ်။ ဒါကို “Semantic Duplication” လို့ ခေါ်ပါတယ်။ ဘာလို့ဒီလိုဖြစ်ရသလဲဆိုတော့ Agent တစ်ခုဟာ ကိုယ့် Product ကို တစ်ကြိမ်မှာ File တစ်ခုချင်းစီအလိုက်ပဲ ဖတ်ရှုပြီး၊ လွန်ခဲ့တဲ့ တစ်နာရီက သူ ဘာဆုံးဖြတ်ခဲ့လဲဆိုတာကို မှတ်မိတဲ့ Memory မရှိလို့ပဲ ဖြစ်ပါတယ်။

ဒီတော့ ဒါဟာ Setup ပိုင်း ပြဿနာသက်သက်ပဲ၊ ပိုကောင်းတဲ့ Agent Crew နဲ့ ဆိုရင် ဒါမျိုး လုပ်မှာမဟုတ်ဘူးလို့ ပြောကြပါတယ်။ သူတို့ပြောတာ မှန်ပါတယ်။ အဲဒါကပဲ systems လိုအပ်တဲ့ အဓိက အချက်ပါပဲ။ တစ်ခုထပ် ပိုတဲ့ အရာတွေရှိလာပြီဆိုရင် systems ရဲ့ အသက်က ပိုထင်ရှားလာပါပြီ။

• Colleague တစ်ယောက်တိုးလာသည်ဖြစ်စေ၊

• Feature တစ်ခုတိုးလာသည်ဖြစ်စေ၊

• Agent တစ်ခု တိုးလာသည်ဖြစ်စေ၊

• Team တစ်ခု တိုးလာသည်ဖြစ်စေ၊

Systems ဆိုတာ တစ်ခုထက်ပိုသော အရာတိုင်းအတွက် interconnected ဖြစ်စေတဲ့အရာဖြစ်ပါတယ်။

Agent တစ်ခုကို အသစ်ထပ်ခါထပ်ခါ တီထွင်နေခြင်းကနေ တားဆီးပေးမယ့် Setup ဆိုတာ Design System ပဲ ဖြစ်ပါတယ်။ အခုဆိုရင် Atlassian လို Organization တွေဟာ သူတို့ရဲ့ Design System ကို Machine-readable context အဖြစ် ပြောင်းလဲပြီး Agents တွေဆီ တိုက်ရိုက် Feed လုပ်ပေးနေကြပါပြီ။ အဲ့ဒီမှာ တစ်ခုသတိထားတာက သူတို့က AI ကို ရော့အင့် system ဆောက်ပေးဆိုပြီးခိုင်းတာမဟုတ်ဘဲ နှစ်ရှည်လများစွာ လေ့လာခဲ့တဲ့ pattern တွေကနေ organization တစ်ခုအတွက် အဆင်ပြေဆုံး system က ဘယ်လိုဖြစ်မလဲဆိုတာကို အဖြေရှာရင်း strategic ကျကျ Document လုပ်ထားတဲ့ context တွေ ဖြစ်ပါတယ်။ System ဆိုတာ ကြိုတည်ဆောက်လို့ရတဲ့အရာလည်းမဟုတ်ပါဘူး။ အတွေ့အကြုံ၊ သင်ခန်းစာတွေကနေမှ အချိန်တစ်ခုကြာတဲ့အခါမှာ ဖြည်းဖြည်းချင်းပုံပေါ်လာတဲ့အရာလည်းဖြစ်ပါတယ်။

Why do we still need it inside Figma?

Figma ထဲမှာ ဒီ Design Decision တွေ၊ components တွေ ရှိနေရဦးမယ့် ရည်ရွယ်ချက်က ဘာလို့လဲဆိုတော့ လူတွေကပဲ trade-offs တွေ၊ ဆုံးဖြတ်ချက်တွေကို ဆက်လက် ချမှတ်နေရဦးမှာမို့လို့ပါ။ Figma ထဲမှာဆိုရင် ကိုယ့်ရဲ့ system မျက်ဝါးထင်ထင် မြင်တွေ့နိုင်ပြီး လက်နဲ့ဆုပ်ကိုင်ထားလို့ရတဲ့ နေရာဖြစ်သလို ပြင်ဆင်မှုတွေကို လက်တစ်ကမ်းအလိုနဲ့တင် ပြင်ဆင်လို့ရပါတယ်။ ဆုံးဖြတ်ချက်တွေကို Code ထဲမှာ agent ကို generate လုပ်ခိုင်းတာထက် Canvas ပေါ်မှာ စဉ်းစားတွေးခေါ်ရတာ ပိုမိုလွယ်ကူသလို၊ အများသဘောတူညီချက် ရယူရတာလည်း ပိုမိုလွယ်ကူပါတယ်။ Brainstorming session တွေမှာဆိုလည်း ရှိပြီးသား component တွေကို ကောက်စီပြီး UI တစ်ခု ကို အများသဘောတူထုတ်လို့ရနိုင်ပါတယ်။ Extreme Designing လုပ်လို့ရတာပေါ့။

တစ်ယောက်ထဲ အလုပ်လုပ်ရတာမဟုတ်ဘဲ အများနဲ့အတူတူ စဥ်းစားရတဲ့ အပိုင်းတွေမှာ ဒီ system ထဲက ဒီ canvas ပေါ်က component တွေကို မီတင်ထဲမှာတင် လျင်မြန်စွာ တည်ဆောက်ပြီး တစ်ခါထဲ Approval ရခဲ့တဲ့ ဒီ UI ကို ဒီ system အကြောင်းနားလည်နေတဲ့ Agent ဆီသို့ သယ်ဆောင်သွားတဲ့ အခါ ကိုယ်တွေရဲ့ UI တစ်ခုဟာ POV မျိုးစုံကနေ သယ်လာတဲ့ ခိုင်မာတဲ့ product တစ်ခုကို တည်ဆောက်ပေးနိုင်ပါတယ်။

ဆိုတော့ ပြောရရင် systems က Figma မှ မဟုတ်ဘူး Product အတွက်လိုအပ်မယ့် tool တိုင်းက အလွယ်တကူ access လုပ်ဖို့အတွက် သင့်လျော်သလိုပုံစံနဲ့ တည်ရှိနေဖို့လိုပါတယ်။

Components ဆိုတာ မျက်နှာပြင်သက်သက်ပါပဲ။ System ဆိုတာကမှ AI Agent နဲ့ လုပ်ဖော်ကိုင်ဖက်တွေကို ထိုအရာတွေကို ဘယ်လိုအသုံးပြုရမလဲဆိုတာ ပြောပြပေးတဲ့အရာ အားလုံး ဖြစ်ပါတယ်။chaw su

Idea → Brainstorm → Build → Iterate လုပ်တဲ့ Journey တစ်လျှောက်လုံးမှာ ပါဝင်နေတဲ့ actor အကုန်လုံးကို တူညီတဲ့အတွေးအမြင်နဲ့ ထိန်းချုပ်ပေးနိုင်မယ့်အရာက system ဖြစ်ပါတယ်။

A design system never ends

Design systems ဆိုတာလည်း product တွေလိုပါပဲ။ ပြီးဆုံးသွားတယ်ဆိုတာမရှိပါဘူး။ Product တွေလည်ပတ် ကြီးထွားလာသ၍ system လည်းကြီးမာလာသလို၊ မလိုတာတွေ ရှင်းထုတ်ရတဲ့အပိုင်းတွေ၊ များစွာသော trade-off တွေလုပ်ဖို့ လိုနေစမြဲပါ။

Component အခု ၁၀၀ ဆောက်ပြီးသွားလို့ ကြွားစရာမဟုတ်သလို၊ အဲ့ component တွေက တကယ်ရော အသုံးဝင်နေရဲ့လား၊ one-off ဖြစ်ရမယ့်အစား၊ component တည်ဆောက်ထားမိနေလား၊ component အသစ်ကို ဘယ်တော့ ထပ်ထည့်ရမှာလဲ၊ ဘယ်တော့ deprecate လုပ်ရမှာလဲ၊ ဘယ်တော့ version အသစ်လုပ်ရမှာလဲ၊ မေးခွန်းပေါင်းများစွာဟာ ရှိလာဦးမှာပါပဲ။ အဲ့ဒီလို မေးခွန်းပေါင်းများစွာအတွက်လည်း system တွေ ချမှတ်ရပါသေးတယ်။ Systems on systems ထိန်းချုပ်ရမယ့် အပိုင်းတွေလည်း ထပ်မံကျယ်ပြန့်လာဦးမှာပါ။

အဆုံးမရှိတဲ့ ဒီခရီးကို AI နဲ့တင် နှစ်ပါးသွားကဖို့ဆိုတာ မဖြစ်နိုင်ဘူးလို့ ထင်ပါတယ်။ AI နဲ့အတူ powerful ဖြစ်တာတွေ component တွေ၊ screen တွေ အချိန်တိုတိုအတွင်းမှာ များများထုတ်လာလေလေ၊ လူ့ဦးနှောက်က အကုန်ဖတ်ဖို့ ဝေးလေလေ၊ ကိုယ်ဟာ ဒီ product ရဲ့ guest တစ်ယောက်အနေနဲ့ပဲ ဖြစ်လာတတ်ပါတယ်။ အဲ့ကြောင့်ပဲ Design System အတွက် တိကျ သေချာ၊ trace လုပ်ဖို့လိုတဲ့ agentic experience တွေ သေချာတည်ဆောက်ဖို့ လိုလာတာပါ။

နိဂုံးချုပ်သော်

Design Systems ဆိုတာ တစ်ခုထက်ပိုသော အစုအဝေးတစ်ခုအတွက် ချည်နှောင်ပေးထားတဲ့ ကြိုးမျှင်လေးတစ်ချောင်းဖြစ်ပါတယ်။ Developer ဖြစ်စေ၊ Designer ဖြစ်စေ၊ Agent ဖြစ်စေ၊ အကုန်လုံးဟာ တူညီတဲ့အတွေးအခေါ်အောက်မှာ စိတ်တိုင်းကျ ပုံဖော်ကစားနိုင်အောင် ထောက်ပံ့ပေးမယ့် ထောက်တိုင်တစ်ခုလည်း ဖြစ်ပါတယ်။ AI ခေတ်မှာ systems thinking ကို တိုးတက်အောင်ကြိုးစားကြပါ။ ဒါက တကယ့် အလုပ်တစ်ခုဖြစ်လာမှာပါ။