Skip to main content

ကျွန်တော်လေ့လာဖြစ်တဲ့ Design Thinking


Design Thinking လို့ ပြောရင် Designer တွေအတွက် လိုက်နာရမယ့် အကြောင်းအရာလို့ပဲ ထင်ကြလိမ့်ရှိတယ်။ အမှန်တော့ Design Thinking က လူတိုင်းအတွက် အသုံးဝင်ပါတယ်။ Engineering ပဲမဟုတ် Business၊ Science နဲ့ အခြား Field တွေမှာလည်း သုံးလေ့ရှိပါတယ်။ Design Thinking ကို Apple, Google စတဲ့ နာမည်ကြီး ကုမ္ပဏီတွေမှာ သုံးလေ့ရှိပြီးတော့ Harvard, MIT နဲ့ Stanford လို Universities တွေမှာလည်း သင်ကြားလေ့ရှိပါတယ်။

ဒါဆို Design Thinking ကဘာလဲ?
Design Thinking လို့ပြောရရင် Customer တွေရဲ့ ကြုံတွေ့နေရတဲ့ ပြဿနာတွေကို နားလည်အောင် အရင်လုပ်၊ ပြီးရင် Customer တွေအဓိကလိုအပ်ချက်တွေကို ဖြည့်ဆည်းပေးခြင်းဖြစ်ပါတယ်။ Design Thinking ဆိုရင် UI လှလှတွေ နဲ့ မွန်းမံတာ မဟုတ်ပဲ၊ Customer တွေတကယ်လိုအပ်တာကို ထိရောက်အောင် ဖြေရှင်းပေးရတာပဲဖြစ်ပါတယ်။

ဒီဆောင်းပါးမှာတော့ Design Thinking Process အကြောင်းကို အတိုချုပ် ပြောပြချင်ပါတယ်။ Design Thiking လို့ Google မှာရိုက်ရှာလိုက်ရင် ပုံမှန်အားဖြင့် Process ၅ ခုကို လေ့လာရပါလိမ့်မယ်။ အဲ့ဒီ Process ၅ခုအစား ပိုမိုလွယ်ကူလောက်တဲ့ Alan Cooper ရဲ့ Desing Thinking in 3 Steps နဲ့ပဲ အတိုချုပ်ဝေမျှကြည့်ပါမယ်။

Alan ရဲ့ "Design Thinking Framework" က Understand, Envision and Prototype ဆိုပြီး အဆင့် ၃ ဆင့် ရှိပါတယ်။ 


Understand
“Who is it for and what are their goals?”
Understand အဆင့်မှာတော့ သုံးခု ထပ်ခွဲထားပါတယ်။ အဲ့ဒါတွေက...

1. Plan your Research
ဒါက Customer တွေရဲ့ ပြဿနာအခက်အခဲတွေကို နားလည်အောင်လုပ်ရတဲ့ Research (Interview) ပဲဖြစ်ပါတယ်။ အရင်ဆုံး Customer ဆီက ကိုယ်လေ့လာချင်တဲ့ Objectives ကိုရွေးပါ။ ကိုယ်က Delivery Business တစ်ခုလုပ်မယ်ဆိုရင် Objectives က Delivery နဲ့ပတ်သတ်တဲ့ အကြောင်းအရာတွေဖြစ်ရပါမယ်။ အဲ့အထဲကမှ Breakdown ထပ်လုပ်လို့ရမယ်ဆိုရင် ထပ်လုပ်ပါ။ ဥပမာ...အစားအသောက် Delivery လား၊ ပစ္စည်း Delivery လားပေါ့။ Research Objectives ရပြီဆိုရင် Target Audience ကို ရှာပါ။ Target Audience လို့ပြောရင် ကိုယ့် Direct User ပဲမဟုတ်ပဲ...ဒီ Direct User တွေရဲ့ အခက်အခဲကို ဖြေရှင်းပေးမယ့် လူတွေအကုန်ပါပါတယ်။ ဥပမာ...Delivery မှာမယ့် Direct User အပြင်၊ Delivery သမားများ၊ စားသောက်ဆိုင်များပါ အားလုံးက Target Audience ဖြစ်ပါမယ်။ နောက်ဆုံးတစ်ခု ပြင်ဆင်ရမှာက Interview Structure ပါ။ သူတို့ကို Research အနေနဲ့ interview မေးမယ်ဆိုရင် Objectives နဲ့ဆိုင်တဲ့ Topics တွေကို ပုံပြင်ပြောသလို လုံးစေ့ပတ်စေ့ ပြောခိုင်းပါ။ မိမိဘက်မှလည်း Open-ended Questions တွေ မေးပြီး စကားမပြတ်အောင်ကြိုးစားပါ။

2. Conduct your Research
Interview အတွက် မိမိဘက်က ပြင်ဆင်ပြီးရင် နောက်တစ်ဆင့်က Interview မေးရပြီပေါ့။ Interview မေးရင် အနည်းဆုံး နှစ်ရောက် ရှိသင့်ပါတယ်။ တစ်ယောက်က Interview မေးမယ့်သူ၊ နောက်တစ်ယောက်က Note မှတ်မယ့်သူဖြစ်ပါတယ်။ ရောက်တာနဲ့ တန်းမမေးပဲ...Audience အတွက် Expectation ထားရပါမယ်။ ဥပမာ...ဘာကြောင့်သူက Interview ခံရတာလည်း၊ Interview ဘယ်လောက်ကြာမှာလဲ၊ စသဖြင့်ပေါ့။ မိမိအနေနဲ့လည်း Interview တောက်လျှောက် Active Listenting အမြဲလုပ်ဆောင်ရပါမယ်။

3. Identify your Findings
Interview မေးပြီးရင်တော့ Interview ကရလာတဲ့ အဖြေတွေထဲက Pattern တွေကို လေ့လာရပါမယ်။ Pattern တွေဆိုတာက ဒီပြဿနာကို ပဲ အများစု ကြုံတွေနေရတဲ့ အရာတွေပါ။ ဥပမာ...Delivery မှာတဲ့လူတွေထဲမှာမှ Credit Card နဲ့ Payment လုပ်ရတာအဆင်မပြေတဲ့ လူတွေ။ နောက်တဆင့်အနေနဲ့ ဒီ Pattern တွေက User Personas တွေဖြစ်တတ်ပါတယ်။


Envision
“How can we help them meet their goals?”

1. Brainstorm new Ideas
Interview က User Persona ကို ရပြီဆိုတော့ Solution ထုတ်တဲ့အဆင့် ကိုဆက်သွားရပါမယ်။ ဒီအဆင့်မှာတော့ မိမိဖြေရှင်းပေးချင်တဲ့ Problem က အရမ်းလည်း မကျယ်ပြန့်သင့်သလို၊ အရမ်းလည်း မချုံ့သင့်ပါဘူး။ ဒီနေရာမှာ idea တွေကို ဘယ် idea ကကောင်းတယ် မကောင်းဘူးဆိုပြီး Evaluate မလုပ်သင့်ဘဲ အသစ်အသစ်သော idea တွေထွက်အောင်ဘဲ Generate လုပ်ဖို့ဘဲ ကြိုးစားသင့်ပါတယ်။

2. Choose an Idea
Idea တွေရပြီဆိုရင် နောက်တစ်ဆင့်က အကောင်းဆုံးကို ရွေးရပါမယ်။ အကောင်းဆုံးလို့ပြောရင် Criteria ၂ ခုခွဲပြီး ရွေးချယ်လို့ရပါတယ်။ ပထမ Criteria က Goal Directed Solutions ပါ။ ဘယ် idea က ကိုယ့် User Persona’s Goals နဲ့ အလိုက်ဆုံးလဲပေါ့။ အကယ်၍ idea တစ်ခုထက်မက ရှိနေပါက ဒုတိယ Criteria ကို ထပ်ပြီးကိုက်မကိုက်ကြည့်ရပါမယ်။ ဒုတိယ Criteria က Business Goal၊ Investement အကြီးအသေး၊ လုပ်နိုင်စွမ်းဖြစ်တဲ့ Feasibility တို့ပဲဖြစ်ပါတယ်။ ဒီအချက်တွေကို ထည့်စဉ်းစားပြီး အကောင်းဆုံး idea ကို ရွေးချယ်ရပါမယ်။

Prototype
“How could it work?”

1. Build a Storyboard
နောက်ဆုံးအဆင့်မှာတော့ အကောင်းဆုံး ရွေးချယ်လိုက်တဲ့ idea ကို Storyboard တစ်ခုတည်ဆောက်ချင်းပဲဖြစ်ပါတယ်။ ဘာကြောင့် Prototypte ဆွဲကြတာလဲ? Prototype တစ်ခုဆွဲရခြင်းက Develop မလုပ်ခင် မိမိ idea တကယ်အလုပ်ဖြစ်နိုင်၊ မဖြစ်နိုင်ကို သိနိုင်သလို...အဖိုးအခလည်း သက်သာလို့ပါ။ နောက်တစ်ခုက မိမိ idea က လိုအပ်ချက်တွေရှိနေသေးရင် အချိန်မှီ ပြန်လည်ပြင်ဆင်ပြီး Develop လုပ်လို့ရပါတယ်။ Prototype ဆွဲနည်း မျိုးစုံရှိနိုင်ပါတယ်။ အကောင်းဆုံးနည်းကို အကြံပေးရရင် စာရွက်နဲ့ ခဲတံနဲ့ ဆွဲကြည့်ချင်းပဲဖြစ်ပါတယ်။ Draw.io တို့လို Tools တွေသုံးတတ်ရင်လည်း ပိုမို လွယ်ကူပါလိမ့်မယ်။

2. Test with Users
Prototype ရပြီဆိုရင် နောက်ဆုံးအနေနဲ့ User တွေနဲ့ Test လုပ်ကြည့်ဖို့ပါ။ Test လုပ်မယ့် User ကိုခေါ်၊ Background information အနည်းငယ်ပြောပြ၊ Tips တစ်ခုကတော့ သူတို့ စဉ်းစားနေတာကို ဖြစ်နိုင်ရင် အသံထွက်ပြီး စဉ်းစားခိုင်းဖို့ပါဘဲ။ ဒါမှမဟုတ်လည်း Task တစ်ခုလုပ်ပြီးတိုင်း “ဒီတစ်ခုလုပ်ပြီး ဘာကို စဉ်းစားနေလဲတို့၊ ဘယ်ဆက်သွားမှာလဲလို့” စသဖြင့်မေးပေးလို့လဲ ရပါတယ်။ မိမိကတော့ Feedback ပေးလာသမျှကို Note မှတ်ရပါမယ်။

ကဲ...Design Thinking Process က ဒါပါပဲ။ 
Design Thinking လုပ်ချင်းအားဖြင့် မိမိဆီက တစ်ခါဝယ်ပြီး ပျောက်သွားတဲ့လူတွေထက် တရစပ် လာဝယ်မယ့် Loyal Customer တွေတိုးပွားလာနိုင်ပါတယ်။ ဘာကြောင့်လဲဆိုတော့ Design Thinking ကိုသုံးပြီး ဒီ Customer တွေရဲ့ အခက်အခဲ ပြဿနာတွေကို Deep Dive ဝင်ရောက်ဖြေရှင်းပေးလို့ပဲဖြစ်ပါတယ်။ ကိုယ့် Company က လူတွေအချင်းချင်း ဒီ Feature ကမိုက်တယ်၊ Competitor တွေဆီမှာလည်းရှိတယ်၊ ငါတို့ လိုက်ပြီး Develop လုပ်မယ်ချည်း ဖြစ်မနေတော့ဘဲ မိမိဆီက တကယ့် Customer တွေရဲ့ အခက်အခဲကို တိုက်ရိုက်ဖြေရှင်းပေးတော့ ထုတ်လိုက်တဲ့ Feature တွေ၊ Product တွေတိုင်းက အားရကျေနပ်စရာဖြစ်သွားတာပေါ့။

------

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

Follow us on Facebook and Linkedin for the latest updates.

Comments

HYHM said…
Thanks for sharing.
Thanks for reading the article! :)
Htun Linn Aung said…
Thanks for sharing for this helpful post.

Popular Posts

အသုံးများတဲ့ 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

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 Death Cycle ထဲမဝင်မိအောင်

User-centric Product ဖြစ်ဖို့ ကိုယ့် User တွေရဲ့ Feedback တွေကို အမြဲနားထောင်ပြီး လိုအပ်ချက်တွေ ဖြည့်ဆည်းဖို့၊ Product ကို Improve လုပ်သွားဖို့ အရေးကြီးပါတယ်။ ဒါပေမယ့် ကိုယ့် Existing User တွေက အတောမသတ်နိုင်တဲ့ Feature Request တွေ၊ Changes တွေကို တောင်းဆိုနေ၊ Feedback တွေ ပေးနေခဲ့ရင်ရော? ဒါနဲ့ပတ်သက်ပြီး Product သမားတိုင်း သတိထားမိသင့်တဲ့ စိတ်ဝင်စားစရာ Product Death Circle ဆိုတဲ့ Concept အကြောင်းကို ဝေမျှချင်ပါတယ်။ Feature Factory Product နဲ့လည်း ဆက်စပ်နေတာမို့ စိတ်ဝင်စားရင် ProductBaze က ရေးသားခဲ့တဲ့ Feature Factory Product ဆောင်းပါးကို ဖတ်ကြည့်ဖို့ တိုက်တွန်းပါတယ်။ “Product Death Cycle” ဆိုတဲ့ အခေါ်အဝေါ်ကို Silicon Valley မှာရှိတဲ့ နာမည်ကြီး Author နဲ့ Founder ဖြစ်သူ David Bland က Twitter မှာ ဒီပုံလေးတင်ပြီး ဝေမျှခဲ့ရာကနေ စတင်ပါတယ်။ Product မှာ New User တွေ ရဖို့ခက်ခဲနေတယ်၊ ဘယ်သူမှ သိပ်လာမသုံးကြဘူး။ ဒီအခါ ရှိပြီးသား User တွေကို ဘာအဆင်မပြေလို့လဲ၊ ဘာ Feature တွေ လိုအပ်နေလဲ စသဖြင့် Feedback တွေ တောင်းကြလေ့ရှိပါတယ်။ User တွေကပေးတဲ့ Feedback ပေါ်မူတည်ပြီး Product ကို ပြင်ဆင်ကြ