Privasi UX: Pemberitahuan dan Permintaan Izin yang Lebih Baik

• Bagian 1: Kekhawatiran Privasi Dan Privasi Dalam Formulir Web
• Bagian 2: Pengalaman Persetujuan Cookie yang Lebih Baik
• Bagian 3: Notifikasi Lebih Baik UX Dan Permintaan Izin
• Bagian 4: Kerangka Desain Sadar Privasi

Bayangkan Anda terlambat untuk salah satu pertemuan yang sebenarnya tidak ingin Anda datangi. Anda buru-buru memakai sepatu dan mantel Anda dan mengambil kunci pintu Anda dan memegang pegangan pintu — hanya untuk keluar tepat waktu. Saat Anda menuruni tangga, Anda merogoh saku dan mengeluarkan ponsel Anda untuk memeriksa jadwal kereta bawah tanah atau memesan taksi.

Pandangan sekilas ke layar sudah cukup untuk membuat Anda berkeringat: Anda menyadari bahwa Anda lupa untuk mengisi daya ponsel Anda dalam semalam, dan dengan bangga menjalankannya dengan sisa daya baterai 2%. Saat Anda bergegas menyusuri jalan, penuh harapan dan keyakinan, Anda meredupkan kecerahan layar dan mencari ikon aplikasi yang tepat di layar beranda. Tentu saja, pada saat yang tepat banyak pemberitahuan mengalir di layar Anda, meminta perhatian penuh Anda untuk pengikut baru, pembaruan, pengingat, dan pesan.

Kemungkinan besar Anda tahu betul bagaimana rasanya. Seberapa besar kemungkinan Anda untuk bertindak berdasarkan tumpukan pemberitahuan yang mengalir dalam situasi itu? Dan seberapa besar kemungkinan Anda mematikan notifikasi sama sekali saat pengingat lain mencapai Anda beberapa menit kemudian, tepat saat Anda kehilangan koneksi? Itulah salah satu situasi ketika notifikasi benar-benar menghalangi dengan cara yang paling mengganggu, dan terlepas dari semua aliran pengguna yang dibuat secara menyeluruh dan piksel berharga yang dipoles.

Dengan begitu banyak aplikasi dan layanan serta orang-orang dan mesin serta chatbot yang memperebutkan perhatian kita, tetap fokus adalah kemewahan yang perlu dinikmati dan dilindungi , jadi tidak heran notifikasi tidak menikmati reputasi yang layak akhir-akhir ini. Lebih dari itu, seringkali mereka merasa melenceng dan juga manipulatif.

"Mereka sering muncul pada saat mereka paling tidak relevan, dan mereka menciptakan rasa urgensi yang salah, melemahkan fokus dan menyebabkan frustrasi."

— Alex Potrivaev, Intercom

Ini berlaku untuk jendela mengambang di layar beranda sebanyak jumlah yang belum dibaca di bilah alat. Ini juga berlaku untuk pesan pemasaran yang disamarkan sebagai pemberitahuan, serta pembaruan sosial yang dipecah dalam banyak pesan kecil untuk menarik perhatian secara permanen ke layanan.

Semua pemberitahuan ini menuntut perhatian segera dan terasa sangat invasif , memainkan keinginan kami untuk tidak ketinggalan dan tetap terhubung dengan grup sosial kami. Faktanya, mereka mengganggu privasi dengan cara yang tidak dapat dilakukan oleh pola gelap — dengan menuntut dan merebut perhatian tanpa syarat, apa pun yang dilakukan pengguna saat ini.

Namun, bukan kesalahan pemberitahuan bahwa mereka merasa invasif; itu karena kami mendesainnya sedemikian rupa sehingga mereka sering menghalangi. Pengguna tidak ingin ketinggalan pemberitahuan penting dan kehilangan pesan tepat waktu atau penjualan terbatas, tetapi mereka juga tidak ingin merasa direcoki oleh gelombang pembaruan yang tidak pernah berakhir. Jika yang terakhir terjadi terlalu sering, pengguna mematikan notifikasi sama sekali, seringkali dengan rasa pahit terhadap aplikasi dan merek karena "keputusasaan memohon perhatian", seperti yang dikatakan salah satu pengguna. Pelaku tunggal dapat merusaknya untuk orang lain, dan terlepas dari kenyataan bahwa tidak ada pemberitahuan seperti yang lain.

Banyak Wajah Pemberitahuan

Pemberitahuan pada dasarnya adalah gangguan; mereka membawa perhatian pengguna ke peristiwa (yang berpotensi) signifikan yang tidak mereka sadari atau mungkin ingin diingatkan. Dengan demikian, mereka bisa sangat membantu dan relevan, memberikan bantuan, dan membawa struktur dan ketertiban ke rutinitas sehari-hari. Sampai mereka tidak.

Secara umum, pemberitahuan dapat berupa informasi (pengingat kalender, pemberitahuan penundaan, hasil pemilihan malam) atau mendorong tindakan (menyetujui pembayaran, memasang pembaruan, mengonfirmasi permintaan pertemanan). Mereka dapat mengalir dari berbagai sumber, dan dapat memiliki berbagai dampak:

• Notifikasi UI muncul sebagai kartu halus di UI saat pengguna berinteraksi dengan antarmuka web — dengan demikian, notifikasi tersebut diterima secara luas dan kurang invasif dibandingkan beberapa rekan mereka.
• Pemberitahuan push dalam browser lebih sulit untuk diabaikan, dan menarik perhatian mereka sendiri meskipun pengguna tidak mengakses UI.
• Pemberitahuan dalam aplikasi langsung di dalam aplikasi desktop dan seluler, dan dapat sesederhana pemberitahuan UI, tetapi dapat mengambil peran yang lebih sentral dengan pesan yang didorong ke layar beranda atau pusat pemberitahuan.
• Pemberitahuan OS seperti pembaruan perangkat lunak atau perubahan operator seluler juga ikut campur, sering kali muncul bersamaan dengan berbagai macam catatan, pembaruan kalender, dan segala sesuatu di antaranya.
• Terakhir, notifikasi dapat masuk ke email, SMS, dan aplikasi perpesanan sosial, yang berasal dari chatbot, sistem rekomendasi, dan manusia yang sebenarnya.

Anda dapat melihat bagaimana notifikasi — mengingat semua rasa dan sumbernya — bisa menjadi berlebihan di beberapa titik. Namun, kami tidak memberikan perhatian yang sama persis pada setiap notifikasi yang kami terima. Untuk sebagian besar pengguna, diperlukan waktu berminggu -minggu hingga mereka akhirnya menginstal pembaruan perangkat lunak yang diminta oleh pemberitahuan OS mereka, sedangkan biasanya tidak lebih dari beberapa jam untuk mengonfirmasi atau menolak permintaan LinkedIn atau Facebook baru.

Tidak setiap notifikasi sama , dan tingkat perhatian yang diberikan pengguna kepada mereka akan bergantung pada sifatnya, atau, lebih khusus lagi, bagaimana dan kapan notifikasi dipicu.

Dalam artikelnya tentang “Analisis Kritis Sistem Notifikasi”, Shankar Balasubramanian telah melakukan penelitian luar biasa yang memecah pemicu notifikasi menjadi beberapa kelompok:

Kami tidak dapat menyimpulkan bahwa satu kelompok pemicu selalu lebih efektif daripada yang lain, tetapi beberapa pemberitahuan dari setiap kelompok cenderung jauh lebih baik dalam menarik perhatian daripada yang lain:

• Orang-orang lebih peduli dengan pesan baru dari teman dekat dan kerabat, pemberitahuan dari kolega tertentu selama jam kerja, transaksi bank dan peringatan penting, pemberitahuan kalender, acara terjadwal, alarm, dan konfirmasi atau rilis yang dapat ditindaklanjuti dan ditunggu.
• Orang-orang kurang peduli tentang pembaruan berita, pembaruan umpan sosial, pengumuman, fitur baru, laporan kerusakan, pemberitahuan web, pesan informasional dan otomatis secara umum.

Tidak mengherankan, pengguna cenderung memperhatikan pemberitahuan baterai rendah atau konfirmasi pembayaran segera; juga, pengingat kalender, pembaruan kemajuan (misalnya ETA pengiriman paket) dan pesan satu-ke-satu lebih penting daripada pemberitahuan lainnya. Faktanya, dalam setiap percakapan yang kami lakukan dengan pengguna, pesan dari manusia lain dihargai jauh lebih tinggi daripada pemberitahuan otomatis apa pun. Prioritas mungkin sedikit berubah, tentu saja, jika pengguna tidak sabar menunggu pemberitahuan, tetapi hanya sedikit orang yang akan meninggalkan semuanya dengan terburu-buru untuk memeriksa suka ke-77 di foto mereka.

Jadi notifikasi bisa berbeda, dan notifikasi yang berbeda dianggap berbeda; namun, semakin banyak pemberitahuan yang bersifat pribadi, relevan, dan tepat waktu, semakin tinggi keterlibatan yang kita harapkan. Tapi apa artinya semua itu untuk desain notifikasi, dan bagaimana kita bisa membuatnya tidak terlalu mengganggu dan lebih efisien?

Jangan Mengandalkan Default Umum: Atur Mode Pemberitahuan

Biasanya ada alasan bagus mengapa pelanggan memilih untuk mendaftar layanan. Tidak banyak orang yang bangun di pagi hari dengan harapan dapat membuat akun baru pada hari itu. Bahkan, mereka mungkin merasa bahwa layanan Anda dapat membantu mereka dalam tugas sehari-hari, atau dapat meningkatkan alur kerja mereka. Mudah-mudahan mereka tidak memerlukan pemberitahuan untuk memahami cara kerja suatu layanan, tetapi mereka mungkin perlu menerima pemberitahuan untuk memahami nilai yang diberikan layanan tersebut.

Mungkin mereka telah menerima pesan penting dari calon majikan, atau mungkin ada profil kencan yang cocok untuk dilihat. Mereka mungkin tidak ingin melewatkan pesan-pesan ini hanya karena mereka lupa untuk memeriksa layanan untuk sementara waktu. Sebagai desainer, kita perlu memercikkan sedikit notifikasi yang tepat ke dalam campuran untuk membuat pelanggan tetap termotivasi, sambil hanya memberikan petunjuk yang relevan dan dapat ditindaklanjuti kepada mereka.

Sayangnya, dengan sebagian besar layanan, tidak jarang mendaftar, hanya untuk menyadari beberapa saat kemudian bahwa kotak masuk diisi dengan semua jenis pesan (kebanyakan murni informasi), sering dikirim segera setelah yang lain, dan jarang ditindaklanjuti. Pemberitahuan email terutama sering diaktifkan secara default, dengan persetujuan pengguna tersirat dengan menyetujui syarat dan ketentuan yang panjang dan tidak dapat diatur. Tidak ada yang suka dibombardir dengan aliran pesan yang tidak diminta, dan itu berlaku untuk email spam dan juga untuk notifikasi yang tidak diinginkan.

Alih-alih mengatur frekuensi notifikasi default untuk semua pelanggan secara default, kami dapat mulai mengirim beberapa notifikasi pilihan dengan sangat jarang. Karena pelanggan terus menggunakan antarmuka, kami dapat meminta mereka untuk memutuskan jenis notifikasi yang mereka inginkan dan frekuensinya. Hal yang sama berlaku untuk permintaan persetujuan cookie: kami dapat memberikan opsi yang direkomendasikan yang telah ditentukan sebelumnya dengan "mode tenang" (frekuensi rendah), "mode biasa" (frekuensi sedang), dan "mode pengguna daya" (frekuensi tinggi).

Kami bahkan bisa lebih granular dari ini. Basecamp, misalnya, telah memperkenalkan opsi “Always On” dan “Work Can Wait” sebagai bagian dari pengalaman orientasi mereka, sehingga pelanggan baru dapat memilih apakah mereka ingin menerima notifikasi saat terjadi (kapan saja), atau memilih waktu tertentu rentang dan hari saat pemberitahuan dapat dikirim. Atau, sebaliknya, kami dapat menanyakan kepada pengguna kapan mereka tidak ingin diganggu, dan menangguhkan notifikasi pada saat itu. Tidak setiap pelanggan ingin menerima pemberitahuan terkait pekerjaan di luar jam kerja atau di akhir pekan, bahkan jika rekan kerja mereka mungkin bekerja lembur pada Sabtu malam di belahan dunia lain.

Seiring berjalannya waktu, format notifikasi mungkin memerlukan penyesuaian juga. Alih-alih mengirim notifikasi satu per satu saat peristiwa terjadi, pengguna dapat memilih "mode ringkasan", dengan semua notifikasi dikelompokkan menjadi satu pesan mandiri yang dikirimkan pada waktu tertentu setiap hari atau setiap minggu.

Itulah salah satu pengaturan yang disediakan Slack dalam hal notifikasi; sebenarnya, sistem juga menyesuaikan frekuensi notifikasi dari waktu ke waktu. Awalnya, karena saluran Slack bisa sangat sunyi, sistem mengirimkan pemberitahuan untuk setiap pesan yang diposting. Karena aktivitas menjadi lebih sering, Slack merekomendasikan untuk mengurangi tingkat notifikasi sehingga pengguna hanya akan diberi tahu ketika mereka benar-benar disebutkan.

Fitur lain yang ditawarkan Slack adalah memungkinkan pengguna untuk menyorot pilihan kata sehingga pengguna hanya mendapat pemberitahuan ketika topik yang mereka pedulikan telah disebutkan:

Mungkin terdengar seperti frekuensi notifikasi menerima terlalu banyak perhatian pada saat ini, tetapi ketika ditanya tentang masalah umum dengan notifikasi, masalah yang paling umum adalah, sejauh ini, frekuensinya yang tinggi, bahkan jika pesannya relevan atau dapat ditindaklanjuti.

Intinya adalah: mulailah mengirim notifikasi secara perlahan tapi pasti ; mengatur mode notifikasi, dan menyediakan opsi terperinci seperti pilihan pemicu dan format notifikasi. Lebih baik mengirim terlalu sedikit daripada terlalu banyak: Anda mungkin tidak mendapatkan kesempatan lain jika pelanggan ingin memilih keluar dari banyak pemberitahuan yang membuat mereka kesal pada waktu yang salah.

Pilih Waktu dengan Hati-hati

Kita mungkin tidak suka mengakuinya, tetapi bagi banyak dari kita, hari tidak dimulai dengan salam matahari terbit yang damai dan penuh perhatian; alih-alih, itu dimulai dengan pandangan reflektif yang membosankan ke layar ponsel kita yang bersinar. Lebih khusus lagi, hal pertama yang kita lihat setiap pagi bukanlah waktu saat ini atau orang yang kita cintai, tetapi tumpukan notifikasi yang menumpuk tanpa lelah saat kita tidur.

Keadaan pikiran itu belum tentu merupakan kesempatan terbaik untuk mengingatkan pengguna tentang kebijakan privasi yang diperbarui, fitur baru yang mengkilap, atau pengeluaran luar biasa yang perlu diselesaikan. Namun, pemberitahuan pribadi seperti pembagian sosial baru dan reaksi dari lingkaran sosial mungkin jauh lebih relevan, seperti janji temu dan tugas yang akan datang untuk hari itu.

Waktu penting, dan begitu juga pemberitahuan tepat waktu . Anda mungkin tidak ingin mengganggu pelanggan Anda di tengah malam saat mereka tiba di tempat tujuan yang jauh dengan jet lag yang parah. Oleh karena itu, ada baiknya untuk melacak perubahan zona waktu dan waktu setempat, dan menyesuaikan pengiriman notifikasi yang sesuai. Di sisi lain, pelanggan tidak akan terlalu senang dengan pemberitahuan penting yang muncul ketika tidak lagi relevan, jadi jika mereka melacak acara atau pengumuman penting, Anda harus memutuskan apakah acara tersebut cukup penting untuk mengganggu mereka di waktu yang tidak nyaman.

Analitik Anda akan memberi tahu Anda kapan pengguna Anda cenderung bertindak berdasarkan notifikasi Anda, jadi ada baiknya untuk mempelajari dan melacak respons berdasarkan waktu, dan memicu pengiriman notifikasi sekitar waktu tersebut. Misalnya, jika pelanggan paling mudah menerima berbagi pesan di pagi hari, tunda pemberitahuan hingga saat yang tepat pada waktu pagi setempat.

Hindari Situasi Stres Dengan Desain

Dengan notifikasi, waktu bukan satu-satunya atribut penting yang perlu dipertimbangkan. Ingat karakter malang yang berharap mendapatkan koneksi mereka dari awal bagian ini? Melepaskan setumpuk pemberitahuan pada tingkat baterai yang sangat rendah bukanlah ide yang baik, dan itu sama kontraproduktifnya ketika pengguna berjuang dengan konektivitas atau fokus pada tugas seperti mengendarai mobil. Jika Anda dapat menilai tingkat baterai dan kualitas koneksi, ada baiknya untuk menghindari pengiriman notifikasi saat kondisi pengguna kurang optimal. Tentu saja, notifikasi juga harus relevan, jadi jika Anda juga dapat menilai lokasi pengguna, hindari mengirim notifikasi yang bergantung pada lokasi yang tidak berlaku sama sekali.

Terkadang sulit untuk menahan notifikasi karena mungkin penting untuk aktivitas pengguna saat ini. Jika pengguna mengendarai mobil, mengikuti petunjuk di aplikasi navigator, Anda mungkin perlu memberikan pemberitahuan yang lebih gigih dan sederhana tentang perubahan rute yang disarankan karena kecelakaan di jalan. Dalam hal ini, seperti pemberitahuan penting lainnya, kami dapat menampilkan tombol mengambang “Pembaruan baru tersedia. Menyegarkan." Ini jauh lebih tidak invasif daripada pemberitahuan yang memblokir akses ke konten, tetapi sama efektifnya dalam menunjukkan bahwa halaman atau status halaman mungkin sudah usang dan informasi baru tersedia.

Bahkan, alih-alih mengirimkan pemberitahuan pada waktu default tertentu, meskipun itu didasarkan pada perilaku pengguna di masa lalu, Anda dapat menjelajahi sisi lain dari koin dan memanfaatkan momen bahagia dan sukses sebagai gantinya . Layanan pengiriman uang, TransferWise, menampilkan pemberitahuan saat pelanggan menerima pembayaran — dan bukankah itu waktu yang tepat untuk meminta ulasan aplikasi di App Store? Kami dapat melacak pencapaian penting dan memberi tahu pengguna tentang fitur lanjutan saat fitur tersebut tercapai, tepat waktu , seperti yang disebut Luke Wroblewski.

Kurangi Frekuensi Dengan Mengelompokkan Notifikasi

Tidak ada aturan emas untuk jumlah notifikasi yang tepat pada hari tertentu. Sama seperti setiap notifikasi yang berbeda, begitu juga preferensi dan motivasi setiap pelanggan. Untuk mempertahankan interaksi pengguna, Anda mungkin perlu melepaskan blok notifikasi secara bertahap bergantung pada jangkauan atau preferensi pelanggan. Di situlah pengelompokan bertahap terjadi, seperti yang dijelaskan dalam artikel "Merancang Notifikasi Cerdas" oleh Alex Potrivaev, perancang produk di Intercom.

Idenya sederhana. Jika Anda mengetahui rata-rata pelanggan Anda mendapatkan kurang dari lima reaksi per postingan, mungkin ada baiknya Anda memberikan notifikasi unik untuk masing-masing dari mereka. Anda juga dapat memicu pemberitahuan jika ada pesan yang datang dari peristiwa penting, seperti pesan dari teman dekat, keluarga, atau orang berpengaruh. Selain itu, seperti yang kita ketahui bahwa pemberitahuan yang dipicu oleh tindakan dari orang lain lebih dihargai daripada pemberitahuan otomatis, memprioritaskan dan fokus terutama pada yang pribadi , untuk pelanggan tertentu.

Setelah volume notifikasi meningkat, kami dapat mulai mengelompokkannya dan memberikan ringkasan ringkas pada waktu yang tepat. Misalnya, Facebook merangkum pemberitahuan dalam blok yang tidak mengganggu, dengan setiap baris menyoroti tepat satu jenis peristiwa, seperti reaksi terhadap pesan tertentu (“Stoyan Stefanov dan 48 orang lainnya bereaksi terhadap kiriman Anda…”) . LinkedIn, di sisi lain, tampaknya memicu hampir setiap peristiwa satu per satu (“Stoyan Stefanov mengomentari posting Anda”) , sehingga mencemari aliran notifikasi dan membuatnya sulit untuk dipindai dan digunakan.

Tentu saja, berdasarkan riwayat pengguna, kami dapat menyesuaikan lebih dari sekadar pengelompokan notifikasi. Setelah kami mengetahui bagaimana reaksi pengguna terhadap suka foto baru, apakah mereka melihat sekilas atau menyelami setiap notifikasi, kami dapat memberikan notifikasi yang lebih baik di lain waktu. Seperti yang Alex simpulkan:

“Berdasarkan cara Anda biasanya berinteraksi dengan konten, pilihan kata dan struktur yang lebih baik dapat ditawarkan, dan tergantung pada perilaku default, Anda mungkin melihat notifikasi terstruktur secara berbeda.”

Ini, tentu saja, juga membutuhkan putaran umpan balik yang berkelanjutan.

Izinkan Pengguna Menunda Atau Menjeda Pemberitahuan

Hampir tidak ada perusahaan yang akan mengabaikan nilai data tentang pelanggan mereka. Faktanya, kita dapat memperoleh wawasan jangka panjang yang berharga dengan memperkenalkan loop umpan balik ; yaitu, terus-menerus menawarkan opsi kepada pelanggan untuk "Lihat lebih banyak" atau "Lihat lebih sedikit" pemberitahuan jenis tertentu. Tetapi seperti halnya kita cenderung menganggap disabilitas sebagai kondisi aktif/nonaktif (Anda memiliki disabilitas atau tidak), kita sering merasa bahwa kita dapat secara akurat memprediksi perilaku pengguna berdasarkan perilaku mereka di masa lalu saja.

Kenyataannya, bagaimanapun, jarang hitam dan putih. Pengguna kami mungkin terhalang untuk sementara saat menggendong bayi di satu tangan, atau karena kecelakaan yang tidak menguntungkan baru-baru ini, dan kondisi di mana mereka dapat berfluktuasi dengan cara yang sama. Tindakan cepat seperti menunda untuk menanggapi notifikasi yang masuk dapat membantu meringankan masalah, meskipun untuk sementara.

Konteks pengguna terus berubah . Jika Anda melihat penurunan yang tidak biasa dalam tingkat keterlibatan, atau jika Anda mengantisipasi volume notifikasi yang sangat tinggi (mungkin ulang tahun, ulang tahun pernikahan, atau malam pemilihan), pertimbangkan untuk memberikan opsi untuk menonaktifkan, menunda, atau menjeda notifikasi , mungkin selama 24 jam ke depan.

Ini mungkin sangat bertentangan dengan intuisi kita, karena kita mungkin ingin melibatkan kembali pelanggan jika mereka tiba-tiba terdiam, atau kita mungkin ingin memaksimalkan keterlibatan mereka saat peristiwa penting terjadi. Namun, menekan dengan frekuensi notifikasi terlalu berbahaya di sebagian besar waktu. Sangat mudah untuk mencapai titik ketika pemberitahuan yang tampaknya tidak berbahaya akan menjauhkan pelanggan, bahkan dalam jangka panjang. Mungkin ada alasan bagus mengapa pengguna tidak atau tidak ingin aktif untuk sementara waktu, dan lebih sering daripada tidak, itu tidak ada hubungannya dengan layanan sama sekali.

Pilihan lain adalah menyarankan perubahan media yang digunakan untuk menggunakan notifikasi. Pengguna cenderung mengasosiasikan tingkat urgensi yang berbeda dengan saluran komunikasi yang berbeda. Pemberitahuan dalam aplikasi, pemberitahuan push, dan pesan teks dianggap jauh lebih mengganggu daripada email lama, jadi ketika frekuensi melebihi ambang batas tertentu, Anda mungkin ingin mendorong pengguna beralih dari pemberitahuan push ke ringkasan email harian.

Tetapkan Ambang Batas Dan Bangun Pohon Keputusan Pemberitahuan

Namun, ambang batasnya tidak mudah diatur dengan benar. Peristiwa penting harus memicu pemberitahuan langsung untuk diterima tepat waktu. Acara yang kurang penting bisa menunggu, tetapi mungkin berguna untuk menarik perhatian pelanggan ke layanan tersebut. Pemberitahuan yang berpotensi tidak relevan harus disaring tanpa henti untuk menyisakan waktu dan ruang agar pemberitahuan penting dihargai dan dihargai.

Secara umum, notifikasi yang lebih pendek, seperti pesan dari teman dan kolega, paling cocok sebagai notifikasi UI jika tidak mendesak, atau notifikasi push jika mendesak. Notifikasi yang lebih panjang lebih baik sebagai email — apakah itu mendesak atau tidak. Aturan praktis ini akan bervariasi dari layanan ke layanan, sehingga Anda dapat membuat pohon keputusan notifikasi untuk melacak media mana yang paling cocok untuk jenis notifikasi tertentu berdasarkan urgensi, durasi, dan frekuensinya. Selain itu, Anda dapat menentukan ambang batas dan memicu permintaan untuk menunda atau menyesuaikan pengaturan jika ambang batas tercapai.

Jadikan Keikutsertaan dan Penyisihan Jelas

Hari-hari ini hampir diharapkan untuk layanan menjadi ekstrem sehingga sangat sulit bagi pelanggan untuk memilih keluar dari pemberitahuan yang maha kuasa. Kata-kata yang tidak jelas dan label yang tidak jelas dengan terampil disembunyikan di sudut-sudut antarmuka yang jauh bukanlah hal yang aneh. Beberapa pertimbangan desain lainnya bisa lebih berbahaya dan merusak merek. Ketika pengguna tidak dapat menyesuaikan pengaturan dengan mudah, mereka menerapkan artileri berat, menandai pemberitahuan email sebagai spam, atau memblokir pemberitahuan di pengaturan OS atau pengaturan browser. Untuk situs web atau aplikasi, tidak ada cara mudah untuk memulihkannya, kecuali meminta langganan lagi.

Jalan keluar yang jauh lebih sederhana adalah dengan memberikan kontrol yang sangat terperinci atas notifikasi, termasuk konten, format, frekuensi, dan waktu jangan ganggu. Kami dapat memberikan opsi untuk membalas pemberitahuan terbaru dengan "Lebih sedikit email" atau "Berhenti" untuk mengubah frekuensi, melewati login situs web atau login aplikasi (Notion.so melakukan itu). Untuk aplikasi, berikan preferensi notifikasi yang terintegrasi ke dalam aplikasi daripada mengandalkan pengaturan asli OS. Di sana, Anda juga dapat menjelaskan apa yang diharapkan pengguna dari setiap jenis notifikasi, bahkan mungkin dengan contoh tampilannya.

Dalam praktiknya, banyak pengguna akan mencari pengaturan notifikasi di kedua tempat jika mereka benar-benar membutuhkannya, tetapi semakin lama mereka menemukan pengaturan yang samar-samar itu, semakin sedikit kesabaran mereka. Pada kenyataannya, sebagian besar pengguna mencari cara untuk mematikan notifikasi pada saat mereka benar-benar frustrasi atau terganggu oleh notifikasi terbaru. Itu bukan keadaan pikiran yang menyenangkan, dan sebagai layanan, Anda mungkin tidak ingin memperpanjang keadaan pikiran itu dengan mengorbankan perasaan terganggu dan bingung oleh pelanggan Anda yang membayar.

Jangan lupa untuk menjelajahi sisi lain dari koin juga. Identifikasi bagian dari perjalanan pengguna saat pengguna cenderung berlangganan notifikasi; misalnya, setelah pesanan di toko online berhasil dilakukan, atau pemesanan penerbangan telah dikonfirmasi. Dalam kedua kasus tersebut, pemberitahuan dapat membantu pelanggan melacak penundaan atau mengambil boarding pass tepat waktu. Itu juga saat yang tepat untuk menyarankan pemberitahuan push real-time, yang juga berarti pertama-tama meminta izin pelanggan untuk mengirim pengingat tersebut. Dan topik itu layak mendapat percakapan terpisah.

Meminta Izin, Jalan Rendah Hati

Beberapa situs web cukup berkarakter, bukan? Memanjakan diri sendiri, tidak sopan di hati, dan juga benar-benar tidak disukai. Seberapa sering Anda tersandung pada halaman yang tampaknya sederhana dan sederhana hanya untuk disambut dengan permintaan izin yang meminta untuk mengirimi Anda pemberitahuan? Anda belum membaca satu kata pun, tapi itu dia, sudah meminta komitmen jangka panjang — dan sejujurnya, cukup invasif .

Dalam hal pengalaman pengguna, menampilkan permintaan izin saat dimuat mungkin merupakan cara terbaik untuk membuat kesan pertama yang buruk, dan dalam banyak kasus merupakan kesalahan yang tidak dapat diubah. Mulai Januari 2019, Chrome telah mengubah opsi yang ditampilkan saat permintaan asli dipicu. Sementara pengguna mungkin dapat mengabaikan pemberitahuan untuk bereaksi nanti, sekarang mereka harus memilih apakah mereka ingin "Terima" atau "Blokir" pemberitahuan. Yang terakhir menghasilkan pemberitahuan web yang diblokir secara permanen untuk seluruh situs, kecuali jika pengguna menemukan jalan mereka melalui hutan belantara pengaturan browser untuk memberikan akses. Tidak heran sebagian besar pengguna langsung memblokir permintaan tersebut, tanpa membaca isinya sama sekali.

Secara strategis, lebih baik meminta izin hanya ketika ada kemungkinan besar pengguna akan benar-benar menerima. Agar itu terjadi, kami perlu menjelaskan kepada pelanggan mengapa kami benar-benar membutuhkan izin mereka, dan nilai apa yang dapat kami berikan kepada mereka sebagai imbalannya. Dalam praktiknya, strategi ini sering diimplementasikan dalam bentuk 'pola permintaan ganda'. Alih-alih meminta izin segera, kami menunggu sejumlah keterlibatan terlebih dahulu : mungkin beberapa kunjungan halaman, beberapa interaksi, sejumlah waktu yang dihabiskan di situs. Pada akhirnya, kami dapat menyoroti fakta bahwa pengguna dapat berlangganan notifikasi dan betapa berharganya notifikasi tersebut, atau bahwa kami memerlukan izin mereka untuk hasil penelusuran yang lebih akurat dan sadar lokasi. Terkadang konteks halaman sudah cukup, seperti ketika sebuah antarmuka ingin menanyakan geolokasi saat pengguna mengunjungi halaman pencari lokasi toko.

Dalam semua kasus ini, tombol ajakan bertindak yang menonjol akan menunggu saat ketika pengguna paling reseptif untuk bertindak. Jika pengguna memilih untuk mengetuk tombol, kita dapat berasumsi bahwa mereka cenderung melanjutkan tindakan tersebut. Jadi, setelah diklik, tombol tersebut akan meminta permintaan izin asli yang sebenarnya.

Pada dasarnya, kami memecah permintaan izin menjadi dua permintaan:

1. Permintaan yang dibangun ke dalam UI,
2. Permintaan asli di tingkat browser.

Seperti yang dicatat Adam Lynch, jika pengguna masih mencabut izin, mungkin karena salah ketuk atau salah klik di prompt browser asli, kita perlu menampilkan halaman cadangan yang menjelaskan cara mengaktifkan izin secara manual melalui pengaturan browser mereka (atau tautan ke penjelasan). Jelas, tidak masuk akal untuk menampilkan permintaan notifikasi jika pengguna telah memberikan izin. Kita dapat menggunakan Permissions API untuk menanyakan status izin apa pun melalui antarmuka asinkron tunggal dan menyesuaikan UI yang sesuai.

Strategi yang sama dapat diterapkan untuk segala jenis permintaan izin, seperti akses ke geolokasi, kamera, mikrofon, Bluetooth, MIDI, WebUSB, dan sebagainya. Namun, susunan kata dan tampilan permintaan notifikasi UI sangat penting di sini, jadi sebaiknya lacak rasio interaksi dan penerimaan untuk setiap izin atau fitur , dan lakukan tindakan yang sesuai. Dan itu membawa kita ke raja dari semuanya — melacak metrik utama untuk notifikasi Anda.

Melacak Metrik Untuk Notifikasi

Biasanya pemberitahuan tidak dikirim untuk tujuan memberi tahu pelanggan tentang acara yang akan terjadi atau yang akan datang. Notifikasi yang baik berguna dan dapat ditindaklanjuti, membantu pelanggan dan bisnis mencapai tujuan mereka. Untuk itu, metrik yang relevan harus ditemukan dan didefinisikan terlebih dahulu.

Minimal, kami mungkin perlu mengetahui apakah notifikasi yang kami kirim relevan.

• Apakah susunan kata, format, dan frekuensi notifikasi mendorong tindakan yang diinginkan yang ingin kami capai (baik itu berbagi sosial, waktu yang dihabiskan di situs, atau pembelian)?
• Jenis pemberitahuan apa yang lebih penting daripada yang lain?
• Apakah notifikasi benar-benar membawa pengguna kembali ke aplikasi?
• Berapa lama waktu yang berlalu antara pengiriman notifikasi dan pengguna kembali ke situs atau aplikasi?
• Berapa banyak waktu yang dihabiskan rata-rata antara pemberitahuan klik-tayang dan pengguna meninggalkan situs?

Percobaan dengan kata-kata, panjang, waktu pengiriman, dan pengelompokan dan frekuensi pemberitahuan untuk berbagai tingkat keterlibatan pengguna — pemula, pengguna biasa, dan pengguna yang kuat. Misalnya, pengguna cenderung lebih mudah menerima pesan percakapan yang terasa lebih santai dan tidak seperti notifikasi sistem. Menyebutkan nama-nama manusia yang tindakannya memicu pemberitahuan mungkin berguna juga.

Bukan ide yang buruk untuk mulai mengirim notifikasi secara perlahan untuk melacak potensi dampak negatifnya juga — baik itu penyisihan atau pencopotan pemasangan aplikasi. Dengan mengirimkan grup notifikasi ke grup kecil terlebih dahulu, Anda masih memiliki kesempatan untuk “menyesuaikan atau membatalkan kampanye notifikasi yang merugikan sebelum terlambat”, seperti yang dikatakan Nick Babich dalam “What Makes A Good Notification”.

Semua upaya ini memiliki tujuan yang sama: menghindari gangguan yang signifikan dan mencegah kelelahan notifikasi bagi pelanggan kami , sambil memberi tahu mereka tentang apa yang ingin mereka ketahui pada saat mereka perlu mengetahuinya. Namun, jika permintaan cookie hanya mengganggu, dan pemberitahuan yang sering hanya merupakan gangguan, dalam hal keamanan data pribadi dan cara mengelolanya, pelanggan cenderung memiliki masalah yang jauh lebih mendesak.

Perlu dicatat bahwa ada perbedaan signifikan dalam cara pemberitahuan diminta, dikelompokkan, dan ditampilkan di Android dan iOS, jadi jika Anda mendesain aplikasi asli atau hibrida, Anda harus memeriksanya secara mendetail. Misalnya, di iOS, pengguna tidak menyiapkan notifikasi aplikasi hingga orientasi atau penggunaan aplikasi di lain waktu, sementara pengguna Android dapat memilih keluar dari notifikasi selama penginstalan, dengan perilaku default adalah ikut serta. Pemberitahuan push yang dikirim oleh PWA akan berperilaku seperti pemberitahuan asli pada masing-masing OS.

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
• Bagian 2: Pengalaman Persetujuan Cookie yang Lebih Baik
• Part 3: Better Notifications UX And Permission Requests
• Bagian 4: Kerangka Desain Sadar Privasi

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