User Interface State ทุกแอปพลิเคชั่นควรมี
สวัสดีครับ 🙏🏻 วันนี้ผมจะมาพูดถึง State ที่ Application ควรมี หลายคนคงตั้งคำถามอยู่หรือสงสัยว่า State อะไรบ้างล่ะ ที่ควรมี แล้วทำไมต้องมี มีเหตุผลอะไรที่เราจะต้องทำ State ต่างๆ เพื่อออกมารองรับการออกแบบเพื่อแก้ไขปัญหาและส่งต่องาน Dev เพื่อให้ Dev ทำงานออกมาได้อย่างไม่ต้องมีข้อสงสัยว่า ถ้าเป็นแบบนี้จะแสดงยังไง ?
หลายคนที่เป็นนักออกแบบ UI ไม่ว่าจะอยู่บน Platform อะไรก็ตาม เช่น Web, Mobile, Car, TV หรืออื่นๆ ก็อาจจะมีประสบการณ์การทำงานมาไม่มากก็น้อยที่จะได้ทำงาน Full System เราจะต้องคิดอยู่เสมอว่า User Flow ของ System เป็นยังไง ถ้ากดตรงนี้มันจะไปหน้าไหน แล้วกดตรงนั้นจะแสดงหน้าไหนต่อใช่มั้ยล่ะครับ แต่หลายคน (รวมถึงผมด้วย 🤓) มักจะลืมการทำงานจุดเล็กๆของ UI แต่และหน้าไป มันคือส่วนของ State และพวก Micro Interaction ต่างๆ เพราะฉะนั้น Design Team ผมจึงได้คิด UI State ที่ควรจะมีมาได้ทั้งหมด 6 ข้อด้วยกัน ใส่ลงไปใน Process สำหรับการทำงานในแต่ละ Project ไปดูกันว่ามีอะไรบ้างครับ
1. Ideal State - หน้าแสดงสถานะข้อมูลสมบูรณ์ครบถ้วนพร้อมแสดงผล
ในส่วนของ Ideal State นั้น มันเป็นงานที่ Designer ต้องทำแน่นอนอยู่แล้ว ส่วนมาก Designer ก็มักจะขึ้นโครงสร้าง UI ด้วย State นี้กันหมด เพราะเราจะใช้เป็นพื้นฐานในการสร้าง State อื่นๆ ในการออกแบบ เพราะฉะนั้นสิ่งสำคัญที่สุดในการออกแบบ State คือ การลงรายละเอียดให้ครบถ้วนเท่าที่ข้อมูลจะแสดงได้ ใส่ข้อมูลเท่าที่ตกลงกับทีมในโครงสร้างไว้ ไม่ขาดไม่เกิน
📌 เพื่อให้ลงลึกไปอีกขั้นตอนในการทำงาน เราอาจจะต้องคำนึงในส่วนของชุด Text ด้วยว่าถ้ายาวไป หรือสั้นไป จะแสดงอย่างไร หากเราเริ่ม Ideal State ได้ดี ก็จะทำให้การออกแบบใน State อื่นๆ นั้นสมบูรณ์มากขึ้น (และจะได้ไม่ต้องกลับมาแก้งาน ยังไงล่ะ!! 😂)
2. Empty State - หน้าแสดงข้อมูลให้ผู้ใช้งานรับทราบว่ายังไม่มีข้อมูลแสดง
ในกรณีที่ Application บางระบบ จะต้องมีหน้าที่ไว้เก็บข้อมูลของ User คนนั้น ก็จะทำให้เราต้องคำนึงถึงการออกแบบในส่วนของ Empty State มากขึ้น เช่น ระบบ Favorite, Bookmark, Wishlist, Add to Cart, หรือ การเข้าใช้งานครั้งแรกเป็นต้น ระบบพวกนี้จะมีข้อมูลแสดงได้ก็ต่อเมื่อผู้ใช้งานนั้นได้ทำการบันทึกหรือเปิดการใช้งาน หรือลบข้อมูลทั้งหมดถึงจะมีข้อมูลแสดง ถามว่าแล้วถ้าเราไม่ทำ Empty State ล่ะ จะเกิดอะไรขึ้น ?
งง สิครับ ถามได้ !! 🤣 เมื่อผู้ใช้เข้ามาแล้วเจอหน้าเปล่า อาจจะทำให้เขาคิดว่ามันโหลดอยู่เหรอ มัน Bug หรือเปล่า หลายคนอาจจะคิดว่า ไม่งงหรอก เดี๋ยวผู้ใช้งานเขาเล่นไปเล่นมาก็คิดได้เองเหลาะ ถ้าให้ผมตอบตรงๆ เลยคือ มันก็ได้ครับ ผู้ใช้งานเขาอาจจะต้องใช้เวลาเรียนรู้ (ถ้าเขาทนเล่น Application เราต่อนะ) แต่นั่นคือสิ่งที่ดีที่สุดสำหรับผู้ใช้งานแล้วจริงหรือเปล่า? จากประสบการณ์และอ่านการถกเถียงกันใน UX Community ทั้งไทย และนอก เขาก็แจ้งพื้นฐานในการคิดสำหรับการออกแบบ UX ที่ดี คือ “ทำยังไงก็ได้ ให้ผู้ใช้งานนั้นคิดน้อยที่สุด” เราจะออกแบบยังไงให้เรียกประสบการณ์ผู้ใช้ออกมาให้ได้ดี (เราจะไม่พูดถึง UX Process นะครับ เดี๋ยวจะหลุดประเด็น) เราก็ต้องมีข้อมูล Empty State นี้เหลาะครับ เพื่อให้เขาเห็นว่าเขากำลังอยู่ในสถานะอะไรในหน้านี้
📌 เพื่อให้ลงลึกไปอีก ในหน้า Empty State อาจจะไม่ได้บอกแค่ว่า “หน้านี้ยังไม่มีข้อมูล” เราก็ควรจะแจ้งว่า การที่เขาจะได้ข้อมูลนั้นมา เขาต้องทำอย่างไร ยกตัวอย่างเช่น อาจจะเป็นชุด Text อธิบายเพื่อ Guide ผู้ใช้งานคร่าวๆ ก็ได้ว่าหน้านี้คืออะไร ซึ่งในส่วนนี้ก็อาจจะต้องพิจารณาตามตัวงานและพูดคุยกับทีม ว่าแบบไหนที่เราคิดว่าดีที่สุด เพราะถ้ามันไม่ได้มีความสำคัญ ก็อาจจะไม่ต้องอธิบายอะไรเยอะครับ ใช้แค่ “ยังไม่มีข้อมูลแสดง” ก็มีความเป็นไปได้ครับ สุดท้ายถ้าหาก Product ปล่อยออกไปจริงๆ เราอาจจะได้ Feedback ที่แท้จริงจากผู้ใช้งานเพื่อมาแก้ปัญหาก็ได้ครับ
3. Over State - หน้าแสดงข้อมูลจำนวนมากกว่าปกติ
แสดงข้อมูลมากกว่าปกติเป็นอย่างไร ในส่วนของ Over state เราจะออกแบบไว้ในกรณีมีข้อมูลเยอะ เช่น ค้นหาข้อมูลร้านแล้ว จำนวนที่แสดงเกินหน้า Base Size ที่เราตั้งไว้ อาจจะมีคนตั้งคำถามว่า “เฮ้ย !! แค่นี้ต้องทำด้วยหรอ Dev มันก็จินตนาการเอาเองก็ได้มั้ง ว่ามันจะแสดงอย่างไร ก็แค่เลื่อนขึ้น ครบ 20 Objects แล้วโหลดเพิ่ม” ไอ้ประโยคที่พูดมาเมื่อกี๊เหลาะครับ ทำ Design Over State ซะ !! เขาจะได้เห็นภาพและทีมจะได้เข้าใจตรงกัน
จากตัวอย่างข้างต้น อาจจะทำให้เห็นภาพมากขึ้นว่า ทำไมเราถึงต้องทำ Over State เพราะ Dev และ Designer จะได้เข้าใจกันและกันมากขึ้นครับ ในการทำงาน
📌 เพื่อให้ลงลึกไปอีก เราก็ทำ Interaction แสดงการทำงานของมันด้วยครับ ว่ามันทำงานอย่างไร เพื่อที่จะลดช่องว่างระหว่างการสื่อสารในทีม มันก็ไม่ได้มีแค่กรณีที่ผมยกตัวอย่างข้างต้นนะครับที่จะทำให้เกิดปัญหาช่องว่างที่ขาดหายไป หากเราไม่ทำ Design Over State ออกมา นอกจาก Design UI Over State แล้วเราสามารถออกแบบ Interaction เพื่อเสริมความเข้าในการทำงานสำหรับขั้นตอนการเลื่อนขึ้น การทำ Over State หรือ การทำ Interaction ในส่วนนี้จะทำให้เห็นภาพการทำงานมากขึ้นครับ
จากตัวอย่าง หากเราไม่ทำ Interaction ให้ Dev จะไม่ทราบเลยว่า Scroll แล้ว App bar จะ Transparent ขึ้นมา Text จะ Slide ขึ้นมา พร้อม Logo และ Background จะขึ้นมาพร้อม List จนสุดที่ App bar แล้วหยุด
4. Partial State - หน้าแสดงข้อมูลที่บอกว่ายังไม่สมบูรณ์
หน้าแสดงข้อมูลแบบไม่สมบูรณ์เป็นอย่างไร อ่านดูแล้วมันจะคล้ายกับ Empty State หรือเปล่า ในความจริงแล้วไม่ใช่นะครับ มันเป็นอีกส่วนของการออกแบบเพื่อแจ้งสถานะการทำงานของ App หากต้องมีเงื่อนไขสำหรับ User ในการใช้งาน ยกตัวอย่างเช่น ขั้นตอนการสมัครสมาชิก, การตอบแบบสอบถาม เป็นต้น การทำ Partial State ในส่วนนี้จะแก้ปัญหาเรื่องความอดทนในการใช้งาน App ที่มีความจำเป็นต้องทำให้ครบสมบูรณ์จนกว่าจบขั้นตอนสุดท้ายเพื่อเริ่มใช้งาน แต่เราจะทำยังไงให้เขา “เสพติด” ใช้งาน App เราต่อ หรือทำยังไงให้เขาอยากเข้ามาใช้งาน App เราต่อ ไปดูตัวอย่างกันดีกว่า
ยกตัวอย่างเช่น UI ของ Progress Bar ที่บอกจำนวนข้อ, เปอร์เซ็นต์, หรือ Interaction อะไรก็ตามที่แสดงถึงขั้นตอนการใช้งานเพื่อให้เขารู้ว่าเหลืออีกเท่าไรเขาถึงจะทำเสร็จสมบูรณ์ทุกขั้นตอนครับ
เมื่อจบขั้นตอนอันยุ่งยากแล้ว เราก็ต้องให้รางวัล หรือมีอะไรนิดๆ หน่อยๆ เพื่อบอกว่าเขาได้ทำรายการเสร็จแล้วนะ เขาจะได้รู้สึกประทับใจ และพอใจกับการใช้งาน เพื่อที่ผู้ใช้จะได้อยากกลับมาใช้อีกครั้งครับ 😊
จากตัวอย่างงานที่ผมเอามาให้ดู เป็นแค่การยกตัวอย่าง Partial State ท่ีเอามาให้ดูกันนะครับ ซึ่งมีอีกหลายวิธีมากมายที่จะทำให้ Partial State ที่เราออกแบบมานั้น ดึงดูด และ ทำให้ผู้ใช้งานไม่รู้สึกเบื่อกับการใช้งานที่มีขั้นตอนที่ยุ่งยากและยาวนาน
สามารถหาตัวอย่าง Case Partial State ดีๆ ได้จากหลายๆ App ครับ หากใครไม่รู้ว่าจะไปลองเล่น App อะไรดี ผมแนะนำว่าให้ลองเล่นพวก App of the year หรือพวก Editors’ choice แนะนำครับ ไปต่อกันที่ข้อต่อไปกันเลย
5. Loading State - สถานะกำลังโหลดข้อมูล
การแสดงโหลดนั้นมีความสำคัญในระดับต้นๆ เลย เพราะการแสดงตัวโหลดไม่ได้มีความหมายเพียงแค่การแสดงสถานะให้ผู้ใช้งานรับรู้เท่านั้นว่า ฉันกำลังโหลดข้อมูลอยู่นะ ไม่ได้ค้างแต่อย่างใด แต่มันยังสามารถเรียกความสนใจหรือเบี่ยงเบนความสนใจได้ให้ผู้ใช้รู้สึกว่า จริงๆ แล้วก็ไม่ได้โหลดนานหนิ โหลดแป๊บๆ ก็เสร็จละ แล้วมันจะน่าสนใจยังไงล่ะ? ก็ทำให้มันสวยสิเธอ!!🤣
การออกแบบ Loading State ผมจะขอแบ่งเป็น 2 ประเภทคือ Micro loading และ Full page loading
5.1 Micro Loading
คือตัวโหลดขนาดเล็กที่จะไปแทรกการโหลดข้อมูลต่างๆ เช่น การโหลด List เพื่อมาแสดง หรือ Toast Loading ใน Android เป็นต้น การโหลดประเภทนี้อาจจะใช้กับกรณีที่โหลดข้อมูลไม่นาน เพียง 0.00 sec — 1.00 sec ก็ควรจะใช้ตัวโหลดประเภทนี้ การเลือกใช้ตัว Loading ก็ควรจะเลือกที่เข้ากับงาน UI ที่เราออกแบบไว้ไม่ให้ดูขัดกันจนเกินไป
5.2 Full page loading
คือตัวโหลดแบบแสดงเต็มหน้า ตัวโหลดแบบนี้จะถูกใช้สำหรับหน้าที่ต้องการโหลดข้อมูลนานๆ เช่น การโหลด เพื่อเข้า Application ครั้งแรก หรือการโหลดข้อมูลเยอะๆระหว่างหน้าก็ใช้ได้เหมือนกัน ลูกเล่นของตัวโหลด Full Page นั้นเราสามารถทำลูกเล่นได้เยอะนะครับ ไม่ว่าจะเป็นการทำ Motion สวยๆ หรือการทำ Interaction ให้ผู้ใช้งานกดเล่นระหว่างรอ Loading ก็ได้
ตัวอย่าง Full page loading เพื่อเข้า Application ตัวนี้จำเป็นต้องโหลดข้อมูลบางส่วนก่อนเข้าใช้งาน การแสดงโหลดแบบ Full page loading มีหลากหลายมากครับ สามารถหา Ref ดูเป็นตัวอย่างจากเว็บต่างๆ ได้เลย
นอกจาก Loading State จะช่วยเรื่องการใช้งานของ User แล้ว การทำออกแบบ Loading State ไว้ก็จะทำให้ App เรานั้นสมบูรณ์และไปในทิศทางเดียวกันกับ UI ที่เราต้องการนำเสนอได้ครับ แล้วถ้าเราไม่ออกแบบ Loading State ล่ะ? แน่นอนว่า Dev ต้องใส่ตัวโหลด Default ของ Platform นั้นๆ หรือ ตัวโหลดแปลกๆ มาแน่นอน ถ้าเราไม่ทำไว้
6. Error State - สถานะแสดงข้อมูลผิดพลาด
สุดท้ายแล้วโว้ยยยยยย ออกแบบอะไรเยอะแยะ เน๊อะ~~ (บ่น🤣)
ในส่วนของ Error State นี้มันก็เป็นของตายคล้ายๆ Ideal State นั้นเหลาะครับ มันเป็นส่วนที่เราต้องทำ แต่ส่วนมากนักออกแบบ รวมถึงผมด้วยก็มักจะลืมที่จะทำกัน ว่ามันจะต้องแสดงอย่างไร Text ต้องแสดงแบบไหน ใช้คำว่าอะไรในการแจ้งเตือน
📌 เพื่อจะให้ลงลึกไปอีก การที่เราใส่ใจเลือกชุด Text ในการออกแบบ Error state จะทำให้เรานั้นสามารถควบคุมทิศทางงานออกแบบ UI ของเรานั้นได้มากยิ่งขึ้น ตัวอย่างเช่น Error จากกูเกิ้ล มักจะใช้ชุด Text ที่อ่านแล้วรู้สึก Friendly เสมอ หรือถ้าเราได้ออกแบบ App ที่ต้องการความน่าเชื่อถือสูง เราก็ควรใช้ UI และ Text ที่มองเห็นแล้วรู้สึกถึงความน่าเชื่อถือได้
Error State นั้นควรจะถูกแสดงขึ้นมาเมื่อ User ทำอะไรผิดพลาด เช่น มีปัญหาในการเชื่อมต่อต่างๆ หรือ เตือนก่อนที่จะกดทำอะไรสำคัญๆ เช่น การกรอกแบบฟอร์มผิด การออกจากหน้าที่กำลังทำการบันทึก การกดลบอะไรสำคัญทิ้ง และที่แน่ๆ เลยคือ อะไรที่ต้องเสียเงินเสียทอง ต้องเตือนผู้ใช้!!💵
บางคนคิดว่าถ้ามัดรวมแบบนี้ จะเรียก Error State หมดเลยหรือเปล่าครับ เพราะบางอย่างก็ไม่ได้เป็นการ Error นะ เช่น การ เตือนเพื่อลบอะไรทิ้งซักอย่าง หรือการลืมกรอกข้อความอะไรซักอย่าง เอาเป็นว่า ผมขอมัดรวมอยู่ใน หัวข้อ Error State แล้วกันนะครับ เพราะมันคือ State ที่ควรจะมีในการออกแบบเพื่อรับรองการทำงานที่สมบูรณ์ของระบบนั้นๆ ครับ
ครบแล้วครับกับ User Interface State ที่ทุกแอปพลิเคชั่นควรมี หลังจากอ่านจบหวังว่าจะทำให้ได้มุมมองจากฝั่งนักออกแบบ UI กันไปบ้าง หรือหากเป็นนักออกแบบอยู่แล้ว ก็หวังว่าหลังจากอ่านบทความนี้จบไป จะทำให้ Project ที่กำลังทำอยู่แน่นขึ้นอีกเป็นกองนะคร้าบบบบ
หากชอบก็ฝากปรบมือแรงๆ 👏🏻 เป็นกำลังใจสำหรับการเขียนบทความต่อๆ ไปด้วยครับ ขอบคุณครับ
อ่านบทความอื่นๆ
ประเภทของ Prototyping?
สร้างไฟล์ Gif ยังไงให้คมชัด
