Privacy UX: Daha İyi Bildirimler ve İzin İstekleri

• Bölüm 1: Gizlilik Endişeleri ve Web Formlarında Gizlilik
• 2. Bölüm: Daha İyi Çerez Onay Deneyimleri
• Bölüm 3: Daha İyi Bildirimler UX ve İzin İstekleri
• Bölüm 4: Gizliliğe Duyarlı Tasarım Çerçevesi

Gerçekten geç kalmak istemediğiniz toplantılardan birine geç kaldığınızı hayal edin. Aceleyle ayakkabılarınızı ve paltonuzu giyer, kapı anahtarlarınızı alır ve tam zamanında yola çıkmak için kapı kolunu tutarsınız. Merdivenlerden inerken, metro tarifesini kontrol etmek veya taksi sipariş etmek için cebinize uzanıyor ve cep telefonunuzu çıkarıyorsunuz.

Ekrana kısa bir bakış terlemeniz için yeterli: Telefonunuzu bir gecede şarj etmeyi unuttuğunuzu fark ediyorsunuz ve kalan %2 pil şarjıyla gururla çalışıyor. Umut ve inançla caddede koşarken, ekranın parlaklığını azaltır ve ana ekranda doğru uygulama simgesini ararsınız. Tabii ki, tam o anda, ekranınızda bir dizi bildirim kademeli olarak düşer ve yeni takipçiler, güncellemeler, hatırlatıcılar ve mesajlar için bölünmemiş dikkatinizi ister.

Bunun nasıl bir his olduğunu çok iyi biliyor olma ihtimalin yüksek. Bu durumda basamaklı bildirim yığınına göre hareket etme olasılığınız nedir? Ve birkaç dakika sonra, tam bağlantınızı kaçırdığınızda, başka bir hatırlatıcı size ulaştığında, bildirimleri tamamen kapatma olasılığınız nedir? Bu, bildirimlerin kelimenin tam anlamıyla mümkün olan en rahatsız edici şekilde ve baştan sona hazırlanmış tüm kullanıcı akışlarına ve cilalı, değerli piksellere rağmen bir şekilde engellendiği durumlardan biridir.

Dikkatimizi çekmek için savaşan bu kadar çok uygulama ve hizmet, insanlar, makineler ve sohbet robotları ile odaklanmak, tadını çıkarması ve korunması gereken bir lükstür ve bu nedenle, bu günlerde bildirimlerin iyi bir üne sahip olmamasına şaşmamalı. Bunun da ötesinde, çoğu zaman konunun dışında ve manipülatif hissederler.

"Genellikle en az alakalı oldukları zamanlarda ortaya çıkıyorlar ve yanlış bir aciliyet duygusu yaratıyorlar, odağı sulandırıyorlar ve hayal kırıklığına neden oluyorlar."

— Alex Potrivaev, İnterkom

Bu, araç çubuklarındaki her şeye kadir okunmamış sayı kadar, ana ekranda kayan pencereler için de geçerlidir. Bu, bildirimler olarak gizlenen pazarlama mesajları ve hizmete kalıcı olarak dikkat çekmek için birçok küçük mesaja bölünmüş sosyal güncellemeler için de geçerlidir.

Tüm bu bildirimler, sosyal gruplarımızı kaçırmama ve bağlantıda kalma arzumuz üzerinde oynayarak, anında dikkat gerektiriyor ve inanılmaz derecede istilacı hissediyor . Aslında, kullanıcının şu anda ne yaptığı önemli değil, koşulsuz olarak dikkat çekerek ve talep ederek hiçbir karanlık örüntünün yapamayacağı şekilde gizliliği bozarlar.

Ancak, kendilerini istilacı hissettikleri bildirimlerin suçu değil; onları, çoğu zaman yollarına çıkacak şekilde tasarlıyoruz. Kullanıcılar önemli bildirimleri ve zamanında gelen mesajları veya sınırlı satışları kaçırmak istemiyorlar, ancak hiç bitmeyen bir gürültülü güncelleme dalgası tarafından rahatsız edilmek de istemiyorlar. İkincisi çok sık gerçekleşirse, kullanıcılar bildirimleri tamamen kapatırlar ve bir kullanıcının dediği gibi, "umutsuzca dikkat dilenmesi" nedeniyle genellikle uygulamaya ve markaya karşı acı bir tat bırakırlar . Tek bir suçlu, diğer herkes için onu mahvedebilir ve hiçbir bildirimin diğerine benzememesine rağmen.

Bildirimlerin Birçok Yüzü

Bildirimler doğası gereği dikkat dağıtıcıdır; kullanıcının dikkatini, farkında olmadığı veya hatırlatılmak isteyebileceği (potansiyel olarak) önemli bir olaya çekerler. Bu nedenle, yardım sağlayarak ve günlük rutine yapı ve düzen getirerek çok yardımcı ve alakalı olabilirler. Onlar olmayana kadar.

Genel olarak, bildirimler bilgilendirici olabilir (takvim hatırlatıcıları, gecikme bildirimleri, seçim gecesi sonuçları) veya harekete geçmeyi teşvik edebilir (ödemeyi onaylayın, bir güncelleme yükleyin, bir arkadaşlık isteğini onaylayın). Çeşitli kaynaklardan akış yapabilirler ve çeşitli etkileri olabilir:

• Kullanıcı arabirimi bildirimleri , kullanıcılar web arabirimiyle etkileşime girdikçe kullanıcı arabirimlerinde ince kartlar olarak görünür - bu nedenle, yaygın olarak kabul edilir ve bazı meslektaşlarından daha az istilacıdır.
• Tarayıcı içi push bildirimlerini reddetmek daha zordur ve kullanıcı kullanıcı arayüzüne erişmese bile dikkatleri kendilerine çeker.
• Uygulama içi bildirimler , masaüstü ve mobil uygulamalarda yaşar ve kullanıcı arayüzü bildirimleri kadar mütevazı olabilir, ancak ana ekrana veya bildirim merkezine gönderilen mesajlarla daha merkezi bir rol oynayabilir.
• Yazılım güncellemeleri veya mobil operatör değişiklikleri gibi işletim sistemi bildirimleri de karışıma dahil olur ve genellikle çok çeşitli notlar, takvim güncellemeleri ve aradaki her şeyle birlikte görünür.
• Son olarak, bildirimler, sohbet robotlarından, öneri sistemlerinden ve gerçek insanlardan gelen e-posta, SMS ve sosyal mesajlaşma uygulamalarına girebilir.

Tüm lezzetleri ve kaynakları göz önüne alındığında bildirimlerin bir noktada nasıl bunaltıcı hale gelebileceğini görebilirsiniz. Yine de aldığımız her bildirime tam olarak aynı miktarda dikkat göstermiyoruz. Kullanıcıların büyük çoğunluğu için, işletim sistemi bildirimi tarafından istenen bir yazılım güncellemesini en sonunda yüklemeleri haftalar alabilirken, yeni bir LinkedIn veya Facebook isteğini onaylamak veya reddetmek genellikle birkaç saatten fazla sürmez.

Her bildirim eşit değildir ve kullanıcıların onlara gösterdiği ilgi düzeyi, özelliklerine veya daha spesifik olarak bildirimlerin nasıl ve ne zaman tetiklendiğine bağlı olacaktır.

Shankar Balasubramanian, “Bildirim Sistemlerinin Kritik Analizi” konulu makalesinde, bildirim tetikleyicilerini birkaç gruba ayıran dikkate değer bir araştırma yaptı:

Bir tetikleyici grubunun her zaman diğerinden daha etkili olduğu sonucuna varamayız, ancak her gruptan gelen bazı bildirimler dikkat çekmede diğerlerinden çok daha iyi olma eğilimindedir:

• İnsanlar, yakın arkadaşlardan ve akrabalardan gelen yeni mesajlara, seçilen iş arkadaşlarının çalışma saatleri içindeki bildirimlerine, banka işlemlerine ve önemli uyarılara, takvim bildirimlerine, planlanmış etkinliklere, alarmlara ve eyleme dönüştürülebilir ve beklenen onaylar veya yayınlara daha fazla önem veriyor.
• İnsanlar genel olarak haber güncellemeleri, sosyal besleme güncellemeleri, duyurular, yeni özellikler, kilitlenme raporları, web bildirimleri, bilgilendirici ve otomatik mesajlarla daha az ilgilenir .

Şaşırtıcı olmayan bir şekilde, kullanıcılar düşük pil bildirimlerine veya ödeme onaylarına hemen katılma eğilimindedir; ayrıca takvim hatırlatıcıları, ilerleme güncellemeleri (örneğin paket teslimat ETA'sı) ve bire bir mesajlar diğer bildirimlerden daha önemlidir. Aslında, kullanıcılarla yaptığımız her konuşmada , başka bir insandan gelen mesaj, herhangi bir otomatik bildirimden çok daha değerliydi . Bir kullanıcı sabırsızlıkla bir bildirim bekliyorsa , öncelikler elbette biraz değişebilir, ancak yalnızca birkaç kişi, fotoğraflarındaki 77. beğeniyi kontrol etmek için umutsuz bir aceleyle her şeyi geride bırakır.

Böylece bildirimler farklı olabilir ve farklı bildirimler farklı algılanır; ancak ne kadar kişisel, alakalı ve zamanında bildirimler olursa, o kadar yüksek katılım beklememiz gerekir. Ancak tüm bunlar bildirimlerin tasarımı için ne anlama geliyor ve bunları nasıl daha az müdahaleci ve daha verimli hale getirebiliriz?

Genel Varsayılanlara Güvenmeyin: Bildirim Modlarını Ayarlayın

Müşterilerin bir hizmete kaydolmayı seçmelerinin genellikle iyi bir nedeni vardır. O gün yeni bir hesap oluşturmayı umarak sabahları pek çok insan uyanmaz. Aslında, hizmetinizin günlük görevlerinde onlara yardımcı olabileceğini veya iş akışlarını iyileştirebileceğini düşünebilirler. Umarım bir hizmetin nasıl çalıştığını anlamak için bildirimlere ihtiyaçları yoktur, ancak hizmetin sağladığı değeri anlamak için bildirim almaları gerekebilir.

Belki potansiyel bir işverenden önemli bir mesaj aldılar ya da belki de bakmaya değer bir flört profili eşleşmesi var. Bir süreliğine servisi kontrol etmeyi unuttukları için bu mesajları kaçırmak istemeyebilirler. Tasarımcılar olarak, müşteriyi motive etmek ve onlara yalnızca ilgili ve eyleme geçirilebilir işaretçiler sunarken , karışıma doğru miktarda bildirim serpmemiz gerekiyor.

Ne yazık ki, çoğu hizmette kaydolmak alışılmadık bir durum değildir, yalnızca birkaç dakika sonra gelen kutusunun her türlü iletiyle (çoğunlukla bilgi amaçlı) dolduğunu, genellikle birbiri ardına gönderilen ve nadiren işlem yapılabilir olduğunu fark etmek nadir değildir. E-posta bildirimleri, özellikle uzun ve yönetilemez hüküm ve koşulları kabul ederek kullanıcının rızasını ima ederek varsayılan olarak genellikle açılır. İstenmeyen mesaj akışıyla bombardıman edilmekten kimse hoşlanmaz ve bu istenmeyen bildirimler için olduğu kadar istenmeyen e-postalar için de geçerlidir.

Varsayılan olarak tüm müşteriler için varsayılan bir bildirim sıklığı ayarlamak yerine, çok seyrek olarak yalnızca birkaç özel bildirim göndermeye başlayabiliriz. Müşteri arayüzü kullanmaya devam ettikçe, onlardan tercih ettikleri bildirimlerin türüne ve sıklığına karar vermelerini isteyebiliriz. Aynısı çerez onay istemleri için de geçerlidir: "sakin mod" (düşük frekans), "normal mod" (orta frekans) ve "güçlü kullanıcı modu" (yüksek frekans) ile önceden tanımlanmış önerilen seçenekler sağlayabiliriz .

Yine de bundan daha ayrıntılı olabiliriz. Örneğin Basecamp, işe alım deneyimlerinin bir parçası olarak "Her Zaman Açık" ve "İş Bekleyebilir" seçeneklerini sunmuştur, böylece yeni müşteriler bildirimleri anında (herhangi bir zamanda) almak isteyip istemediklerini veya belirli bir zamanı seçebilirler. bildirimlerin gönderilebileceği aralıklar ve günler. Ya da tam tersi, kullanıcılara ne zaman rahatsız edilmek istemediklerini sorabilir ve o sırada bildirimleri askıya alabiliriz. Her müşteri, iş arkadaşları cumartesi gecesi gezegenin diğer tarafında fazladan saatlerce çalışıyor olsa bile, mesai saatleri dışında veya hafta sonu işle ilgili bildirimler almak istemez.

Zaman geçtikçe, bildirimlerin biçiminin de ayarlanması gerekebilir. Olaylar meydana geldikçe bildirimlerin birer birer gönderilmesi yerine, kullanıcılar tüm bildirimlerin her gün veya her hafta belirli bir saatte teslim edilen tek bir bağımsız mesaj halinde gruplandığı bir "özet modu" seçebilirler.

Bu, Slack'in bildirimler söz konusu olduğunda sağladığı ayarlardan biridir; aslında sistem, bildirimlerin sıklığını da zaman içinde uyarlar. Başlangıçta, Slack kanalları oldukça sessiz olabileceğinden, sistem gönderilen her mesaj için bildirim gönderir. Etkinlikler daha sık hale geldikçe, Slack bildirim düzeyinin düşürülmesini önerir, böylece kullanıcı yalnızca gerçekten bahsedildiğinde bilgilendirilecektir.

Slack'in sunduğu bir başka özellik de, kullanıcıların yalnızca ilgilendikleri bir konudan bahsedildiğinde bilgilendirilmeleri için kullanıcıların bir dizi kelimeyi vurgulamasına izin vermesidir:

Bu noktada bildirimlerin sıklığı çok fazla dikkat çekiyor gibi görünebilir, ancak bildirimlerle ortak sorunlu noktalar sorulduğunda, en yaygın sorun, mesajlar alakalı veya uygulanabilir olsa bile açık ara yüksek sıklıklarıdır.

Sonuç olarak: yavaş ama istikrarlı bir şekilde bildirimleri göndermeye başlayın ; bildirim modları ayarlayın ve tetikleyici seçimi ve bildirim biçimi gibi ayrıntılı seçenekler sağlayın. Çok fazla göndermektense çok az göndermek daha iyidir: Müşteri, yanlış zamanda sinirlerini bozan sayısız bildirimden vazgeçmek isterse, başka bir şansınız olmayabilir.

Zamanlamayı Dikkatlice Seçin

Kabul etmek istemeyebiliriz ama çoğumuz için gün, doğan güneşin huzurlu, dikkatli bir selamlaması ile başlamaz; bunun yerine, cep telefonlarımızın parlayan ekranına can sıkıcı, refleksif bir bakışla başlar. Daha spesifik olarak, her sabah gördüğümüz ilk şey, şimdiki saat veya sevdiklerimiz bile değil, uyurken yorulmadan yığılan bildirimler yığınıdır.

Bu ruh hali, kullanıcılara güncellenmiş bir gizlilik politikasını, parlak yeni özellikleri veya sonuçlandırılması gereken ödenmemiş harcamaları hatırlatmak için en iyi fırsat olmayabilir. Yeni sosyal paylaşımlar ve sosyal çevrelerden gelen tepkiler gibi kişisel bildirimler, tıpkı yaklaşan randevular ve günlük yapılacak işler gibi çok daha alakalı olabilir.

Zamanlama önemlidir ve zamanında bildirimler de önemlidir . Müşterileriniz uzak bir varış noktasına yoğun jet gecikmesi ile geldikleri için muhtemelen gecenin bir yarısında rahatsız etmek istemezsiniz. Bu nedenle, saat dilimlerinin ve yerel saatin değişimini takip etmek ve bildirimlerin teslimini buna göre ayarlamak iyi bir fikirdir. Öte yandan, müşteriler artık alakalı olmadığında görünen önemli bir bildirimden özellikle mutlu olmayacaklardır, bu nedenle önemli bir olayı veya duyuruyu izliyorlarsa, olayın onları rahatsız edecek kadar kritik olup olmadığına karar vermeniz gerekir. rahatsız edici bir zaman.

Analizleriniz, kullanıcılarınızın bildirimlerinize göre ne zaman harekete geçeceğini size söyleyecektir; bu nedenle, yanıtları zamana göre incelemek ve izlemek ve bu süre zarfında bildirimlerin gönderilmesini tetiklemek iyi bir fikirdir. Örneğin, bir müşteri bir mesajı en çok sabahları paylaşmaya açıksa, yerel sabah saatinde tam doğru ana kadar bildirimleri erteleyin.

Tasarımla Stresli Durumlardan Kaçının

Bildirimlerde, dikkate alınması gereken tek önemli özellik zamanlama değildir. Bu bölümün başında bağlantılarını yakalamayı uman zavallı karakteri hatırlıyor musunuz? Kritik düzeyde düşük pil seviyesinde bir dizi bildirimi serbest bırakmak iyi bir fikir değildir ve kullanıcı bağlantı sorunu yaşadığında veya araba kullanmak gibi bir göreve odaklandığında da aynı derecede verimsizdir. Pil seviyesini ve bağlantı kalitesini değerlendirebiliyorsanız, kullanıcının koşulları yetersiz olduğunda bildirim göndermekten kaçınmak iyi bir fikirdir. Elbette, bildirimlerin de alakalı olması gerekir, bu nedenle kullanıcının konumunu da değerlendirebiliyorsanız , hiç geçerli olmayan konuma bağlı bildirimler göndermekten kaçının .

Bazen, kullanıcının mevcut etkinliği için kritik olabileceğinden, bildirimleri tutmak zordur. Kullanıcı bir navigasyon uygulamasındaki talimatları izleyerek araba kullanıyorsa, yoldaki bir kaza nedeniyle önerilen rota değişikliği hakkında daha kalıcı ve mütevazı bir bildirim sağlamanız gerekebilir. Bu durumda, diğer kritik bildirimler gibi, kayan bir düğme görüntüleyebiliriz “Yeni güncellemeler mevcut. Yenile.” İçeriğe erişimi engelleyen bir bildirimden çok daha az müdahalecidir, ancak sayfanın veya sayfanın durumunun güncelliğini yitirmiş olabileceğini ve yeni bilgilerin mevcut olduğunu belirtmekte bir o kadar etkilidir.

Aslında, belirli varsayılan zamanlarda bildirim göndermek yerine, kullanıcının geçmiş davranışlarına dayalı olsa bile, madalyonun diğer yüzünü keşfedebilir ve bunun yerine mutlu ve başarılı anlardan yararlanabilirsiniz. Bir para transferi hizmeti olan TransferWise, müşteri bir ödeme aldığında bildirimler görüntüler ve bu, App Store'da bir uygulama incelemesi istemek için harika bir zaman değil mi? Luke Wroblewski'nin dediği gibi, önemli kilometre taşlarını takip edebilir ve tam zamanında , ulaşıldığında gelişmiş özellikler hakkında kullanıcıları bilgilendirebiliriz.

Bildirimleri Gruplandırarak Sıklığı Azaltın

Belirli bir günde yalnızca doğru miktarda bildirim için altın bir kural yoktur. Her bildirim farklı olduğu gibi, her müşterinin tercihleri ​​ve motivasyonları da değişir. Bir kullanıcının etkileşimini sürdürmek için müşterinin erişim veya tercihlerine bağlı olarak bildirim bloklarını kademeli olarak serbest bırakmanız gerekebilir. Intercom'un ürün tasarımcısı Alex Potrivaev'in “Akıllı Bildirimleri Tasarlama” makalesinde açıklandığı gibi, kademeli gruplama burada devreye giriyor.

Fikir basit. Müşterilerinizin gönderi başına ortalama beşten az tepki aldığını biliyorsanız, her biri için benzersiz bir bildirim sağlamak iyi bir fikir olabilir. Yakın arkadaşlarınızdan, ailenizden veya etkili kişilerden gelen bir mesaj gibi önemli olaylardan bir mesaj geliyorsa da bir bildirimi tetikleyebilirsiniz. Ayrıca, başka bir kişinin eylemiyle tetiklenen bildirimlerin, otomatik bildirimlerden daha değerli olduğunu bildiğimiz için, o müşteri için öncelikli olarak kişisel bildirimlere öncelik verin ve odaklanın .

Bildirimlerin hacmi arttığında, bunları gruplandırmaya başlayabilir ve uygun bir zamanda kısa özetler sağlayabiliriz. Örneğin, Facebook, bildirimleri müdahaleci olmayan bloklar halinde özetler ve her satır, belirli bir mesaja verilen tepkiler gibi tam olarak bir tür olayı vurgular (“Stoyan Stefanov ve diğer 48 kişi gönderinize tepki gösterdi…”) . LinkedIn ise neredeyse her olayı tek tek tetikliyor gibi görünüyor (“Stoyan Stefanov gönderinize yorum yaptı”) , bu nedenle bildirim akışını kirletiyor ve taranmasını ve kullanılmasını zorlaştırıyor.

Elbette, bir kullanıcının geçmişine dayanarak, bildirimlerin gruplandırılmasından daha fazlasını özelleştirebiliriz. Bir kullanıcının yeni fotoğraf beğenilerine nasıl tepki verdiğini, kısaca onlara bakıp bakmadığını veya her bildirime derinlemesine daldığını öğrendiğimizde, bir dahaki sefere daha iyi bildirimler sağlayabiliriz. Alex'in şu sonuca vardığı gibi:

"Genellikle içerikle etkileşim biçiminize bağlı olarak, daha iyi ifadeler ve yapı seçenekleri sunulabilir ve varsayılan davranışa bağlı olarak farklı yapılandırılmış bildirimler görebilirsiniz."

Bu, elbette, sürekli geri besleme döngüleri gerektirir.

Kullanıcıların Bildirimleri Ertelemesine veya Duraklatmasına İzin Verin

Neredeyse hiçbir şirket, müşterileri hakkındaki verilerin değerini göz ardı etmeyecektir. Aslında, geri bildirim döngülerini tanıtarak değerli uzun vadeli içgörüler elde edebiliriz; yani, müşterilere belirli bir türdeki "Daha fazlasını görme" veya "Daha az görme" seçeneklerini sürekli olarak sunar. Ancak, engelliliği bir açık/kapalı durumu olarak algılamaya meyilli olduğumuz gibi (ya bir engeliniz var ya da yok), çoğu zaman yalnızca geçmiş davranışlarına dayanarak kullanıcının davranışını doğru bir şekilde tahmin edebileceğimizi düşünüyoruz.

Ancak gerçek nadiren siyah ve beyazdır. Kullanıcılarımız, bir kolunda bebek tutarken veya son zamanlarda yaşanan talihsiz bir kaza nedeniyle geçici olarak engellenebilir ve içinde bulundukları koşullar da aynı şekilde dalgalanma gösterebilir. Gelen bir bildirime yanıt olarak erteleme gibi hızlı eylemler, sorunu geçici de olsa hafifletmeye yardımcı olabilir.

Kullanıcının bağlamı sürekli değişir . Etkileşim oranında olağandışı bir düşüş fark ederseniz veya alışılmadık derecede yüksek hacimli bildirimlerin (doğum günü, evlilik yıl dönümü veya seçim gecesi) geleceğini tahmin ediyorsanız, bildirimleri sessize alma, erteleme veya duraklatma seçeneği sunmayı düşünün. , belki önümüzdeki 24 saat için.

Bu, sezgilerimize çok ters düşebilir, çünkü birdenbire sessizleşirlerse müşteriyle yeniden etkileşim kurmak isteyebiliriz veya önemli olaylar meydana geldiğinde etkileşimlerini en üst düzeye çıkarmak isteyebiliriz. Ancak, bildirimlerin sıklığına basmak çoğu zaman çok tehlikelidir. Görünüşte zararsız bir bildirimin, potansiyel olarak uzun vadede bile bir müşteriyi uzaklaştıracağı bir noktaya ulaşmak kolaydır. Kullanıcının bir süredir aktif olmamasının veya olmak istememesinin iyi nedenleri olabilir ve çoğu zaman bunun hizmetle hiçbir ilgisi yoktur.

Başka bir seçenek de, bildirimleri tüketmek için kullanılan bir ortam değişikliği önermek olacaktır. Kullanıcılar, farklı aciliyet düzeylerini farklı iletişim kanallarıyla ilişkilendirme eğilimindedir. Uygulama içi bildirimler, anında iletme bildirimleri ve metin mesajları, eski e-postalardan çok daha fazla müdahaleci olarak kabul edilir, bu nedenle sıklık belirli bir eşiği aştığında, kullanıcıları anında iletme bildirimlerinden günlük e-posta özetlerine geçişe yönlendirmek isteyebilirsiniz.

Eşikleri Ayarlayın ve Bildirim Karar Ağacı Oluşturun

Yine de eşiklerin doğru şekilde ayarlanması kolay değildir. Önemli olaylar, zamanında alınacak anında bildirimleri tetiklemelidir. Daha az önemli olaylar bekleyebilir, ancak müşterinin dikkatini hizmete çekmek faydalı olabilir. Önemli bildirimlerin önemsenmesi ve değer verilmesi için zaman ve alan bırakmak için, potansiyel olarak alakasız bildirimlerin amansızca filtrelenmesi gerekir.

Genel olarak, arkadaşlardan ve iş arkadaşlarından gelen mesajlar gibi daha kısa bildirimler, acil değilse UI bildirimleri veya acillerse push bildirimleri olarak en uygun olanıdır. Acil olsun ya da olmasın , daha uzun bildirimler e-posta olarak daha iyidir . Bu temel kural hizmetten hizmete değişir, böylece aciliyet, uzunluk ve sıklıklarına göre belirli bildirim türleri için hangi ortamın en iyi sonucu verdiğini izlemek için bir bildirim karar ağacı oluşturabilirsiniz. Ek olarak, eşikler tanımlayabilir ve bir eşiğe ulaşıldığında erteleme veya ayarların değiştirilmesi için bir uyarı tetikleyebilirsiniz.

Kabul Etmeyi ve Devre Dışı Bırakmayı Açık Hale Getirin

Bu günlerde, bir hizmetin, bir müşterinin her şeye kadir bildirimlerden vazgeçmesini gülünç derecede zorlaştıracak şekilde aşırıya gitmesi bekleniyor. Arayüzün uzak köşelerinde ustaca gizlenmiş belirsiz ifadeler ve belirsiz etiketler nadir değildir. Diğer birkaç tasarım düşüncesi bir marka için daha zararlı ve zarar verici olabilir. Kullanıcılar ayarları kolayca ayarlayamadıklarında, ağır silahlar kullanırlar, e-posta bildirimlerini spam olarak işaretlerler veya işletim sistemi ayarlarında veya tarayıcı ayarlarında bildirimleri engellerler. Bir web sitesi veya uygulama için, abonelik için tekrar yalvarmaktan başka, bundan kurtulmanın kolay bir yolu yoktur.

Çok daha basit bir çıkış yolu, içerik, biçim, sıklık ve rahatsız edilmeme süreleri dahil olmak üzere bildirimler üzerinde çok ayrıntılı kontrol sağlamaktır. Web sitesi girişlerini veya uygulama girişlerini atlayarak, sıklığı değiştirmek için yakın tarihli bir bildirime "Daha az e-posta" veya "Durdur" ile yanıt verme seçeneği sağlayabiliriz (Notion.so bunu yapar). Uygulamalar için, işletim sisteminin yerel ayarlarına güvenmek yerine uygulamaya entegre edilmiş bildirim tercihleri ​​sağlayın. Orada, kullanıcının her türlü bildirimden ne bekleyebileceğini, belki de nasıl görüneceklerine dair örneklerle bile açıklayabilirsiniz.

Pratikte, birçok kullanıcı gerçekten ihtiyaç duymaları halinde her iki yerde de bildirim ayarlarını arayacaktır , ancak bu belirsiz ayarı bulmaları ne kadar uzun sürerse, o kadar az sabırlı olurlar. Gerçekte, çoğu kullanıcı, son bildirimlerden gerçekten hayal kırıklığına uğradıkları veya rahatsız oldukları anda bildirimleri kapatmanın bir yolunu arar. Bu, içinde bulunmak hoş bir ruh hali değil ve bir hizmet olarak, muhtemelen, ödeme yapan müşterileriniz tarafından rahatsız edilmek ve kafasının karışması pahasına bu ruh halini gereksiz yere genişletmek istemezsiniz.

Madalyonun diğer yüzünü de keşfetmeyi unutmayın. Bir kullanıcının bildirimlere abone olma olasılığı daha yüksek olduğunda, kullanıcı yolculuğunun bölümlerini belirleyin; örneğin, bir çevrimiçi mağazada bir sipariş başarıyla verildiğinde veya bir uçuş rezervasyonu onaylandığında. Her iki durumda da bildirimler, müşterilerin gecikmeleri takip etmesine veya biniş kartlarını zamanında almasına yardımcı olabilir. Bu aynı zamanda gerçek zamanlı anında iletme bildirimleri önermek için de iyi bir zamandır; bu, aynı zamanda bu hatırlatıcıları göndermek için önce müşterinin iznini istemek anlamına gelir. Ve bu konu ayrı bir konuşmayı hak ediyor.

İzin İstemek, Mütevazi Yol

Bazı web siteleri oldukça karakterlidir, değil mi? Kendini beğenmiş, özünde kaba ve aynı zamanda gerçekten sevimsiz. Size bildirim göndermek için yalvaran harika izinlerle karşılaşmak için ne sıklıkla görünüşte mütevazı, gösterişsiz bir sayfaya rastlarsınız? Henüz tek bir kelime okumadınız, ama işte orada, zaten uzun vadeli bir taahhüt talep ediyor - ve açıkçası, oldukça istilacı .

Kullanıcı deneyimi açısından, yükleme sırasında bir izin istemi görüntülemek, muhtemelen kötü bir ilk izlenim bırakmanın en iyi yoludur ve çoğu durumda geri dönüşü olmayan bir hatadır. Ocak 2019'dan itibaren Chrome, yerel bir istem tetiklendiğinde görüntülenen seçenekleri değiştirdi. Kullanıcılar daha sonra tepki vermek için bir bildirimi kapatabilirken, şimdi bildirimleri "Kabul Et" veya "Engelle" arasında seçim yapmak zorundalar. Sonuncusu, kullanıcı sonuçta erişim vermek için tarayıcı ayarlarının vahşi doğasında yolunu bulamadıkça, web bildirimlerinin tüm site için kalıcı olarak engellenmesiyle sonuçlanır. Kullanıcıların büyük çoğunluğunun, içeriklerini hiç okumadan bu tür istemleri hemen engellemesine şaşmamalı.

Stratejik olarak, yalnızca bir kullanıcının gerçekten kabul etme şansı yüksek olduğunda izin istemek daha iyidir. Bunun olması için, müşteriye neden gerçekten izinlerine ihtiyacımız olduğunu ve karşılığında onlara hangi değeri sağlayabileceğimizi açıklamamız gerekiyor. Pratikte, bu strateji genellikle 'çifte istek modeli' şeklinde uygulanır. Hemen izin istemek yerine, önce belirli bir miktarda etkileşimi bekleriz : belki birkaç sayfa ziyareti, birkaç etkileşim, sitede geçirilen belirli bir süre. Sonunda, bir kullanıcının bildirimlere abone olabileceğini ve bunların nasıl değerli olabileceğini veya daha doğru, konuma duyarlı arama sonuçları için onların iznine ihtiyacımız olduğunu vurgulayabiliriz. Bazen sayfanın bağlamı yeterlidir, örneğin kullanıcı mağaza bulma sayfasını ziyaret ettiğinde bir arayüzün coğrafi konum sormak istemesi gibi.

Tüm bu durumlarda, göze çarpan bir harekete geçirici mesaj düğmesi, kullanıcının harekete geçmeye en açık olduğu anı bekleyecektir. Kullanıcı düğmeye dokunmayı seçerse, büyük olasılıkla işleme devam edeceklerini varsayabiliriz. Bu nedenle, bir kez tıklandığında, düğme gerçek bir yerel izin isteği ister.

Esasen, izin istemini iki talebe ayırıyoruz:

1. Kullanıcı arayüzünde yerleşik bir istek,
2. Tarayıcı düzeyinde yerel bir istek.

Adam Lynch'in belirttiği gibi, kullanıcı, yerel tarayıcı istemindeki bir yanlış tıklama veya yanlış tıklama nedeniyle, yine de izni iptal ederse, iznin tarayıcı ayarları aracılığıyla manuel olarak nasıl etkinleştirileceğini (veya açıklama linki). Açıkçası, kullanıcı zaten izin vermişse, bildirim isteği görüntülemenin bir anlamı yoktur. Tek bir asenkron arayüz üzerinden herhangi bir iznin durumunu sorgulamak ve kullanıcı arayüzünü buna göre ayarlamak için Permissions API'sini kullanabiliriz.

Aynı strateji, coğrafi konum, kamera, mikrofon, Bluetooth, MIDI, WebUSB vb. erişim gibi her türlü izin talebine uygulanabilir. Kullanıcı arayüzü bildirim istemlerinin ifadesi ve görünümü burada kritik öneme sahiptir, bu nedenle her izin veya özellik için etkileşim ve kabul oranlarını izlemek ve bunlara göre hareket etmek iyi bir fikirdir . Bu da bizi hepsinin kralına getiriyor: bildirimleriniz için önemli metrikleri takip etmek.

Bildirimler İçin Metrikleri İzle

Genellikle bildirimler, müşterileri meydana gelen veya yaklaşan bir etkinlik hakkında bilgilendirmek amacıyla gönderilmez. İyi bildirimler, hem müşterilerin hem de işletmelerin hedeflerine ulaşmasına yardımcı olarak kullanışlıdır ve eyleme geçirilebilir. Bunun için öncelikle ilgili metriklerin keşfedilmesi ve tanımlanması gerekir.

Asgari olarak, gönderdiğimiz bildirimlerin ilk etapta alakalı olup olmadığını bilmemiz gerekebilir.

• Bildirimlerin ifadesi, biçimi ve sıklığı, ulaşmayı hedeflediğimiz istenen eylemi (sosyal paylaşımlar, sitede geçirilen zaman veya satın almalar) yönlendiriyor mu?
• Ne tür bildirimler diğerlerinden daha önemlidir?
• Bildirimler gerçekten kullanıcıları uygulamaya geri getiriyor mu?
• Bildirimin gönderilmesi ile kullanıcının siteye veya uygulamaya dönmesi arasında ne kadar zaman geçer?
• Tıklama bildirimi ile kullanıcının siteden ayrılması arasında ortalama ne kadar zaman harcanır?

Yeni başlayan, normal kullanıcı ve uzman kullanıcı gibi farklı kullanıcı katılımı düzeyleri için ifadeler, uzunluk, gönderim süreleri ve gruplandırma ve bildirimlerin sıklığı ile denemeler yapın. Örneğin, kullanıcılar daha rahat ve sistem bildirimlerine daha az benzeyen konuşma mesajlarına daha açık olma eğilimindedir. Eylemleri bir bildirimi tetikleyen gerçek insanların adlarından bahsetmek de faydalı olabilir.

Devre dışı bırakma veya uygulama kaldırma işlemleri gibi olası olumsuz etkilerini de izlemek için bildirimleri yavaş yavaş göndermeye başlamak asla kötü bir fikir değildir. Nick Babich'in “What Makes A Good Notification” bölümünde belirttiği gibi, önce küçük bir gruba bir grup bildirim göndererek, “herhangi bir zararlı bildirim kampanyasını çok geç olmadan ayarlama veya iptal etme” şansınız var.

Tüm bu çabaların aklında aynı amaç vardır: Müşterilerimiz için önemli kesintileri önlemek ve bildirim yorgunluğunu önlemek , aynı zamanda onları bilmek istediklerini, bilmeleri gereken zamanda bilgilendirmek. Ancak, çerez istemleri yalnızca can sıkıcıysa ve sık bildirimler yalnızca bir rahatsızlıksa, konu kişisel verilerin güvenliği ve bunların nasıl yönetildiği konusunda olduğunda, müşterilerin çok daha acil endişeleri olma eğilimindedir.

Android ve iOS'ta bildirimlerin nasıl istendiği, gruplandırıldığı ve görüntülendiği konusunda önemli farklılıklar olduğunu belirtmekte fayda var, bu nedenle yerel veya karma bir uygulama tasarlıyorsanız bunları ayrıntılı olarak incelemeniz gerekir. Örneğin, iOS'ta kullanıcılar, uygulama ilk başlayana veya uygulamanın sonraki bir kullanımına kadar uygulama bildirimleri ayarlamazken, Android kullanıcıları yükleme sırasında bildirimleri devre dışı bırakabilir ve varsayılan davranış etkinleştirilir. Bir PWA tarafından gönderilen anında iletme bildirimleri, ilgili bir işletim sisteminde yerel bildirimler gibi davranacaktır.

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. Bölüm: Daha İyi Çerez Onay Deneyimleri
• Part 3: Better Notifications UX And Permission Requests
• Bölüm 4: Gizliliğe Duyarlı Tasarım Çerçevesi

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