Kullanıcı Sözleşmesi UX'i: Okunan Bir Sözleşme Nasıl Yazılır
Kullanıcı sözleşmesi, çoğu üründe kimsenin okumadığı ama herkesin kabul ettiği metindir. Okunmamasının sebebi genelde konunun ağırlığı değil, metnin nasıl yazıldığı ve arayüzde nereye konduğudur. İkisi de hukuk bilgisi değil, düz yazı ve tasarım kararı ister.
Sözleşme metni arayüzün neresinde duruyor
Bir sözleşme tek başına var olmaz. Kayıt formunun altındaki onay kutusunda, ödeme adımında ya da uygulamayı ilk açtığında karşına çıkan tam ekran katmanda görünür. Metnin okunup okunmayacağını belirleyen ilk şey cümleler değil, akışın hangi anında ve ne kadar yerle gösterildiğidir. Üç satırlık kaydırma alanına sıkıştırılmış otuz sayfalık bir metin, dili ne kadar sade olursa olsun okunmaz.
Buradan işe yarar bir sıra çıkıyor: önce metni nerede göstereceğine karar ver, sonra o alana sığacak yapıyı kur, cümleleri en sonda yaz.
Sadeleştirme neyi çözer
Hukuk dili çoğu maddede zorunlu değildir, alışkanlıktır. "İşbu sözleşme tarafların karşılıklı hak ve yükümlülüklerini düzenler" cümlesi, "Bu sözleşme sizin ve bizim haklarımızı anlatır" olarak yazıldığında hiçbir şey kaybetmez. Aynısı sorumluluk maddeleri için de geçerli: "Kullanıcı, platform üzerinde gerçekleştirdiği her türlü işlemden münhasıran sorumludur" yerine "Platformdaki işlemlerinizden siz sorumlusunuz" yazabilirsin.
Cümleleri kısaltmak da aynı işi görür. Bir cümle tek bir fikir taşısın, bir paragraf tek bir konuyu bitirsin. Bu, ana dili farklı olan kullanıcılar ve ekran okuyucuyla ilerleyen kullanıcılar için kozmetik değil, doğrudan anlama farkı yaratan bir değişiklik.
Özet kutularının gizli maliyeti
Karmaşık maddenin yanına sade bir özet koymak yaygın bir tavsiye ve okumayı gerçekten kolaylaştırıyor. Ama ortaya ikinci bir metin çıkıyor. Özetle madde arasında küçük bir anlam farkı oluştuğunda, tüketici sözleşmelerinde açık olmayan şart tüketici lehine yorumlanır; yani kullanıcının okuduğu sade cümle, senin dayanmak istediğin uzun maddenin önüne geçebilir. Özet yazacaksan maddeyi de özete uydur ve iki metni ayrı ayrı güncellenebilir bırakma. Aksi halde sadeleştirme çabası, altı ay sonra çelişkili iki metne dönüşür.
Biçim kararları
Tamamen büyük harfle dizilmiş bloklar okuma hızını düşürür ve uyarıyı vurgulamak yerine gözden kaçırılan bir gürültüye çevirir. Büyük harfi tek tek uyarı cümlelerinde kullan, paragraflarda değil.
Punto konusunda sabit bir sayı vermek yerine ölçülebilir bir eşiğe bakmak daha sağlam: metin yüzde 200 büyütüldüğünde içerik kaybolmuyor, üst üste binmiyor ve yatay kaydırma gerektirmiyorsa boyut yeterlidir. Bu ölçüt WCAG'in metin yeniden boyutlandırma ölçütüdür ve sabit bir 12 punto kuralından çok daha fazlasını kapsar.
Bir de az konuşulan bir ayrıntı var: maddeleri numaralandır. Kullanıcı destek ekibine yazdığında "şu paragrafta" değil "madde 7.2" diyebiliyorsa hem destek süresi kısalır hem de metnin hangi bölümünün anlaşılmadığı elinde veri olarak birikir.
Kabul anını kaydetmek
Sözleşme metni değişir. Değiştiğinde geriye dönük olarak kimin neyi onayladığı sorusu ortaya çıkar ve bu soru arayüzde değil veritabanında cevaplanır. Metni sürüm numarasıyla sakla, kabul kaydında da o sürümü tut; "kullanıcı tam olarak neyi kabul etti" sorusuna cevap veremiyorsan sade dilin de bir hükmü kalmaz. Bunu üç sütunla çözersin: sürüm etiketi, kabul zamanı ve metnin özet değeri. Üçüncü parti bir onay yönetimi aracına geçmeden önce bu üç sütunu denemekte fayda var.
Anlaşıldı mı, nasıl anlarsın
Kullanıcıya "bu metin anlaşılır mıydı" diye sormak işe yaramaz, çünkü herkes anladığını sanır. Bunun yerine metni önlerine koy ve görev sorusu sor: aboneliğinizi iptal etmek isteseniz ne yapmanız gerekiyor, hangi süre içinde? Verilerinizi silmemizi istediğinizde ne oluyor?
Ölçtüğün şey memnuniyet değil, cevabın doğruluğu ve cevaba ulaşma süresi olur. Birkaç kullanıcı, metnin hangi bölümlerinin çalışmadığını görmeye fazlasıyla yeter; kalan iş o bölümleri yeniden yazmaktır.
Kaynak