Gizlilik UX: Gizliliğe Duyarlı Tasarım Çerçevesi
Yayınlanan: 2022-03-10- 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
Daha iyi tanımlama bilgisi onay istemleri, izin istekleri ve UX bildirimleri için yaklaşımları zaten araştırdık, ancak tasarım araçlarımızda tasarım kararları verirken bunlar genel bir tasarım stratejisine nasıl uyuyor?
İngiltere, Bristol'deki Mubaloo'da bir UX ve UI tasarımcısı olan Claire Barrett, "GDPR, UX için ne anlama geliyor?" başlıklı makalesinde, tasarım ajansının GDPR ile ilgili olarak takip ettiği çok pratik ve eyleme geçirilebilir bir UX yönergeleri grubunu paylaştı. . Bu yönergeler özellikle GDPR'yi hedeflemekle birlikte, çok daha geniş bir kullanıcı dostu ve gizliliğe duyarlı etkileşimler kapsamına uygulanabilir ve bu nedenle her tür projeye uygulanabilir :
- Kullanıcılar, verilerinin toplanmasını ve kullanılmasını aktif olarak seçmelidir.
- Kullanıcılar, her tür veri işleme faaliyetine onay vermelidir.
- Kullanıcılar , onaylarını istedikleri zaman kolayca geri çekme hakkına sahip olmalıdır.
- Kullanıcılar, verileri işleyecek her kuruluşu ve tüm üçüncü tarafları kontrol edebilmelidir.
- Rıza, şartlar ve koşulları kabul etmekle aynı şey değildir, bu nedenle bunlar bir araya getirilmemelidir; ayrıdırlar ve ayrı formları olmalıdır.
- Doğru zamanlarda onay istemek iyi olsa da, onayın neden deneyimlerine fayda sağlayacağını açıkça açıklamak daha da iyidir.
Claire'in makalesinde önerdiği ilginç şeylerden biri, “tam zamanında” veri toplamaya odaklanmak (bu dizinin 3. bölümünde bahsedilmiştir); yani, verilerin neden gerekli olduğunu ve nasıl kullanılacağını ve kullanılmayacağını açıklayın - ancak yalnızca uygulama veya web sitesi gerçekten ihtiyaç duyduğunda. Açıkçası, bu, toplanan daha kişisel bilgi parçalarının yanına bir "bilgi" simgesi ekleyerek ve istek üzerine veri toplamanın ardındaki yararları ve mantığıyla birlikte araç ipucunu göstererek yapılabilir.
Birçok mobil uygulama, kurulum sırasında konuma, fotoğraflara ve hatta kameraya erişim gerektirir ve bu çoğu müşterinin memnuniyetle kabul edeceği bir şey değildir. İzin almanın daha etkili bir yolu, "tam zamanında" istemleri kullanarak veri toplama noktasındaki verilere duyulan ihtiyacı açıklamaktır, böylece kullanıcılar, tıpkı bizim yaptığımız gibi, yalnızca amacını anladıklarında onay verebilirler. bu seride daha önce izinlerle görüldü.
Açıklamalar ayrıca, uygun olduğunda, onayın nasıl geri çekileceği konusunda müşterilere bilgi vermeli ve gizlilik politikasına bir bağlantı sağlamalıdır. Tamamen anlaşılmaz bir hukuk diliyle yazılmış uzun gizlilik politikalarının özel bir inceleme oturumu olmadan anlaşılması neredeyse imkansız olduğundan, bunlar yıllardır devam eden şikayetler konusu olmuştur. (Aslında, 2008'de yapılan bir araştırma, ortalama bir kişinin kullandıkları sitelerin tüm gizlilik politikalarını okumasının yılda yaklaşık 244 saat süreceğini ve bu da günde yaklaşık 40 dakikaya tekabül ettiğini gösterdi.)
Gizlilik politikasını dolambaçlı bir metin duvarı olarak sunmak yerine, yığınlara ayrılabilir ve net bir şekilde etiketlenmiş bölümler ve genişletilebilir metinler halinde gruplandırılabilir, tarama, yerleştirme ve anlama için optimize edilebilir.
Onay verildiğinde, müşteriler verileri üzerinde tam kontrole sahip olmalıdır; diğer bir deyişle, uygulamalarımızın sahip olduğu herhangi bir veriye göz atma, değiştirme ve silme yeteneği. Bu, mobil uygulamalarımızdaki veri ayarlarının, izni iptal etmek ve pazarlama tercihlerinden çıkmak için ayrıntılı seçeneklerin yanı sıra, karmaşık yardım bölümleri ve belirsiz ayar panellerinden oluşan labirentte gezinmeden herhangi bir veriyi indirme ve silme seçeneği sağlaması gerektiği anlamına gelir.
Gizliliğe duyarlı tasarım kararlarıyla ilgili ana sorun, veri toplamanın etkisini ve tasarım ve geliştirme üzerinde oluşturduğu tüm arayüz zorluklarını değerlendirmenin zor olmasıdır. Alçakgönüllü ve incelikli olmak sadece bir saygı meselesi değil, aynı zamanda teknik borcu azaltmak ve yolda yasal savaşlardan kaçınmakla da ilgilidir. Bunun için aşağıdaki genel yönergeler de yardımcı olabilir.
Olabildiğince Az Veri Kaydet
Kredi kartı verilerini saklamayı seçerseniz, bunları gizli bir şekilde saklamak için aldığınız güvenlik önlemleri konusunda açık olmalısınız. Ne kadar az veriye ihtiyaç duyar ve depolarsanız, olası bir ihlalin yaratacağı etki o kadar az olur.
Kişisel Verilere İyi Bakın
Tüm veriler eşit oluşturulmaz. Kullanıcılar kişisel bilgiler sağladığında, özel bilgiler muhtemelen genel bilgilerden daha hassas olduğundan, farklı veri katmanları arasında ayrım yapın. Kişisel verilere iyi davranın ve asla varsayılan olarak yayınlamayın. Örneğin, bir kullanıcı profilini tamamlarken, tüm girdileri yayınlamadan önce gözden geçirme seçeneği sunun. Alçakgönüllü olun ve her zaman önce izin isteyin ; kullanıcıları proaktif olarak koruyun ve hassas verileri saklamayın. Bu, ileride rahatsız edici durumların önlenmesine yardımcı olabilir.
Bu, yalnızca kullanıcı verilerini sunucularınızda depolama ve yayınlama prosedürü için değil, aynı zamanda parola kurtarma veya herhangi bir bağlı kuruluş ortaklığı için müşteri verilerini kullanma söz konusu olduğunda da geçerlidir. Aslında, bir müşterinin e-postasını açık bir onay olmadan başka birine teslim etmek, güven ve gizliliğin ihlalidir ve çoğu zaman, müşteriler aniden güvenmedikleri bir markayla karşı karşıya kaldıkları için spam olarak işaretlenmesine neden olur. Aslında, ikincisi, ücretsiz bir hediye, videolara erişim ve ücretsiz teklifler karşılığında sürekli olarak e-posta toplayan açgözlü web sitelerine karşı bir savunma mekanizması gibidir.
Üçüncü Tarafların Ne Tür Kullanıcı Verilerini Alacağını Erkenden Açıklayın
Sosyal oturum açma seçeneği sunarken, kullanıcının verilerine ne olacağı ve üçüncü tarafların hangi izinlere sahip olacağı konusunda net olun. Genellikle sosyal oturum açma istendiğinde ince bir not görünür, ancak verilerin nasıl ele alınacağı ve özellikle bir kullanıcının verilerine ne olmayacağı konusunda hemen açık olmak iyi bir fikirdir.
Müşteriler, yeni hesaplarını halihazırda var olan hesaplara bağlamaya zorlandıklarında veya uygulamada ilerleme kaydetmek için sosyal profillerini kullanmaya teşvik edildiğinde, kullanıcı etkileşimlerinin durma noktasına geldiğini görmek sık görülen bir durumdur. Bu asla atılacak basit bir adım değildir ve erişimi iptal etmenin kolay olduğuna dair bir açıklama ve güvence gerektirir.
Müşteri Verilerini Dışa Aktarma İçin Hazırlayın
Toplanan verilerin tam bir resmini elde etmek, özellikle üçüncü taraflar söz konusuysa, önemsiz değildir. Kişisel veriler toplandığında, daha sonra dışa aktarma ve silme için optimize edilmiş bir şekilde yapılandırıldığından emin olun. Son kullanıcı için de sindirilebilirse bonus puanlar, böylece çok özel bir şeyle ilgilendiklerinde ihtiyaç duydukları parçaları ve parçaları bulabilirler. Bu aynı zamanda ne tür verilerin toplandığını ve verilerin nereye aktığını izlemek anlamına gelir, çünkü bu yapıyı daha sonra kullanıcı arayüzümüzdeki veri ayarları ve gizlilik tercihleri üzerinde ayrıntılı kontrol sağlamak için kullanabiliriz.
Kişisel verileri içe aktarmayı son derece sorunsuz hale getiren, ancak kullanıcı verilerini dışa aktarmanın acı verici bir şekilde zor veya imkansıza yakın olmasını sağlayan birkaç arkadaş canlısı şirket duymuş olabilirsiniz. Şaşırtıcı olmayan bir şekilde, bu uygulama müşteriler tarafından iyi algılanmamaktadır; ve özellikle hesaplarını silmeyi düşündükleri zamanlarda, böylesine yaygın bir kilitlenme, müşteri destek şikayetlerine, çağrı merkezi aramalarına ve sosyal kanallarda öfke patlamalarına yol açacaktır. Bu onları uzun süre sadık tutacak hoş bir özellik değil.
Bazı şirketler, büyüklükleri nedeniyle kamuoyunu suçlayabilirken, birçok küçük ve orta ölçekli şirket için itibar, sahip oldukları en değerli varlıktır ve bu nedenle onunla kumar oynamamak akıllıca olur. Benzer hizmetlerle ortaklık kurmayı bile düşünebilir ve aynı özelliğin ortaklar tarafından da desteklenmesini beklerken kullanıcı verilerini sorunsuz bir şekilde taşınabilir ve her biri için aktarılabilir hale getirebilirsiniz.
Bir Hesabı Kapatmayı veya Silmeyi Zorlaştırmak Uzun Vadede Başarısız
Kurumsal devler, müşterilerin hesaplarını kapatmasını veya silmesini oldukça zor hale getirme konusunda başarılı oldu. Ve bu teknik, taşınmanın çok zor olduğu durumlarda işe yarar – Amazon ve Facebook için durum böyle.
Ancak, sadık müşterileri için çabalayan nispeten küçük bir web sitesinde çalışıyorsanız, en azından uzun vadede başarılı bir şekilde çekemeyebilirsiniz. Genellikle aboneliklerde olduğu gibi, yinelenen bir ödemeyi iptal etmeyi zorlaştırırsanız, genel etki daha da zararlı olur. (Aslında, aboneliklerin satılmasının da zor olmasının nedeni budur - bu yalnızca aylık ödeme taahhüdü değil, daha çok erken iptal nedeniyle ek ücret ödemeden aboneliği daha sonra iptal etmenin zorluğudur.)
Aslında, nasıl tasarımcılar bir hesabı silmek için kötü şöhretli profil ayarlarını gizlemede daha iyi hale geliyorlarsa, müşteriler de labirentte gezinmenin yollarını bulma konusunda daha iyi hale geliyorlar ve çoğu zaman bloglarda kolayca keşfedilebilir öğreticilerin sonsuz bilgeliği ile destekleniyor. Durum böyle değilse, müşteriler en çok işe yaradığını bildikleri araçlara başvururlar: genellikle e-postaları spam olarak işaretleyerek, bildirimleri engelleyerek ve hizmeti daha az kullanarak, amaçlarına saygı göstermeyen hizmete sırt çevirmek. Bir gecede olmaz; ancak yavaş ve kademeli olarak ve görüşmelerin gösterdiği gibi, bu müşterilerin hizmeti arkadaşlarına veya meslektaşlarına önermemeleri garanti edilmektedir.
Şaşırtıcı bir şekilde, hesabı kapatmak son derece kolay olduğunda durum bunun tam tersidir. Tıpkı bildirimlerde olduğu gibi, kullanıcının devam etmeyi seçmesinin iyi nedenleri olabilir ve çoğu zaman bunun hizmet kalitesiyle hiçbir ilgisi yoktur. Sağladığınız tüm harika faydaların ayrıntılı bir özetiyle müşteriyi kalmaya ikna etmeye çalışmak yanlış hedeflere ulaşmak olabilir: özellikle kurumsal ortamlarda, karar zaten verilmiş olacaktır, bu nedenle hesabı kapatan kişi kelimenin tam anlamıyla " Yön değiştirme konusunda fazla bir şey yapmayın.
Smashing Üyelik için sesi saygılı ve alçakgönüllü tutmaya çalıştık, aynı zamanda gemiden ayrılma sırasında da biraz kişiliğimizi gösterdik. Verilere ne olduğunu ve geri alınamaz şekilde ne zaman silineceğini (yedi gün) açıklıyoruz, planı geri yükleme seçeneği sunuyoruz, müşterilerin siparişlerini dışa aktarmalarına izin veriyoruz ve verilerin üçüncü taraflarla paylaşılmamasını garanti ediyoruz. Üyelik aboneliğini iptal eden çok sayıda insanın, kendileri için kullanmamış olsalar bile, onlar için bir değer olduğunu düşündükleri için arkadaşlarına ve meslektaşlarına tavsiye etmesi şaşırtıcıydı.
Kullanıcı Hizmetten Rahatsız Oluncaya Kadar Kişileri İçe Aktarmayı Erteleyin
Elbette, uygulamalarımızın çoğu, kullanıcının sosyal çevresini bütünleştirmeden özellikle yararlı değildir, bu nedenle müşterilerden arkadaşlarını erkenden yalnız veya terk edilmiş hissetmemeleri için davet etmelerini istemek makul görünüyor. Ancak bunu yapmadan önce, müşterileri bir süre hizmeti kullanmaya teşvik etmenin yollarını düşünün ve kişileri içe aktarmayı, kullanıcıların bunu yapmaya daha meyilli olduğu noktaya kadar erteleyin. Varsayılan olarak, birçok müşteri, henüz uygulamaya güvenmedikleri için erken bir isteği engeller.
Hesap Kapatıldıktan Sonra Kullanıcı Verilerini Sınırlı Bir Süre Boyunca Kaydet
Hatalar olur ve son derece kötü bir günün ardından tüm kişisel verileri silmek kadar, yanlışlıkla yapılan yanlış dokunmalar için de geçerlidir. Bu nedenle, verileri indirme ve silme seçeneği sunmamız gerekirken, kısa bir süre içinde bir hesabı geri yükleme seçeneği de sunuyoruz. Bu, verilerin hesap silindikten sonra kaydedileceği, ancak bu ek süre geçtikten sonra geri alınamayacak şekilde kaldırılacağı anlamına gelir. Genellikle 7-14 gün fazlasıyla yeterlidir.
Bununla birlikte, kullanıcılara, e-posta isteği yoluyla veya hatta bir düğmeyi tıklatarak verilerin anında silinmesini talep etme seçeneği de sunabilirsiniz. Kullanıcılar dosyalarının nihai olarak silinmesi konusunda bilgilendirilmeli mi? Belki. Nihai karar muhtemelen verilerin ne kadar hassas olduğuna bağlı olacaktır: ne kadar hassas olursa, kullanıcıların verilerin tamamen gittiğini bilmek isteme olasılığı o kadar artar. İstisna, anonimleştirilmiş verilerdir: çoğu zaman müşteriler bununla hiç ilgilenmez.
Gizlilik Politikası Değişikliklerinin Kullanıcı Dostu Özetlerini Sağlayın
Hiçbir şey kesin olarak belirlenmemiştir ve bu nedenle, yeni kişiselleştirme özellikleri veya izleme komut dosyasındaki bir değişiklik nedeniyle gizlilik politikanızın ve varsayılan gizlilik ayarlarınızın ayarlanması gerekebilir. Bu olduğunda, uzun metin bölümlerinde gizliliğin önemini vurgulamak yerine, değişikliklerin net, kullanıcı dostu özetlerini sağlayın. Her şeyin eskiden nasıl olduğunu ve şimdi nasıl farklı olduklarını vurgulayarak özeti yapılandırabilirsiniz. Değişikliğin aslında kullanıcı için ne anlama geldiğini açıklayarak yasal dili daha okunabilir bir şeye çevirmeyi unutmayın.
Açıkçası, çoğu kullanıcı gizlilik politikası değişikliklerini pek umursamadı. 2018'de hiç bitmeyen politika güncelleme bildirimleri akışından sonra, varsayılan tepki genellikle anında onaydır. Konu satırında veya e-posta gövdesinde gizlilik politikasıyla ilgili herhangi bir şey fark ettiklerinde, e-postanın en altına bile gitmeden değişiklikleri hemen kabul ederler. Bununla birlikte, saklanan veriler ne kadar kişisel olursa, genellikle oldukça kafa karıştırıcı ve belirsiz olan değişiklikleri gözden geçirmek için o kadar fazla zaman harcandı.
Not : Gizlilik politikası değişikliklerini kullanıcılarınız ve abonelerinizle nasıl paylaşacağınız konusunda daha fazla ilham almak istiyorsanız, Gerçekten İyi E-postalar'daki kişiler GDPR ile ilgili harika e-posta tasarımı örnekleri topladılar.
İhlal Durumunda Bir İletişim Stratejisi Oluşturun
Kullanıcı verilerinin güvenliği ihlal edildikten sonra kimse zarar görmek istemez. Bu gibi durumlarda, net ve güçlü bir iletişim stratejisine sahip olmak çok önemlidir. Bazı kullanıcı verilerinin tehlikeye girmesi durumunda bir açıklama hazırlayın. Mandy Brown, A List Apart'ta “Yangın Tatbikatları: Krizde İletişim Stratejisi” adlı harika bir makale yayınladı ve nasıl kurulacağını ve bunu yaparken göz önünde bulundurulması gereken birkaç şeyi açıkladı.
Tasarıma Göre Gizlilik
Web sitelerini ziyaret etmek oldukça sıradan bir etkinlik gibi görünebilir ve kullanıcılar sosyal oturum açma, kişileri içe aktarma ve çerez istemleri gibi özellikler konusunda kendilerini rahat ve aşina hissetmelidir. Bu seride gördüğümüz gibi, pek çok önemsiz gizlilik hususu vardır ve çoğu zaman müşterilerin kişisel verilerini paylaşma konusunda endişeleri, şüpheleri ve endişeleri vardır.
Tabii ki, bu dizinin kapsamı çok daha fazla uzayabilir ve parola kurtarma, uygulama içi gizlilik ayarları tasarımı, kayan sohbet pencereleri ve açılır pencereleri, performans ve erişilebilirlik hususları veya aşağıdakiler için gizlilik deneyimleri tasarlamaya bile bakmadık. en savunmasız kullanıcılar – çocuklar, yaşlılar ve dezavantajlı olanlar. Yine de, gizlilikle ilgili tasarım kararları verirken kritik nokta her zaman aynıdır: Yapabileceğimiz ve yapabileceğimiz tüm bilgileri toplamak yerine, katı iş gereksinimleri ile kullanıcıların verilerini kontrol etmelerine ve takip etmelerine yardımcı olan saygılı tasarım arasında bir denge bulmamız gerekir. müşterileri hizmetimize kilitlemek.
Bu dengeyi bulmak için iyi bir yol haritası, Tasarıma Göre Gizlilik (PbD) olarak bilinen, gizlilik öncelikli en iyi uygulama çerçevesini benimsemektir. 1990'larda Kanada'da ortaya çıkan bu, tek bir kod satırı yazılmadan önce gizlilik sorunlarını öngörmek, yönetmek ve önlemekle ilgilidir. AB'nin veri koruma politikası yürürlükteyken, tasarım gereği gizlilik ve veri koruma, tüm kullanımlar ve uygulamalarda varsayılan hale geldi. Bu, web sitenizin veya uygulamanızın hem GDPR uyumluluğunu hem de daha iyi gizlilik UX'ini sağlamak için birçok ilkesinin uygulanabileceği anlamına gelir.
Temelde, çerçeve, mahremiyetin varsayılan bir ayar olmasını ve ilk aşamasında ve ürünün yaşam döngüsü boyunca bir tasarıma gömülü olacak proaktif ( reaktif değil) bir önlem olmasını bekler. Kullanıcılara ayrıntılı gizlilik seçenekleri, saygılı gizlilik varsayılanları, ayrıntılı gizlilik bilgileri bildirimleri, kullanıcı dostu seçenekler ve değişikliklerin açık bildirimini sunmayı teşvik eder. Bu nedenle, bu dizide ana hatlarıyla belirttiğimiz yönergelerle iyi çalışır.
Heather Burns'ün, dijital hizmetlerde Tasarıma Göre Gizlilik çerçevesini uygulamaya yönelik ayrıntılı bir kılavuz sunduğu “Tasarıma Göre Gizlilik Çerçevesiyle Kullanıcılarınızı Nasıl Koruyacağınız” başlıklı makalelerinden birini okumanızı şiddetle tavsiye ederim.
O halde nereden başlamalı? Büyük değişimler küçük adımlarla başlar. Tasarım aşamasında ilk araştırmaya ve fikre mahremiyeti dahil edin ve bir web formunu doldurmaktan işe alım ve işten çıkarmaya kadar varsayılanlara, gizlilik ayarlarına ve hassas temas noktalarına karar verin. Mümkünse toplanan veri miktarını en aza indirin ve üçüncü tarafların hangi verileri topladığını takip edin. Kişisel verileri anonimleştirebiliyorsanız, bu da bir bonus.
Bir kullanıcı kişisel bilgilerini her gönderdiğinde, soruların nasıl çerçevelendiğini ve verilerin nasıl toplandığını takip edin. Bildirimleri ve izin isteklerini tam zamanında, müşterinin kabul edeceğinden neredeyse emin olduğunuzda görüntüleyin. Ve sonunda, kullanıcıları gizlilik politikası değişiklikleri hakkında anlaşılır özetlerle bilgilendirin ve verileri dışa aktarmayı ve silmeyi veya bir hesabı kapatmayı kolaylaştırın.
Ve en önemlisi: Bir dahaki sefere yalnızca bir onay kutusu eklemeyi veya ikili seçenekler sağlamayı düşündüğünüzde, içinde yaşadığımız güzel bulanık ve ikili olmayan dünyayı düşünün. Genellikle ikiden fazla seçenek vardır, bu nedenle her zaman bir çıkış yolu sağlayın, bir seçim ne kadar bariz görünürse görünsün. Müşterileriniz bunu takdir edecektir.