Skip to main content

Product Manager တစ်ယောက် Wireframe ဆွဲတတ်ဖို့လိုလား

ဆိုကြပါစို့… ကျွန်တော်က Company တစ်ခုရဲ့ Product Manager…  အခုပဲ Company အတွက် Feature Idea တစ်ခု ရတယ်...Solution ကလည်း အရမ်းကောင်း၊ Management ကလည်း စ Develop လုပ်ဖို့ မီးစိမ်းပြနေပြီ။
ကျွန်တော် ဘယ်နေရာကစရမလဲ?

Product / Feature ကောင်းတစ်ခုရဖို့ အရင်ဆုံးလုပ်ရမှာက Idea ကို Validate လုပ်ခြင်းဖြစ်တယ်။ Validate လုပ်တဲ့နည်းတွေထဲက တစ်ခုက Wireframe တစ်ခု ဆွဲကြည့်ခြင်းပါ။ လွယ်လွယ်ပြောရရင် စကားနဲ့ပြောတာထပ် ပိုမြင်လွယ်အောင် ပုံဆွဲပြတာပေါ့။ အဲ့တော့မှပဲ ကိုယ့် Product Team က ငါတို့လိုချင်တာ ဒါပါလား ဆိုတာ ကို သိပြီး Feedback ပေး၊ ရှေ့ဆက်လုပ်လို့ရမှာဖြစ်ပါတယ်။

Wirefreame ဆိုတာ ကျွန်တော်တို့ လုပ်မယ့် Feature တွေကို ဘယ်နေရာက ဘာရှိမယ်ဆိုတဲ့ အကြမ်းဖြင်း Structure ရအောင် ရေးဆွဲခြင်းပဲဖြစ်တယ်။ Wireframe က တစ်ခါတည်းဆွဲပြီး ပြီးသွားမယ့် အရာမဟုတ်ဘဲ Iterative Process နဲ့ အမြဲတမ်း Idea Validation မှာ ပါဝင်တတ်တဲ့ Process တစ်ခုဖြစ်ပါတယ်။ ပထမ Wireframe ဆွဲမယ်။ ပြီးရင် Customer Feedback ယူ၊ ထပ်ဖြည့်စွက်ပြီး ပိုကောင်းတဲ့ Feature တွေ၊ Product တွေဖြစ်လာကြပါတယ်။ မိမိပြိုင်ဖက် Product တွေကြည့်ရင်လည်း အမြဲတမ်း ပြောင်းလဲနေတဲ့ UIUX ကို တွေ့ရမှာပါ။


Product Manager တစ်ယောက်အတွက် Wireframe လုပ်တဲ့အခါ ရှောင်ပြေးနေလို့မရပါဘူး။ ကိုယ်တိုင် Wireframe ဆွဲရမှာလား ဆိုတာကတော့ သင့် Product Team ရဲ့ Size နဲ့ Capacity ပေါ် မူတည်ပါလိမ့်မယ်။ လူနည်းတဲ့ Product Team မျိုးဆိုရင်တော့ Product Manager ကိုယ်တိုင် Wireframe ဆွဲရနိုင်ခြေ များမှာပါ။ ကိုယ်တိုင် မဆွဲရလည်း Product Manager တစ်ယောက်အတွက် အဲ့ Process ထဲ ဝင်ပါဖို့နဲ့ အကြံဉာဏ်ပေးဖို့ကတော့ အရေးကြီးပါတယ်။ ကျွန်တော်ပြောခဲ့သလိုပဲ Product Team နဲ့ Feature Idea တွေ ထဲထဲဝင်ဝင်ဆွေးနွေးဖို့ ပုံဆွဲပြခြင်းက ပိုလွယ်ကူပါတယ်။


Wireframe, Mockup နဲ့ Prototype ဘာကွာလဲ

ဒီသုံးခုက အကြမ်းဖြင်းဆိုရင် ဆင်တူလိုဖြစ်နေပေမယ့်လည်း တကယ်တော့ သူ့ Use Case နဲ့သူပါပဲ။

Wireframe ကအပေါ်မှာပြောခဲ့တဲ့အတိုင်း Idea Validation မှာပါဝင်တဲ့ Process တစ်ခုပါ။ သူက Product ဒါမှမဟုတ် Feature တစ်ခုရဲ့ အကြမ်းဖြင်း Structure တစ်ခုဖြစ်ပါတယ်။ ဥပမာပြောရရင် Website တစ်ခုက Search Feature ဆိုပါတော့၊ သူ့ကို Page ရဲ့ အပေါ် ညာဘက်မှာထားမယ်။ User Input တောင်းမယ့် Text Field တစ်ခုရှိမယ်။ Input ရိုက်ပြီး နှိပ်ရှာရမယ့် Button တစ်ခု ဘေးမှာထားမယ်။ အဲ့လို စဉ်းစားပြီး ရေးဆွဲကြည့်ခြင်းက Wireframe ပါပဲ။ Wireframe လုပ်ရခြင်းရည်ရွယ်ချက်က Product/ Feature တစ်ခုက ဘာလဲ၊ ဘယ်လို အလုပ်လုပ်တာလဲနဲ့ ဘယ်လိုရှိလဲ (What it does, How it does and How it looks like) ဆိုတာကို ဖြေရှင်းပေးရတာပါ။

Wireframe လုပ်တာနဲ့ Design ထွက်လာပြီလားမေးရင် မထွက်ပါဘူး။ Wireframe က Design Phase ထဲက First Step ပါ။ အကြမ်းဖြင်း Structure ပါ။ နောက်ဆုံး Design ကို မြင်ရဦးမှာမဟုတ်ပါဘူး။ Structure ရပြီဆိုရင် အထဲမှာ တန်ဆာပလာ တွေ ထည့်ရတော့မယ်။ အလှဆင်တဲ့ အဆင့်ကို Mockup လို့ခေါ်ပါတယ်။ ခုနက ဥပမာအရဆိုရင် Search Button က ဘာအရောင်ထားမလဲ။ Text Field က လေးထောင့်လား၊ Rounded Corner ထားမှာလား၊ Font က ဘာသုံးမှာလဲ ဆိုတာကို ထည့်ဆွဲကြည့်ရတာပါ။ ဒီအဆင့်ပြီးသွားရင်တော့ ကိုယ့် Product ရဲ့ ရုပ်ထွက် ကို အသေအချာမြင်ရပြီပေါ့။

နောက်တစ်ခုက Prototype… ကိုယ့်မှာ Product Structure လည်းသေချာပြီ၊ ရုပ်ထွက်လည်းလှပြီ ဆိုတာနဲ့ Design Phase ကမပြီးသေးပါဘူး။ နောက်ဆုံးအနေနဲ့ Interaction တွေကို စဉ်းစားရပါတယ်။ ရုပ်ထွက်လှပြီး တကယ်သုံးကြည့်လို့ အလုပ်မလုပ်ရင် Users တွေဆက်သုံးဖို့ဆိုတာ မလွယ်ကူပါဘူး။ ဥပမာကိုဆက်ရရင်.. .Search Input Field ထဲမှာ စာလုံးရိုက်ထည့်ကြည့်မယ်။ Auto Suggestion ကျလာတာမျိုး၊ နောက်ပြီး Search Button ကိုနှိပ်လိုက်ရင် Search Result Page နောက်တစ်ခုကို ရောက်သွားမယ်ဆိုတာကို ဆွဲကြည့်ရတာပါ။ ဒီအဆင့်တွေအထိပြီးသွားရင် ကိုယ့် Product က တကယ့်လက်တွေ့မှာ ဘယ်လို အလုပ်လုပ်မယ်ဆိုတာကို အသေအချာ မြင်တွေ့သွားနိုင်ပါတယ်။

Wireframe က ဖွဲ့စည်းပုံ (Structure) ကို ပေး၊ Mockup က ရုပ်ထွက် (Visual) ကို ထုတ်၊ Prototype က သုံးစွဲပုံ (Usability) ကို ပြဖို့အတွက် ရည်ရွယ်ပါတယ်။ Mockup က များသောအားဖြင့် Designer တွေဆွဲကျပြီးတော့ Wireframe နဲ့ Prototype ကတော့ UIUX Team နဲ့အတူ၊ Product Manager တွေပါဝင်လေ့ရှိတဲ့ Process တစ်ခုဖြစ်ပါတယ်။

အောက်က ဇယားမှာတော့ Wireframe၊ Mockup နဲ့ Prototype လုပ်လို့ရတဲ့ Tools တွေကို List Down လုပ်ထားပါတယ်။ တခြား Tools တွေလည်းရှိပေမယ့် Industry မှာ အသုံးများတဲ့ Powerful Tools တွေပါ။



ဒါကတော့ Product Manager အတွက် Design နဲ့ ပတ်သတ်ပြီး အခြေခံ Topic ကို ဝေမျှထားတာဖြစ်ပါတယ်။ နောက်တစ်ခေါက် UIUX Team နဲ့ တွေ့ပြီး Wireframe တွေ၊ Mockup တွေ၊ Prototype တွေအကြောင်း ပြောရင် နှုတ်ပိတ်နေစရာမလိုတော့ဘူး ထင်ပါတယ်။ ကိုယ့်မှာ တခြား Tools တွေ၊ Good Practice တွေ ရှိရင်လည်း အောက်က Comment မှာ တချက် Share ပေးကြပါဦး။ 
------------------------------

Product သမားအချင်းချင်း idea တွေ၊ knowledge နဲ့ experience တွေ share ဖို့ နွေးနွေးထွေးထွေးဖိတ်ခေါ်ပါတယ်။ နောက်ထပ် Post တွေမလာခင် product management နဲ့ ပတ်သက်တဲ့ ဘယ်လို topic တွေဖတ်ချင်လဲဆိုတာ ဒီ Google Form ကနေတဆင့် အကြံပေးနိုင်ပါတယ်။
ProductBaze အကြောင်း (၁) မိနစ်စာ မိတ်ဆက် post လေးကို ဒီ link မှာ ဖတ်လို့ရပါတယ်။ ProductBaze ကို ဆက်သွယ်ချင်ရင် productbaze@gmail.com သို့ ပေးပို့ ဆက်သွယ်နိုင်ပါတယ်။

Comments

Popular Posts

SMART Goal ဘယ်လိုတည်ဆောက်မလဲ

Personal အတွက်ဖြစ်စေ၊ လုပ်ငန်းခွင်မှာဖြစ်စေ.. ရည်မှန်းချက်ကြီးမားတာ ကောင်းပေမယ့် ကိုယ်စိတ်ကူး ပေါ်ရာ ကိုယ်ဖြစ်ချင်ရာ ရည်မှန်းချက်တွေ ရမ်းသမ်းချမှတ်တာက လက်တွေ့မကျတဲ့၊ ချသာ ချမှတ်ထားပြီး အသုံးမဝင် Effective မဖြစ်တဲ့ ရည်မှန်းချက်တွေ ဖြစ်နေနိုင်ပါတယ်။ မဖြစ်နိုင်တဲ့ Goal နောက်ကိုလိုက်ရင်း ရင်းနှီးမြှုပ်နှံရတဲ့ အချိန်တွေ၊ ငွေကြေးတွေ၊ Resource တွေလည်း ဆုံးရှုံးမှုတွေဖြစ်စေနိုင်ပါတယ်။ “SMART Goal ဖြစ်ဖို့တော့ လိုမယ်နော်” ဆိုတဲ့ စကားမျိုး ကြားဖူးကြပါလိမ့်မယ်။ SMART Goal ဆိုတဲ့ concept ကို စီးပွားရေးလောက၊ Marketing အပြင် နယ်ပယ်အသီးသီးမှာ တွင်တွင်ကျယ်ကျယ်အသုံးပြုကြပါတယ်။ SMART Goal ဆိုတာ တိုတိုပြောရရင် တိကျရှင်းလင်းပြီး လက်တွေ့ကျတဲ့ Goal တွေချမှတ်ခြင်းလို့ ပြောနိုင်ပါတယ်။ မိမိ Business အတွက်၊ Product အတွက်၊ Team အတွက်၊ Personal အတွက် Goal တွေ ချမှတ်တဲ့အခါ လက်တွေ့ဖြစ်နိုင်ချေရှိတဲ့ ရည်မှန်းချက်ကို သေချာသတ်မှတ်ပေးနိုင်တဲ့ SMART Objective နည်းလမ်းကို သုံးကြည့်သင့်ပါတယ်။ SMART Goal ဆိုတာက ကိုယ့်ချမှတ်ရေးဆွဲမယ့် Goal တွေက S (Specific) - ဘာကိုရရှိအောင်လုပ်မယ်ဆိုတာ တိတိကျကျဖြစ်ရမယ် M (

Cross-Functional Team အကြောင်း တစေ့တစောင်း

Cross-functional Team ဆိုတာ အပြောလည်းများသလို အသုံးလည်းများပါတယ်။ Product Team တွေမှာလည်း Cross-functional Team ပုံစံကို တော်တော်များများ အသုံးပြုကြပါတယ်။ ProductBaze ဆောင်းပါးအချို့မှာလည်း ထည့်ရေးဖူးပြီး၊ Product Squad ဆောင်းပါးမှာ Squad တည်ဆောက်ပုံက Cross-functional Team ပုံစံကို အခြေခံတဲ့အကြောင်းရေးရင်းနဲ့ Cross-functional Team အကြောင်းလေးကိုပါ မိတ်ဆက်ပေးဖို့ ဖြစ်လာပါတယ်။ ပုံမှန် Organization တွေမှာ Department တွေ, Team တွေက လုပ်ငန်းသဘောသဘာဝ တူညီရာ (Tech, Marketing, Sales, Operation…) စသဖြင့် အသီးသီး ဖွဲ့စည်းထားကြပြီး ဖွဲ့စည်းပုံကလည်း အထက်ကနေ အောက် Hierarchy အတိုင်းဖြစ်ကြပါတယ်။ Decision တစ်ခုလိုအပ်ရင်လည်း Hierarchy အတိုင်း အပေါ်ကို ပြန်တက်ပြီး Request လုပ်ကြရသလို၊​ Company တစ်ခုထဲက Team အသီးသီးက အခြား Department တွေ ဘာလုပ်နေလဲဆိုတာ သိဖို့ ထင်သလောက် မလွယ်ကူပါဘူး။ Silos Team (တသီးတသန့် အလုပ်လုပ်တဲ့ Team) တွေ ဖြစ်လာပြီး Direction တွေ ညှိရခက်တတ်ပါတယ်။ Cross-functional Team ဆိုတာက Organization ထဲမှာ ကျွမ်းကျင်မှုမတူ (သို့မဟုတ်) ဌာနမတူတဲ့ လူတွေကို Team အနေနဲ့ဖွဲ့ပေးပြီး Project တစ်

ကိုယ့် Boss ကို ဘယ်လို Manage လုပ်မလဲ

“Manage My Boss” ဆိုတဲ့ ခေါင်းစဉ်ကြီးဖတ်လိုက်ရလို့ တမျိုးကြီးဖြစ်သွားမယ်ထင်ပါတယ်။ သို့ပေမယ့် ကျွန်တော် အခုပြောပြမယ့် “How to Manage your Boss” က Management အကြောင်း လေ့လာတဲ့အခါတွေမှာလည်း ပါဝင်လေ့ရှိသလို အပြင်လုပ်ငန်းခွင်မှာလည်း တကယ်အရေးပါတဲ့ ကိစ္စရပ်ပါပဲ။ ကိုယ်ကိုယ်တိုင်က Middle Management Level လို့ပြောကြတဲ့ Manager ဖြစ်နေမယ်၊ ကိုယ့်အောက်မှာ Team Members တွေရှိသလို၊ ကိုယ့်အပေါ်မှာလည်း ကိုယ် Report လုပ်ရတဲ့ Senior Manager သော်လည်းကောင်း၊ Head သော်လည်းကောင်း၊ C-Level သော်လည်းကောင်း ကိုယ့် Boss ရှိမယ်ပေ့ါ။ Management Term အရဆိုရင် ကိုယ့် Team ကို Manage လုပ်ရတာကို “Managing Down” or “Downward Management” လို့ ခေါ်ပြီး၊ ကိုယ့် Boss ကို Manage လုပ်တာကို “Managing Up” or “Upward Management”လို့ခေါ်ပါတယ်။ အဲ့တော့ အခုဆွေးနွေးမှာက Upward Management အကြောင်းပါ။ အိုကေ… ကိုယ့် Boss ကို ဘယ်လို Manage လုပ်တာလဲ??? ကိုယ်က Manage လုပ်ခံရမှာမဟုတ်ဘူးလား??? ကိုယ့်အတွက်ရော ဘယ်လို အကျိုးရှိမှာလဲ??? “Boss ကို Manage လုပ်တယ်ဆိုတာ ဘာလဲ” ကနေ စရအောင်ပါ။ Boss ကို Manage လုပ်တဲ့ အဓိက Goal က Boss ကို အပြည

အသုံးများတဲ့ Product Testing တွေ

Webinar တစ်ခုမှာ Product Testing တွေအကြောင်းထည့်ပြောတော့ နောက်ဆုံးအမေးအဖြေအချိန်မှာ အမေးခံရဖူးတာလေး မှတ်မှတ်ရရရှိလို့ပါ။ “A/B Testing ဆိုတာ Alpha Testing, Beta Testing ကို ပြောတာလား” ဆိုတဲ့ မေးခွန်းပါ။ သိတဲ့သူအတွက်တော့ ဘာမှမဆိုင်တဲ့ Testing တွေမှန်း တန်းသိနိုင်ပေမယ့် တစ်ဖက်မှာလည်း မေးလည်းမေးချင်စရာ အခေါ်အဝေါ်က ခပ်ဆင်ဆင်တူနေတာကိုးလို့ တွေးမိပါတယ်။ ဒါကြောင့် ဒီဆောင်းပါးမှာ မကြာမကြာလည်း ပြောဖြစ်ကြပြီး၊ အသုံးလည်းများ၊ အသုံးလည်းဝင်တဲ့ Alpha Testing, Beta Testing နဲ့ A/B Testing တို့အကြောင်းကို တီးမိခေါက်မိအောင် ရေးချင်ပါတယ်။ Feature Development တွေပြီးတဲ့အခါ Product Owner နဲ့ Development Team တွေ User Acceptance Testing (UAT) ကို အတူတကွ ပြုလုပ်ကြပါတယ်။ QA က အဓိက Test တာဖြစ်နိုင်ပေမယ့် အားလုံးက ပူးပေါင်းလုပ်ဆောင်ကြရတာပါ။ Product (သို့) Feature က UAT လည်းပြီးပြီ၊ Release လုပ်တော့မယ်လို့ စ Plan တဲ့အခါ Alpha Testing နဲ့ Beta Testing အခန်းကဏ္ဍဆီ ရောက်ပါတယ်။ Alpha Testing Alpha Testing ဆိုတာ လွယ်လွယ်ပြောရရင် ကိုယ့်လူနဲ့ကိုယ် အရင်စမ်းသပ်တဲ့ Testing အမျိုးအစားပါ။ မိမိရဲ့ Software

၅ မိနစ်စာ Product Roadmap

Product တစ်ခုစလုပ်ရင် အလိုအပ်ဆုံးက Product Roadmap လို့ပြောလို့ရမယ်။ Product Roadmap က မိမိ လုပ်မယ့် Product အကြောင်း Overview ပြောပြပေးနိုင်သလို၊ မိမိ Product Goal တွေကို ဘယ်လိုရောက်အောင် လျှောက်မလဲဆိုတာကို ချပြပေးလို့ပါပဲ။ Product Roadmap မရှိရင် ကိုယ်ထင်ရာ လုပ်မိနေနိုင်ပြီး မိမိ Goals တွေကို လက်လှမ်းမမှီနိုင်ဖြစ်သွားလိမ့်မယ်။ Product Roadmap ရှိတော့ ကိုယ့် Team Member တွေဖြစ်ဖြစ်၊ CEO ဒါမှမဟုတ် Investor တွေနဲ့ပဲပြောပြော အသုံးဝင်ပါလိမ့်မယ်။ ဒါဆို Product Roadmap ဘယ်လိုဆွဲရမလဲလို့မေးမယ် ။ အလုပ်အဖြစ်ဆုံး Product Roadmap Template ဆိုပြီးတော့မရှိပါဘူး။ မိမိ Roadmap ကို ကြည့်မယ့်လူပေါ်မူတည်ပြီး Roadmap ဒီဇိုင်းတွေကပြောင်းလဲရပါမယ်။ ဥပမာ… CEO က Timeline တွေနဲ့ ဘယ်နေ့ဘာ Feature ပြီးမှာလဲကို ကြည့်ချင်နေတဲ့အချိန် ကိုယ်က Feature List ပဲ သွားပြလို့မရပါဘူး။ Template မရှိပေမယ့် ဒီနေရာမှာ Share ပေးချင်တာက ကျွန်တော့် အတွက် အလုပ်ဖြစ်ခဲ့တဲ့ Roadmap Key Components တွေနဲ့ တခြား popular ဖြစ်တဲ့ Product Roadmap တွေကို ဝေမျှပေးသွားပါမယ်။ Product Roadmap မှာ အတွေ့အများဆုံးက Quarterly Roadmap (Q1,