ถ้าคนหัวเหลี่ยมต้องการออกแบบบ้าง

หลายๆ คนที่ตามอ่าน ux.in.th เป็น programmer ที่ไม่ค่อยถนัดเรื่องงานออกแบบ แต่สนใจ UX (ผมก็คนนึง) วีดีโออันนี้อยู่ในงาน Google I/O 2012 ครับ เค้าพูดถึงงานออกแบบในภาษาที่คนหัวเหลี่ยมเข้าใจได้

session Advanced Design for Engineers ที่งาน Google I/O

เขาพยายามย้ำว่างานออกแบบไม่ใช้เรื่องมหัศจรรย์ แต่เป็นเรื่องที่ทุกคนสามารถเรียนรู้ได้ ในงาน Designer จาก Google จะเล่าถึงการทำ interactive และ visual design ซึ่งมีหัวข้อหลักๆ ในเรื่อง mental models, natural mappings, metaphors, mode errors, visual hierachies, typography และ gestalt principles

ถ้ามีโอกาศอยากให้ลองดูครับ น่าจะช่วยให้คุณภาพของงานที่เราทำอยู่ดีขึ้นมากทีเดียว

UX และ UI ก็เหมือนไก่กับไข่ มันเกิดพร้อมกัน

วีดีโอขำๆ เกี่ยวกับความสัมพันธ์ของ UX และ UI ครับ

โปรแกรมควรมีเครื่องมือใช้ง่าย หรือแค่เท่ก็พอ

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

ตัวอย่างหน้าจอโปรแกรม SketchBook และ Paper

เราลองเทียบโปรแกรมวาดรูปสองตัวอันหนึ่งเป็นตัวแทนความครบถ้วน อีกอันเป็นตัวแทนความเท่

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

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

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

ประสบการณ์ของผู้ใช้ควบคุมได้ครับ :-D

อยากให้ผู้ใช้รู้สึกแบบไหน "ง่ายดี" หรือ "เท่ดี"

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

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

หน้าจอโปรแกรม Wunderlist และ Clear

กรณีศึกษาของความง่าย และความเท่ ผ่านโปรแกรม Todo list สองตัวคือ Wunderlist และ Clear 

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

โปรแกรม Clear ไม่พอใจแค่นั้น เค้าไม่ได้ต้องการแค่สร้างประสบการณ์ที่ง่ายและสวย แต่ต้องการสร้างประสบการณ์ความเท่ด้วย โดยเค้ายอมแลกด้วยหน้าตาที่ไม่เหมือนโปรแกรมบน iOS และ Animation แปลกตา และ หน้าตาที่เดาได้ยากว่าโปรแกรมใช้งานอย่างไร ถ้าไม่ได้ดูวีดีโอคงต้องเสียเวลาเดาอยู่นาน แต่เมื่อผู้ใช้ทำเป็นก็จะง่ายแถมเท่ด้วย ได้รับคำชมจากหลายเว็บทีเดียว

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

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

สำหรับผมตัวอย่างที่เห็นชัดๆ อีกอันคือมือถือ iOS, Android หรือ Window Phone ลองวิเคราะห์กันสนุกๆ ว่าเค้ายอมแลกอะไรเพื่อความเท่บ้างหรือเปล่า

One & Co บริษัทที่ออกแบบมือถือให้ HTC

วันนี้ได้อ่านบทความจาก thumbsup.in.th ว่ามีคนไทยคนหนึ่ง อยู่บริษัท One & Co แล้วได้มีส่วนในการออกแบบมือถือ HTC เลยเกิดความสงสัยว่า สิ่งสำคัญอย่างรูปแบบของมือถือ น่าจะเป็นสิ่งที่สำคัญมากๆ สำหรับบริษัทแบบ HTC ทำไมถืงไม่ระดมคนเข้ามาอยู่ในบริษัท หรือทำไมไม่ซื้อบริษัท One & Co  ไปซะเลย

เมื่อเกิดความสงสัยจึงลองค้นๆ ดูจาก youtube ครับ

วีดีโอนำเสนอปรัชญาการออกแบบของ One & Co

หลังจากดูไปแล้วก็ยังไม่ได้คำตอบว่าทำไม HTC ไม่ซื้อ One & Co แต่ได้ความรู้สึกว่างานในแต่ละวันของเรา ยังไม่เคยได้จัดเต็มขนาดเค้าเลย พวกนี้เค้าลงไปศึกษาผู้ใช้จริงๆ พยายามสร้างประสบการณ์ผู้ใช้กันแบบเต็มๆ ทำเอาอิจฉาเลย

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

วีดีโออธิบายโครงการ Shop Spot

สำหรับบริษัท Software ของไทยผมคิดว่าโปรแกรม Shop Spot เป็นหนึ่งในโปรแกรมที่จัดเต็มเรื่องนี้ ลองดูตัวอย่างวีดีโองอธิบายโปรแกรมของเค้าก่อน ส่วนวีดีโอที่เกี่ยวกับ UX จะลองถามเค้ามาอีกทีนึงครับ วันก่อนไปคุยกันที่งาน ux.in.th @ the sync แต่ไม่นึกว่าจะหาบน youtube ไม่เจอ :'(

Twitter หน้าตาใหม่บน ipad ได้อะไรแลกกับอะไร

ทีม UX ของ Twitter นับว่าเป็นทีมที่เก่งมากๆ งานออกแบบครั้งที่แล้วได้สร้างรูปแบบใหม่ในการใช้งานโปรแกรมบน iPad ขึ้นมา และที่เท่มากคือมันเป็นของใหม่ที่ผู้ใช้ยังรู้สึกว่าเป็น App ของ Platform นี้อยู่

มาครั้งนี้มีการ Update ใหม่อีกครั้ง คราวนี้ Twitter ทำตัวเองให้เรียบง่ายมากขึ้น และเน้นเรื่อง Branding อย่างชัดเจน

ภาพหน้า List

Twitter ใหม่ จะย้าย Tab Message, Tab List ปุ่ม Setting ไปไว้ใน Profile และ Tab Search ไปไว้บน Title Bar ทำให้ Tab ด้านข้างเหลือแค่ 4 ปุ่ม ทำให้ง่ายสำหรับผู้เข้ามาใหม่ แลกมาด้วยความยากสำหรับคนที่รู้อยู่แล้วว่าต้องการอะไร

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

แถบสีฟ้าที่เพิ่มเข้ามาเป็นการสร้าง Brand ของ Twitter ให้ชัด แทนที่จะซ่อน Logo ไว้ที่แถบด้านซ้ายมือ

ภาพหน้ารายละเอียดของ Tweet

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

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

อีกอย่างก็คือเสียความเก๋ที่แผ่นตรงกลางสามารถเลื่อนไปมาได้ แต่ tweeter ก็เลือกที่จะเปลี่ยน

ภาพแสดงหน้าจอ Tweet

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

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

ตอนนี้ Wow factor หายไปหลายที่ แต่ตอนนี้ Tweeter ไม่ต้องการแล้ว ดังนั้นของใหม่จึงเข้ามาตอบโจทย์เรื่องความเรียบง่ายและ Branding แทน

UX บน Kinect

Minority Report เป็นหนัง Sci-fi ที่น่าตื่นตาตื่นใจมาก โดยเฉพาะในส่วนของ UI ที่ Tom Cruise ใช้ในเรื่อง ซึ่งในปัจจับันนี้ Kinect ได้ทำให้ UI แบบนั้นเป็นความจริงขึ้นมาได้

Kinect นั้นมีความสามารถที่จะให้ ผู้ใช้สามารถร่างกายการแสดงท่าทางต่างๆและเสียงอย่างเป็น "ธรรมชาติ" ในการติดต่อหรือบังคับคอมพิวเตอร์  และมีการเรียก UI ในลักษณะนี้ว่า Natural User Interface (NUI) 

การที่เราสามารถออกท่าทางต่างๆเวลาเล่นเกม ทำให้เราสนุกมากขึ้นกว่าการกดปุ่มธรรมดาๆ มี experience ที่ดีขึ้น เชื่อว่าหลายๆคนคงรู้สึก :) 

แต่.........ก็ไม่เสมอไปเน๊อะ ทุกอย่างมีข้อยกเว้น

เมื่อก่อนเคยนั่งจินตนาการว่าถ้าเราต้องทำงานสักอย่างนึงกับคอมพิวเตอร์ แต่ต้องมายกมือยกไม้แกว่งไปมา แถมต้องค้างๆไว้อีกแบบที่ Tom Cruise ทำ Minority Report มันจะต้องเมื่อยแน่ๆเลย - - 

บังเอิญช่วงนี้กำลังต้องทำงานเกี่ยวกับ Kinect บวกกับมีโอกาสไปเดินเล่นแถวๆพารากอน แล้วก็ได้ไปลองเล่น app ที่ใช้ Kinect ในการพัฒนา ที่ shop โทรศัพท์มือถือยี่ห้อหนึ่งได้เอามาตั้งไว้เก๋ๆ  

เวลาเล่นเราก็ต้องแกว่งแขนไปมาเพื่อควบคุม cursor บนจอ ก็ยากอยู่นะ กว่าที่จะพยายามบังคับมันให้ไปดั่งใจได้ อันนี้ไม่แน่ใจว่าจะเกี่ยวกับความเหนื่อยล้าของเครื่องแล้วก็ noise ต่างๆที่รบกวนรึเปล่า แต่การที่ต้องไปแกว่งแขนไปมากลางห้างที่ผู้คนเดิมผ่านไปผ่านมานั้น ก็อาจจะไม่ใช่ประสบการณ์ที่ดีของใครหลายๆคนก็เป็นได้ สำหรับเราแล้วถ้าเป็นแค่ multi-touch screen ธรรมดาก็อาจจะเพียงพอแล้วก็ได้ อาจจะไม่ตื่นตาตื่นใจเท่า แต่ว่า user friendly มากกว่า

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

สรุปได้ว่า user และ use case เป็นสิ่งสำคัญในการเลือกและออกแบบ interaction และ interface เพราะฉะนั้นระวังกันให้ดีๆนะคะ

ปล. ที่ต้องเอา Minority Report ภาษาฝรั่งเศสมา เพราะว่าหาภาษาอังกฤษไม่ได้ เขาเอาออกหมดเลย

ผู้ช่วยสำหรับงานออกแบบ UI ของมือถือ

ช่วงนี้ชีวิตวุ่นวาย ทำให้บทความที่เตรียมเอาไว้หมดลงอย่างรวดเร็ว ทำให้ต้องเร่งหาความรู้ใหม่ๆ มาเขียนลง ux.in.th ไม่งั้นจะหมดแรงเอาได้ :-D 

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

ตัวอย่าง Template ที่มีเตรียมไว้

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

ตัวอย่า Template สำหรับ WP7

ถ้าเรา Print เตรียมเอาไว้ พอเรามี idea ก็สามารถหยิบขึ้นมาต่อยอดได้ทันที นั่นเป็นเบื้องต้น แต่สิ่งที่ชอบมากๆ สำหรับชุดนี้คือมันผ่านการลองผิดลองถูกมาแล้ว อย่างใน WP7 แทนที่เค้าจะทำเป็นหน้าจอเดียวๆ แบบ iPhone คนทำก็เลือกที่จะเขียนให้มันต่อเนื่องกันไป (ตามรูป) หรือในกรณีของ tablet ก็จะมีเส้นตารางเตรียมไว้ให้

ดังนั้นใครที่กำลังหมกมุ่นอยู่กับการออกแบบโปรแกรมบนมือถือ ให้รีบ Download โดยด่วนครับ

Original: Download the package

My Dropbox: pixle_outline_tapsize.zip

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

ที่มา: androiduipatterns.com, smashingmagazine.com

5 ความเชื่อที่บั่นทอนพลังของ UX

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

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

ผมลองยกตัวอย่างความเชื่อที่ขัดกับแนวทาง UX มาซัก 5 อย่างครับ

เลือกเข้าตลาดก่อนแทนที่จะทำสินค้าให้ดี

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

เลือกเก็บเงินไว้แทนที่จะลงทุนในเรื่องประสิทธิภาพ

ผมมองว่าประสิทธิภาพนั้นเงินซื้อไม่ได้ ดังนั้นถ้ามีโอกาสที่จะเอาเงินแลกประสิทธิภาพได้ ก็อย่าปล่อยโอกาสนั้นไป

ใช้แนวทาง Six Sigma ในการสร้างนวัตกรรม

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

พยายามตามเก็บ feature ให้ทันคู่แข่ง แทนที่จะพยายามสร้างประสบการณ์ผู้ใช้ที่แตกต่าง

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

ออกแบบโดยแน้นหน้าตาที่สวยงาม โดยยึดติดกับการตลาดและสิ่งที่จะใช้โฆษณา

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

ที่มา : หนังสือ Effective UI

Pictogram: รูปภาพแทนข้อมูล

เราจะเห็นการใช้งานรูปภาพแทนข้อมูลกันอยู่บ่อยๆ โดยเฉพาะตามสถานที่ที่จะต้องให้ข้อมูลที่จำเป็นแต่ผู้รับข้อมูลมีจำนวนมากและมีเวลาน้อย เช่น

• สนามบิน
• บนนถนน
• ในอาคาร

ผมไปลองค้นมาพบว่าเรื่องนี้ถูกกำหนดไว้เป็นมาตรฐานอุตสาหกรรมเรียกว่า ISO 7001 ที่ว่าถึง สัญลักษณ์แทนข้อมูลในที่สาธารณะ (Public Information Symbols) ผมไปเจอ slides ชุดหนึ่งที่อธิบายอย่างง่ายๆ ว่า ISO 7001 คืออะไร และมีข้อแนะนำในการเลือกใช้สัญลักษณ์สำหรับการเรียกความสนใจแต่ละแบบอย่างไร

ค้นต่อไปอีกนิดก็เจอว่า Department of Transportation (DoT - กระทรวงคมนาคม) ของสหรัฐอเมริกา น่าจะเป็นหน่วยงานรัฐหน่วยงานแรกๆ ของโลกที่ปรับใช้ Pictograms มาใช้ในการทำเป็นสัญลักษณ์แทนข้อมูลสำหรับคนเดินทาง โดยมี pictograms ทั้งหมด 50 ชิ้น ที่ครอบคลุมบริการสาธารณะต่างๆ โดยมีสัญญาอนุญาตเป็นสาธารณสมบัติให้บุคคลทั่วไปสามารถนำไปใช้งานได้โดยเสรี เอกสารที่ใกล้เคียงที่สุดเท่าที่หาเจอชื่อว่า In-Vehicle Display Icons and Other Information Elements

ของไทยก็มี มอก. ดูแลมาตรฐานนี้อยู่ภายใต้ มอก. 843-2532 สัญลักษณ์ตัวควบคุม ตัวชี้บอก และตัวแสดงของยานยนต์ทางบก เอกสารค่อนข้างเก่ามากและไม่มีตัวอย่างรูปให้ดู แต่ก็น่าจะสืบทอดมาจาก ISO 7001 อีกทีหนึ่ง

สิ่งที่น่าสนใจคือต่อให้เรามี มอก. ของเครื่องหมายสำหรับยานยนต์ทางบก แต่ไม่เจอเครื่องหมายของสัญลักษณ์ในอาคารต่างๆ เช่นสถานีขนส่ง, สนามบิน, ท่าเรือ ไม่แน่ใจว่ากระทรวงคมนาคมยึดแบบอย่างจากมาตรฐานหรือข้อกำหนดอันไหนเหมือนกัน

ตามหาโปรแกรมสำหรับวาด Wireframe

การวาด Wireframe ถือเป็นส่วนสำคัญมากๆ ของทีม UX เพราะมันจะเป็นตัวที่ใช้ในการสื่อสารกับทีมงานคนอื่นๆ ไม่ว่าจะเป็น Owner User Developer Tester ทำให้ทุกคนสามารถคุยกันผ่านทาง Wireframe ได้ ช่วยลดเวลาในการคุยได้ ช่วยยืนยันว่าทุกคนเข้าใจตรงกัน และที่สำคัญช่วยให้เดาได้ง่ายขึ้นว่า Product จะออกมาเป็นอย่างไร

ทาง UX Magazine ได้เลือกเอาโปรแกรมวาด wireframe ขึ้นมาสามตัว มีทั้งตัวที่ใช้ผ่าน Web และที่เป็น App บน Desktop

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

หน้าจอ HotGloo

ถึงแม้ใน Review จะบอกว่ามัน lightweight แต่ด้วยความที่มันเป็น Flash ทำให้เชื่อได้ยากว่ามันจะรู้สึกแบบนั้นจริงๆ และที่สำคัญคือเราเปิดใช้มันบน iOS ไม่ได้แน่นอน แม้แต่จะ comment ยังไม่ได้เลย แต่ด้วยความที่เป็น Flash อีกนั่นละ ทำให้ Interaction ของมันได้คุณภาพระดับ Desktop Application มาอย่างไม่ยากเย็น 

ตัวต่อไปคือ MockFlow ได้รับการ Review ว่าทำงานเร็วที่สุดในสามตัว 

หน้าจอ MockFlow

พัฒนาขึ้นมาด้วยเทคโนโลยี Adobe Air ไม่จำเป็นต้องเปิด Browser ก็สามารถใช้งานได้ ตาม Review บอกว่าเป็นตัวที่ตอบสนองการ point&click ได้เร็วที่สุดครับ

ตัวสุดท้ายคือ Protoshare เป็นตัวเดียวที่ใช้ Javascript ในการทำงาน

หน้าจอ PROTOSHARE

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

ใครสนใจในรายละเอียด และวิธีการให้คะแนนลองตามไปอ่าน uxmag.com นะครับ

สำหรับผมเอง คงไม่ย้ายไปจาก Omnigraffle ง่ายๆ ตราบใดที่ยังไม่มีโปรแกรมวาด Wireframe ตัวไหนช่วยให้ผมทำงานร่วมกันกับทีมได้เหมือน Google docs

ที่มา: uxmag.com

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