UX ของใบสั่งอาหาร (1)

อันนี้เป็นเรื่องแปลกและน่าสนใจสำหรับผมครับ ดูลักษณะแล้วจะยาว แบ่งเป็นตอนๆ ละกัน

ช่วงนี้มีเหตุให้ต้องอยู่เชียงใหม่บ่อยๆ นานๆ สังเกตอย่างหนึ่งว่าร้านอาหารในเชียงใหม่หลายๆ ร้านที่ผมไปกิน จะมีวิธีการให้ลูกค้าสั่งอาหารลักษณะที่น่าสนใจคล้ายๆ กันอยู่

วิธีการสั่งอาหารเวลาที่ผมจะคุ้นอยู่บ่อยๆ คือ มีคนมาจดรายการอาหารหรือเราจดรายการอาหาร รูปแบบการจดก็เป็นแบบ

[ชื่ออาหาร][คุณสมบัติ] [จำนวน]

ยกตัวอย่างเช่น

[สำตำปูปลาร้า][เผ็ดน้อย พริกเม็ดเดียว] [1]

ซึ่งรูปแบบนี้ก็เข้าใจง่ายดี มีข้อดี

• คนสั่งมีิอิสระค่อนข้างสูงในการประกอบคุณสมบัติของอาหารขึ้นมา
• ลักษณะการกำหนดจำนวนก็ค่อนข้างง่าย เพราะรูปแบบ [ชื่ออาหาร] [จำนวน] เป็นลักษณะที่คุ้นเคยในการบอกจำนวนนับ

แต่แบบจดลงกระดาษก็มีข้อเสียคือ

• คนทำอาหารอาจจะอ่านลายมือไม่ออก
• รายการอาหารนั้นๆ อาจจะไม่มีเพราะคนสั่งสร้างเมนูขึ้นมาเอง อาจจะนำไปสู่การอารมณ์เสียของคนทำอาหาร ซึ่งเป็นปัจจัยทำให้อาหารไม่อร่อยได้ง่าย

ทีนี้ประเด็นที่น่าสังเกตของร้านอาหารหลายๆ ร้านในเชียงใหม่ที่เจอมาคือ เขาจะมีใบสั่งอาหารที่พิมพ์รายการอาหารไว้ และเว้นช่องให้ใส่จำนวนแบบนี้

ใบสั่งอาหารของร้านป้าเล็กส้มตำ

ใบสั่งอาหารของร้านอะไรสักอย่างแถวๆ หลัง มช. ด้านซ้ายเป็นใบสั่งก๋วยเตี๋ยว ด้านขวาเป็นใบสั่งอาหารว่าง

ตัวอย่างอีกอันหนึ่งคือจากร้านอะไรสักอย่างแถวๆ หลัง มช. อันนี้จะลักษณะคล้ายๆ ร้านป้าเล็กส้มตำแต่มีการแบ่งใบสั่งอาหารเป็นสองแบบ คือ ใบสั่งก๋วยเตี๋ยว และ ใบสั่งอาหารว่าง มีคุณสมบัติเพิ่มเติมให้คนสั่งอาหารเลือกได้อาทิ ประเภทของเส้นก๋วยเตี๋ยว ขนาดธรรมดาหรือพิเศษ รวมไปถึงหมายเหตุที่อาจจะให้คนสั่งไว้กำหนดคุณสมบัติพิเศษเช่น ไม่พริก ไม่ผัก ฯ

การทำใบสั่งอาหารแบบนี้มีข้อดีข้อเสียที่คิดได้ประมาณนี้คือ

ข้อดีคือ

• ไม่ต้องทำเมนูอาหาร
• สร้าง force function ให้กับคนสั่งอาหาร โดยที่ยังสามารถควบคุมตัวเลือกให้คนสั่งอาหารไม่รู้สึกว่ามีอาหารให้เลือก น้อยไป จนไม่อยากกินหรือมากไปจนขี้เกียจเลือกได้
• ลดความเสี่ยงในการตีความชื่ออาหารผิด
• สามารถนำใบนี้มาคำนวณราคาอาหารตอนเก็บเงินได้ทันที

ข้อเสียคือ

• หากมีการแก้ไขจำนวนอาหารที่จะสั่ง อาจจะเริ่มลำบาก นึกถึงกรณีไปกันหลายๆ คน คนหยิบใบนี้มาคนแรกก็จะสั่งอาหารที่ตัวเองจะสั่ง แล้วตามวิถีของ behavioral economy คนต่อไปก็จะมีแนวโน้มเลือกตามคนแรกค่อนข้างสูง ทำให้มีโอกาสการแก้ซ้ำๆ คนล้นช่องและกลายเป็นดูลำบากไปค่อนข้างสูง

 ยังมีใบสั่งอาหารลักษณะคล้ายๆ กันอีกหลายแบบ เดี๋ยวมาต่อตอน 2 จ้ะ :D

คุ้มหรือเปล่าที่จะทำ UX

มีเพื่อนบน facebook.com/groups/ux.in.th ท่านหนึ่ง พูดถึงมุมมองของบริษัทต่อ UX ว่า

พี่ท่านนึงที่จบป.โท ด้าน Human-Computer interaction มาโดยตรงเคยคุยให้ฟังว่า UX ถูกมองว่า เป็นการลงทุนที่สิ้นเปลือง ทำให้ตลาดงานยังค่อนข้างแคบ

ผมมองว่ามันมีที่มาของความคิดแบบนั้น สำหรับคนที่มารู้จัก UX ใหม่ๆ เค้าจะพยายามจับ UX เทียบกับสิ่งที่เค้าผ่านมาแล้วด่วนสรุปในหัวว่า UX เป็นเพียงตำแหน่งงานหนึ่ง ซึ่งหน้าที่นี้ฝ่ายออกแบบก็ทำอยู่แล้ว ฝ่ายการตลาดก็ทำอยู่แล้ว ฝ่ายพัฒนายิ่งไม่เกี่ยวเพราะไม่ต้องออกแบบ ดังนั้นตำแหน่ง UX จึงเป็นการลงทุนที่ซ้ำซ้อนและสิ้นเปลือง

บางกลุ่มมองว่า UX เป็นงานของทีม Graphic Design หรือไม่ก็ทีมเก็บ Requirement ซึ่งสองตำแหน่งนี้ก็คิดถึง User อยู่แล้วทำไมต้องมาทำ UX อีก

บางกลุ่มมองว่าการทำให้ User ได้รับประสบการณ์ที่ดี ไม่ได้ทำให้บริษัทได้เงินเพิ่มขึ้น หรือทำให้ต้องลงทุนมากไป จนไม่คุ้ม

คนที่คำนึงถึงลูกค้า และคนที่ศึกษา UX จะรู้ว่าการคำนึงถึงลูกค้าตลอดเวลา มันมีค่ามากขนาดไหน ผมเคยดู Video อันหนึ่งที่พูดถึง Return of Investment (ROI) ของงาน UX ครับ

Video ของ HFI Animate

วีดีโอนี้ได้ทดลองคำนวนต้นทุน และผลกำไรที่ได้จากการทำ UX ออกมาอย่างชัดเจน ดังนั้นถ้าใครมีปัญหากับหัวหน้า ว่าทำไมต้องทำ UX ลองเอาวีดีโอนี้ให้ดูนะครับ

สุดท้ายเค้าจะรู้ว่า UX ไม่ใช่เรื่องของใครหรือตำแหน่งใด แต่เป็นเรื่องของทุกคนในทีม ที่คิดถึงลูกค้าเป็นหลัก และถ้าทำได้จะทำให้ทั้งต้นทุนลดลง กำไรก็มีโอกาสที่จะเพิ่มขึ้นครับ ดังนั้นถ้าจะมีตำแหน่ง UX ก็จะเป็น UX Master คล้าย Scrum Master ครับ

ออกแบบ Tab บน Android (ตอนที่ 3)

ตอนที่ 1 และ ตอนที่ 2 เราพูดถึงเรื่องตำแหน่ง และ Style ในการออกแบบ Tab บน Android มาถึงตอนที่สามเราจะมาเก็บรายละเอียดกัน บางทีสิ่งที่อยู่ในตอนที่สามนี่ละ ที่เป็นหัวใจของ UX ที่สามารถนำไปใช้ได้ในทุก Platform

ข้อแรก Tab มีไว้ใช้สำหรับนำทาง (Navigation) ไม่ใช่การกระทำ (Action)

Tab ทั้ง Android และ iPhone ต่างเอาไว้สำหรับการนำทาง (navigate) ไปยังหน้าจอต่างๆ ใน App ดังนั้นไม่ควรนำปุ่มสั่งงานมาไว้ที่ Tab

ตัวอย่างการใช้ Tab ที่ผิด

ในภาพตัวอย่างจะเห็นว่านักพัฒนาเอา  Action มาปนอยู่ใน Navigation  บาง Tab ทำให้หน้าจอเปลี่ยน บาง Tab เป็นการสั่งงานไม่ได้พาผู้ใช้ไปหน้าจอไหนเลย ลักษณะนี้จะสร้างความสับสับให้ผู้ใช้ได้ครับ

Tab ต้องถูกเลือกอยู่ตลอดเวลา

ต้องมี Tab ใด Tab หนึ่งแสดงว่าตัวเองถูกเลือกอยู่ เพราะเราต้องการบอกผู้ใช้ว่าตอนนี้เค้าอยู่ตรงส่วนไหนของโปรแกรม และทำให้เค้าสามารถกลับมาได้ถูกต้องเมื่อไปที่ Tab อื่น 

เงื่อนไขข้อนี้จะไปเสริมกับเงือนไขข้อแรกว่า ปกติผู้ใช้กดบน Tab แล้ว Tab นั้นจะเปลี่ยนสีค้างไว้เพื่อแสดงว่าผู้ใช้อยู่บน Tab นี้ แต่ถ้า Tab นั้นกลายเป็น Action ผู้ใช้กดเท่าไหรก็ไม่สามารถเข้ามาสู่ Tab นั้นได้ จะทำให้ผู้ใช้จะรู้สึกเหมือนหลงทางได้ครับ

การใช้ Back กับ Tab

การเปลี่ยน Tab ไม่ถือว่าเป็นการเปลี่ยนหน้าสำหรับ android ถ้าผู้ใช้กดปุ่ม Back โปรแกรมจะนำผู้ใช้ออกไปจากโปรแกรมหรือกลับไปที่หน้าก่อนหน้าที่มี Tab นี้อยู่

ที่เป็นแบบนี้เพราะว่าแนวคิดของปุ่ม Back ของ Android คือการกลับจากหน้ารองไปสู่หน้าหลัก ดังนั้นการเปลี่ยน Tab ไม่ได้ไปสู่หน้ารอง แต่เป็นการไปอีก tab หนึ่งและสามารถกลับมาหน้าเดิมได้ด้วยการกดบน Tab ไม่จำเป็นต้องใช้ปุ่ม Back

การเปลี่ยน Tab ด้วย Swipe!

บน Android 4.x ผู้ใช้สามารถเปลียน Tab ได้ด้วยการลากนิ้วมือไปทางซ้าย/ขวา จะเป็นการเปลี่ยน Tab ได้ ดังนั้นนักพัฒนาจะต้องระวังเรื่อง Transition ให้ดี ในกรณีของ iPhone เมื่อผู้ใช้กดบนหัวข้อจะเกิด Transition ว่าหน้าจอเนื้อหาไหลจากทางซ้ายเข้ามา แต่บน Android ถ้าทำแบบนั้นผู้ใช้อาจจะรู้สึกว่าอีก Tab นึงมันเลื่อนเข้ามา ซึ่งทำให้การรับรู้ผิดไป

เขียนครั้งเดียวใช้ได้ทั้งจอเล็ก จอใหญ่

เมื่อเป็นจอเล็ก Tab จะลงมาเป็นบรรทัดที่สอง แต่ถ้าเป็นจอใหญ่เนื้อที่ด้านบนมีมาก ให้เอา Tab ขึ้นไปอยู่ด้านบน นอกจากนั้นสำหรับจอใหญ่ให้เอาเนื้อหาในหน้าที่สองมาไว้ข้างขวาบนหน้าแรกได้เลย

ตัวอย่าง App ในงาน google IO

สรุปว่า

Tab จะดีได้เราต้องพัฒนาออกมาให้ตรงตาม Guide line ด้วย แต่เนื่องจาก Tab ในแต่ละ Platform ทำงานไม่เหมือนกันดังนั้นขอให้นักพัฒนาระวังไว้ดีๆ ห้ามเอาประสบการณ์จาก Platform อื่นมาตัดสินเพราะถ้าทำผิดจาก Guideline จะทำให้ผู้ใช้สับสน ในทางตรงกันข้าม ถ้าทำได้ตาม Guideline ผู้ใช้จะไม่สับสนและรู้สึกดีกับระบบนำทางในโปรแกรมของคุณ

อย่าลืมว่าเราไม่ใช่ผู้ใช้ ต้องพยายามจิตนาการผู้ใช้ตัวจริงออกมาให้ได้นะครับ

ที่มา: www.androiduipatterns.com/2012/08/tips-for-android-tabs.html

ออกแบบ Tab บน Android (ตอนที่ 2)

ตอนที่ 1 เราคุยกันเรื่องตำแหน่งของ Tab และที่มาที่ไปของแนวคิด แต่นอกจานั้นยังมีเรื่องของรูปแบบ (style) ในการออกแบบด้วย ใครที่เคยทำ Application บน Android ต้องลองย้อยกลับมาดูว่ามันยังถูกต้องอยู่หรือเปล่า ยิ่งถ้าต้องการย้ายมาอยู่บน Android 4.x ยิ่งต้องดูให้ดี

แนวทางในการออกแบบมีหลักๆ 3 ข้อ

1. Tab บน Android ไม่นิยม Icons จะใช้ Text เพื่อบอกไปเลย เหตุผลเพราะว่า การหา icon ให้ตรงกับสิ่งที่ต้องการสือให้ครบมันยากมาก ดังนั้นใช้ Text ไปเลยจะดีกว่า
2. Tab บน Android ไม่เป็นสี่เหลี่ยมจัตุรัสเพราะมันใช้ Text เท่านั้นเลยประหยัดกว่าถ้าเป็นสี่เหลี่ยมผืนผ้า
3. แนวทางของ Android จะเน้นแบนๆ ดังนั้นจึงไม่มีการใส่เงาวิ้งๆ หรือใส่แสงสะท้อน

ยกตัวอย่าง App สองตัวคือ Phone และ Foursquare สองตัวนี้มี Tab เรียบๆ แบนๆ และใช้ขีดบอกว่าตอนนี้ผู้ใช้อยู่ Tab ไหน

ตัวอย่าง Tab ที่ถูกต้องบน Android

จะเห็นว่าในโปรแกรม Phone  จะใช้ icon แทนที่จะเป็น Text อันนี้เป็นกรณีพิเศษเนื่องจากเราสามารถหา icon ที่สื่อได้ตรงและได้ครบทุก Tab จึงสามารถใช้ icon ได้

ตัวอย่างการใช้ Tab ที่ไม่เหมือนโปรแกรมบน Android

โปรแกรมตัวอย่างทั้งสองตัวนี้ทำ Tab อออกมาในลักษณะของ iPhone ทำให้ผู้ใช้ที่คุ้นเคยกับ Platform Android สับสนได้ แต่ถ้าอยากคง Brand ไว้ก็สามารถทำได้ด้วยสีของ Tab และรูปแบบการนำเสนอก็ได้ครับ ไม่จำเป็นต้องทำรูปแบบ Tab ให้เหมือนกัน

ที่มา: androiduipatterns.com

ออกแบบ Tab บน Android (ตอนที่ 1)

การออกแบบ Tab บน Android มีปัญหาอยู่หลายประเด็นมากครับ เริ่มตั้งแต่นักพัฒนาไม่ทำตาม Guideline ของ Android แต่เอา Tab ไปไว้ด้านล่างตาม iPhone หรือประเด็นว่า Tab ของ Android เปลี่ยนไป เมื่อก่อนเป็น  Tab ใหญ่ๆ เดี๋ยวนี้เป็นแบบเล็กๆ มีแต่ตัวหนังสือไม่มีรูปอย่างเดียว หรือปัจจุบัน Guide line บอกให้สามารถใช้การลากนิ้วเพื่อเปลี่ยน Tab ได้ แต่เมื่อก่อนทำไม่ได้

ตัวอย่าง Tab ในปัจจุบัน

เมื่อ Platform มีการเปลี่ยน Guideline นักพัฒนาที่คำนึงถึงผู้ใช้ก็ควรเปลี่ยนให้เหมือนกันโดยพร้อมเพรียงครับ ผู้ใช้จะได้ไม่สับสนและไม่ต้องเรียนรู้หลายๆ แบบ แต่ก็ใช่ว่าเราควรทำตาม Guideline แบบไม่รู้ที่มาที่ไป ไม่อย่างนั้นมันจะเป็นบาบติดตัวเราไปตลอดและทำให้งานออกแบบที่ปรับแก้ไปเรื่อยๆ เริ่มผิดพลาดได้

ทีนี้เราลองมาดูที่มาที่ไปของ Guideline ของ Android กัน

เริ่มจากทำไม Tab ต้องขึ้นไปอยู่ด้านบน สามารถอ่านรายละเอียดได้ที่บทความ tabs-top-or-bottom โดยผมสรุปออกมาได้ 3 ข้อ

1. ปกติการวางลำดับชั้นมักจะไล่จากบนลงล่าง ดังนั้น Tab ที่เป็นหัวข้อหลักจึงควรอยู่ลำดับชั้นบนสุด ซึ่งก็คือบนสุดของจอ
2. App ที่ซับซ้อนมักจะมีลำดับชั้นมากกว่าหนึ่งขั้น การเอา Tab หลักไว้ด้านล่างแล้วมี Tab รองอยู่ด้านบนจะสร้างความสับสนให้ผู้ใช้ได้
3. ผู้ใช้จะอ่านจากบนลงล่าง ดังนั้นผู้ใช้น่าจะเข้าใจลำดับชั้นของโปรแกรมได้ดีกว่าถ้า Tab อยู่ด้านบน

ตัวอย่างเปรียบเทียบงานปรับแก้ของ eurosport ที่เคยเอา Tab หลักไว้ด้านล่าง และมี Tab รองอยู่ด้านบน ทำให้ผู้ใช้ลำบากในการคาดเดาว่าตัวใดคือ Menu หลัก

 

Application eurosport เปลี่ยนจากแบบเก่าทางซ้ายไปเป็นแบบใหม่ทางขวา

หลังจากการปรับแก้ทำให้ Tab ไปอยู่ด้านบน และแปลง Menu รอง ให้กลายเป็น Filter บน Titile Bar ทำให้โปรแกรมดูง่ายขึ้น ไม่สับสนระหว่า Tab ด้านบนและ Tab ด้านล่าง

เพิ่มเติม: สำหรับคนที่พัฒนาโปรแกรมบน iPhone โดยมี Tab อยู่ด้านล่างก็ไม่ควรมี Tab ไว้ทั้งข้างบนและข้างล่างแบบ eurosport ตัวเก่านะครับ ควรจะแปลง Tab รองที่อยู่ด้านบนให้เป็น Filter บน Title bar แทน แล้วคง Tab ให้อยู่ด้านล่างแบบเดิมครับ เท่านี้ก็จะลดความสับสนได้แล้ว

ที่มา: androiduipatterns.com

Traditional web หรือ Rich Internet web

ก่อนหน้านี้เว็บส่วนมากจะไม่มีลูกเล่นพิเศษ การกด Link หรือกดปุ่มใดๆ จะมีการ Refresh ทั้งหน้าจอเสมอ ซึ่งผมมองว่านั่นเป็นสิ่งที่ทำให้เว็บง่าย ทั้งการทำความเข้าใจได้เร็วและโอกาสที่จะเดาการทำงานผิดก็น้อยด้วย ผมจะเรียกเว็บแบบนี้ว่า Traditional web 

ส่วนเว็บในปัจจุบันที่สามารถทำหลายอย่างได้ในหน้าเดียว ตัวเว็บสามารถ refresh ได้เป็นจุดๆ สามารถ double click, drag & drop, right click ได้ เหมือนกับการยก Desktop Application มาไว้บนเว็บ บางทีเราเลยเรียกว่า Web Desktop Class Application หรือในที่นี้เราจะเรียกมันว่า Rich Internet Application 

ภาพเปรียบเทียบ Traditional web เทียบกับ Rich Internet App

RIA หรือ Rich Internet Application เติบโตมาจากเทคโนโลย Java Applet, Flash, SVG จนปัจจุบันเทคโนโลยี และมาตรฐานของ HTML/HTML5 พัฒนาขึ้นมาจนเราไม่ต้องใช้ plugin ทั้งสามตัวที่กล่าวมาก็สามารถทำ RIA ได้ ทำให้ผู้ใช้สะดวกสะบายขึ้นมาก เพราะไม่ต้องลงโปรแกรมเสริม

เมื่อความลำบากของผู้ใช้ลดลง สิ่งที่ขวางไม่ให้ใช้ RIA ก็น้อยลง เราสามารถใช้ RIA กับเว็บของเราได้ทันที การตัดสินใจจึงขึ้นอยู่กับว่า RIA เหมาะกับ Web ของเราหรือเปล่า?

ตัวอย่าง RIA จาก framework cappuccino

แนวทางง่ายๆ ในการเลือก ให้พิจารณาจากความต้องการของผู้ใช้และลักษณะของ web ของเราเป็นหลัก ถ้ากลุ่มเป้าหมายของเราเป็น Home use ความง่ายจะมาเป็นอันดับหนี่ง ผู้ใช้สามารถรอได้ สามารถ click หลายครั้งได้ ถ้ามันทำให้ง่ายขึ้น พวกนี้เราจะใช้ Traditional  web

แต่สำหรับให้มืออาชีพใช้ เช่น นักบัญชีมืออาชีพ นักออกแบบมืออาชีพ นักทำ presentation มืออาชีพ พวกนี้ความง่ายเป็นรอง ความรวดเร็วในการสร้างงาน จะมาก่อน คนกลุ่มนี้ยินดีแลกเวลาในการเรียนรู้กับเวลาในการทำงาน ดังนี้เราสามารถทำ web ให้ใช้งานยากได้ จึงเหมาะกับพวก RIA ครับ

ก่อนพัฒนาขอให้แน่ใจว่าเราเลือกรูปแบบการพัฒนา ให้เข้ากับผู้ใช้ของเราแล้ว และคุณลักษณะของโปรแกรมของเราแล้ว จึงค่อยเริ่มงานพัฒนานะครับ

ขอแนะนำให้รู้จัก CX

CX ในที่นี้ย่อมาจาก Customer eXperience แปลตรงตัวก็คือประสบการณ์ของลูกค้า ถ้านำมาเปรียบเทียบกับ UX คงทำให้กรอบของ UX แคบลงจนกลายเป็นประสบการณ์เฉพาะด้าน Technology หรือด้านของ Application  เท่านั้น ส่วน CX จะหมายถึงประสบการณ์ทั้งหมดของลูกค้า

ถ้ายกตัวอย่างเป็น Application ตัว UX จะเป็นเพียงส่วนหนึ่งของ CX เพราะ UX จะครอบคลุมเฉพาะตัวโปรแกรม การติดตั้ง การติดต่อกับ Software ตัวอื่น แต่ CX จะรวมไปถึงการตั้งราคา การส่งไปให้กับลูกค้า หน้าร้าน การออกแบบกล่อง การบริการหลังการขาย และทุกอย่างที่ลูกค้าหนึ่งคนต้องมีปฏิสัมพันธ์กับสินค้าของเรา

หลายบริษัทเริ่มมีตำแหน่ง CX อยู่ในบริษัท ทำหน้าที่คล้ายๆ คนคอยคุมให้ทุกฝ่ายคิดถึงประสบการณ์ของลูกค้าอยู่ตลอดเวลา ถ้าเทียบกับโลกของ Agile:Scrum ก็คล้ายๆ กับ Scrum Master ครับ คือไม่ได้เข้าไปตัดสินใจแทนแต่ละฝ่าย แต่เป็นแค่คนคอยเตือนและกำกับทิศทาง

CX is a responsibility of the whole company 

and not something that can be handled by isolated departments

ถ้าต้องการใช้ CX ให้ประสบความสำเร็จเราต้องทำร่วมกันทั้งบริษัท ไม่ใช่แต่ละฝ่ายแยกย้ายกันไปทำ เพราะมันต้องมีการรับการส่งที่ดี โดยแต่ละแผนกต้องมีภาพของ "ประสบการณ์" ที่จะให้ผู้ใช้ได้รับเป็นแบบเดียวกันอยู่ในใจ

สำหรับรายละเอียดและโครงสร้างของ CX ไว้เราจะเอามา post ไว้บน ux.in.th ในตอนต่อๆ ไปนะครับ

ที่มาและที่ไปของ CX

ส่วนใครที่สนใจเรื่อง CX เป็นพิเศษผมแนะนำให้อ่าน customerexperiencesuccess.wordpress.com ถึงแม้จะเขียนมาตั้งแต่ปี 2008 แต่ก็ยังใช้ได้อยู่ครับ

ตามหา Guideline สำหรับ Metro style

วันก่อนผมพยายามตามหา Guideline สำหรับอ้างอิงเพื่อออกแบบ App บน Windows Phone 7 จนพบว่ามันมีที่พอจะใช้อ้างอิงได้อยู่สามที่

ที่แรกเป็นของ Jeff Wilcox พูดถึง “Metro” design guide for developers พร้อมกับมี best practise ให้นิดหน่อยด้วย

“Metro” design guide for developers

ที่สองเป็น video งาน MIX10 ที่จะช่วยเล่าที่มาที่ไปของ Metro ให้ฟัง ทำให้เราสามารถจิตนาการตัว App ได้ง่ายขึ้น ตัว video จะเก็บไว้ที่ channel9.msdn.com ในหัวข้อ Windows Phone UI and Design Language

channel9.msdn.com

อันสุดท้ายเป็น Official Guideline ถึงแม้จะอ่านยากเหมือนไม่อยากให้อ่าน แต่เป็นของที่เจ้าตัวทำออกมาเอง น่าจะใช้อ้างอิงได้ดีที่สุด ตัวบทความจะอยู่ใน msdn หัวข้อ User Experience Design Guidelines for Windows Phone

msdn.microsoft.com

สำหรับคนที่ต้องการออกแบบ MS Phone ลอง download psd สองไฟล์นี้ไปใช้นะครับ

http://msdn.microsoft.com/en-us/library/windows/apps/hh700403

http://dribbble.com/shots/301642-Windows-8-Metro-UI-Demo-PSD

UX คืออะไร

ถ้ามีใครถามเราว่าโปรแกรมนี้โปรแกรมนั้นมี UX ดีหรือไม่ดี เราสามารถบอกได้ไม่ยากนักแต่ถ้าจะให้วิเคราะห์ลงไปว่าเป็นเพราะอะไร มันจะยากขึ้นมาทันทีเพราะเรื่องของ UX เป็นความชอบส่วนบุคคล ขึ้นอยู่กับประสบการณ์ที่ผ่านมาของแต่ละคน จึงไม่มีกฏตายตัวในการวิเคราะห์

ดังนั้นการทำงานกับ UX จึงต้องกำหนดหน้าที่และกลุ่มเป้าหมายของของโปรแกรม ให้ชัดเจน จึงจะสามารถออกแบบโปรแกรม หรือใช้ความรู้ด้าน UX เพื่อโน้มน้าวใครๆ ให้เชื่อในงานของเราได้

คำว่า UX หรือ User eXperience เป็นตัวแทนของการอธิบายประสบการณ์ของผู้ใช้เมื่อใช้งานโปรแกรม จริงๆ เราสามารถใช้ UX ในบริบทที่ไม่ใช้ Software ได้ด้วย แต่ตอนนี้กำลังฮิตใช้กันในอุตสาหกรรม Software โดยเฉพาะในด้าน User Interface

 

ภาพแสดงองค์ประกอบของ UX

คำว่า User เป็นตัวแทนของทุกคน ทั้งผู้ดูแลระบบ  ลูกค้า หัวหน้างาน คนขาย คนจ่ายตัง คนติดตั้งโปรแกรม หรือใครก็ตามที่ต้องติดต่อกับโปรแกรมของเรา ส่วนคำว่า eXperience ก็เป็นตัวแทนของความรู้สึกทั้งหมดที่เกิดขึ้นกับโปรแกรมของเรา ทั้งความรู้สึก พอใจ เสียใจ ดีใจ ช้า เร็ว ทันใจ ไม่ทันใจ 

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

UX คือผลรวมของ Science Art และ Craftsmanship

การจะได้ UX ที่ดีนั้นต้องรู้จักการตั้งสมติฐานและการหาคำตอบ (Science) เพื่อใช้คาดการที่มาที่ไปของสิ่งต่างๆ (สามารถหาข้อมูลเพิ่มเติมได้ในเรื่อง Usability และ Information Architecture)

แต่ความรู้ด่านเทคนิคก็ไม่สามารถเป็น UX ที่ได้ได้ เรายังต้องการศิลปะ (Art) เพื่อใช้อธิบายสิ่งที่จับต้องไม่ได้ทั้งหลาย เช่น ความสวยงาม หรือ องค์ประกอบศิลป์ เป็นต้น

ทั้ง Science และ Art ต่างเป็นองค์ความรู้สำคัญที่ทำให้ได้งานที่ดี แต่ถ้าขาดความเชี่ยวชาญ ประสบการณ์ และความตั้งใจ งานที่มี UX ดีก็จะไม่เกิดขึ้น ความเร็วในการตอบสนองของโปรแกรม ความต่อเนื่องของแต่ละหน้าจอ สิ่งเหล่านี้เรียกว่าเป็นงานหัตถศิลป์ (Craftsmanship) ได้เลยทีเดียว

สรุปก็คือการที่จะทำ UX ให้ได้ดีนั้น ต้องประกอบด้วยความรู้ด้านวิทยาศาสตร์ ความรู้สึกในศิลปะ และฝีมือครับ 

ส่วนรายละเอียดในองค์ความรู้แต่ละตัวจะค่อยๆ เฉลยไว้ใน ux.in.th นะครับ

ผู้ใช้ชอบ Simple จริงหรือ

John Maeda เป็นอาจารย์อยู่ที่ MIT Media Lab ได้พูดถึงความหมายและความสำคัญของ Simplicity ไว้อย่างน่าสนใจ โดยเฉพาะการตอบคำถามว่า "Simple นั้นดีกับผู้ใช้จริงๆ หรือ?"

John Maeda พูดในงาน TED

หลังจากฟังแล้วทำให้รู้ว่า Simple สำคัญ แต่ไม่จำเป็นต้อง Simple ไปทั้งหมด

ที่มา: ted.com