Privacy UX: การแจ้งเตือนและการขออนุญาตที่ดีขึ้น
เผยแพร่แล้ว: 2022-03-10- ส่วนที่ 1: ข้อกังวลเกี่ยวกับความเป็นส่วนตัวและความเป็นส่วนตัวในเว็บฟอร์ม
- ส่วนที่ 2: ประสบการณ์การยินยอมคุกกี้ที่ดีขึ้น
- ส่วนที่ 3: การแจ้งเตือน UX และการขออนุญาตที่ดีขึ้น
- ส่วนที่ 4: กรอบการออกแบบที่คำนึงถึงความเป็นส่วนตัว
ลองนึกภาพว่าคุณมาสายสำหรับการประชุมที่คุณไม่อยากมาสายจริงๆ คุณรีบสวมรองเท้าและเสื้อโค้ทและหยิบกุญแจประตูและจับที่จับประตู - เพียงเพื่อออกไปทันเวลา ในขณะที่คุณก้าวลงบันได คุณล้วงกระเป๋าและดึงโทรศัพท์มือถือของคุณออกมาเพื่อตรวจสอบตารางเวลารถไฟใต้ดินหรือสั่งรถแท็กซี่
การเหลือบมองหน้าจอเพียงชั่วครู่ก็เพียงพอแล้วที่จะทำให้คุณรู้สึกเหนื่อย: คุณรู้ว่าคุณลืมชาร์จโทรศัพท์ในชั่วข้ามคืน และมันก็ใช้งานได้อย่างภาคภูมิใจเมื่อชาร์จแบตเตอรี่ 2% ที่เหลืออยู่ ในขณะที่คุณวิ่งไปตามถนนที่เต็มไปด้วยความหวังและศรัทธา คุณจะหรี่ความสว่างของหน้าจอและตามล่าหาไอคอนแอพที่เหมาะสมทั่วทั้งหน้าจอหลัก แน่นอน ในขณะนั้นเอง การแจ้งเตือนจำนวนมากจะลดหลั่นลงมาบนหน้าจอของคุณ เพื่อเรียกร้องความสนใจอย่างไม่มีการแบ่งแยกจากคุณสำหรับผู้ติดตามใหม่ การอัปเดต การเตือนความจำ และข้อความ
มีโอกาสสูงที่คุณจะรู้ดีว่าความรู้สึกนี้เป็นอย่างไร คุณมีแนวโน้มที่จะดำเนินการกับการแจ้งเตือนแบบเรียงซ้อนในสถานการณ์นั้นมากน้อยเพียงใด และ มีแนวโน้มมากเพียงใดที่คุณจะปิดการแจ้งเตือนทั้งหมด เมื่อมีการเตือนความจำอีกไม่กี่นาทีต่อมา เมื่อคุณพลาดการเชื่อมต่อ นั่นเป็นหนึ่งในสถานการณ์เหล่านั้นเมื่อการแจ้งเตือนเข้ามาขวางทางมากที่สุดเท่าที่จะเป็นไปได้ และแม้ว่าผู้ใช้ที่ออกแบบมาอย่างประณีตและพิกเซลอันล้ำค่าที่ได้รับการขัดเกลาแล้วก็ตาม
ด้วยแอปพลิเคชันและบริการจำนวนมาก ผู้คนและเครื่องจักร และแชทบอทต่อสู้เพื่อความสนใจของเรา การ จดจ่ออยู่กับความหรูหราที่จำเป็นต้องได้รับรสชาติและการปกป้อง จึงไม่น่าแปลกใจที่การแจ้งเตือนจะไม่ได้รับชื่อเสียงที่ดีในทุกวันนี้ ยิ่งไปกว่านั้น พวกเขามักจะรู้สึกไม่ตรงประเด็นและบงการเช่นกัน
“มักปรากฏขึ้นในบางครั้งที่มีความเกี่ยวข้องน้อยที่สุด และทำให้เกิดความรู้สึกเร่งด่วนที่ผิดพลาด ทำให้โฟกัสลดลง และก่อให้เกิดความคับข้องใจ”
— อเล็กซ์ Potrivaev, อินเตอร์คอม
สิ่งนี้ใช้สำหรับหน้าต่างลอยบนหน้าจอหลักมากเท่ากับจำนวนที่ยังไม่ได้อ่านอันยิ่งใหญ่ในแถบเครื่องมือ สิ่งนี้เป็นจริงเช่นกันสำหรับข้อความทางการตลาดที่ปิดบังเป็นการแจ้งเตือน เช่นเดียวกับการอัปเดตทางสังคมที่แยกย่อยเป็นข้อความเล็กๆ จำนวนมากเพื่อดึงดูดความสนใจไปที่บริการอย่างถาวร
การแจ้งเตือนทั้งหมดเหล่านี้ ต้องการความสนใจในทันทีและรู้สึกว่ามีการบุกรุกอย่างไม่น่าเชื่อ โดยเล่นกับความปรารถนาของเราที่จะไม่พลาดและติดต่อกับกลุ่มโซเชียลของเรา อันที่จริงแล้ว มันทำลายความเป็นส่วนตัวในแบบที่ไม่มีรูปแบบมืดๆ ทำได้ — โดยการเรียกร้องและเรียกร้องความสนใจอย่างไม่มีเงื่อนไข ไม่ว่าผู้ใช้จะทำอะไรอยู่ก็ตาม

อย่างไรก็ตาม ไม่ใช่ความผิดของการแจ้งเตือนที่พวกเขารู้สึกว่าเป็นการบุกรุก คือการที่เราออกแบบให้พวกมันมักจะเข้ามาขวางทาง ผู้ใช้ไม่ต้องการที่จะพลาดการแจ้งเตือนที่สำคัญและพลาดข้อความที่ทันเวลาหรือการขายที่จำกัด แต่พวกเขาก็ไม่ต้องการที่จะรู้สึกถูกรบกวนด้วยการอัปเดตที่มีเสียงดังอย่างไม่สิ้นสุดเช่นกัน หากสิ่งหลังเกิดขึ้นบ่อยเกินไป ผู้ใช้จะปิดการแจ้งเตือนทั้งหมด ซึ่งมักจะมี รสขมที่ค้างอยู่ในคอต่อแอป และแบรนด์เนื่องจาก "การขอร้องอย่างสิ้นหวัง" ตามที่ผู้ใช้รายหนึ่งกล่าว ผู้กระทำผิดเพียงคนเดียวสามารถทำลายมันให้กับทุกคนได้ และแม้ว่าข้อเท็จจริงที่ว่าไม่มีการแจ้งเตือนก็เหมือนกับคนอื่น
ใบหน้ามากมายของการแจ้งเตือน
การแจ้งเตือนเป็นการรบกวนโดยธรรมชาติ พวกเขาดึงความสนใจของผู้ใช้ไปยังเหตุการณ์สำคัญ (ที่อาจเป็นไปได้) ที่พวกเขาไม่ทราบหรืออาจต้องการได้รับการเตือน ด้วยเหตุนี้ พวกเขาจึงมีประโยชน์และมีความเกี่ยวข้องอย่างมาก ให้ความช่วยเหลือ และนำโครงสร้างและระเบียบมาสู่กิจวัตรประจำวัน จนกว่าพวกเขาจะไม่ได้
โดยทั่วไป การแจ้งเตือนอาจเป็นการให้ ข้อมูล ก็ได้ (การเตือนปฏิทิน การแจ้งเตือนล่าช้า ผลการเลือกตั้งในคืน) หรือ สนับสนุนการดำเนินการ (อนุมัติการชำระเงิน ติดตั้งการอัปเดต ยืนยันคำขอเป็นเพื่อน) พวกเขาสามารถสตรีมจากแหล่งต่าง ๆ และสามารถมีผลกระทบต่าง ๆ :
- การ แจ้งเตือน UI จะปรากฏเป็นการ์ดที่ละเอียดอ่อนใน UI เมื่อผู้ใช้โต้ตอบกับอินเทอร์เฟซบนเว็บ ดังนั้นจึงเป็นที่ยอมรับในวงกว้างและมีการบุกรุกน้อยกว่าคู่หูของพวกเขา
- การแจ้งเตือนแบบพุชในเบราว์เซอร์ จะยกเลิกได้ยากกว่า และดึงดูดความสนใจมาที่ตัวเองแม้ว่าผู้ใช้จะไม่ได้เข้าถึง UI ก็ตาม
- การแจ้งเตือนในแอพ ใช้งานได้ภายในแอพเดสก์ท็อปและมือถือ และอาจดูเรียบง่ายเหมือนการแจ้งเตือน UI แต่สามารถมีบทบาทสำคัญในการส่งข้อความไปยังหน้าจอหลักหรือศูนย์การแจ้งเตือน
- การ แจ้งเตือนของระบบปฏิบัติการ เช่น การอัปเดตซอฟต์แวร์หรือการเปลี่ยนแปลงของผู้ให้บริการอุปกรณ์เคลื่อนที่ยังได้รับการผสมผสาน มักปรากฏขึ้นพร้อมกับบันทึกย่อ การอัปเดตปฏิทิน และทุกสิ่งในระหว่างนั้น
- สุดท้าย การ แจ้งเตือนสามารถหาทาง เข้าอีเมล, SMS และแอปข้อความโซเชียล ที่มาจากแชทบอท ระบบการแนะนำ และมนุษย์จริงๆ
คุณสามารถดูได้ว่าการแจ้งเตือน เมื่อพิจารณาจากรสชาติและแหล่งที่มาทั้งหมดแล้ว อาจกลายเป็นเรื่องล้นหลามในบางจุดได้อย่างไร ไม่ใช่ว่าเราให้ความสนใจเท่ากันทุกประการกับการแจ้งเตือนทุกครั้งที่เราได้รับ สำหรับผู้ใช้ส่วนใหญ่ อาจต้องใช้เวลา หลายสัปดาห์ กว่าจะติดตั้งการอัปเดตซอฟต์แวร์ในที่สุดโดยแจ้งจากการแจ้งเตือนของระบบปฏิบัติการ ในขณะที่โดยปกติแล้วจะใช้เวลาไม่เกินสองสาม ชั่วโมง ในการยืนยันหรือปฏิเสธคำขอ LinkedIn หรือ Facebook ใหม่
ไม่ใช่ว่าทุกการแจ้งเตือนจะเท่ากัน และระดับความสนใจที่ผู้ใช้มอบให้จะขึ้นอยู่กับลักษณะของการแจ้งเตือน หรือโดยเฉพาะอย่างยิ่ง การแจ้งเตือนจะถูกทริกเกอร์อย่างไรและเมื่อใด
ในบทความของเขาเรื่อง “การวิเคราะห์ที่สำคัญของระบบการแจ้งเตือน” Shankar Balasubramanian ได้ทำการวิจัยที่น่าทึ่งโดยแยกย่อยการแจ้งเตือนออกเป็นสองสามกลุ่ม:
การแจ้งเตือนเหตุการณ์เรียก | อัพเดทข่าวสาร คำแนะนำ สถานะการเปลี่ยนแปลง |
การแจ้งเตือนที่เรียกโดยระบบปฏิบัติการ | แบตเตอรี่ต่ำ การอัปเดตซอฟต์แวร์ หรือการแจ้งเตือนฉุกเฉิน |
การแจ้งเตือนที่เรียกตนเอง | เตือนความจำหรือนาฬิกาปลุก |
การแจ้งเตือนข้อความแบบหลายต่อหนึ่ง | ข้อความกลุ่มจาก Slack หรือ WhatsApp |
การแจ้งเตือนข้อความแบบตัวต่อตัว | อีเมลส่วนตัวจากเพื่อนหรือญาติ |
เราไม่สามารถสรุปได้ว่าทริกเกอร์กลุ่มหนึ่งมีประสิทธิภาพมากกว่ากลุ่มอื่นเสมอ แต่การแจ้งเตือนบางรายการจากทุกกลุ่มมักจะดึงดูดความสนใจได้ดีกว่ากลุ่มอื่นๆ:
- ผู้คนใส่ใจมากขึ้น เกี่ยวกับข้อความใหม่จากเพื่อนสนิทและญาติ การแจ้งเตือนจากเพื่อนร่วมงานที่เลือกในช่วงเวลาทำงาน ธุรกรรมธนาคารและการแจ้งเตือนที่สำคัญ การแจ้งเตือนในปฏิทิน กิจกรรมตามกำหนดการ การเตือน และการยืนยันหรือการประกาศที่ดำเนินการและรอดำเนินการใดๆ
- ผู้คนไม่ค่อยใส่ใจ ในการอัปเดตข่าวสาร การอัปเดตฟีดโซเชียล ประกาศ คุณลักษณะใหม่ รายงานข้อขัดข้อง การแจ้งเตือนทางเว็บ โดยทั่วไปข้อความแสดงข้อมูลและอัตโนมัติ
ไม่น่าแปลกใจที่ผู้ใช้มักจะเข้าร่วมการแจ้งเตือนแบตเตอรี่เหลือน้อยหรือการยืนยันการชำระเงินทันที นอกจากนี้ การแจ้งเตือนปฏิทิน การอัปเดตความคืบหน้า (เช่น ETA การจัดส่งพัสดุภัณฑ์) และข้อความแบบตัวต่อตัวมีความสำคัญมากกว่าการแจ้งเตือนอื่นๆ อันที่จริง ในทุกการสนทนาที่เรามีกับผู้ใช้ ข้อความจากมนุษย์อีกคนมีค่า มากกว่าการแจ้งเตือนอัตโนมัติใดๆ ลำดับความสำคัญอาจเปลี่ยนไปเล็กน้อยแน่นอน ถ้าผู้ใช้ รอ การแจ้งเตือนอย่างใจร้อน แต่มีเพียงไม่กี่คนเท่านั้นที่จะทิ้งทุกอย่างไว้ข้างหลังด้วยความเร่งรีบอย่างยิ่งที่จะตรวจสอบอันดับที่ 77 ในรูปภาพของพวกเขา
ดังนั้นการแจ้งเตือนจึงอาจแตกต่างกัน และการแจ้งเตือนที่แตกต่างกันจึงแตกต่างกัน อย่างไรก็ตาม ยิ่งการแจ้งเตือนที่เป็นส่วนตัว มีความเกี่ยวข้อง และทันเวลามากขึ้นเท่าใด การมีส่วนร่วมที่เราควรคาดหวังก็จะยิ่งสูงขึ้น แต่การออกแบบการแจ้งเตือนทั้งหมดมีความหมายอย่างไร และเราจะทำให้การแจ้งเตือนเหล่านี้รบกวนน้อยลงและมีประสิทธิภาพมากขึ้นได้อย่างไร
อย่าพึ่งพาค่าเริ่มต้นทั่วไป: ตั้งค่าโหมดการแจ้งเตือน
มักมีเหตุผลที่ดีว่าทำไมลูกค้าจึงเลือกสมัครใช้บริการ มีคนไม่มากที่ตื่นขึ้นมาในตอนเช้าโดยหวังว่าจะสร้างบัญชีใหม่ในวันนั้น อันที่จริง พวกเขาอาจรู้สึกว่าบริการของคุณอาจช่วยพวกเขาในงานประจำวัน หรือสามารถปรับปรุงเวิร์กโฟลว์ได้ หวังว่าพวกเขาจะไม่ต้องการการแจ้งเตือนเพื่อทำความเข้าใจวิธีการทำงานของบริการ แต่อาจจำเป็นต้องรับการแจ้งเตือนเพื่อทำความเข้าใจคุณค่าของบริการที่มีให้
บางทีพวกเขาอาจได้รับข้อความสำคัญจากผู้ที่อาจเป็นนายจ้าง หรือบางทีอาจมีโปรไฟล์การนัดหมายที่คู่ควรแก่การดู พวกเขาอาจไม่ต้องการพลาดข้อความเหล่านี้เพียงเพราะพวกเขาลืมเช็คอินบริการมาระยะหนึ่งแล้ว ในฐานะนักออกแบบ เราจำเป็นต้อง โรยการแจ้งเตือนเพียงเล็กน้อยลงในมิกซ์ เพื่อให้ลูกค้ามีแรงจูงใจ ในขณะที่นำเสนอเฉพาะตัวชี้ที่เกี่ยวข้องและดำเนินการได้สำหรับพวกเขา
น่าเสียดายที่บริการส่วนใหญ่นั้นไม่ใช่เรื่องแปลกที่จะสมัครใช้งาน เพียงไม่กี่วินาทีต่อมาก็พบว่ากล่องจดหมายเต็มไปด้วยข้อความทุกประเภท (ส่วนใหญ่เป็นข้อมูลล้วนๆ) มักจะส่งทันทีหลังจากนั้น และแทบจะดำเนินการไม่ได้ การแจ้งเตือนทางอีเมลโดยเฉพาะอย่างยิ่งมักจะเปิดอยู่โดยค่าเริ่มต้น โดยได้รับความยินยอมจากผู้ใช้โดยนัยโดยยอมรับข้อกำหนดและเงื่อนไขที่มีความยาวและจัดการไม่ได้ ไม่มีใครชอบที่จะถูกโจมตีด้วยกระแสข้อความที่ไม่พึงประสงค์ และนั่นก็เป็นความจริงสำหรับอีเมลขยะพอๆ กับการแจ้งเตือนที่ไม่ต้องการ
แทนที่จะตั้งค่าความถี่การแจ้งเตือนเริ่มต้นสำหรับลูกค้าทั้งหมดตามค่าเริ่มต้น เราสามารถเริ่มส่งการแจ้งเตือนที่ได้รับการดูแลจัดการเพียงไม่กี่รายการไม่บ่อยนัก ในขณะที่ลูกค้าใช้อินเทอร์เฟซต่อไป เราอาจขอให้พวกเขาตัดสินใจเกี่ยวกับประเภทของการแจ้งเตือนที่ต้องการและความถี่ เช่นเดียวกับข้อความแจ้งความยินยอมคุกกี้: เราสามารถ ให้ตัวเลือกที่แนะนำที่กำหนดไว้ล่วงหน้า ด้วย "โหมดสงบ" (ความถี่ต่ำ) "โหมดปกติ" (ความถี่ปานกลาง) และ "โหมดผู้ใช้ระดับสูง" (ความถี่สูง)
แม้ว่าเราจะละเอียดกว่านี้ ตัวอย่างเช่น Basecamp ได้แนะนำตัวเลือก "Always On" และ "Work Can Wait" เป็นส่วนหนึ่งของประสบการณ์การเริ่มต้นใช้งาน ดังนั้นลูกค้าใหม่สามารถเลือกได้ว่าต้องการรับการแจ้งเตือนเมื่อเกิดขึ้น (เมื่อใดก็ได้) หรือเลือกเวลาเฉพาะ ช่วงและวันที่สามารถส่งการแจ้งเตือนได้ หรือในทางกลับกัน เราอาจถามผู้ใช้เมื่อไม่ต้องการถูกรบกวน และระงับการแจ้งเตือนในขณะนั้น ไม่ใช่ลูกค้าทุกคนที่ต้องการรับการแจ้งเตือนเกี่ยวกับงานนอกเวลาทำการหรือวันหยุดสุดสัปดาห์ แม้ว่าเพื่อนร่วมงานของพวกเขาอาจจะทำงานเกินชั่วโมงในคืนวันเสาร์ที่อยู่อีกฟากหนึ่งของโลกก็ตาม

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

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

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

บางครั้งก็ยากที่จะระงับการแจ้งเตือน เนื่องจากอาจมีความสำคัญต่อกิจกรรมปัจจุบันของผู้ใช้ หากผู้ใช้ขับรถโดยทำตามคำแนะนำในแอพเนวิเกเตอร์ คุณอาจต้องให้การแจ้งเตือนที่สม่ำเสมอและสุภาพกว่านี้เกี่ยวกับการเปลี่ยนเส้นทางที่แนะนำอันเนื่องมาจากอุบัติเหตุบนท้องถนน ในกรณีนั้น เช่นเดียวกับการแจ้งเตือนที่สำคัญอื่นๆ เราสามารถแสดงปุ่มลอย "มีการอัปเดตใหม่ รีเฟรช” มีการบุกรุกน้อยกว่าการแจ้งเตือนที่บล็อกการเข้าถึงเนื้อหา แต่มีประสิทธิภาพในการระบุว่าหน้าหรือสถานะของหน้าอาจล้าสมัยและมีข้อมูลใหม่
ที่จริงแล้ว แทนที่จะส่งการแจ้งเตือนตามเวลาเริ่มต้นที่เฉพาะเจาะจง แม้ว่าจะอิงตามพฤติกรรมในอดีตของผู้ใช้ คุณสามารถสำรวจอีกด้านหนึ่งของเหรียญและ แตะช่วงเวลาที่มีความสุขและประสบความสำเร็จแทน บริการโอนเงิน TransferWise จะแสดงการแจ้งเตือนเมื่อลูกค้าได้รับการชำระเงิน — และไม่ใช่ช่วงเวลาที่เหมาะสมในการขอรีวิวแอพใน App Store ใช่ไหม เราสามารถติดตามเหตุการณ์สำคัญและแจ้งให้ผู้ใช้ทราบเกี่ยวกับคุณลักษณะขั้นสูงเมื่อถึงแล้ว ทันเวลา ตามที่ Luke Wroblewski เรียกพวกเขา
ลดความถี่ด้วยการจัดกลุ่มการแจ้งเตือน
ไม่มีกฎทองสำหรับการแจ้งเตือนในปริมาณที่เหมาะสมในวันที่กำหนด เช่นเดียวกับการแจ้งเตือนแต่ละรายการที่แตกต่างกัน ดังนั้นการตั้งค่าและแรงจูงใจของลูกค้าทุกคนก็เช่นกัน เพื่อรักษาการมีส่วนร่วมของผู้ใช้ คุณอาจต้องค่อยๆ ปล่อยบล็อกการแจ้งเตือนขึ้นอยู่กับการเข้าถึงหรือความชอบของลูกค้า นั่นคือที่มาของ การจัดกลุ่มทีละน้อย ตามที่อธิบายไว้ในบทความ "การออกแบบการแจ้งเตือนอัจฉริยะ" โดย Alex Potrivaev นักออกแบบผลิตภัณฑ์ที่ Intercom
ความคิดนั้นง่าย หากคุณรู้ว่าลูกค้าของคุณได้รับการตอบสนองโดยเฉลี่ยน้อยกว่า 5 ครั้งต่อโพสต์ อาจเป็นความคิดที่ดีที่จะให้การแจ้งเตือนที่ไม่ซ้ำกันสำหรับแต่ละโพสต์ คุณยังทริกเกอร์การแจ้งเตือนได้หากข้อความมาจากเหตุการณ์สำคัญ เช่น ข้อความจากเพื่อนสนิท ครอบครัว หรือผู้มีอิทธิพล นอกจากนี้ เนื่องจากเราทราบดีว่าการแจ้งเตือนที่เกิดจากการกระทำจากบุคคลอื่นนั้นมีค่ามากกว่าการแจ้งเตือนอัตโนมัติ จัดลำดับความสำคัญและเน้นที่การแจ้งเตือนส่วนบุคคลเป็นหลัก สำหรับลูกค้ารายนั้นโดยเฉพาะ
เมื่อปริมาณการแจ้งเตือนเพิ่มขึ้น เราสามารถเริ่มจัดกลุ่มการแจ้งเตือนและจัดทำสรุปย่อในเวลาที่เหมาะสม ตัวอย่างเช่น Facebook สรุปการแจ้งเตือนในกลุ่มที่ไม่ล่วงล้ำ โดยทุกบรรทัดเน้นเฉพาะเหตุการณ์ประเภทเดียว เช่น การตอบสนองต่อข้อความหนึ่ง ๆ (“Stoyan Stefanov และอีก 48 คนตอบสนองต่อโพสต์ของคุณ…”) ในทางกลับกัน LinkedIn ดูเหมือนว่าจะทริกเกอร์เกือบทุกเหตุการณ์ทีละรายการ (“Stoyan Stefanov แสดงความคิดเห็นในโพสต์ของคุณ”) ดังนั้นจึงสร้างมลพิษให้กับกระแสการแจ้งเตือนและทำให้ยากต่อการสแกนและใช้งาน

แน่นอน ตามประวัติของผู้ใช้ เราสามารถปรับแต่งได้มากกว่าแค่การจัดกลุ่มการแจ้งเตือน เมื่อเราทราบวิธีที่ผู้ใช้ตอบสนองต่อการกดชอบรูปภาพใหม่ ไม่ว่าพวกเขาจะเหลือบมองภาพเหล่านั้นชั่วครู่หรือเจาะลึกลงไปในการแจ้งเตือนแต่ละครั้ง เราสามารถให้การแจ้งเตือนที่ดีขึ้นในครั้งต่อไป ตามที่อเล็กซ์สรุป:
“โดยอิงจากวิธีที่คุณโต้ตอบกับเนื้อหา อาจมีการใช้ถ้อยคำและตัวเลือกโครงสร้างที่ดีขึ้น และขึ้นอยู่กับพฤติกรรมเริ่มต้น คุณอาจเห็นการแจ้งเตือนที่มีโครงสร้างแตกต่างกัน”
แน่นอนว่าสิ่งนี้ต้องการการวนรอบความคิดเห็นอย่างต่อเนื่อง
อนุญาตให้ผู้ใช้ปิดเสียงเตือนชั่วคราวหรือหยุดการแจ้งเตือนชั่วคราว
แทบไม่มีบริษัทใดที่จะละเลยคุณค่าของข้อมูลเกี่ยวกับลูกค้าของตน อันที่จริง เราสามารถได้รับข้อมูลเชิงลึกอันมีค่าในระยะยาวโดยการแนะนำ ลูป การป้อนกลับ กล่าวคือ นำเสนอตัวเลือกแก่ลูกค้าอย่างต่อเนื่องในการ "ดูเพิ่มเติม" หรือ "ดูน้อยลง" สำหรับการแจ้งเตือนประเภทใดประเภทหนึ่งโดยเฉพาะ แต่เช่นเดียวกับที่เรามักจะมองว่าความพิการเป็นเงื่อนไขเปิด/ปิด (คุณอาจมีความทุพพลภาพหรือไม่ก็ตาม) เรามักจะรู้สึกว่าเราสามารถคาดการณ์พฤติกรรมของผู้ใช้ได้อย่างแม่นยำโดยพิจารณาจากพฤติกรรมในอดีตของพวกเขาเพียงอย่างเดียว
อย่างไรก็ตาม ความเป็นจริงมักไม่ค่อยเป็นภาพขาวดำ ผู้ใช้ของเราอาจถูกขัดขวางชั่วคราวขณะอุ้มทารกไว้ในอ้อมแขนข้างเดียว หรือเนื่องจากอุบัติเหตุที่ไม่พึงปรารถนาเมื่อเร็วๆ นี้ และสภาพที่พวกเขาพบว่าตนเองอาจผันผวนในลักษณะเดียวกัน การดำเนินการด่วน เช่น การงีบหลับเพื่อตอบสนองต่อการแจ้งเตือนที่เข้ามาสามารถช่วยบรรเทาปัญหาได้ชั่วคราว
บริบทของผู้ใช้เปลี่ยนแปลงอย่างต่อเนื่อง หากคุณสังเกตเห็นอัตราการมีส่วนร่วมลดลงผิดปกติ หรือหากคุณคาดว่าจะมีการแจ้งเตือนจำนวนมากผิดปกติ (อาจเป็นวันเกิด วันครบรอบแต่งงาน หรือคืนวันเลือกตั้ง) ให้พิจารณาตัวเลือกในการปิดเสียง เลื่อนการแจ้งเตือน หรือหยุดการแจ้งเตือนชั่วคราว อาจจะเป็นอีก 24 ชั่วโมงข้างหน้า
สิ่งนี้อาจขัดกับสัญชาตญาณของเราอย่างมาก เนื่องจากเราอาจต้องการดึงดูดลูกค้าอีกครั้งหากพวกเขาเงียบไปในทันที หรือเราอาจต้องการเพิ่มการมีส่วนร่วมสูงสุดเมื่อมีเหตุการณ์สำคัญเกิดขึ้น อย่างไรก็ตามการกดด้วยความถี่ของการแจ้งเตือนนั้นอันตรายเกินไปเกือบตลอดเวลา ง่ายที่จะไปถึงจุดที่การแจ้งเตือนที่ดูเหมือนไม่มีอันตรายจะคัดท้ายลูกค้าออกไป แม้จะในระยะยาวก็ตาม อาจมีเหตุผลที่ดีว่าทำไมผู้ใช้ถึงไม่เข้าใช้งานหรือไม่ต้องการมีการใช้งานมาระยะหนึ่งแล้ว และบ่อยครั้งกว่านั้น ก็ไม่มีส่วนเกี่ยวข้องกับบริการเลย
อีกทางเลือกหนึ่งคือแนะนำให้เปลี่ยนสื่อที่ใช้เพื่อรับการแจ้งเตือน ผู้ใช้มักจะเชื่อมโยงระดับความเร่งด่วนที่แตกต่างกันกับช่องทางการสื่อสารที่แตกต่างกัน การแจ้งเตือนในแอป การแจ้งเตือนแบบพุช และข้อความตัวอักษรถือเป็นการล่วงล้ำมากกว่าอีเมลเก่า ดังนั้นเมื่อความถี่เกินเกณฑ์ที่กำหนด คุณอาจต้องการกระตุ้นให้ผู้ใช้เปลี่ยนจากการแจ้งเตือนแบบพุชเป็นอีเมลสรุปรายวัน

ตั้งค่าเกณฑ์และสร้างแผนภูมิการตัดสินใจการแจ้งเตือน
เกณฑ์กำหนดนั้นไม่ง่ายที่จะตั้งค่าอย่างถูกต้อง เหตุการณ์สำคัญควรทริกเกอร์การแจ้งเตือนทันทีเพื่อให้ได้รับทันเวลา เหตุการณ์สำคัญน้อยกว่าอาจรอได้ แต่อาจเป็นประโยชน์ในการดึงความสนใจของลูกค้ามาที่บริการ การแจ้งเตือนที่อาจไม่เกี่ยวข้องจะต้องถูกกรองออกอย่างไม่ลดละเพื่อให้เวลาและพื้นที่สำหรับการแจ้งเตือนที่สำคัญได้รับการดูแลและให้คุณค่า
โดยทั่วไป การแจ้งเตือนที่สั้นกว่า เช่น ข้อความจากเพื่อนและเพื่อนร่วมงาน เหมาะที่สุดสำหรับการแจ้งเตือน UI หากไม่เร่งด่วน หรือการแจ้งเตือนแบบพุชหากเป็น การแจ้งเตือนที่ยาวกว่านี้จะดีกว่าถ้าเป็นอีเมล — ไม่ว่ามันจะเป็นเรื่องเร่งด่วนหรือไม่ก็ตาม กฎทั่วไปนี้จะแตกต่างกันไปในแต่ละบริการ ดังนั้นคุณสามารถสร้าง แผนภูมิการตัดสินใจการแจ้งเตือน เพื่อติดตามว่าสื่อใดทำงานได้ดีที่สุดสำหรับการแจ้งเตือนบางประเภทโดยพิจารณาจากความเร่งด่วน ความยาว และความถี่ นอกจากนี้ คุณสามารถกำหนดขีดจำกัดและทริกเกอร์พร้อมท์สำหรับการงีบหลับหรือปรับการตั้งค่าหากถึงเกณฑ์
ทำให้การเลือกเข้าร่วมและการเลือกไม่ใช้ชัดเจน
ทุกวันนี้ เกือบได้รับการคาดหวังแล้วว่าบริการจะถึงขีดสุด ซึ่งทำให้ลูกค้าเลือกไม่รับการแจ้งเตือนอันยิ่งใหญ่ได้ยากอย่างน่าขัน ถ้อยคำที่คลุมเครือและป้ายกำกับที่คลุมเครือซึ่งซ่อนไว้อย่างชำนาญในมุมที่ห่างไกลของอินเทอร์เฟซนั้นไม่ใช่เรื่องแปลก ข้อควรพิจารณาในการออกแบบอื่นๆ เพียงเล็กน้อยอาจสร้างความเสียหายและสร้างความเสียหายให้กับแบรนด์ได้มากกว่า เมื่อผู้ใช้ปรับการตั้งค่าไม่ได้ง่ายๆ ผู้ใช้จะใช้ปืนใหญ่ ทำเครื่องหมายการแจ้งเตือนทางอีเมลว่าเป็นสแปม หรือการบล็อกการแจ้งเตือนในการตั้งค่าระบบปฏิบัติการหรือการตั้งค่าเบราว์เซอร์ สำหรับเว็บไซต์หรือแอป ไม่มีวิธีง่ายๆ ในการกู้คืนจากสิ่งนั้น ยกเว้นการขอสมัครรับข้อมูลอีกครั้ง
วิธีที่ง่ายกว่ามากคือให้การควบคุมการแจ้งเตือนที่ละเอียดมาก ซึ่งรวมถึงเนื้อหา รูปแบบ ความถี่ และเวลาห้ามรบกวน เราสามารถให้ตัวเลือกในการตอบกลับการแจ้งเตือนล่าสุดด้วย "อีเมลน้อยลง" หรือ "หยุด" เพื่อเปลี่ยนความถี่ ข้ามการลงชื่อเข้าใช้เว็บไซต์หรือการลงชื่อเข้าใช้แอป (Notion.so ทำเช่นนั้น) สำหรับแอพ ให้ระบุการตั้งค่าการแจ้งเตือนที่รวม อยู่ใน แอพแทนที่จะใช้การตั้งค่าดั้งเดิมของระบบปฏิบัติการ ที่นั่น คุณสามารถอธิบายสิ่งที่ผู้ใช้คาดหวังได้จากการแจ้งเตือนทุกประเภท แม้กระทั่งตัวอย่างว่าจะมีหน้าตาเป็นอย่างไร
ในทางปฏิบัติ ผู้ใช้จำนวนมากจะค้นหาการตั้งค่าการแจ้งเตือน ในทั้งสองที่หากต้องการ แต่ยิ่งใช้เวลานานกว่าจะพบการตั้งค่าที่คลุมเครือนั้น ผู้ป่วยก็จะยิ่งอดทนน้อยลง ในความเป็นจริง ผู้ใช้ส่วนใหญ่หาวิธีปิดการแจ้งเตือนในขณะที่พวกเขารู้สึกหงุดหงิดหรือรำคาญกับการแจ้งเตือนล่าสุด นั่นไม่ใช่สภาพจิตใจที่น่าพึงพอใจ และในฐานะบริการ คุณอาจไม่ต้องการขยายสภาพจิตใจนั้นโดยไม่จำเป็นด้วยค่าใช้จ่ายของความรู้สึกที่จู้จี้และสับสนจากลูกค้าที่ชำระเงินของคุณ
อย่าลืมสำรวจอีกด้านหนึ่งของเหรียญด้วย ระบุส่วนต่างๆ ของการเดินทางของผู้ใช้เมื่อผู้ใช้มีแนวโน้มที่จะสมัครรับการแจ้งเตือน ตัวอย่างเช่น เมื่อสั่งซื้อในร้านค้าออนไลน์สำเร็จแล้ว หรือยืนยันการจองเที่ยวบิน ในทั้งสองกรณี การแจ้งเตือนสามารถช่วยลูกค้าติดตามความล่าช้าหรือเรียกข้อมูลบอร์ดดิ้งพาสได้ทันเวลา นอกจากนี้ยังเป็นเวลาที่ดีที่จะแนะนำการแจ้งเตือนแบบเรียลไทม์ ซึ่งหมายถึงการขออนุญาตจากลูกค้าในการส่งการแจ้งเตือนเหล่านั้นก่อน และหัวข้อนั้นสมควรได้รับการสนทนาแยกต่างหาก
การขออนุญาต, ทางที่อ่อนน้อมถ่อมตน
บางเว็บไซต์ค่อนข้างเป็นตัวละครใช่ไหม? ตามใจตัวเอง ไม่สุภาพ และไม่น่าเป็นไปได้อย่างแท้จริงด้วย บ่อยแค่ไหนที่คุณสะดุดกับหน้าที่ดูเรียบง่ายและไม่โอ้อวดเพียงเพื่อรับการต้อนรับด้วยการอนุญาตที่น่าอัศจรรย์พร้อมทั้งขอร้องให้ส่งการแจ้งเตือนถึงคุณ? คุณยังไม่ได้อ่านคำแม้แต่คำเดียว แต่มันมีอยู่แล้วที่ขอคำมั่นสัญญาระยะยาวแล้ว และค่อนข้างเป็นการ รุกราน
ในแง่ของประสบการณ์ของผู้ใช้ การแสดงพรอมต์การอนุญาตขณะโหลดอาจเป็นวิธีที่ดีที่สุดในการสร้างความประทับใจแรกพบที่ไม่ดี และในกรณีส่วนใหญ่เป็นข้อผิดพลาดที่แก้ไขไม่ได้ ตั้งแต่เดือนมกราคม 2019 Chrome ได้เปลี่ยนตัวเลือกที่แสดงเมื่อมีการเรียกใช้พรอมต์ดั้งเดิม แม้ว่าผู้ใช้อาจปิดการแจ้งเตือนเพื่อโต้ตอบในภายหลังได้ แต่ตอนนี้พวกเขาต้องเลือกว่าต้องการจะ "ยอมรับ" หรือ "บล็อก" การแจ้งเตือน หลังส่งผลให้การแจ้งเตือนทางเว็บถูกบล็อกอย่างถาวรสำหรับทั้งไซต์ เว้นแต่ผู้ใช้จะหาทางผ่านการตั้งค่าเบราว์เซอร์ที่รกร้างว่างเปล่าเพื่อให้เข้าถึงได้ ไม่น่าแปลกใจที่ผู้ใช้ส่วนใหญ่บล็อกข้อความแจ้งดังกล่าวทันที โดยไม่ต้องอ่านเนื้อหาเลย
ในเชิงกลยุทธ์ เป็นการดีกว่าที่จะขออนุญาตเฉพาะเมื่อมีโอกาสสูงที่ผู้ใช้จะยอมรับจริงๆ เพื่อให้สิ่งนี้เกิดขึ้น เราต้องอธิบายให้ลูกค้าทราบว่าเหตุใดเราจึงจำเป็นต้องได้รับอนุญาตจากพวกเขาจริง ๆ และคุณค่าใดที่เราสามารถตอบแทนพวกเขาได้ ในทางปฏิบัติ กลยุทธ์นี้มักใช้ในรูปแบบของ 'รูปแบบคำขอซ้ำซ้อน' แทนที่จะขออนุญาตในทันที เรา รอสำหรับการมีส่วนร่วมจำนวนหนึ่งก่อน : บางทีการเข้าชมหน้าเว็บสองสามครั้ง การโต้ตอบ 2-3 ครั้ง ระยะเวลาที่ใช้บนไซต์ ในท้ายที่สุด เราสามารถเน้นย้ำถึงข้อเท็จจริงที่ว่าผู้ใช้สามารถสมัครรับการแจ้งเตือนและรู้ว่าการแจ้งเตือนเหล่านั้นอาจมีประโยชน์อย่างไร หรือเราต้องการการอนุญาตจากพวกเขาเพื่อผลการค้นหาที่ทราบตำแหน่งที่แม่นยำและแม่นยำยิ่งขึ้น บางครั้งบริบทของหน้าก็เพียงพอแล้ว เช่น เมื่ออินเทอร์เฟซต้องการขอตำแหน่งทางภูมิศาสตร์เมื่อผู้ใช้เข้าชมหน้าเครื่องระบุตำแหน่งร้าน
ในกรณีเหล่านี้ ปุ่มคำกระตุ้นการตัดสินใจที่เด่นชัดจะรอสักครู่เมื่อผู้ใช้ตอบรับการกระทำนั้นมากที่สุด หากผู้ใช้เลือกที่จะแตะที่ปุ่ม เราสามารถสันนิษฐานได้ว่าพวกเขามีแนวโน้มที่จะดำเนินการต่อไป ดังนั้น เมื่อคลิกแล้ว ปุ่มจะแจ้งคำขอสิทธิ์ดั้งเดิมที่เกิดขึ้นจริง
โดยพื้นฐานแล้ว เรากำลังแบ่งคำขออนุญาตออกเป็นสองคำขอ:
- คำขอที่สร้างขึ้นใน UI
- คำขอดั้งเดิมที่ระดับเบราว์เซอร์
ตามที่ Adam Lynch ได้บันทึกไว้ว่า หากผู้ใช้ยังคงเพิกถอนการอนุญาต อาจเป็นเพราะการแตะผิดหรือการคลิกผิดพลาดในพรอมต์ของเบราว์เซอร์ดั้งเดิม เราจำเป็นต้องแสดงหน้าทางเลือก ที่อธิบายวิธีเปิดใช้งานการอนุญาตด้วยตนเองผ่านการตั้งค่าเบราว์เซอร์ (หรือ ลิงก์ไปยังคำอธิบาย) เห็นได้ชัดว่า การแสดงคำขอการแจ้งเตือนไม่สมเหตุสมผลหากผู้ใช้ได้ให้สิทธิ์ไปแล้ว เราสามารถใช้ Permissions API เพื่อสอบถามสถานะของการอนุญาตใดๆ ผ่านอินเทอร์เฟซแบบอะซิงโครนัสเดียวและปรับ UI ตามนั้น
กลยุทธ์เดียวกันนี้สามารถนำไปใช้กับคำขออนุญาตประเภทใดก็ได้ เช่น การเข้าถึงตำแหน่งทางภูมิศาสตร์ กล้อง ไมโครโฟน บลูทูธ MIDI WebUSB และอื่นๆ การใช้ถ้อยคำและลักษณะที่ปรากฏของการแจ้งเตือน UI มีความสำคัญอย่างยิ่งในที่นี้ ดังนั้นจึง ควรติดตามอัตราส่วนการมีส่วนร่วมและการยอมรับสำหรับการอนุญาตหรือคุณลักษณะแต่ละรายการ และดำเนินการตามนั้น และนั่นนำเราไปสู่ราชาของพวกเขาทั้งหมด — ติดตามตัวชี้วัดที่สำคัญสำหรับการแจ้งเตือนของคุณ
ติดตามตัวชี้วัดสำหรับการแจ้งเตือน
โดยปกติจะไม่ส่งการแจ้งเตือนเพื่อแจ้งลูกค้าเกี่ยวกับเหตุการณ์ที่กำลังจะเกิดขึ้นหรือที่จะเกิดขึ้น การแจ้งเตือนที่ดีมีประโยชน์และนำไปดำเนินการได้ ซึ่งช่วยให้ทั้งลูกค้าและธุรกิจบรรลุเป้าหมาย สำหรับสิ่งนั้น เมตริกที่เกี่ยวข้องจะต้องถูกค้นพบและกำหนดก่อน
อย่างน้อยที่สุด เราอาจจำเป็นต้องทราบว่าการแจ้งเตือนที่เราส่งมีความเกี่ยวข้องตั้งแต่แรกหรือไม่
- ถ้อยคำ รูปแบบ และความถี่ของการแจ้งเตือนผลักดันการดำเนินการที่เราตั้งเป้าไว้ (ไม่ว่าจะเป็นการแบ่งปันทางสังคม เวลาที่ใช้บนไซต์ หรือการซื้อ) หรือไม่
- การแจ้งเตือนประเภทใดมีความสำคัญมากกว่าแบบอื่นๆ
- การแจ้งเตือนนำผู้ใช้กลับมาที่แอปพลิเคชันจริงหรือไม่
- เวลาผ่านไปนานเท่าใดระหว่างการส่งการแจ้งเตือนและการกลับมาที่ไซต์หรือแอปของผู้ใช้
- ใช้เวลาโดยเฉลี่ยเท่าใดระหว่างการแจ้งเตือนการคลิกผ่านและผู้ใช้ที่ออกจากไซต์

ทดลองการใช้ถ้อยคำ ความยาว เวลาจัดส่ง การจัดกลุ่มและความถี่ของการแจ้งเตือนสำหรับระดับการมีส่วนร่วมของผู้ใช้ที่แตกต่างกัน ไม่ว่าจะเป็นระดับเริ่มต้น ผู้ใช้ทั่วไป และผู้ใช้ระดับสูง ตัวอย่างเช่น ผู้ใช้มักจะเปิดกว้างต่อข้อความสนทนาที่ให้ความรู้สึกเป็นกันเองและไม่ชอบการแจ้งเตือนของระบบ การกล่าวถึงชื่อของมนุษย์ที่แท้จริงซึ่งการกระทำที่ก่อให้เกิดการแจ้งเตือนอาจเป็นประโยชน์เช่นกัน
ไม่ควรเริ่มส่งการแจ้งเตือนอย่างช้าๆ เพื่อติดตามผลกระทบที่อาจเกิดขึ้นเช่นกัน ไม่ว่าจะเป็นการเลือกไม่ใช้หรือถอนการติดตั้งแอป การส่งกลุ่มการแจ้งเตือนไปยังกลุ่มเล็กๆ ก่อน คุณยังมีโอกาสที่จะ "ปรับหรือยกเลิกแคมเปญการแจ้งเตือนที่เป็นอันตรายก่อนที่จะสายเกินไป" ตามที่ Nick Babich กล่าวถึงในหัวข้อ "What Makes A Good Notification"
ความพยายามทั้งหมดเหล่านี้มีเป้าหมายเดียวกัน: หลีกเลี่ยงการหยุดชะงักที่สำคัญและป้องกันการแจ้งเตือนที่ล้าหลังสำหรับลูกค้าของเรา ในขณะที่แจ้งให้พวกเขาทราบเกี่ยวกับสิ่งที่พวกเขาต้องการทราบในเวลาที่พวกเขาต้องการทราบ อย่างไรก็ตาม หากข้อความแจ้งเกี่ยวกับคุกกี้สร้างความรำคาญ และการแจ้งเตือนบ่อยครั้งเป็นเพียงการรบกวน เมื่อพูดถึงการรักษาความปลอดภัยของข้อมูลส่วนบุคคลและวิธีจัดการข้อมูล ลูกค้ามักมีความกังวลเร่งด่วนมากขึ้น
เป็นที่น่าสังเกตว่ามีความแตกต่างอย่างมากในวิธีการขอ จัดกลุ่ม และแสดงการแจ้งเตือนบน Android และ iOS ดังนั้น หากคุณกำลังออกแบบแอปเนทีฟหรือแอปไฮบริด คุณจะต้องตรวจสอบอย่างละเอียด ตัวอย่างเช่น ใน iOS ผู้ใช้จะไม่ตั้งค่าการแจ้งเตือนของแอปจนกว่าจะมีการเริ่มต้นใช้งานหรือใช้งานแอปในภายหลัง ในขณะที่ผู้ใช้ Android สามารถเลือกไม่รับการแจ้งเตือนระหว่างการติดตั้งได้ การแจ้งเตือนแบบพุชที่ส่งโดย กปภ. จะทำตัวเหมือนการแจ้งเตือนแบบเนทีฟบนระบบปฏิบัติการที่เกี่ยวข้อง
Admittedly, these issues will not be raised immediately, but as customers keep using an interface and contribute more and more personal data, doubts and concerns start appearing more frequently, especially if more people from their social circles are involved. Some of these issues are easy refinements, but others are substantial and often underestimated blockers.
In the final article of the series, we'll be looking into notifications UX and permission requests, and how we can design the experience around them better, with the user's privacy in mind.
- Part 1: Privacy Concerns And Privacy In Web Forms
- ส่วนที่ 2: ประสบการณ์การยินยอมคุกกี้ที่ดีขึ้น
- Part 3: Better Notifications UX And Permission Requests
- ส่วนที่ 4: กรอบการออกแบบที่คำนึงถึงความเป็นส่วนตัว
Useful Resources And References
- “Designing Notifications For Apps,” Shashank Sahay
- “Different Types Of Notifications: Websites, Apps And Beyond,” Joanna Martin
- “It's Time For Notifications To Get Smart,” Alex Potrivaev
- “Improving User Experience With Real-Time Features,” Lauren Plews