“ขออินโฟกราฟิกหนึ่งภาพครับ เน้นสวย ๆ อ่านง่าย”
บรีฟแบบนี้ฟังดูไม่มีอะไรยาก จนคนออกแบบถามกลับว่าให้ใส่ข้อมูลอะไรบ้าง ฝั่งเจ้าของงานจึงส่งไฟล์ Excel มาทั้งชุด พร้อมข้อความจากฝ่ายขายอีกสองหน้า และภาพตัวอย่างที่ชอบอีกห้ารูป คราวนี้ทุกคนรู้แล้วว่าอยากได้ภาพสวย แต่ยังไม่มีใครตอบได้ว่าคนดูควรเข้าใจอะไรหลังเลื่อนผ่านภาพนั้น
งานเลยติดตั้งแต่ก่อนเริ่มวาด ไม่ใช่เพราะนักออกแบบคิดไม่ออก แต่เพราะยังไม่ตกลงกันว่าเรื่องไหนต้องเด่น เรื่องไหนเป็นรายละเอียด และตัวเลขไหนใช้ได้จริง
เริ่มจากคำถามเดียว: คนดูต้องเข้าใจอะไรภายในไม่กี่วินาที
สมมติบริษัทขนส่งอยากทำภาพแสดงขั้นตอนรับสินค้า ตั้งแต่ลูกค้าจองคิวจนได้รับหลักฐานจัดส่ง ถ้าหัวข้อหลักคือ “ส่งของกับเรามีกี่ขั้นตอน” คนดูก็ควรเห็นลำดับงานก่อน ราคา เบอร์โทร เงื่อนไขพิเศษ และโปรโมชันไม่จำเป็นต้องมาชิงพื้นที่ในภาพเดียวกันทั้งหมด
ลองเขียนประโยคที่อยากให้คนดูจำได้หนึ่งประโยคก่อน เช่น “ก่อนส่งสินค้าต้องเตรียมข้อมูลสามอย่าง” ถ้ายังเขียนไม่ได้ อาจต้องกลับไปคุยเรื่องเนื้อหาก่อนเลือกสีหรือหารูป
ไฟล์ข้อมูลหนึ่งชุด ไม่ได้หมายความว่าต้องใส่ลงไปทั้งชุด
ข้อมูลในตารางมีไว้ช่วยตัดสินใจว่าจะเล่าเรื่องอะไร ไม่ใช่รายการของทุกอย่างที่ต้องปรากฏบนภาพ
ตัวอย่างร้านจำหน่ายอุปกรณ์สำนักงานมีข้อมูลสินค้าหลายสิบรุ่น แต่ลูกค้ามักถามแค่ “รุ่นไหนเหมาะกับออฟฟิศเล็ก?” อินโฟกราฟิกที่ตอบคำถามนี้ควรเทียบเกณฑ์ที่เกี่ยวข้อง เช่น พื้นที่ใช้งานหรือประเภทงาน โดยใช้ข้อมูลผลิตภัณฑ์ที่ตรวจสอบแล้ว ไม่จำเป็นต้องยกสเปกทุกช่องในแค็ตตาล็อกมาแสดง
ถ้าข้อมูลสำคัญมากและตัดออกไม่ได้ ลองพิจารณาแยกเป็นหลายภาพหรือทำบทความรายละเอียดประกอบ อย่าฝืนให้ตัวอักษรเล็กลงเรื่อย ๆ จนอ่านไม่ได้บนมือถือ
ตัวเลขตัวหนึ่ง ต้องรู้ว่ามาจากไหนและหมายถึงอะไร
คำว่า “ประหยัดเวลา 40%” ดูสะดุดตาดี แต่ก่อนเอาไปวางตัวใหญ่กลางภาพ ต้องตอบให้ได้ว่าเทียบกับอะไร วัดเมื่อไร วัดกับใคร และยังใช้ได้กับลูกค้าปัจจุบันหรือไม่
ถ้าไม่มีหลักฐาน ก็ไม่ควรใส่
บางครั้งแค่เปลี่ยนจากคำอ้างผลลัพธ์เป็นการอธิบายวิธีทำงานจริง ภาพก็มีประโยชน์มากขึ้น เช่น จาก “ส่งเร็วที่สุด” เป็น “ตรวจสถานะงานได้จากเลขติดตาม” เมื่อบริการมีระบบนั้นจริง การสื่อสารไม่จำเป็นต้องเว่อร์เพื่อให้น่าสนใจ
บรีฟให้นักออกแบบรู้เรื่องตั้งแต่รอบแรก
แทนที่จะส่งข้อความยาว ๆ แล้วบอกว่า “ประมาณนี้ครับ” ลองสรุปโจทย์เป็นข้อความสั้น ๆ ที่อ่านเข้าใจตรงกันก่อน
ตัวอย่างเช่น ร้านขายเครื่องปิดกล่องอยากเปรียบเทียบรุ่นกึ่งอัตโนมัติกับรุ่นอัตโนมัติ บรีฟควรเริ่มจากคนอ่านคือใคร กำลังติดปัญหาอะไร และข้อมูลสเปกของรุ่นที่ขายจริงมีอะไรบ้าง ไม่ใช่เริ่มจากขอให้ทำกราฟิกสีส้มแล้วค่อยคิดคำพูดทีหลัง
จุดที่ต้องแจ้งไว้ตั้งแต่แรกคือสิ่งที่ห้ามสื่อผิด เช่น ความเร็วในการทำงานขึ้นกับขนาดกล่องและวิธีป้อนสินค้า ไม่ใช่ทุกโรงงานจะได้ผลเหมือนกัน จากนั้นระบุว่าจะใช้ภาพบน Facebook หรือเว็บไซต์ และใครเป็นผู้ตรวจสเปกก่อนปล่อยเผยแพร่ เท่านี้นักออกแบบก็มีขอบเขตชัดขึ้นมาก
บรีฟลักษณะนี้ไม่ได้ทำให้คนออกแบบขาดอิสระ ตรงกันข้าม เขาจะมีพื้นที่คิดเรื่องการจัดวางและภาพประกอบมากขึ้น เพราะไม่ต้องเดาว่าข้อมูลส่วนไหนเปลี่ยนได้หรือไม่ได้
ตกลงโครงก่อนลงสี ช่วยลดงานแก้ที่ไม่จำเป็น
เคยเจองานที่แก้ไปห้ารอบเพราะแต่ละคนเข้าใจคำว่า “เด่น” ไม่เหมือนกันไหม? คนหนึ่งอยากให้ตัวเลขใหญ่ อีกคนอยากให้ชื่อแบรนด์ใหญ่ ส่วนฝ่ายขายอยากใส่ข้อความจากโบรชัวร์ทั้งหมด นักออกแบบทำตามทุกฝ่ายจนสุดท้ายไม่มีจุดไหนเด่นจริง
ทางออกไม่ต้องซับซ้อน ขอภาพร่างขาวดำที่เห็นตำแหน่งหัวเรื่อง ภาพหลัก และข้อมูลรองก่อนสักหนึ่งรอบ ดูว่าเมื่อกวาดตาผ่านแล้วคนอ่านจะจับอะไรเป็นอย่างแรก หากโครงยังเล่าเรื่องไม่รู้เรื่อง การเพิ่มสีและไอคอนก็ช่วยได้ไม่มาก การคุยรอบนี้ควรให้คนที่มีอำนาจตัดสินใจเรื่องสารหลักเข้าร่วมด้วย จะได้ไม่ย้อนกลับมารื้อเมื่อจัดภาพเสร็จแล้ว
หนึ่งเรื่องอาจต้องใช้ภาพมากกว่าหนึ่งขนาด
ภาพที่ใช้เป็นเนื้อหาในบทความกับภาพที่คนเห็นผ่าน ๆ บนโซเชียลไม่จำเป็นต้องใช้ข้อความเท่ากัน บนเว็บไซต์เราอาจให้รายละเอียดต่อใต้ภาพได้ แต่บนฟีดโทรศัพท์คนอาจเห็นเพียงภาพย่อ ไม่ได้ขยายอ่านทุกบรรทัด
ถ้ามีข้อมูลมาก ลองแยกหน้าปกที่ตั้งคำถามชัด ๆ กับภาพอธิบายรายละเอียดด้านใน หรือแยกเป็นชุดภาพที่มีลำดับอ่านต่อกัน วิธีนี้ดีกว่าลดขนาดตัวอักษรเพื่อยัดทุกอย่างลงภาพเดียว แล้วหวังว่าคนดูจะซูมเอง
เลือกภาพให้เข้ากับชนิดของข้อมูล
เรื่องที่เป็นลำดับขั้นตอน เหมาะกับภาพที่มองตามทางเดินได้ เรื่องเปรียบเทียบสองทางเลือก ต้องเห็นความต่างในจุดเดียวกัน ส่วนข้อมูลที่เป็นสัดส่วนหรือแนวโน้มอาจใช้กราฟ แต่ต้องระบุหน่วย ช่วงเวลา และฐานข้อมูลให้ชัด
อย่าใช้กราฟแท่งกับเรื่องที่ไม่มีตัวเลข เพียงเพราะชอบสไตล์ Dashboard และอย่าใช้ไอคอนน่ารักแทนข้อมูลที่คนดูจำเป็นต้องอ่านจริง ๆ
ถ้าไม่แน่ใจว่าจะใช้ภาพแบบไหน ลองอธิบายเรื่องด้วยปากเปล่าก่อน ถ้าต้องพูดว่า “ข้อแรก ข้อสอง ข้อสาม” นั่นอาจเป็นงานแสดงขั้นตอน ถ้าต้องพูดว่า “แบบนี้ดีกว่าในกรณีนี้ แต่แบบนั้นเหมาะกับอีกกรณี” อาจเป็นตารางเปรียบเทียบมากกว่า
ภาพสวยบนจอใหญ่ อาจอ่านไม่ออกเมื่ออยู่ในฟีด
ปัญหาคลาสสิกคือออกแบบที่ขนาดเต็ม แล้วทุกคนซูมดูในโปรแกรมจนเห็นชัด พอเอาไปโพสต์จริง ตัวหนังสือกลับเล็กกว่าคำบรรยายใต้โพสต์เสียอีก
ลองย่อภาพให้เท่ากับขนาดที่คนดูเห็นบนมือถือโดยไม่ขยาย ถ้าอ่านหัวข้อไม่ได้ หรือแยกสีเส้นกราฟไม่ออก ให้ลดข้อความ เพิ่มระยะห่าง หรือแยกภาพใหม่ ไม่ใช่แค่เพิ่มความคมชัดตอน Export
สำหรับข้อมูลสำคัญบนเว็บไซต์ ควรมีคำอธิบายในเนื้อหาหน้าด้วย เพราะภาพที่มีกราฟ ตาราง หรือข้อมูลหลายส่วนอาจต้องใช้ข้อความอธิบายมากกว่าคำบรรยายสั้น ๆ หนึ่งบรรทัด แนวทางของ W3C WAI แนะนำให้มีข้อความทดแทนที่สื่อข้อมูลสำคัญของภาพและคำอธิบายเพิ่มเติมสำหรับภาพซับซ้อน
ก่อนส่งงาน ตรวจข้อมูลกับตรวจความสวยแยกกัน
คนอนุมัติสีและเลย์เอาต์ไม่จำเป็นต้องเป็นคนยืนยันข้อเท็จจริงทุกตัว แต่ต้องมีเจ้าของข้อมูลที่รับผิดชอบตรวจข้อความ ราคา ตัวเลข ชื่อรุ่น และเงื่อนไขให้เรียบร้อยก่อนเผยแพร่
อีกคนจึงค่อยตรวจเรื่องการเว้นขอบ ความสมดุล ขนาดตัวอักษร และคุณภาพไฟล์ วิธีนี้ช่วยลดปัญหาแก้ภาพกันหลายรอบเพราะเพิ่งพบว่าตัวเลขผิดหลังออกแบบเสร็จ
งานจริงอาจมีสองรอบตรวจ: รอบแรกดูว่าข้อมูลเล่าถูกเรื่องไหม รอบสุดท้ายดูว่าคนอ่านเข้าใจไหม ต่างจากการถามรวบยอดว่า “สวยหรือยัง” ซึ่งแต่ละคนมักตอบไม่เหมือนกัน
ส่งบรีฟให้ชัดหนึ่งหน้าก่อนเปิดโปรแกรมออกแบบ
ถ้าจะเริ่มวันนี้ ไม่จำเป็นต้องทำเอกสารยาว เลือกเรื่องหนึ่งเรื่อง เขียนคำถามลูกค้าหนึ่งข้อ ระบุคำตอบสำคัญสามประเด็น แนบที่มาของข้อมูล และบอกขนาดภาพที่ต้องใช้ จากนั้นให้คนตรวจข้อมูลยืนยันก่อนเริ่มออกแบบ
เมื่อโจทย์ชัด งานภาพก็ไม่ต้องแบกทุกข้อความของบริษัทไว้ในรูปเดียว หากต้องการให้ทีมช่วยเปลี่ยนข้อมูลที่มีให้เป็นภาพสำหรับสื่อสารธุรกิจ สามารถดูรายละเอียด บริการออกแบบ Infographic ของ Social Plus System แล้วเตรียมข้อมูลตามรายการนี้ไปคุยกันได้
คำถามที่พบบ่อย
แหล่งข้อมูล
แหล่งอ้างอิง
- W3C Web Accessibility Initiative. Images Tutorial: การใช้ภาพบนเว็บไซต์ให้เข้าถึงได้ (ม.ป.ป.). เข้าถึงวันที่ 2026-10-27.
- W3C Web Accessibility Initiative. Complex Images: แนวทางอธิบายกราฟและภาพข้อมูลซับซ้อน (ม.ป.ป.). เข้าถึงวันที่ 2026-10-27.
- W3C Web Accessibility Initiative. Images of Text: ข้อควรพิจารณาเมื่อใช้ข้อความในภาพ (ม.ป.ป.). เข้าถึงวันที่ 2026-10-27.
ดูขอบเขตบริการที่เกี่ยวข้อง วิธีทำงาน และข้อมูลที่ควรเตรียมก่อนให้ทีมประเมิน
ดูบริการที่เกี่ยวข้องมีโจทย์คล้ายบทความนี้? ส่งข้อมูลให้ทีมช่วยดูได้
กรอกเฉพาะข้อมูลจำเป็น ทีมจะใช้เพื่อประเมินขอบเขตเบื้องต้นและติดต่อกลับ โดยระบบจะบันทึกว่าคุณมาจากบทความนี้
