User Scenario Analysis รู้ว่าเค้า…ใช้งานยังไง…ทำแอพร้อยแอพ ปังทุกแอพ

การวิเคราะห์ความต้องการของผู้ใช้ หรือของระบบธุรกิจ สามารถทำได้หลายวิธี แต่กับระบบหรือแอพที่ความซับซ้อนไม่มาก และยึดถือผู้ใช้เป็นศูนย์กลาง (User Center Design: UCD) วิธีการที่ผมใช้บ่อย และสามารถเก็บรายละเอียดได้รวดเร็วคือการวิ่งเข้าไปใน Business flow หรือ User flow ซึ่งเป็นที่รู้จักกันในชื่อ User Scenario Base Design ซึ่งอาจมองเป็นส่วนย่อยของการทำ User Story ที่คนสาย Agile ชอบใช้กัน

ใครบ้างควรใช้วิธีนี้ (USA:User Scenario Analysis) ในการเก็บความต้องการ

  • นักพัฒนา Mobile App ที่มี Target User ค่อนข้างชัดเจน (อาจจะสร้าง Personas ขึ้นมาก่อนได้) เพื่อสร้าง Draft Requirement และ Mockup ตัว Screen flow ขึ้นมาเพื่อยืนยันกับผู้ใช้เป้าหมาย
  • นักวิเคราะห์ระบบ ที่มีระบบงานเดิมเป็นแบบ Manual หรือ Semi-Auto แล้วอยากทำเป็นระบบงานใหม่ หรือ Application โดยมี flow ของระบบงานเดิมเป็นพื้นฐาน เราสามารถสร้าง Mock-up flow แล้วค่อยไปยืนยันกับผู้ใช้งานได้ โดยวิธีนี้ทั้งคนเก็บความต้องการ และผู้ให้ความต้องการจะเหนื่อยน้อยลง
  • นักเรียน นักศึกษา ที่ต้องการร่าง Scope ของโครงงาน เช่น Senior Project สามารถวิเคราะห์จากปัญหาที่ต้องการจะแก้ไข แล้วไล่ use case การใช้งานไปทีละ flow ทำให้ตัว scope งานมีความชัดเจนมากขึ้น โดยจะยังไม่อิงเทคโนโลยี หรือเฟรมเวิร์กใดๆ ค่อยมาเลือกวิธีการพัฒนา และเครื่องมือที่เหมาะสมทีหลัง

 

จะใช้วิธีนี้ต้องรู้อะไรบ้าง

  • มีความเข้าใจในระบบงานพื้นฐาน หรือ Business domain ที่ใกล้เคียงกันมาก่อน เช่น ถ้าเกี่ยวกับเงินๆทองๆ ก็ควรมีพื้นฐานระบบบัญชีเบื้องต้น ถ้าเป็นแอพกระเป๋าเงิน ก็ควรทดลองใช้แอพอื่นที่มีลักษณะใกล้เคียงในสิ่งที่เราจะทำ ถ้าไม่มีให้ศึกษาเลย อาจจะต้องลงทุน ไปนั่งดู หรือสังเกตุการจากการทำงานจริงของผู้ใช้เพื่อเก็บข้อมูลก่อน เช่นระบบร้านอาหาร แบบครบวงจรตั้งแต่หน้าร้านจนถึงห้องครัว เราควรที่จะต้องรู้กระบวนการคร่าวๆ ตั้งแต่ลูกค้าเดินเข้าร้าน เรียกเมนู สั่งอาหาร ทำอาหาร เสิรฟ จนถึงเช็คบิล แบบพื้นฐาน ซึ่งในระบบงานจริงที่จะทำอาจมีขั้นตอนปลีกย่อย แตกต่างกันออกไป เช่น ร้านพิซซ่า กับร้านอาหารทั่วไป อาจมีบางขั้นตอนแตกต่างกัน
  • ผู้ใช้ และผู้ที่เกี่ยวข้องกับระบบ แต่ละคนมีขั้นตอนการใช้งานหรือทำงานอย่างไร มีการติดต่อกับผู้ใช้คนอื่นหรือไม่ สิทธิในการเข้าถึงข้อมูลหรือเข้าถึงฟังก์ชันงานแต่ละส่วนแตกต่างกันอย่างไร มีโอกาสเกิดความขัดแย้งกับผู้ใช้อื่นหรือไม่
  • Platform หรืออุปกรณ์ที่ ผู้ใช้ ใช้ในการเข้าถึงระบบ รวมถึงขีดความสามารถพื้นฐานในการใช้งานอุปกรณ์ เช่น เด็ก วัยรุ่น คนทำงาน ผู้สูงอายุ มีความเข้าใจและความคล่องตัวในการใช้งานอุปกรณ์มือถือแตกต่างกัน เวลาออกแบบกระบวนการ ส่วนติดต่อผู้ใช้ รวมไปถึงวิธีการ input ข้อมูลก็อาจมีความแตกต่างกัน ยังไม่รวมถึงเรื่องของขนาดตัวอักษร และสีที่จะใช้ในกลุ่มผู้ใช้แต่ละแบบ
  • จำนวนข้อมูลที่ต้องนำเข้า ส่งต่อ และส่งออก มากน้อยขนาดไหน เป็นการสร้างภาระให้กับผู้ใช้ หรือผู้ดูแลระบบหรือไม่ เช่นพวกข้อมูลของผู้ใช้ หรือสินค้า บางส่วนสามารถนำเข้ามารอไว้ก่อน หรือเตรียมไว้ก่อนได้หรือไม่ เพื่อลดภาระการอินพุทข้อมูล เป็นต้น
  • ฟังก์ชันหรือฟีเจอร์ที่ควรต้องมี ไม่มีไม่ได้ ซึ่งคือส่วนที่เป็น Core Value ของระบบหรือแอพของเรา ที่จะทำให้ผู้ใช้ต้องมาใช้ระบบเราเท่านั้นในการแก้ปัญหาของเค้า ถ้าเป็นไปตามกฏ 80:20 แล้ว ใน 100 ฟีเจอร์ อาจมีแค่ 20 ฟีเจอร์เท่านั้นที่ผู้ใช้ต้องการจริงๆ
  • เครื่องมือที่ใช้ในการนำเสนอ User Scenario เพื่อเอาไว้ยืนยันกับผู้ใช้ ซึ่งอาจจะใช้แค่ข้อความกับลูกศร หรืออยู่ในรูปของ Business Flow Diagram หรืออยู่ในรูปของ Activity Diagram หรืออาจอยู่ในรูปแบบของ Screen Flow ที่เป็น Mock-up ก็ย่อมได้

ตัวอย่างการทำ User Scenario :  กรณีศึกษาระบบแอพร้านอาหาร

มองในมุมมองของ ผู้ใช้แอพ ที่จะเข้ามาทานอาหาร

  • ผู้ใช้ค้นหาร้านอาหารใกล้เคียง -> [ List, Map Near Me] -> เลือกร้าน -> แสดงรายละเอียดร้าน เมนูแนะนำ, แผนที่, เวลา เปิด-ปิด, วันนี้เปิดรึเปล่า, ราคาเฉลี่ย, *จองโต๊ะได้หรือไม่ -> กลับไปดูร้านอื่น/จองโต๊ะ
  • ผู้ใช้ จองโต๊ะ ->  ใส่จำนวนคน -> แสดงโต๊ะที่ว่าง -> กรณีไม่ว่าง ถามสะดวกแยกโต๊ะหรือไม่ -> จอง -> ยืนยันการจอง
  • ผู้ใช้ไปถึงร้าน -> แสดงโค้ดการจอง -> พนักงานพาไปที่โต๊ะ -> เลือกเมนู -> สั่งอาหาร
  • ผู้ใช้ จองและสั่งอาหารล่วงหน้า -> เลือกรายการอาหาร จำนวน -> โอนเงิน/จ่ายเงิน ค่าอาหารที่สั่ง -> รับรหัสการจองและหมายเลขโต๊ะ พร้อมเวลาเสริฟ
  • จริงๆ ยังมีอีกเยอะถ้าอยากจะทำ เช่น กรณีสั่งอาหารเพิ่ม สั่งกลับบ้าน สั่งพิเศษ อันนี้ลิสต์ให้ดูเป็นไอเดียนะครับ

มุมมองของ บริกร ที่ต้อนรับลูกค้า

  • ผู้ใช้เดินเข้ามาในร้าน -> ขอดูรหัสการจอง / สแกน QR ->  ตรวจสอบความเรียบร้อยของโต๊ะ -> พาลูกค้าไปที่โต๊ะ -> รับออเดอร์
  • กรณีผู้ใช้สั่งล่วงหน้า -> confirm รายการ -> นำอาหารจากครัวมาเสริฟ -> ยืนยันการรับอาหารครบถ้วน
  • ผู้ใช้เช็คบิล -> confirm รายการ รับครบ -> ส่งรหัสการแจ้งเก็บเงิน -> ลูกค้ายืนยัน จ่ายเงินผ่าน E-Wallet
  • ….

มุมมองของ ห้องครัว

  • มี order เข้ามา -> หมายเลขโต๊ะ รายการอาหาร คำสั่งพิเศษ เวลาที่ต้องเสิร์ฟ -> ทำอาหาร เสร็จ -> แจ้งยืนยันอาหารเสร็จ ตามรายการที่ระบุ -> ข้อความส่งไปถึงบริกร ให้เตรียมเสริฟ -> ข้อความส่งถึงลูกค้าว่าอาหารกำลังจะเสิร์ฟ -> ลูกค้าได้รับอาหาร
  • การณีสั่งเพิ่ม -> พิจารณา Priority และความต่อเนื่องของลูกค้า -> จัดทำอาหารที่สั่งเพิ่ม …..

นอกจากนี้ถ้าเป็นระบบใหญ่ ยังมีอีกหลายมุมมอง เช่นมุมมองผู้จัดการร้าน ผู้บริหาร ผู้บริหารที่มีร้านหลายสาขา ผู้ถือหุ้น เป็นต้น ซึ่งสิ่งเหล่านี้สามารถเขียนออกมาก่อนได้ แล้วค่อยไปยืนยันกับลูกค้า ว่าส่วนไหนที่ In Scope และส่วนไหนทีเป็น Out Scope ก็ตัดออกไป หรืออาจมีบางส่วนที่ขาดหายไป ไม่ครบถ้วนก็จะหาเจอได้โดยง่าย

เปรียบเทียบกับวิธีดั้งเดิม

  • ถ้าใช้วิธีการวิเคราะห์โดยการเขียน Scope เป็นข้อๆ ก็จะได้คนละมุมมองเช่น ผู้ใช้ สามารถทำอะไรได้บ้าง 1) ค้นหาร้านอาหาร   2) จองโต๊ะ 3) สั่งอาหารล่วงหน้า 4) ยืนยันการชำระเงิน เป็นต้น สังเกตว่าส่วนที่แสดงความต่อเนื่องในการใช้งานหายไป ทำให้อาจพลาดสิ่งสำคัญไป รวมทั้งสร้างประสบการณ์การใช้งานที่ไม่ดี ถึงขั้นลำดับหน้าจอผิด (เหมือนเวลาที่เราดูหนังที่ตัดต่อไม่ดีนั่นเอง) เวลาไปทำ Mock-up  Screen ก็จะติดปัญหาเดียวกัน คือลำดับไม่ถูก
  • การเขียนในเชิงของ Use Case Diagram จะเห็น Module (Use Case) แต่ละก้อนซึ่งจะเน้นไปที่ฟังก์ชันการทำงาน กับผู้ใช้ และความสัมพันธ์ระหว่าง Use Case กับผู้ใช้ แต่จะไม่เห็นความต่อเนื่องในการใช้งานเช่นกัน เพราะบาง Business Flow จะมีการใช้งานหลาย  Use Case ในลักษณะของ workflow ทำให้อาจพลาดส่วนสำคัญไป กว่าจะไปเขียนตัว Activity Diagram ข้างในก็ไม่ทันแล้ว

สังเกตว่าเราสามารถใช้ User Scenario ในการวิเคราะห์เส้นทางการใช้งาน ตั้งแต่ต้นจนจบ ในแต่ละกรณีการใช้งานได้อย่างมีประสิทธิภาพ เมื่อเก็บรายละเอียดครบแล้ว ก็ยังสามารถถอดออกมาเป็น Use Case Diagram , Activity Diagram , Class Diagram หรือแม้กระทั่งถอดกลับออกมาเป็น Scope ของสิ่งที่ต้องทำ ซึ่งในที่นี้เรายังสามารถให้ผู้ใช้เป็นคนตัดสินใจได้ว่า flow ไหนที่ต้องการใช้เป็น feature แรกๆ ตัวไหนไม่มีก็ได้ จะได้ทำการตัดออกตั้งแต่เนิ่นๆ ตามกฏ 80:20 นั่นเอง

 

อันที่จริง ที่เล่ามายังไม่ลึกมากเพราะกลัวจะเหนื่อยกันซะก่อน เพราะมันจะมีอีกหลายมุมมอง เช่นในมุมมอง UX ต้องแสดงรายการให้ผู้ใช้เลือกอย่างไร วิธี input ลูกค้าถนัดขวา หรือถนัดซ้าย สายตาปกติรึเปล่า  มุมมองเชิงธุรกิจ หน้ารายงาน หรือ dashboard ควรแสดงอะไรบ้าง จะนำตัวเลขหรือสถิติไหนมาใช้ รูปแบบของ Chart ความถี่ในการปรับปรุงข้อมูล ลักษณะการรับส่งข้อมูลและการจัดเก็บ ส่วนไหนควรเป็น Automate ส่วนไหนต้อง notify ผู้ใช้ …

 

วันนี้คงเบาๆ แค่นี้ก่อน เหตุที่มาเริ่มเขียนแนวนี้อีก เพราะตอนนี้กลับมาสอนเด็กๆ แล้ว พบเจอปัญหาในการตี Scope ระบบงาน และโครงงาน Senior Project ยังไม่แตก หรือไม่ชัดเจน เลยอยากนำเสนออีกวิธีการหนึ่ง ที่อาจจะช่วยให้ชีวิตง่ายขึ้น แค่เปลี่ยนวิธีคิดจากการมองระบบเป็นก้อนๆ(Module) มามองเป็นเส้นๆ (Scenario) แทน หวังว่าคงเอาไปประยุกต์ใช้กันได้นะครับ ^_^

ติดตามข้อมูลผ่าน FanPage เข้าไปกด Like ที่: https://www.facebook.com/AjBeeMePage

“ระบบยาก ผมไม่กลัว กลัวก็แต่ระบบที่ Scope ไม่ชัดเจน …ทำวนไปไม่รู้จบ …สิ้นเปลืองพลังชีวิตอย่างแรง”

มาร์ก ซักเกอร์เบิร์ก ไม่ได้กล่าวไว้ ;P

barcamp_chiangrai_2017

ใครอ่านมาถึงด้านล่างนี้ ฝากประชาสัมพันธ์งาน Barcamp ChiangRai 2017 (ครั้งที่ 4) จัดในวันที่ 18 กุมภาพันธ์ 2017 นี้ รายละเอียด(https://www.facebook.com/barcampCR/) ซึ่งผมเป็นหนึ่งในทีมงานจัดกิจกรรมนี้ร่วมกับสาขา Software Engineering สำนักเทคโนโลยีสารสนเทศ ม. แม่ฟ้าหลวง จ. เชียงราย ใครต้องการมาแลกเปลี่ยนความรู้กัน รีบจองตั๋วมานะครับ เที่ยวเหนือไปด้วย ได้เจอเพื่อนใหม่ๆในสายงาน แบ่งปันความรู้ดีๆ ให้กับน้องๆนักศึกษา ^_^