Kazara Tıklamaları Engellemenin 3 Stratejik Yolu
Dokunmatik cihazlarda yanlışlıkla yapılan “tıklamaları” gidermek için birçok farklı yol vardır. Bu yazıda, en baskın olan üç stratejiyi gözden geçireceğiz.
Mobil e-ticaret kullanışlılık testi sırasında, kullanıcılar genellikle sayfadaki öğeleri yanlışlıkla “tıklıyor”, parmaklarını telefonda ayarlamak veya parmaklarını kaydırmak istiyorlarken (veya kaydırdıklarında) kazara tıklamalar meydana gelebiliyordu.
Kullanıcılar bazen herhangi bir buttona ve link’e tıklamadığı için web’deki kaza ile tıklamalar önemli değildi. Ancak, başka zamanlarda kullanıcıların yanlışlıkla formlarını erken gönderdikleri veya üzerinde durmak istedikleri sayfalardan ayrıldığı gibi dramatik sonuçlar ortaya çıktı. Bu durum bazen kullanıcıların veri kayıplarına kadar ciddi sorunlar oluşmasına sebep oldu.
Dokunmatik cihazlarda kazayla oluşan “tıklamaları” ele almak için ilk adım; doğal olarak onları önlemektir. Bu, kullanıcı arabiriminizdeki farklı alan boyutlarını ve yerleşimlerini dikkatli bir şekilde göz önüne alarak gerçekleştirilirse bu durumun önüne geçilmiş olur. Kazayla yapılan tıklamaları ele almak için farklı stratejiler vardır; Üç temel strateji şunlardır:
1. Too Bad: Kazara yapılan “tıklamalar” basitçe kabul edilir. Olumsuz yönler açıktır. Yanlışlıkla yapılan tıklamaları gerçek anlamda ele almaz; bu kısım, bazı kullanıcıların istemeden işlem gerçekleştireceği anlamına gelir; yani risk durumu en az kısım diyebiliriz.
2. Demonstrate Intent: Kullanıcı, örneğin, bir diyalogda eylemlerini onaylayarak, bir düğmeye basarak, basılı tutarak veya benzer gelişmiş etkileşim vasıtasıyla niyetlerini açıkça göstermelidir. Bu stratejinin dezavantajı, tüm kullanıcılara artan UX yükü ile sistemi yorabilir.
3. Reversibility : Olguların ardından, kullanıcıların eylemlerini “geri almasına” veya sonuçlarını “düzenlemesine” izin verir. Bu, kullanıcıların yavaş ve daha karmaşık kullanıcı arabirimi olan arabirimlerde yanlışlıkla yapılan tıklamaların geri alınmasını sağlar. Bu stratejinin temel dezavantajı, getireceği teknik ve mantıksal zorluklardır.
Bu makalede, bu üç stratejiden her birinin çeşitli tasarımlarını inceleyeceğiz ve örnekleyeceğiz, “ne yapmak uygun olduğunda” gözden geçireceğiz ve stratejilerin nasıl birleştiğini anlatacağım.
Strategy #1: “Too Bad”
Bu kısımda risk oluşturmayan ve kazayla yapılan tıklamaların başvurma seçenekleri olmaksızın gerçekleşmesine izin verirsiniz. Yüksek ciddiyet derecesi olan işlemler için yanlışlıkla bir seçeneği “tıklatan” veya yanlış seçeneği seçen şanssız kullanıcılara yüklediği yüksek UX maliyeti nedeniyle, kabul edilemez bir stratejidir.
Yukarıdaki resimlere sahip olan uygulamada “Siparişi İnceleme Sayfası” bulunmamaktadır ve kullanıcıların siparişlerini “Sipariş Onay” sayfasında kolayca düzenlemesine izin vermez. Sipariş İnceleme sayfası olmadığı için kullanıcı siparişlerini düzenlerken yanlışlıkla siparişi gönder butonuna tıklayarak geri dönüşü olmayan bir hata ile karşılaşabilir ve büyük bir maddi kayıp yaşayabilme riski bulunabilir.
Kazayla yapılan tıklamaların maliyetinin “Sil”, “Gönder” veya “Öde” gibi belirli işlemler için çok yüksek olabileceğini bilmek önemlidir. Bu nedenle, yalnızca birkaç kullanıcının olması durumunda bile, sonuçları tehlikeli olabilir ve dolayısıyla sonraki aşamalarda bu durumu düzeltmeniz için ekstra çaba sarf etmeniz gerekebilir.
Bununla birlikte, “Too Bad” stratejisinin mükemmel bir şekilde iyileştirilebileceği koşullar da mevcut. Örneğin, dosyaların arşivlenmesi veya görevlerin başka bir listeye taşınması gibi bir eylem kritik değilse (ve özellikle sık tekrarlanacaksa), kullanıcıları yavaşlatmak veya işlemleri karışık hale getirmek yerine yalnızca eylemleri kabul etmek daha çekici olabilir. Bunun için(strateji # 3'e bakınız)
Strategy #2: Demonstrate Intent (ya da“Bunu yapmak istediğinize emin misiniz?”)
Kullanıcıların gerçekten de gerçekleştirmek istedikleri eylemi yapmayı planladığından emin olmanın bir yolu, onlardan bunu onaylamalarını istemektir. Bu durumun genellikle uygulanması kolaydır ve en azından yanlışlıkla yapılan tıklamaları önler, ancak otomatik pilot modunda devam edebilecek ve böylece klasik “onayla” iletişim kutusunu kabul etmeye meyilli olan geçici bir şekilde dalgın kullanıcıyı yakalayamazlar.
Resimdeki uygulamanın mobil ödeme süresince şirket logosuna dokunulduğunda, kullanıcıdan gerçekten ödeme işleminden çıkmak istediklerini onaylamalarını isteyen bir iletişim kutusu görüntülenir. Bu, eylemin nadir ve açık olmayan niteliğini göz önüne alan “onaylama” iletişim kutusunun iyi bir şekilde kullanılmasıdır. Tabii ki eylemi geri döndürülemez hale getirmek (kullanıcıların çıkış sayfasındaki kaydedilmemiş alanlar da dahil olmak üzere herhangi bir veri kaybı olmaksızın ödemeye geri dönmesine izin vermek) ideal olabilir.
Kullanıcılardan hareketlerini onaylamalarını istemek (genellikle klasik “onaylama” istemi yoluyla) uygulanması kolay olma eğilimindeyken maalesef kullanıcı deneyimine çok müdahaleci davranmakta ve eylemi gerçekleştiren herkes için çağrılmaktadır. Başka bir deyişle, eylemi gerçekleştirmek niyetinde olanların çoğunu da içeren tüm kullanıcılar tarafından ekstra çaba gerektirir. Örneğin, kullanıcıların yapılacak bir işi tamamladıklarında onaylamalarını gerektiren bir görev listesi düşünün — tabii ki bu durum çoğu kullanıcı için sinir bozucu olabilir.
IOS “Saat” uygulamasında, bir alarmı silmek ancak önce sol “-” işaretine basmak suretiyle yapılabilir. Bunun ardından, ekranın sağ tarafındaki “Sil” düğmesi görüntülenir ve bu butona basılması gerekir. Bu durum kullanıcıya birden fazla tıklama işlemi gerçekleştirerek kullanıcıyı zorlayabilir. Bunun yerine alarmı silmek isteyen kullanıcı alarmı hızlıca kaydırıp veya basılı tutarak silme işlemi yaptırılabilir.
Bir başka örnek vermek gerekirse;
Amazon, mobil uygulamasında “Siparişinizi vermek için hızlıca kaydır” ile denemeler yapılmıştır. Bu, yanlışlıkla yapılan tıklamaları önler, çünkü butona basılması yerine kaydırma işlemi yapılmakta. Ancak yine de bu durum da hatalara sebebiyet verebilir.
Bir eylemi başlatmak için kullanıcıya yatay bir kaydırma / hızlıca basmak kazara “tıklamaları” engeller. Burada önemli olan nokta, kaydırma yönünü sayfa kaydırma yönünün tersine tutmaktır.
Dolayısıyla, ikinci stratejimiz bu nedenle sıklıkla gerçekleştirilen eylemler için arzulanan bir tasarım stratejisidir, ancak daha az kullanılan eylemler için uygun olmayabilir.
Strategy #3: Reversibility (or “Time Machine”)
Kullanıcıların eylemlerini geri alabilmelerine izin vermek son kullanıcı açısından en ideal tasarım stratejisidir diyebiliriz. Ancak form gönderimleri ve “Sil” eylemleri gibi şeyler için, “geri alma” genellikle hem mantıksal hem de teknik açıdan çok daha karmaşıktır.
Yukarıdaki iki resmi kıyasladığımızda soldaki resim strateji 2'yi destekleyerek kullanıcıya silme işlemini onaylatma odaklı işlem yaparken, sağ tarafta bulunan resim ise ideal olan Strateji 3'e ait yani kullanıcıya yanlışlıkla yaptığı işlemleri geri almasına imkan sağlayan tasarımdır.
Kullanıcıya geri dönüşü olmayan silme işlemlerini yaptırırken, her zaman silinen verilerin database tarzı saklama alanlarında saklanarak kullanıcının geri çağırma işlemini yaptığında datanın geri çağrılması en sağlıklı yol olarak gösterilmektedir. Böylece kullanıcı kazara bir tıklama yapmış olsa bile işlemini geri alarak işlemine kaldığı yerden devam edebilir.
Strateji 3'e uyan uygulamalardan biri resimde gösterilen Google Inbox uygulamasıdır. Google Inbox, kullanıcının gerçekleştirebileceği (yani iptal edebileceği) işlem gerçekleşmeden önce küçük bir gecikme süresi getirerek aslında geri döndürülemez bir işlem için geri alma imkanı sunar.
Bir başka örnek vermek gerekirse; Google Keep not uygulaması, kazara tıklama sonucu silinen notu “Arşiv” kısmına alarak notu bu alanda saklar. Daha sonra kullanıcı kazara sildiği notu bu alandan geri yükleyerek mağduriyetini giderir.
Bir iş başvurusunda bulunacağımızı düşünelim; Bu durumda, geri döndürülebilirlik, kullanıcının gönderdikten sonra uygulamanın “geri alınmasına” ya da düzenlemelerine izin vermenizi gerektirecektir. Aynı şekilde online bir sipariş verirken, siparişi verdikten sonra kazara yanlış adreslerinizden birini seçtiğinizi varsayarsak, ürünün yanlış adrese gitmesini önleyebilmek için sipariş sonrası da kullanıcıya siparişi tekrar düzenleme imkanı sağlamalısınız.
Buna göre tüm stratejilerimizi göz önüne alırsak;
Strateji # 1: Kazayla sonuçlanan gönderilerin sıklığı ve kullanıcıya yüklediği UX yükü
Strateji # 2: “Onaylama Eylemi” ile eklenen görev sıralamasının kullanıcıyı sıkması
Strateji # 3: Tüm işlemlerin ertelenmesi ve geri alınmasının uygulanması
olarak tarif edebiliriz.
Kullanıcının yaptığı işlemlerin sıklığı ve kullanıcı işlemlerini yarıda bırakmamak için Strateji 1 ve Strateji 3 kullanılabilir.
Ciddiyet ne kadar yüksek olursa, bunu önlemek de o kadar önemlidir. (yani Strateji 2 “niyet göstermek” veya Strateji 3 “geri dönüşüm” kullanılır.)
Son olarak; kullanıcı deneyimine gereksiz karmaşıklık eklemeden, kullanılabilirlik açısından bakıldığında, çevrilebilme, yeniden düzenlenebilir olmak açıkça idealdir. Geri dönüşümün bazı eylemlerde diğerlerinden daha önemli olduğu açıktır.
Kaynak:
Baymard.com — 3 Strategies for Handling Accidental ‘Taps’ on Touch Devices
