แอนิเมชันที่มีจุดมุ่งหมาย

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

---

จุดมุ่งหมายของแอนิเมชัน

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

ความสำคัญของเจตนา

• ก่อนใส่แอนิเมชัน ควรถามก่อนว่า "แอนิเมชันนี้มีไว้เพื่ออะไร"
• ตัวอย่างเช่น แอนิเมชันการตลาดของ Product Intelligence ของ Linear ช่วยให้ผู้ใช้เข้าใจได้ทันทีว่า ฟีเจอร์นั้นทำงานอย่างไร แทนที่จะใช้ภาพนิ่ง
• เอฟเฟกต์ scale down เล็กน้อยเมื่อกดปุ่ม ช่วยให้อินเทอร์เฟซรู้สึก มีชีวิตชีวาและตอบสนองได้ดีขึ้น
• แอนิเมชันการแสดง toast ของ Sonner มีจุดประสงค์อยู่ 2 ข้อ
  • ทำให้ปรากฏขึ้นอย่างเป็นธรรมชาติแทนการโผล่มาอย่างกะทันหัน เพื่อลดความรู้สึกแปลกแยก
  • ปรากฏและหายไปในทิศทางเดียวกันเพื่อรักษา ความสอดคล้องเชิงพื้นที่ และเพิ่มความเป็นธรรมชาติของ gesture แบบ swipe-down
• บางครั้ง "ความยินดี" เองก็อาจเป็นจุดประสงค์ของแอนิเมชันได้ และในปฏิสัมพันธ์ที่เกิดขึ้นไม่บ่อย มันสามารถมอบ ความแปลกใหม่ และ ประสบการณ์ที่น่าจดจำ
• อย่างไรก็ตาม เมื่อความถี่ในการใช้งานสูงขึ้น ความยินดีในช่วงแรก อาจเปลี่ยนเป็น ความรำคาญ และ ความล่าช้า ได้อย่างรวดเร็ว

ความถี่ในการใช้งานกับแอนิเมชัน

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

การรับรู้เรื่องความเร็วและการตอบสนอง

• ยกเว้นเว็บไซต์การตลาดแล้ว แอนิเมชัน UI ทั้งหมดควรทำงานอย่างรวดเร็ว เพื่อเพิ่มประสิทธิภาพที่ผู้ใช้รับรู้และความรู้สึกว่าระบบตอบสนองดี
• loading spinner ที่หมุนเร็วทำให้รู้สึกว่าโหลดเสร็จไวกว่า แม้เวลาจริงจะเท่ากันก็ตาม
• แอนิเมชัน dropdown ที่ใช้เวลา 180ms ให้ความรู้สึก ตอบสนองได้ดีกว่า แบบ 400ms อย่างมาก
• โดยทั่วไป แอนิเมชัน UI ควรใช้เวลา น้อยกว่า 300ms
• tooltip ควรมีดีเลย์เล็กน้อยตอนแสดงครั้งแรก แต่เมื่อเปิดแล้ว การตอบสนองทันทีโดยไม่มีแอนิเมชันเพิ่มเติมจะให้ ประสบการณ์ที่ดีที่สุด (อ้างอิง Radix UI, Base UI)
• การสลับระหว่าง tooltip โดยไม่มีดีเลย์ช่วยปรับปรุงประสบการณ์ผู้ใช้ โดยไม่ทำลายจุดประสงค์เดิม

สร้างอินเทอร์เฟซที่ยอดเยี่ยม

• เป้าหมายสูงสุดไม่ใช่ตัวแอนิเมชันเอง แต่คือการ สร้างส่วนติดต่อผู้ใช้ที่ยอดเยี่ยม
• สิ่งสำคัญคือการสร้างประสบการณ์ที่ผู้ใช้อยากใช้งานด้วยความเต็มใจในชีวิตประจำวัน
• บางครั้งแอนิเมชันก็จำเป็น แต่ในบางสถานการณ์ "ไม่มีแอนิเมชัน" อาจเป็นตัวเลือกที่ดีที่สุด
• การรู้ว่า ควรใช้แอนิเมชันเมื่อไร และใช้อย่างไร คือทักษะสำคัญในการออกแบบ UI/UX

บทสรุป

• การจะสร้างอินเทอร์เฟซที่ยอดเยี่ยมได้ จำเป็นต้องมีความเข้าใจอย่างลึกซึ้งเกี่ยวกับการใช้แอนิเมชัน
• สามารถดูเนื้อหาทฤษฎีและแบบฝึกเพิ่มเติมได้ใน "Animations on the Web"

[GN⁺]

ความคิดเห็นจาก Hacker News

• ทุกครั้งที่นักออกแบบคุยกันเรื่องแอนิเมชัน มักใช้คำอย่าง “policy” หรือ “delight” แล้วชั่งน้ำหนักสิ่งเหล่านี้กับความหน่วงในการรับรู้ ซึ่งก็ไม่ถึงกับผิดทั้งหมด แต่ยังมีจุดที่น่าเสียดายอยู่บ้าง

  1. คิดว่าส่วนของ delight ถูกพูดเกินจริง คนที่ประทับใจกับแอนิเมชันหวือหวาจริง ๆ ส่วนใหญ่ก็คือนักออกแบบคนอื่น
  2. เหนือสิ่งอื่นใด เวลาเลือกว่าจะใช้แอนิเมชันเมื่อไร การโฟกัสที่ “state” มีประโยชน์มากกว่า ถ้ามีความเสี่ยงที่ผู้ใช้จะสังเกตการเปลี่ยน state ได้ไม่ชัด ตอนนั้นค่อยใช้แอนิเมชันช่วยทำให้เห็นภาพ และคิดว่านี่คือจุดประสงค์หลักของการใช้แอนิเมชัน อย่างอื่นนอกจากนั้นคือความฟุ่มเฟือย

  • สำหรับความเห็นที่ว่า “delight ถูกพูดเกินจริง” ถ้าใช้อย่างเหมาะสมและไม่รบกวน แอนิเมชันที่มีความหมายในซอฟต์แวร์ย่อมให้ผลเชิงบวกกับผู้ใช้อย่างชัดเจน เพียงแต่อาจต่างจากผลที่หลายคนคาดหวังเล็กน้อย
    แอนิเมชันที่ออกแบบมาดีคือองค์ประกอบ 20% ท้ายสุดที่แบ่งระหว่างคำว่า “ดี” กับ “ยอดเยี่ยม” แม้ไม่จำเป็นเสมอไป แต่เป็นสิ่งที่สร้างความแตกต่างเมื่อเทียบกับคู่แข่ง
    เหตุผลที่เป็นรูปธรรมว่าทำไมแอนิเมชันจึงมีคุณค่า ก็คล้ายกับปรากฏการณ์ที่ผู้คนใช้ความรู้สึกถึงน้ำหนักหรือความทนทานของสินค้าจริงเป็นเกณฑ์ตัดสินว่าพรีเมียมหรือไม่
    แต่ตลอด 10 ปีที่ผ่านมา งานออกแบบ UI เอนเอียงไปทาง “บรรยากาศ” “การนำเสนอที่ฉูดฉาด” และ “แบรนดิ้ง” มากเกินไป ขณะที่การวิจัยและการใช้งานจริงเกี่ยวกับการใช้แอนิเมชันอย่างมีประสิทธิภาพกลับถูกมองข้าม
    ตอนนี้ถึงเวลาที่ UI design ควรกลับไปให้ความสำคัญกับการใช้งานจริงเป็นหลัก

  • แปลกใจที่มีคนมองว่าเอฟเฟกต์ย่อขนาดลงเล็กน้อยเวลาเราคลิกปุ่มก็ถือเป็นแอนิเมชันชนิดหนึ่ง ทั้งที่มันคือ visual feedback ขั้นพื้นฐานมาก ๆ ที่บอกว่าปุ่มกดได้และระบบรับรู้การคลิกแล้ว

  • ในงานออกแบบซอฟต์แวร์ ท่าทีที่ให้ความสำคัญกับ “delight” มากเป็นพิเศษ มักพบได้บ่อยในหมู่แฟน Apple ยุคเก่า เช่นความรู้สึกเสียดายที่ Apple หลังยุค Jobs มีความขี้เล่นลดลง
    ไม่รู้ว่ามีบทความหลักที่สรุปประเด็นนี้ครบถ้วนหรือไม่ แต่มีการกล่าวถึงในบทความสั้นนี้
    ความชอบรายละเอียดแบบนี้ไม่ใช่แค่รสนิยมเฉพาะของนักออกแบบบางคนหรือเรื่องเฉพาะกลุ่มแคบ ๆ แต่เป็นหนึ่งในลักษณะสำคัญของแฟนด้อม Apple

  • มักเจอสถานการณ์ที่นักออกแบบซึ่งทำงานในสภาพแวดล้อม B2B ออกแบบเหมือนเป็นงานสไตล์ B2C
    ใน B2B (โดยเฉพาะ enterprise) สิ่งที่ผู้ใช้ต้องการก็แค่เครื่องมือทำงานประจำวัน ดังนั้นแอนิเมชันหวือหวา กราเดียนต์หลากสีสัน (ซึ่งทุกวันนี้บางทีก็หมายถึง AI) ฯลฯ ไม่ได้ช่วยงานจริง แถมยังทำให้เสียสมาธิ
    องค์ประกอบตกแต่งแบบนี้มีแต่จะขัดขวางผู้ใช้เวลาต้องไล่อ่าน dashboard ที่เน้นข้อความเพื่อค้นหาข้อมูลอย่างมีประสิทธิภาพ
    ถ้าอยากสร้างประสบการณ์ที่ “สวยและทำให้อารมณ์ดี” จริง ๆ บริษัทสาย workflow อย่าง CRM/ERP ก็คงไม่ใช่ที่เหมาะอยู่แล้ว จะมีความหมายก็ต่อเมื่อไปทำงานกับบริษัทที่ความพึงพอใจเชิงอารมณ์ของผู้ใช้เชื่อมโยงกับคุณค่าทางธุรกิจโดยตรง

  • ไม่เห็นด้วยกับคำพูดที่ว่า “delight ถูกพูดเกินจริง”
    ยกตัวอย่างเช่น ถ้าผู้ใช้ Apple/iPhone ไปลองใช้ Android สักสัปดาห์ ก็มักจะบอกว่ารู้สึก “มีอะไรบางอย่างไม่เป็นธรรมชาติและน่ารำคาญ”
    เรื่องพวกนี้เกิดจากการที่ iOS มีแอนิเมชันที่ถูกขัดเกลามาอย่างละเอียดตลอดทั้งประสบการณ์การโต้ตอบ
    แม้ผู้บริโภคทั่วไปจะไม่ได้อธิบายประสบการณ์ของตัวเองด้วยคำว่า “delight” แต่เมื่อพวกเขาเจอประสบการณ์ที่แย่ลงกว่าที่เคยใช้ ก็รับรู้ได้อย่างชัดเจน

• คิดว่า Apple เองก็มีสิ่งที่ควรเรียนรู้ในเรื่องนี้ เพราะบ่อยครั้งเสียเวลาไปกับการรอแอนิเมชันที่ไม่จำเป็น
  ตัวอย่างเช่น หลังเลื่อนหน้าจอลงสุดแล้วแตะปุ่ม บางทียังต้องกดหลายครั้งกว่าจะตอบสนอง เพราะต้องรอให้แอนิเมชัน bouncing จบก่อน
  การปัดสลับแอป การปิด notification การเปิด dock หรือ drawer และ action ที่อิง gesture ส่วนใหญ่ ล้วนช้าเกินไป
  แอนิเมชันถูกเล่นต่อเนื่องกัน จบอันหนึ่งก่อนถึงจะเริ่มอันถัดไป แล้วค่อยอนุญาตให้สั่งงานต่อ
  มันชวนย้อนแย้งที่ต้องไปปิดแอนิเมชันเหล่านี้ในตั้งค่า Accessibility ถึงจะใช้งานได้สบายขึ้น

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

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

  • บน MacOS ตอนสลับ desktop/space ถ้ายังแอนิเมตไม่เสร็จ input ทั้งหมดจะยังถูกส่งไปที่ space เดิม ทำให้อึดอัดมาก
    ตอนนี้ Apple ไม่ได้ใส่ใจ UI/UX อย่างที่ควร ในองค์กรใหญ่แบบนี้ ถ้าไม่มีคนตัดสินใจที่ทรงพลังแบบ Steve Jobs ก็มักทำ user experience ที่ดีได้ยาก
    และบ่อยครั้งนักออกแบบก็ไม่ตระหนักว่า “ผู้ใช้ทั่วไป” ไม่ได้เป็นแฟนของตัวเองหรือของผลิตภัณฑ์นั้น ๆ แต่แค่ต้องการฟังก์ชันพื้นฐานและความสม่ำเสมอเท่านั้น
    ทุกครั้งที่จะเปลี่ยนอะไร ควรมีท่าทีแบบว่าเอาไปให้คุณย่าดู แล้วถ้าเธอไม่อุทานว่า “ว้าว อันนี้ดีกว่าเดิมมากจริง ๆ” ก็ไม่ควรเปลี่ยน

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

  • ฉันเองเมื่อก่อนก็ใช้ราว 250ms แต่ช่วงนี้ลดเหลือ 200ms
    200ms เป็นความเร็ว transition ของ UI ที่เหมาะที่สุดสำหรับการรับรู้ว่าอะไรเปลี่ยน อย่างไร และทำไม
    ถ้าทำไม่ได้ตามเกณฑ์นี้ ก็ควรตัด transition นั้นทิ้งไปเลย
    200ms ยังสะดวกเพราะใน CSS เขียนง่ายเป็น .2s
    ถ้าต่ำกว่า 150ms อาจให้ความรู้สึกเหมือน rendering glitch ซึ่งถ้าสั้นเกินไป ข้อดีของแอนิเมชันก็จะหายไปเอง

  • เวลาใช้โทรศัพท์ Android ครั้งแรก สิ่งแรกที่ทำคือเข้า developer mode แล้วตั้งความเร็วแอนิเมชันให้เร็วขึ้น 2 เท่า
    พอดูมันทำงานที่ความเร็วปกติแล้วอึดอัดมาก

• แอนิเมชันในงานออกแบบเว็บ จริง ๆ แล้วไม่ต่างจากลูกเล่นใน PowerPoint เท่าไร
  ส่วนใหญ่แค่ใช้เอฟเฟกต์ cross-fade เร็ว ๆ สักหนึ่งหรือสองแบบ ก็ทำ UI ที่ดูสะอาดเป็นระเบียบได้แล้ว และแทบไม่จำเป็นต้องมีอะไรมากกว่านั้น

• ฉันคิดว่าแอนิเมชันมีความหมายก็ต่อเมื่อมันช่วยยืนยันสิ่งที่ผู้ใช้รู้อยู่แล้ว ไม่ควรให้แอนิเมชันกลายเป็นตัวกลางหลักในการสื่อข้อมูล
  กล่าวคือ ต่อให้ปิดแอนิเมชัน ผู้ใช้ก็ควรทำงานได้เร็วเท่าเดิม และเข้าใจ flow ได้เหมือนเดิม
  จุดประสงค์ของแอนิเมชันคือทำให้เส้นทาง UX ลื่นไหล และส่งสัญญาณเล็ก ๆ ว่า state เป็นไปตามที่คาดไว้
  ตัวอย่างเช่น ถ้าเวลาเอาเมาส์ hover แล้วมีการไฮไลต์อย่างรวดเร็ว ก็ไม่ต้องคอยกังวลเพิ่มว่าเมาส์ของฉันอยู่เหนือคอนโทรลนั้นหรือยัง
  อย่างกรณี tooltip popup ถ้าหลังจากขึ้นครั้งแรกแล้วครั้งต่อไปแสดงผลทันทีที่ 0ms ก็จะรู้สึกได้ว่าผู้ออกแบบเข้าใจ flow ของ UX ของผู้ใช้อย่างแท้จริง
  นี่คือตัวอย่างคลาสสิกของแอนิเมชันที่เข้าใจเส้นทาง UX ได้ดี

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

  • สำหรับจุดประสงค์นี้ media query prefers-reduced-motion ของ CSS มีประโยชน์มากจริง ๆ
    ดูเอกสารที่เกี่ยวข้อง

• สำหรับแอนิเมชันที่ใช้แนะนำฟีเจอร์ Product Intelligence ของ Linear เข้าใจเจตนาของนักออกแบบ แต่เวลาใช้งานจริงมันไม่ได้ช่วยให้เข้าใจอะไรเลย
  แอนิเมชันมุมมอง 3D แปลก ๆ ดูไม่เกี่ยวกับ UI จริง
  เอฟเฟกต์ 3D นี้พอจะสื่อได้ว่า box บางอันบนหน้าจอ (ก็คือตัวผลิตภัณฑ์) ไม่ใช่หน้าที่ฉันกำลังอ่านอยู่ แต่ถึงอย่างนั้นก็ไม่ได้ช่วยให้เข้าใจฟีเจอร์นั้นมากขึ้นเท่าไร
  เอฟเฟกต์ fade-in ช่วยดึงสายตาไปยังบริเวณนั้นได้ก็จริง แต่ไม่ได้มีส่วนช่วยถ่ายทอดเนื้อหามากนัก

• แอนิเมชันที่ “สร้างความ delight” ดูโอเคบนหน้าจอของฉัน (เช่น M1 MacBook Pro) แต่พอไปอยู่บนหน้าจออื่น (เช่นจอความละเอียดต่ำ IBM ThinkVision) กลับดูแปลกและช้ามาก
  วิดีโอเดโมบน MacBook
  วิดีโอเดโมบนจอคุณภาพต่ำ
  มันให้ความรู้สึกต่างกันไปโดยสิ้นเชิงตามจอที่ใช้ดู

  • สงสัยว่าจอ IBM นั้นกำลังใช้ที่ความละเอียด native อยู่หรือเปล่า

• สำหรับความเห็นที่ว่า “spinner ที่หมุนเร็วทำให้รู้สึกว่าโหลดเร็วกว่า” ฉันกลับเจอดีไซน์แย่ ๆ ที่ชอบใช้ spinner เร็ว ๆ ทั้งที่จริงแล้วไม่มีอะไรเกิดขึ้นบ่อยมาก จนรู้สึกว่า spinner ที่ช้ากลับน่าเชื่อถือกว่า

  • ฉันเชื่อถือเฉพาะ loading bar ที่แสดงความคืบหน้าแบบไม่เป็นเชิงเส้นเท่านั้น เพราะแบบนั้นจะเห็นสัญญาณชัดเจนว่าในแต่ละช่วงมีบางอย่างกำลังคืบหน้าอยู่จริง

  • spinner ที่ช้ากลับให้ความรู้สึกน่าเชื่อถือกว่า เพราะเหมือนกำลังทำงานหนักจนหน่วงอยู่จริง

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