Home > Software(Product) တစ်ခုရဲ့ Usability ဆိုတာနဲ့ ၎င်းကို Testing ပြုလုပ်ခြင်းအပိုင်း

Software(Product) တစ်ခုရဲ့ Usability ဆိုတာနဲ့ ၎င်းကို Testing ပြုလုပ်ခြင်းအပိုင်း

Software(Product) တစ်ခုရဲ့ Usability ဆိုတာနဲ့ ၎င်းကို Testing ပြုလုပ်ခြင်းအပိုင်း

Ko Aung Pyae Phyo | 27 May, 2020

Article Description

UX ကောင်းတယ် လို့ သတ်မှတ်ကြတဲ့ Software (Product) တွေမှာ ပထမဦးဆုံး မြင်တွေ့ရတဲ့ အချက်က Usability ဖြစ်ပါတယ် ။ အကြမ်းဖျဥ်းပြောရရင်တော့ "ဘယ်လောက် သုံးရတာ လွယ်လဲ” ဆိုပါတော့ ။ ဒီအပိုင်းကို တိုင်းတာနိုင်ဖို့ “ဘာအတွက် သုံးချင်တာလဲ” ဆိုတာကိုလဲ ထည့်စဥ်းစားဖို့ လိုပါလိမ့်မယ် ။ ဥပမာ Taxi ငှားချင်တာလား ၊ ကိုယ့် Social Network ထဲကနေတဆင့် ပိုက်ဆံ ချေးချင်တာလား ၊ Gas မှာ ချင်တာလား ၊ Tutor ရှာချင်တာလား စသည်ဖြင့် ဆိုပါတော့။ ဒီ “ဘာအတွက်” ဆိုတာကို အခြေခံပြီး ဒါ အကောင်အထည်ဖော်နိုင်ဖို့ Software ကို အသုံးပြုပြီး “ဘာတွေ လုပ်ရမယ်” ဆိုတဲ့ Task တွေကို သတ်မှတ်ကြပါတယ် ။ ဒီ Task တွေမှာ Step-by-Step လုပ်ရတာတွေ ပါဝင်သလို ၊ သီးသန့်စီ လုပ်ရတာတွေလည်း ပါဝင်ပါတယ် ။

UX ကောင်းတယ် လို့ သတ်မှတ်ကြတဲ့ Software (Product) တွေမှာ ပထမဦးဆုံး မြင်တွေ့ရတဲ့ အချက်က Usability ဖြစ်ပါတယ် ။ အကြမ်းဖျဥ်းပြောရရင်တော့ "ဘယ်လောက် သုံးရတာ လွယ်လဲ” ဆိုပါတော့ ။

ဒီအပိုင်းကို တိုင်းတာနိုင်ဖို့ “ဘာအတွက် သုံးချင်တာလဲ” ဆိုတာကိုလဲ ထည့်စဥ်းစားဖို့ လိုပါလိမ့်မယ် ။ ဥပမာ Taxi ငှားချင်တာလား ၊ ကိုယ့် Social Network ထဲကနေတဆင့် ပိုက်ဆံ ချေးချင်တာလား ၊ Gas မှာ ချင်တာလား ၊ Tutor ရှာချင်တာလား စသည်ဖြင့် ဆိုပါတော့ ။

ဒီ “ဘာအတွက်” ဆိုတာကို အခြေခံပြီး ဒါ အကောင်အထည်ဖော်နိုင်ဖို့ Software ကို အသုံးပြုပြီး “ဘာတွေ လုပ်ရမယ်” ဆိုတဲ့ Task တွေကို သတ်မှတ်ကြပါတယ် ။ ဒီ Task တွေမှာ Step-by-Step လုပ်ရတာတွေ ပါဝင်သလို ၊ သီးသန့်စီ လုပ်ရတာတွေလည်း ပါဝင်ပါတယ် ။

Task တွေကို သတ်မှတ်ပြီးပြီ ဆိုတာနဲ့ ဘယ်လောက် Usable ဖြစ်တယ် ဆိုတာကို တိုင်းတာဖို့ စတင်နိုင်ပါပြီ ။

ပထမ အဆင့်မှာ ကိုယ့် Software (Product) ကို အသုံးများမဲ့ User Segment နဲ့ အနီးစပ်ဆုံးဖြစ်မဲ့ User လေးငါးယောက်ကို Test Subject အနေနဲ့ ရွေးချယ်ရပါမယ် ။ ပြီးရင် အဲဒီ Test Subject တွေကို ခုနက သတ်မှတ်ထားတဲ့ Task တွေထဲကတစ်ခုခုကို သူတို့ဘာသာ စမ်းလုပ်ကြည့်ခိုင်းရပါမယ် ။ ဒီနေရာမှာ Test Subject တွေကို သူတို့ လုပ်ရမဲ့ Task ရဲ့ Objective ကလွဲရင် ကျန်တာဘာမှပြောဖို့ မလိုပါဘူး ။

ဥပမာ Taxi ခရီးစဥ် တစ်ခု အပြီးမှာ Driver ကို Rating & Review ပေးနိုင်ဖို့ Task လိုမျိုးဆိုပါတော့ ။ စမ်းလုပ်ကြည့်မဲ့ User က ခရီးစဥ်တစ်ခုအပြီးမှာ ပြပေးနေမဲ့ Screen ကို ရောက်နေမယ် ။ အဲဒီကနေတဆင့် Task ကို သူတို့ဘာသာ မှန်းပြီး စမ်းပြီး လုပ်ကြည့်ခိုင်းတဲ့ သဘောဖြစ်ပါတယ် ။

Designer အနေနဲ့ Test Subject က ဒီလို မှန်းပြီး စမ်းပြိး လုပ်တာတွေထဲက ဘယ်လောက်ရာခိုင်နှုံးက Task ကို ပြည့်ပြည့်ဝဝ ပြီးမြောက်တယ် ၊ ဘယ်လောက် ရာခိုင်နှုံးကတော့ ပြီးမြောက်ပေမဲ့ အလယ်မှာ ဟိုနားဒီနား မှားနှိပ်မိတာတွေ ၊ ကြားမှာ Screen ကို သိပ်နားမလည်လို ဖြစ်ကြတယ် ဆိုတာတွေကို စောင့်ကြည့်မှတ်သားထားရပါမယ် ။ ပြုလုပ်နေတဲ့ Task အပြီးမှာ Designer က Test Subject နဲ့ ဒီအပိုင်းတွေကို အသေးစိတ် ပြန်လည်ဆွေးနွေးနိုင်ပါတယ် ။

ဒီ Process ကို Usability Testing လို့ ခေါ်ပါတယ် ။

ဒါမှ အစိတ်အပိုင်း တစ်ခုအပေါ်မှာ Designer က မြင်ထားတဲ့ အမြင်နဲ့ တကယ့် User က သုံးတဲ့အခါ မြင်တဲ့အမြင်ကြားမှာ ဘယ်နေရာတွေ “ဟ” သွားတယ် ဆိုတာကို နားလည်နိုင်မှာ ဖြစ်ပြီး ပိုမို သုံးရတာ လွယ်အောင် စီစဥ်ပေးနိုင်မှာ ဖြစ်ပါတယ် ။

Designer တွေ အကုန်လုံးကတော့ သူတို့ မြင်ထားတဲ့ အသုံးပြုနိုင်မဲ့ ပုံစံကို သူတို့ဘာသာ လွယ်ကူတယ် လို့ပဲ ထင်ကြတာပါပဲ ။ ဒါပေမဲ့ User နဲ့ ဒီလို Usability Testing မျိုး မပြုလုပ်ဘဲ ရည်ရွယ်တဲ့ User တွေအတွက် အမှန်တကယ် သုံးရတာလွယ်မလွယ်ကို တိတိကျကျ မသိရှိနိုင်ပါဘူး ။

ဒီလို Usability Testing ပြုလုပ်တဲ့ အခါမှာ Test Subject တစ်ယောက်ယောက်ရဲ့ Personal Bias တွေကို offset ပြုလုပ်နိုင်ဖို့ကလည်း အရေးကြီးပါတယ် ။ ဒါကြောင့် ဒီလို offset ပြုလုပ်နိုင်ဖို့ Target User Segment ကို ကိုယ်စားပြုဖို့ Test Subject ကို ရွေးချယ်တဲ့အခါမှာ လေးငါးယောက် ရွေးချယ်တာ ဖြစ်ပါတယ် ။

 

General Public အတွက် ရည်ရွယ်တဲ့ ဘယ် Software (Product) ရဲ့ Design ကိုမှ (ပိုင်ရှင် အပါအဝင်) လူတစ်ဦးတစ်ယောက်ရဲ့ Bias ကို အခြေခံပြီး မတည်ဆောက်သင့်ပါဘူး ။

 

တကယ်လို့ Software (Product) မှာ Target Segment တစ်ခုထပ်ပိုရှိနေတယ်ဆိုရင်လည်း Segment တစ်ခုချင်းစီအတွက် အနည်းဆုံး Test Subject လေးငါးယောက်နဲ့ စမ်းသပ်နိုင်ပါတယ် ။

ဒီလို စမ်းသပ်တဲ့ အခါမှာ Test Subject တွေအနေနဲ့ Task တွေကို ပြီးမြောက်ကြပေမဲ့ ဒီ Task တွေက Step တွေများနေတယ် ၊ အချိန်ပေးရတဲ့ ပမာဏများနေတယ် ဆိုရင်လည်း Usability ကို impact ဖြစ်စေပါတယ် ။ ဒါကြောင့် Task တစ်ခုချင်းစီမှာ User တွေ စိုက်ထုတ်ရမဲ့ Effort ကိုတိုင်းတာပြီး တတ်နိုင်သမျှ optimize ပြုလုပ်နိုင်ဖို့လည်း လိုအပ်ပါတယ် ။ စိုက်ထုတ်ရမဲ့ Effort ကိုကတော့ click / tap ပမာဏ ၊ ဖြည့်ရတဲ့ input တွေ လုပ်ရတဲ့ action တွေရဲ့ အရည်အတွက်နဲ့ ပေးရတဲ့ အချိန် တွေနဲ့ တိုင်းတာနိုင်ပါတယ် ။

ဒါပေမဲ့ မော်တော်ကား တစ်စီး မောင်းတာလို ပြုလုပ်ရမဲ့ ကိစ္စ တစ်ခုကို လက်တွန်းလှည်း တွန်းသလောက် လွယ်အောင် လုပ်ပေးနိုင်ဖို့ဆိုတာ အမြဲတမ်းတော့ မဖြစ်နိုင်ပါဘူး ။ ဒါကြောင့် သက်ဆိုင်ရာ Task အတွက် အနည်းဆုံး ဖြစ်နိုင်မဲ့ စိုက်ထုတ်ရမဲ့ ပမာဏကို ရအောင်သာ optimize ပြုလုပ်နိုင်မှာ ဖြစ်ပါတယ် ။

နောက်တစ်ခုက “Perceived Effort” ပါ ။ Task တစ်ခုအတွက် Actual ပေးရတဲ့ Effort ပမာဏ နဲ့ User တွေဘက်က ဘယ်လောက် Effort စိုက်ထုတ်လိုက်ရတယ်လို့ မြင်တဲ့ ပမာဏက တစ်ချို့ case တွေမှာ ကွဲပြားမှုတွေ ရှိနေနိုင်ပါတယ် ။

ဒီ Perceived Effort ကို အဓိက လွှမ်းမိုးတဲ့ အစိတ်အပိုင်း ၂ ခုရှိပါတယ် ။

ပထမ တစ်ခုက Task ကို မလုပ်ခင်မှာ Task အတွက် User ဘက်က (မသိစိတ်ကဖြစ်ဖြစ်) ကြိုမှန်းမိထားတဲ့ Effort ပါ ။ ဥပမာ ကိုယ်က သူငယ်ချင်းတွေကို ပိုက်ဆံ လွှဲတာ (Remittence) နဲ့ သူငယ်ချင်းတွေဆီက ကိုယ်က ပိုက်ဆံချေးတာ (Peer-to-Peer Lending) မှာ User အနေနဲ့ စိုက်ထုတ်ရမဲ့ Effort ကို မှန်းထားတဲ့ ပမာဏချင်း မတူနိုင်ပါဘူး ။ User က ၃ လောက် မှန်းထားတဲ့ Task မှာ စိုက်ထုတ်ရတယ်လို့ ခံစားရတဲ့ Effort က ၃ ဖြစ်နေတာ ကိစ္စ မရှိပေမဲ့ User က ၁ လောက်ပဲ မှန်းထားတဲ့ Task မှာ ၃ လောက် စိုက်ထုတ်ရတယ်လို့ ခံစားရပြီဆိုရင်တော့ နည်းနည်းတော့ adjust လုပ်ဖို့ လိုနေပါပြီ ။

ဒုတိယ တစ်ခုက UI က ဘယ်လောက် စိတ်ကျေနပ်မှု အရသာ (Delightful) ဖြစ်စေတယ် ဆိုတာ ဖြစ်ပါတယ် ။ Delightful ဖြစ်တဲ့ UI တစ်ခုက Perceived Effort (not Actual Effort) ကို သိသိသာသာ လျှော့ချပေးနိုင်ပါတယ် ။

UX တစ်ခုရဲ့ Delightful ဖြစ်မှု အပိုင်းကိုတော့ ရှေ့အပတ်မှာ ဆက်ရေးသွားပါဦးမယ် ။

အားလုံးပဲ UX ကောင်းမွန်တဲ့ Software (Product) တွေ ဖန်တီးတည်ဆောက်နိုင်ကြပါစေ ။

Assets