GUI_Template

Home / ພື້ນຖານ Desktop app / Design Pattern

ຫຼັກການອອກແບບ

ອອກແບບໜ້າຕາໂປຣແກຣມ UX & UI
ອອກແບບໂຄດ OOP & MVC

ຫຼັກການອອກແບບ User Interface (UI) ໃຫ້ມີ Usability

Usability ແມ່ນຫຍັງ?

“Usability” ເປັນຕົວບົ່ງຊີ້ຄຸນນະພາບທີ່ບົ່ງບອກວ່າ Product ໃຊ້ງານໄດ້ງ່າຍຊ່ຳໃດ “ຄວາມຍາກງ່າຍ” ສົ່ງຜົນໂດຍກົງກັບຄວາມຮູ້ສຶກ ແລະ ການຕັດສິນໃຈຂອງ User ວ່າຈະໃຊ້ງານ Product ນີ້ຕໍ່ໄປຫຼືບໍ່

ຕໍ່ໄປນີ້ຈະພາໄປຮຽນຮູ້ກ່ຽວກັບ 10 ເຕັກນິກການອອກແບບ UI

1. Visibility of system status

ພື້ນຖານຂອງຫຼັກການຂໍ້ນີ້ກ່ຽວຂ້ອງກັບການສື່ສານລະຫວ່າງລະບົບກັບຜູ້ໃຊ້ງານ ລະບົບຈະຕ້ອງສື່ສານກັບຜູ້ໃຊ້ງານຢ່າງມີປະສິດທິພາບ ຕໍ່ເນື່ອງ ແລະ ເຮັດໃຫ້ຄົນໃຊ້ເກີດຄວາມເຊື່ອໃຈທີ່ຈະໃຊ້ງານຕໍ່ ຕອນທີ່ພະຍາຍາມເຮັດຫຍັງກັບລະບົບແລ້ວບໍ່ມີຫຍັງຕອບສະຫນອງກັບມາ ຈະເຮັດໃຫ້ຄົນຮູ້ສຶກວ່າຕົວເອງສູຍເສຍການຄວບຄຸມ

Action = Reaction

ຄວນອອກແບບລະບົບໃຫ້ສະແດງ Feedback ໃນເວລາທີ່ເໝາະສົມໃຫ້ User ເຫັນຕອນທີ່ User ເຮັດ Action ຫຍັງບາງຢ່າງກັບລະບົບ ເພື່ອເຮັດໃຫ້ User ຮູ້ວ່າລະບົບຕອບສະຫນອງກັບສິ່ງທີ່ເຮັດໄປເມື່ອກີ້ນີ້ ບໍ່ໄດ້ແອບເຮັດວຽກມິດໆ ແລ້ວປ່ອຍໃຫ້ຄົນຄິດວ່າ Web/App ນີ້ມັນຄ້າງ ພັງ ຫຼື ກົດປູ່ມບໍ່ຖືກຫຼືບໍ່

UI ທຸກຢ່າງທີ່ User ສາມາດມີ Interaction ໄດ້ ຈະຕ້ອງມີປະຕິກິລິຢາຕອບສະຫນອງຢ່າງໃດຢ່າງໜຶ່ງ ເຊັ່ນ ປ່ຽນ status, style, ຕຳແໜ່ງ ແລະ ອື່ນໆ ຖ້າ User ໄປ Trigger attribute ຂອງ UI ນັ້ນ

Button ປ່ຽນຮູບຮ່າງຕອນທີ່ mouse hover (Source)

Card UI ກັບດ້ານຫຼັງກົດປຸ່ມ Detail (Source)

ຄວນອອກແບບ stage ໃຫ້ UI ເຊັ່ນ UI ອັບໂຫຼດ file ຕ້ອງມີ stage ກ່ອນອັບໂຫຼດ, ຕອນກຳລັງອັບໂຫຼດ, ແລະຜົນການອັບໂຫຼດ

ຕອນທີ່ກຳລັງໂຫຼດໄຟລ໌ ມີ UI ສະແດງສະຖານະວ່າໄຟລ໌ກຳລັງຖືກອັບໂຫຼດຢູ່

ຄວນບອກ User ວ່າຕອນນີ້ກຳລັງເຮັດຫຍັງຢູ່ ຕອນໃດທີ່ຕ້ອງຖ້າໃຫ້ລະບົບເຮັດວຽກ ຕອນໃດທີ່ລະບົບເຮັດວຽກສຳເລັດແແລ້ວ

2. Match between system and the real world

ຫຼັກການຂໍ້ນີ້ກ່ຽວຂ້ອງກັບການຈັດການຄວາມຄາດຫວັງຂອງຜູ້ໃຊ້ງານ ຄົນຄາດຫວັງວ່າປະສົບການເທິງໂລກດິຈິດຕອນຈະໃກ້ຄຽງກັບໂລກຄວາມເປັນຈິງ ເຊັ່ນ ການສົ່ງຂໍ້ຄວາມອອນໄລນ໌ກໍຈະໃກ້ຄຽງກັບການສົ່ງຈົດຫມາຍ, ການໄຮໄລທ໌ຂໍ້ຄວາມເທິງ Medium ກໍ່ຄືກັບຕອນທີ່ໃຊ້ບິກຂີດ ເປັນຕົ້ນ ແມ່ນຫຍັງທີ່ຄົນເຮັດຕາມຄວາມຄວາມເຄີຍມັນຈະງ່າຍ

Familiarity = Less Learning curve

ຄວນອອກແບບ UI ໂດຍຍຶດຕາມສິ່ງທີ່ຄົນຄຸ້ນເຄຍຢູ່ແລ້ວ ເພາະຄົນບໍ່ຕ້ອງຮຽນຮູ້ຫຍັງໃໝ່ ແລະ ເຂົ້າໃຈວິທີການໃຊ້ງານໄດ້ທັນທີ ເຊັ່ນ ອອກແບບ UI ໂດຍຮຽນແບບສິ່ງຂອງໃນໂລກຄວາມເປັນຈິງເພື່ອທີ່ຄົນຈະໄດ້ເຫັນແລ້ວເຊື່ອມໂຍງໄດ້ເລີຍວ່າຕ້ອງເຮັດຫຍັງ

UI ຂອງ credit card ຖືກອອກແບບໃຫ້ມີລັກສະນະຄ້າຍບັດແທ້ໆ ຄົນເລີຍສາມາດເຊື່ອມໂຍງໄດ້ວ່າຕົວເລກທີ່ເຫັນໃນ UI Card ກັບເລກໜ້າບັດຄືເລກດຽວກັນ (Credit)

ພາສາທີ່ໃຊ້ໃນ Web/App ຄວນໃຊ້ພາສາທີ່ຄົນທັ່ວໄປເວົ້າ ຢ່າພະຍາຍາມໃຊ້ພາສາຄອມພິວເຕີ ຫຼື ພາສາແປກໆ ຫຼື ຄຳສະເພາະທີ່ຄົນບໍ່ເຂົ້າໃຈ

ພາສາທີ່ໃຊ້ໃນ UI ຄວນເປັນພາສາທີ່ຄົນເຮົາເວົ້າກັນ

3. User control and freedom

Undo

ຢ່າໃຫ້ User ຕ້ອງເໜື່ອຍຕອນທີ່ຢາກຈະຢ້ອນກັບເວລາກົດ ຫຼື ເຮັດຫຍັງພາດໃນລະບົບ ເຮົາຄວນອອກແບບໃຫ້ Web/App ມີປຸ່ມ Back, Undo, Redo ສະເໝີ ຕອນທີ່ User ເຮັດຫຍັງພາດ UI ຄວນຈະຕ້ອງມີທາງອອກສຸກເສີນ, ໂຊວ໌ວິທີແກ້/ວິທີຢ້ອນກັບທີ່ User ເຮັດໄດ້ທັນທີໂດຍການທີ່ບໍ່ຕ້ອງຜ່ານຂັ້ນຕອນຫຍັງຫລວງຫລາຍ

Gmail ມີ Function Undo Send ໃຫ້ User ໃຊ້ ໃນກໍລະນີທີ່ User ຫຼົງກົດສົ່ງອີເມວໂດຍບໍ່ໄດ້ຕັ້ງໃຈ

4. Consistency and standards

Platform conventions

ໜ້າຕາຂອງ UI ຄວນອອກແບບໃຫ້ໄປໃນທິດທາງດຽວກັນ ຖ້າປຸ່ມທີ່ໜຶ່ງເປັນແບບໃດ ຕອນທີ່ປຸ່ມປະເພດດຽວກັນໄປຢູ່ອີກໜ້າກໍ່ຄວນເປັນແບບດຽວກັນ ແລະ ພະຍາຍາມຢ່າອອກແບບ UI ທີ່ບໍ່ເຄີຍມີມາກ່ອນໃນ platform ໃດເລີຍ ຖ້າເປັນໄປໄດ້ໃຫ້ອອກແບບຕາມ UI ພື້ນຖານຂອງແຕ່ລະ platform

ສ້າງ Design System ເພື່ອວາງ Guideline ໃນການອອກແບບ UI ເພື່ອໃຫ້ການອອກແບບໄປໃນທິດທາງດຽວກັນ

ວາງ UI Pattern & Structure ເຊັ່ນ ຖ້າເມນູຢູ່ດ້ານຊ້າຍ ຄວນໃຫ້ຢູ່ຊ້າຍຕະຫລອດທັງລະບົບ ຖ້າປຸ່ມ Action ຢູ່ດ້ານເທິງຂວາ ກໍ່ຕ້ອງຢູ່ເທິງຂວາຕະຫລອດ ການໃຊ້ Pattern ຊ້ຳໆ ຈະເຮັດໃຫ້ຄົນຈຳໄດ້ວ່າຫຍັງຢູ່ໃສ

5. Error prevention

Stop error-prone

ພະຍາຍາມອອກແບບເພື່ອດັກ Error ທີ່ຈະເກີດຂຶ້ນດ້ວຍ ເຊັ່ນ

ຟອມສະແດງ Warning/Error Message ຫາກ User ເຮັດຫຍັງຜິດເງື່ອນໄຂ

UI ມີ Error Message ບອກ User ວ່າ Password ຍັງບໍ່ກົງຕາມເງື່ອນໄຂຫຍັງແດ່

ເຕືອນ ຫຼື ປ້ອງກັນ User ກ່ອນຈະເຮັດຫຍັງທີ່ໄປສ້າງປະສົບການບໍ່ດີ ເຊັ່ນ

ສະແດງ Dialog Confirm ຖ້າ User ຕ້ອງການເຮັດ Action ທີ່ກັບຄືນບໍ່ໄດ້

iPhone ສາມາດເຊັດ Do not disturb mode ປ້ອງກັນຄົນໂທມາຕອນຂັບລົດ

ອອກແບບໂດຍຈຳກັດທາງເລືອກ User ບ່ອນໃດທີ່ຄິດວ່າ User ເຮັດແລ້ວຈະເຈີ Error ກໍ່ໃຫ້ໄປ block ຊ່ອງທາງນັ້ນຊະ ສົມມຸດວ່າ ຟອມທຸກຊ່ອງຕ້ອງປ້ອນຂໍ້ມູນເຖິງຈະກົດປຸ່ມ Submit ໄດ້ຖ້າມີຊ່ອງໃດທີ່ເຮົາລືມປ້ອນ ເວລາທີ່ເຮົາກົດປຸ່ມ Submit ມັນຈະຂຶ້ນ Error ດັ່ງນັ້ນ ຕອນທີ່ເຮົາອອກແບບເຮົາກໍບໍ່ຄວນເຮັດໃຫ້ປຸ່ມ Submit ກົດບໍ່ໄດ້ຖ້າຄົນຍັງປ້ອນຂໍ້ມູນບໍ່ຄົບ

6. Recognition rather than recall

Brainless action

ພະຍາຍາມຢ່າໃຫ້ User ຕ້ອງຈື່ຫຼາຍ ພະຍາຍາມໂຊວ໌ຂໍ້ມູນເທິງໜ້າຈໍແທນທີ່ຈະບັງຄັບໃຫ້ User ຈື່ໃນສະຫມອງ ຫຼື ຕ້ອງໃຊ້ເວລາຄິດວ່ານີ້ແມ່ນຂໍ້ມູນຄືຫຍັງ

Auto complete ຊ່ວຍໃຫ້ຄົນບໍ່ຕ້ອງຈຳວ່າຕົວເລືອກທັງໝົດມີຫຍັງແດ່

Amazon ມີເມນູ Browsing History ໃຫ້ຄົນເຂົ້າໄປເບິ່ງໄດ້ວ່າກ່ອນໜ້ານີ້ຫາກໍ່ເຂົ້າໄປເບິ່ງສິນຄ້າຫຍັງມາ

7. Flexibility and efficiency of use

Pro features

ຫຼັກການຂໍ້ນີ້ມີໄວ້ສຳລັບອຳນວຍຄວາມສະດວກໃຫ້ກຸ່ມ Pro User ເຮົາຄວນອອກແບບລະບົບໃຫ້ເໝາະກັບການໃຊ້ງານຂອງ User ຫຼາຍໆ ລະດັບ ໂດຍ Novice User (ລະດັບເລີ່ມຕົ້ນ) ສາມາດໃຊ້ງານຟັງກ໌ຊັ່ນຕາມວິທີປົກກະຕິໄດ້ ແລະ ກໍມີທາງເລືອກໃຫ້ Pro User ໃຊ້ຟັງກ໌ຊັ່ນໃນວິທີທີ່ມີປະສິດທິພາບ ແລະ ວ່ອງໄວກວ່າ

ມີຟັງກ໌ຊັ່ນສຳລັບກຸ່ມ Pro User ໂດຍສະເພາະ ໂດຍຟັງກ໌ຊັ່ນນີ້ຄ້າຍຄື option ເສີມຄົົນທີ່ຍັງເປັນ Novice ອາດຈະບໍ່ໄດ້ສັງເກດເຫັນວ່າມີຟັງກ໌ຊັ່ນນີ້ຢູ່ກໍໄດ້ ແຕ່ກໍຍັງໃຊ້ງານດ້ວຍວິທີພື້ນຖານໄດ້ຢູ່

ສ້າງ Shortcut ຫຼື ເອົາເມນູທີ່ໃຊ້ເລື້ອຍໆ ໄປໄວ້ໃນທີ່ທີ່ກົດງ່າຍໆ

8. Aesthetic and minimalist design

Less is more

ອອກແບບໂດຍເນັ້ນຄວາມລຽບງ່າຍ ມີຂໍ້ມູນ ການຕົກແຕ່ງ ການໃຊ້ສີທຸກຢ່າງເທົ່າທີ່ຈຳເປັນ ຂໍ້ມູນອັນໃດເຊື່ອງໄຫ້ໃຫ້ເຊື່ອງໄວ້ໃນ Interaction

ຫຼີກລ້ຽງການໃຊ້ Happy talk ຄື ຢ່າໃສ່ຕົວຫນັງສືທີ່ບໍ່ຈຳເປັນ ເພາະເຮັດໃຫ້ເກີດສິ່ງລົບກວນເທິງໜ້າຈໍ (noise)

ເຊື່ອງ Secondary function ໃນ UI State ຕ່າງໆ

9. Help users recognize, diagnose, and recover from errors

ເວລາທີ່ User ເຈີ Error message ຕ່າງໆ ໃຫ້ບອກ User ໃຫ້ຊັດເຈນດ້ວຍວ່າ User ເຮັດຫຍັງຜິດ (ດ້ວຍຄຳເວົ້າທີ່ຄົນທັ່ວໄປໃຊ້ກັນ) ແລະ ຈະຕ້ອງເຮັດແບບໃດເຖິງຈະແກ້ໄຂໄດ້

10. Help and documentation

ຖ້າລະບົບຊັບຊ້ອນ ອາດຈະຕ້ອງມີ link ທີ່ User ສາມາດເຂົ້າໄປອ່ານ Doc, tutorial, FAQs ຫຼື ເບິ່ງວິດິໂອໄດ້ໃນຕອນທີ່ User ຕ້ອງການຄວາມຊ່ວຍເຫຼືອ ແລະ ຢ່າສະແດງ Help ໃນຕອນທີ່ User ບໍ່ຕ້ອງການ ຫຼື ລະຫວ່າງທີ່ User ຢາກເຮັດຢ່າງອື່ນ ການເພີ່ມ Help & documentation ເຮັດໄດ້ຫຼາຍວິທີ ເຊັ່ນ

ເພີ່ມເມນູ Support/Help/FAQs