ทางขึ้นสะพานลอยที่จักรยานเข้าถึงได้

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

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

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

เมื่อเดือนที่แล้วผมมีโอกาสไปเที่ยวทำงานที่เกาหลี สังเกตเห็นเห็นว่าสะพานลอยแถวๆ ที่พักเขาทำร่องกว้างประมาณ 20 ซ.ม. ไว้ที่ด้านขวาทางทางเดินดังรูป

ร่องด้านขวาของทางขึ้นสะพานลอยที่เกาหลี รูปนี่ถ่ายจากข้างบนไปข้างล่าง ร่องจึงอยู่ด้านซ้ายของภาพ

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

เนื้อหาที่ไม่เกี่ยวข้องกับ UX โดยตรง แต่อยากแนะนำให้อ่านเพิ่มเติม

• สำนึกของเสาอัมสเตอร์ดัม - http://thaipublica.org/2012/01/amsterdammertjes-little-one-from-amsterdam/
• จักรยานกับประชาธิปไตย - http://thaipublica.org/2012/04/bicycle-and-democracy/

4 อย่างที่ห้ามพลาด เมื่อย้ายจาก iOS ไปออกแบบ App บน Android

แต่ละ Platform ต่างก็มี Guideline เป็นของตนเองครับ สำหรับ Android ดูเหมือนจะพึ่งเริ่มนิ่ง ตอนนี้เลยเป็นเวลาที่เหมาะมากที่จะมาวิเคราะห์กันครับ

สำหรับคนที่ออกแบบ App บน iOS มาก่อน ผมมองว่าวินาทีนี้ Concept สำคัญที่ต่างกันมากๆ ระหว่าง iOS กับ Android ก็ตรงที่ Android เน้นให้ออกแบบทีเดียว ทำงานได้กับ Device ทุกแบบ ส่วนของ iOS จะเน้นให้ออกแบบ App ให้เหมาะกับแต่ละ Device (ซึ่งมีแค่ iPad กับ iPhone) เลยทำให้การออกแบบบน Android จะมีเงื่อนไขเรื่องการปรับเปลี่ยนหน้าจอแบบอัตโนมัติเข้ามาด้วย

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

ทีนี้เท่าที่ผมลองไล่ดู มี 4 อย่างที่คนทำ iOS มาก่อนควรทำความเข้าใจ และระลึกอยู่เสมอเวลาที่ออกแบบ App บน Android ครับ

1. Tab ของ Android อยู่ด้านบน

การลากนิ้วเพื่อเปลี่ยน Tab

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

2.  Android มีปุ่ม Back และ ปุ่ม Up โดยปุ่ม Back จะของเป็นของ System อยู่ด้านล่าง ส่วนปุ่มที่อยู่ในตำแหน่ง Back ของ iOS เราจะเรียกว่าปุ่ม Up

แสดงการทำงาน และตำแหน่งของปุ่ม Back และ Up

ในรูปแสดงการทำงานของโปรแกรม Mail โดยเริ่มที่หน้าแสดงรายการจดหมาด เมื่อมีการกดที่จดหมายฉบับใด โปรแกรม Mail จะแสดงหน้าเนื้อหาของจดหมายนั้น และผู้ใช้สามารถกด next เพื่อดูจดหมายถัดไปได้ หากกดปุ่ม Back ที่อยู่ด้านล่าง โปรแกรม Mail จะแสดงจดหมายหน้าที่ผ่านมา แต่ถ้ากดปุ่ม Up ที่อยู่ด้านบน โปรแกรมจะกลับไปหน้า แสดงรายการจดหมาย ต่างจากโปรแกรม iOS ที่ปุ่มด้านบนทำหน้าที่เป็นปุ่ม Bak

3. การจัดวางตำแหน่งบน Toolbar

ตำแหน่งต่างๆ บน toolbar

 บน iOS ตัว Toolbar ด้าย ซ้ายมักจะเป็นการกลับไปหน้าก่อนหน้า หรือหน้าด้านซ้ายมือ ส่วนด้านขวาจะเป็น Action สำหรับ page นั้นๆ เช่น Add, Filter, Edit เป็นต้น ส่วนตรงกลางจะแสดงชื่อของหน้านั้นๆ

แต่ของ Android จะเรียงไม่เหมือนกันครับ (1) ด้านซ้ายมือของ Android จะแสดง icon ของ App เพื่อบอกผู้ใช้ว่ากำลังใช้ App อะไรอยู่ (2) ถัดจาก icon จะยังชิดซ้ายเหมือนกัน คือ ช่องที่ใช้เลือกและแสดงว่าตอนนี้ข้อมูลที่แสดงอยู่ด้านล่างเป็นข้อมูลอะไร (3) ชิดขวาจะเป็น Action ของเนื้อหาด้านล่าง (4) เป็น Menu เพิ่มตามถ้าพื้นที่แสดง Action ไม่พอ

การแสดง Toolbar บนหน้าจอต่างๆ

ในกรณีที่พื้นที่แสดง Action ไม่พอเราจะดันให้มาอยู่ด้านล่าง ดังรูปครับ

4. ถ้าคิดจะทำ UI Element เอง ให้คิดให้หนักๆ ไม่ใช่ว่าของ iOS จะคิดน้อย เพราะต้องคำนึงถึง Accessibility และ พฤติกรรมของตัว Element นั้นๆ แต่ของ Android นั้นอาจจะถึงขั้นไม่สามารถคิดได้ เพราะนักพัฒนาจะต้องทำให้ Element ที่ตัวเองสร้างขึ้นมาสามารถทำงานบนอุปกรณ์ที่แตกต่างกันให้ได้ และอาจจะต้องรองรับอุปกรณ์ที่ยังไม่มีในปัจจุบัน

ตัวอย่างตำแหน่งของ Menu บนอุปกรณ์ที่ต่างกัน

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

ทั้งนี้ใครต้องการจะรู้รายละเอียดเพื่อออกแบบ App บน Android ให้เข้ากับ Ecosystem ของมัน แนะนำให้อ่าน android pattern ครับ ส่วนใครที่ยังไม่เคยออกแบบบน iOS ผมแนะนำว่าก่อนจะอ่าน Android ควรลองอ่าน HIG ของ iOS ก่อนครับ ในนั้นมีทฤษฏีที่มีประโยชน์อยู่มากมายทีเดียว

แนะนำ Link: 10 must see usability videos

บน facebook.com/uxinthai คุณ Viriya Reungwai ได้แนะนำ link 10 วิดิโอเกี่ยวกับการทำ Usability Testing ครับ

หนึ่งในวิดิโอจาก 10-must-see-usability-videos

ในนั้นจะมีเรื่อง UI/UX Test ตั้งแต่ของ Google ของ Ted และอีกหลายตัวที่น่าจะเข้าไปดูครับ

แนะนำโปรแกรมที่ iOS Designer ควรพกติดตัว

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

วันนี้เลยมีโปรแกรมมาแนะนำหนึ่งตัวครับ ชื่อว่า LiveView

LiveView Desktop

LiveView on iTunes

เราต้องติดตั้งโปรแกรม LiveView บนเครื่องของเรา จากนั้นก็ Download โปรแกรม LiveView ลงบนอุปกรณ์ iPhone, iPad ครับ หลังจากนั้นก็ทำตามขั้นตอนเพื่อเชื่อม LiveView Desktop เข้ากับ LiveView Devise หลังจากนั้นโปรแกรม LiveView Desktop จะส่งภาพหน้าจอของเราไปยัง iPhone, iPad ให้

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

ที่สำคัญโปรแกรมนี้ฟรี :-)

แต่สำหรับใครที่อยากได้โปรแกรมที่ดูครบกว่านี้ อยากให้ทดลอง xScope Mirror ครับ ราคา 29.99$

คิดให้หนักถ้าจะบังคับผู้ใช้ให้ Register

วันนี้ได้ลอง App ของคนไทยตัวนึง แล้วทำให้นึกถึงวีดีโอในงาน WWDC 2012 ที่พึ่งดูมาครับ มีอยู่ตอนนึงเค้าพูดถึงการออกแบบ Application บน iPhone โดยในนั้นจะมีคำแนะนำอยู่หลายข้อ ข้อที่ผมยกมาคือ ให้ระวังเรื่องการ "Force Register" คือ การที่พอผู้ใช้เปิด App เข้ามาก็เจอปุ่ม Sign Up!  ปุ่ม Sign In เลย แทนที่จะเจอเนื้อหาที่เค้าสนใจ

ภาพตัวอย่างหน้าแรกจาก WWDC 2012

อย่างในรูปเป็น App ปลอม ที่เค้าทำปุ่มมาสองปุ่ม อันแรกเห็นชัดๆ คือ Sign Up! คือบอกให้สมัครสมาชิก ส่วนปุ่มที่สองคือ Sign in คือถ้าเป็นสมาชิกแล้วให้กดปุ่มนี้ แต่เค้าพบว่าผู้ใช้ส่วนใหญ่จะกดปุ่มที่สาม คือปุ่ม Home 

เพราะว่าผู้ใช้ยังไม่ได้รู้จักว่า App นี้ดีแค่ไหน เห็นใน App Store ว่าน่าสนใจก็ Download มา ถ้ามันเริ่มต้นก็ทำให้รำคาญ มันก็น่าจะหนีอยู่นะครับ

แต่เค้าก็ไม่ได้บอกว่าทุก App ไม่ควรมี Force Register เพราะ App ของงาน WWDC ก็บังคับ Login หรือพวก App ที่เป็น Client ชัดเจนถ้าไม่ Login จะใช้งานไม่ได้เลยพวกนี้ก็ต้องให้ Login ก่อน 

ผมมองว่าถ้าเค้ามีฝั่ง Server ชัดเจนอยู่แล้วเช่น Facebook, Twitter พวกนี้จะบังคับให้ผู้ใช้ Login ก่อน ก็ไม่แปลก หรือพวก Line, Path จะบังคับ Register ก่อนก็เป็นเรื่องจำเป็น แต่จะมีบาง App เช่น Fondu เป็นต้น

Fondu: Dining Journal

First launch user experience

Fondu เป็น App Social Network ด้านอาหาร มีหน้าให้ Login ก่อน ด้วย Facebook ตั้งแต่เปิดมาครั้งแรก แต่คนทำเค้ารู้ว่าจริงๆ แล้วผู้ใช้ไม่จำเป็นต้อง Login ก็สามารถอ่าน Review อาหารของคนอื่นๆ ได้ โดยกดที่คำว่า "Get a taste >" โปรแกรมก็จะนำผู้ใช้ไปที่หน้ารายการอาหาร 

ไว้ตอนที่ผู้ใช้ต้องการจะ Share หรือ Review ตอนนั้นค่อยมา Register อีกที ตอนนั้นผู้ใช้จะมีกระใจที่จะ Register แล้ว เพราะรู้จัก App นี้แล้วและมีความต้องการจะทำอะไรบางอย่างอีกต่างหาก

ทีนี้กลับมาที่ App ที่เป็นต้นประเด็นของ Post นี้

หน้าแรก และ หน้า Sign in ของ Shop*Spot

Shop* Spot เป็น App personal e-commerce ซึ่ง concept ดีมากๆ ผมแนะนำให้ทุกคน Load มาใช้ครับ แต่มันมีประเด็นเรื่อง UX นิดหน่อยตามนี้ครับ

ในหน้าแรกของโปรแกรมจะมีแถบริบบิ้นเขียนว่า Sign in ก่อน อันนี้เป็นด่านแรก ถ้าผมยังไม่มี Account อาจจะคิดว่า App นี้เป็นแบบ Member only หรือเปล่า เพราะไม่มีปุ่มให้ register และผมอาจจะกดปุ่ม Home หนีไปเลยก็ได้ 

อีกปัญหาคือตัวริบบิ้นมันไม่ได้สื่อว่ากดได้ อาจจะเป็นการบอกว่าหน้านี้คือหน้า Sign in หรือจะให้ดึงริบบิ้น ไม่ได้ให้กด สมมุติว่าเดาถูกแล้วกด Sign in เข้ามาได้ ผมจะเจอหน้า Sign in ซึ่งแบ่งหน้าจอเป็นสองส่วน ส่วนบนจะมีช่องให้ใส่ Username และ Password พร้อมปุ่ม Create account ส่วนด้านล่างเป็น Sign in ด้วย Facebook พร้อมคำอธิบายว่าไม่ต้องกลัว

หน้าจอตอน Sigin in

ผมทดลอง Sign in แต่แทนที่ผมจะกดปุ่ม Done ด้านบน ผมกลับกดปุ่ม Create account ด้วยความเคยชินว่า Form มักจะมีปุ่ม Submit อยู่ด้านล่าง มันเลยกระโดดเข้าไปหน้า Create account ต้องกดปุ่มกลับมา ถึงมามองดูว่ามีปุ่ม Done ด้านบนให้กดเมื่อพิมพ์ username และ password แล้ว

ถึงตอนนี้ผมไม่อยาก Sign in ละ เลยตัดสินใจระหว่างหนี กับ login ด้วย facebook แทน ตรงจุดนี้ในส่วนของข้อความอธิบาย Facebook ผมมองว่าควรเน้นประโยคว่า "No worry...." มากกว่า "Use Facebook account" เพราะบนปุ่มก็เขียนว่า "Sign in with Facebook" อยู่แล้ว (ลองย้อนกลับไปดูภาพด้านบน)

หลังจากเข้ามาได้ผมกลับพบว่า App ไม่ได้ใช้ข้อมูลบน Facebook ของผมมากนัก จะมีก็ Location ซึ่งอาจจะหาเอาจาก GPS แทนได้

หน้าจอหลังจาก Login

ผมจึงมองว่าน่าจะเข้ากรณีเดียวกับวีดีโอของ WWDC ว่าถ้าข้ามขั้นตอน Login/Register ไปได้ก็ดี แล้วตอนที่เค้าต้องการ Sale หรือต้องการซื้อ ค่อยมา login อีกทีก็ยังทันครับ

นอกเรื่องอีกนิดสำหรับ

นอกจากนั้นจะมีเรื่อง "ตำแหน่งของปุ่มค้นหา" "ปุ่ม Filter" "ตัว Title ของ App" "การใช้ Header ของ Table"   icon บน tab bar ที่ทำให้ผมนำไปเทียบกับปุ่มที่เป็น Disable ตอนแรกก็งงๆ ว่ามันกดได้หรือเปล่า หรือต้องกรอกข้อมูลอะไรเพิ่มก่อนหรือเปล่าจึงจะสามารถกดได้

ถ้ามีโอกาสน่าจะได้ยกขึ้นมาเป็นกรณีศึกษาอีก ผมคิดว่าการออกแบบของเค้าน่าจะมีเหตุผลรองรับอยู่แล้ว ต้องขอขอบคุณที่ทำ App ดีๆ ขึ้นมานะครับ และต้องขออภัยที่นำมาเป็นกรณีศึกษาโดยไม่ได้ขออนุญาติก่อนครับ

การออกแบบ UX หน้าจอแรกของ DoctorMe

ว่าจะเขียนถึงนานแล้ว แต่ถ้ารอไปอีกคงไม่ได้เขียน มีประเด็นน่าสนใจอยากเอามาแบ่งปันครับ

DoctorMe เป็นโปรแกรมเพื่อการรักษาสุขภาพด้วยตัวเองบน iOS และ Android พอดีได้มีส่วนร่วมในการออกแบบ interaction และ UX ทั้งหมดของโปรแกรม

โจทย์หลักคือข้อมูลที่มีอยู่เป็นข้อมูลเชิง encyclopedia ที่เจาะลึกอาการป่วยไปเรื่อยๆ จนถึงวิธีการดูแลรักษาตัวเองตามอาการที่ระบุ หนึ่งในวิธีที่ทีมคิดกันมาคือการแบ่งอาการเป็น 2 ประเภทนั่นคือ

• อาการเฉพาะส่วนต่างๆ ของร่างกาย
• อาการที่เกิดขึ้นที่ใดก็ได้

 ร่างแรกที่ทีมทำกันออกมาทีมนึกถึงกันว่าเนื่องจากเป็นเรื่องสุขภาพเลยทำเป็นแบบนี้

DoctorMe สำหรับ iOS ร่างแรก

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

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

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

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

และรุ่นสุดท้ายที่เปิดให้ดาวน์โหลดก็เป็นรูปร่างแบบนี้

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

UX ของ Olympic 2012

Nick Haley ซึ่งเป็น Head of User Experience and Design for Sport & London 2012 ที่ BBC Future Media ได้เขียน Blog เผยเบื้องหลังการพัฒนาและออกแบบ Application และ เว็บไซต์ ทั้งบน iPhone Android และ Desktop Browser ไว้อย่างน่าสนใจ

บรรยากาศการทำงาน

Nick เล่าให้ฟังว่า Vision สำหรับ 2012 คือ "Never miss a moment" ซึ่งตอนแรกเค้าคิดจะทำเฉพาะส่วน Live Interactive Video Player แต่สุดท้ายมันขยายครอบคลุมทั้ง Olympic เลย

ตลอดเวลาที่เค้าออกแบบเว็บ Sport ของ BBC ขึ้นมาใหม่ เค้าจะมีประโยคที่เป็นแนวทางคือ "Live Beyond Live" ซึ่งในบทความไม่ได้บอกว่าเค้าทำอย่างไร แต่เค้าบอกว่าเค้าพยายามหาทางที่จะสื่อให้คนรู้ว่า content ไหนเป็น Live ตัวไหนไม่เป็น Live

สีฟ้าแสดงว่าเป็น Live

สุดท้ายเค้าเช้าสี ในการแยก โดยถ้าส่วนไหนที่มีสีฟ้า แสดงว่ามันเป็น Live และ เราแนวทางนี้ไม่ได้ใช้มันเฉพาะใน Web Desktop นะ แต่เราใช้มันบนมือถือและทีวีด้วย

Branding ของ Web Desktop, Web Mobile, iPhone, Android

รูปด้านบนแสดงให้ดูว่าแต่ละ Platform จะมีตัว Navigation ที่ใหม่เหมือนกัน ขึ้นอยู่กับแนวทางของ Platform นั้นๆ แต่ทุกตัวยังคงรักษา Branding เป็นชุดเดียวกันเสมอ นี่ก็เป็นหนึ่งในความใส่ใจของคนออกแบบ

ผมมองว่านี่เป็นอีกหนึ่งตัวอย่างของการออกแบบที่คิดมามาก และถ้าเราเข้าไปศึกษา เราจะได้ความรู้จากงานออกแบบนี้แน่นอน ดังนั้นสำหรับคนที่สนใจ สามารถเข้าไปดูได้ที่ BBC Olympic design ครับ

 ที่มา: http://www.bbc.co.uk/blogs/bbcinternet/

ออกแบบ Mobile UI ตามแนว Print Media

บริษัท TAT (The Astonishing Tribe) ได้ทดลองออกแบบ Mobile UI โดยเลียนแบบลักษณะของงานสิ่งพิมพ์ ได้ผลมาตาม video ครับ

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

แต่สำหรับโลก Mobile จะไม่เหมือนกัน ด้วยลักษณะการถือการอ่าน จะคล้ายกับสิ่งพิมพ์พวกหนังสือ หรือนิตยสารมากกว่า ดังนั้นมันอาจจะประสบความสำเร็จก็ได้

ผมเข้าใจว่าโลกของสิ่งพิมพ์มันวิวัฒนาการมานานมาก มี best practist อยู่มากมายที่เอามาใช้ได้ทันที ถ้าเราเปิดใจเราจะสามารถรับเอาสิ่งดีๆ เหล่านี้มาไว้ใน Application ของเราได้ครับ

หน้าจอสัมผัส: แตะกับแตะค้าง

อันนี้เน้นการประยุกต์และธรรมชาติการใช้งานการแตะกับแตะค้างบนหน้าจอของ app บน iOS ชื่อ Wikipanion ไม่ได้ค่าโฆษณานะ แต่ใช้อยู่ :-P

Wikipanion เป็นโปรแกรมอ่าน วิกิพีเดีย มีความสามารถหลายอย่าง เรื่องทำไมต้องใช้ app อ่านวิกินั้นไม่ใช่ประเด็นหลัก :-P แต่สิ่งที่น่าสนใจคือตัว app เองมีการประยุกต์การแตะกับการแตะค้างไว้อย่างน่าสนใจ

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

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

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

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

• แตะลิงก์เพื่อไปยังเนื้อหานั้น
• แตะลิงก์ค้างเพื่อเก็บลิงก์นั้นเข้าคิว

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

• แตะลิงก์เพื่อเก็บลิงก์นั้นเข้าคิว
• แตะลิงก์ค้างเพื่อไปยังเนื้อหานั้น

แตะลิงก์ Gale Crater เพื่อเก็บเข้าคิว

แตะค้างลิงก์ Gale Crater เพื่อไปยังเนื้อหาทันที

สิ่งที่น่าสนใจคือทำไม Wikipanion ถึงเลือกที่จะเปลี่ยนพฤติกรรมของผู้ใช้?

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

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

หากจะโต้วาทีเรื่องนี้ก็อาจจะต้องย้อนไปว่า พฤติกรรมการอ่านวิกิพีเดียควรจะเป็นแบบไหนถึงจะได้ความรู้สูงสุด อ่านให้จบเป็นชิ้นๆ หรืออ่านกระโดดไปกระโดดมา?

ภูเขาน้ำแข็งของ Web Usability

ก่อนที่จะเริ่มทำงานด้าน UX เราควรมีความเข้าใจในเรื่อง Usability ก่อน แล้ว Usability คืออะไร?

Usability คือการออกแบบสิ่งใดๆ ให้มนุษย์คนอื่นๆ เข้าใจมันได้ง่ายๆ

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

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

ภูเข้าน้ำแข็งของ Web Usability

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

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

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

ตอนนี้เราจะเริ่มเห็นภาพคร่าวๆ ในหัวแล้ว แต่ยังไม่ต้องรีบวาด UI ยังมีอีกหนึ่งอย่างที่เราต้องคิด นั้นก็คือ Structure การกำหนด Structure จะต้องเริ่มจากการกำหนดองค์ประกอบในเว็บ ว่าจะมีอะไรบ้าง โดยอาศัยสิ่งที่เราคิดไว้ใน Strategy และ Scope เป็นตัวกำหนด จากนั้นนำมาวางเป็นแผนภูมิต้นไม้ โดยคำนึงถึง common sense ของกลุ่มเป้าหมายให้มากที่สุด เพื่อให้กลุ่มเป้าหมายของเราเดาได้ถูก

ที่สำคัญต้องไม่ลืมว่า Structure ไม่ใช่ Flow !!

เมื่อเราได้โครงสร้างแล้ว ก็ให้ลองวาด Skeleton กัน โดยเป้าหมายคือต้องการให้ทีมรับรู้ว่า หน้าตาหลักๆ ของเว็บจะเป็นอย่างไร แบ่งสัดส่วนอย่างไร เน้นให้ความสำคัญในส่วนไหนของหน้าจอบ้าง และแต่ละหน้าจะส่งข้อความอะไรให้กับผู้ใช้ จะใช้วิธีการวาด Storyboard, Wireframe หรือทำ Prototype ออกมาก็ได้ แต่สำคัญต้องพยายามไม่ใส่งานออกแบบ (งานด้านความสวยงาม) ลงไปในขั้นตอนนี้ ไม่อย่างนั้นเราอาจจะโดนความสวยงามหลอกเอา หรือไม่ก็โดนความสวยงามทำให้เสียดาย จนยอมลด Usability ลงก็ได้

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

ถ้าเราทำได้ตามลำดับขั้นตอนทั้ง 5 ก็มองได้ว่าเราได้ทำ web ที่มี usability ที่ดีแล้ว แต่นั้นยังไม่ใช่ User Experience ที่ดีนะครับ เพราะมันตอบโจทย์แค่สามารถเรียนรู้ได้เร็ว แต่ยังไม่ตอบโจทย์เรื่องความรู้สึก หรือ ความคาดหวังของผู้ใช้ 

แล้วถ้าต้องการให้ครอบคลุม UX เราต้องทำอย่างไร? คำตอบนี้ขอให้ติดตามใน blog นี้ต่อไปนะครับ