Uygulamalarda Form Tasarımı: Hata Önleme ve Doğrulama

Formlar, bir uygulamada kullanıcının en çok emek harcadığı yerlerdir: üyelik, ödeme, başvuru, profil, ayarlar. Mobilde bu emek daha da artar; ekran küçüktür, klavye ekranın yarısını kaplar, yazım hatası kolaydır. Bu yüzden form tasarımı, hataları güzel göstermekten önce hataları önlemekle ilgilidir. Bu yazı; hata önleme, doğrulama zamanlaması, mobil klavye ve otomatik doldurma, WCAG 2.2'nin form ölçütleri ve Türkiye'ye özgü alanlar üzerinden uygulamalardaki form tasarımını ele alıyor.

Önce alanları azaltın

Hatasız doldurulan alan, hiç sorulmayan alandır. Her alan için şu soruyu sorun: bu bilgi şimdi, bu iş için gerçekten gerekli mi? Gerekli değilse çıkarın; gerekli ama şimdi değilse, ihtiyaç anına erteleyin. Örneğin teslimat adresi sipariş anında, fatura bilgisi ilk ödemede, doğum tarihi yalnız yaşa bağlı bir hizmet varsa istenir.

Bu yalnız bir kullanılabilirlik kararı değil. 6698 sayılı Kişisel Verilerin Korunması Kanunu, kişisel verilerin işlendikleri amaçla bağlantılı, sınırlı ve ölçülü olmasını genel ilkeler arasında sayıyor 8. Yani "ileride lazım olur" diye eklenen her alan, hem form hatası hem de veri yükü riski taşır.

GOV.UK Design System'ın telefon numarası kalıbı da aynı noktadan başlıyor: telefon numarasını yalnız gerçekten ihtiyaç varsa isteyin ve herkesin telefonu olmadığını düşünerek iletişim yöntemi için seçenek sunun 7.

Hata önleme: klavye, otomatik doldurma, tanıdık biçimler

Mobilde hataların büyük kısmı, yanlış klavye ve elle yazılan uzun değerlerden gelir. Platformlar bunu azaltacak araçları zaten sunuyor; tasarımcının işi, her alan için bunların belirtilmesini sağlamaktır.

Birkaç ayrıntı bu tabloyu tamamlar:

• Doğru klavye. Android'de giriş türü, sistemin hangi ekran klavyesini göstereceğini belirler; telefon, e-posta, sayı ve şifre için ayrı türler var. Aynı ayarlarla otomatik düzeltme ve büyük harf davranışı ile klavyedeki eylem tuşu ("İleri", "Gönder", "Bitti") da belirlenir 3. Apple da içeriğe uygun klavye türünü göstermeyi öneriyor 2.
• Otomatik doldurma ipuçları. Android, otomatik doldurma servisinin alanları tahminle tanımaya çalıştığını ve bu tahminin uygulama güncellendikçe değişebileceğini; bu yüzden alanlara açık ipucu verilmesini öneriyor. Şifre ya da kart numarası gibi kullanıcının otomatik doldurma beklediği alanlarda bu özelliği kapatmanın kötü deneyime yol açacağını da ayrıca belirtiyor 4.
• Etiket ayrı, örnek ayrı. Apple, yer tutucu metnin yazmaya başlayınca kaybolduğunu, bu yüzden alanın amacını hatırlatan ayrı bir etiketin de yararlı olduğunu söylüyor 2. Yalnız yer tutucuya dayanan formlarda kullanıcı yazarken neyi doldurduğunu unutur.
• Alan boyu, beklenen girdiyi anlatır. Apple, alanın boyutunu beklenen metin miktarına göre ayarlamayı öneriyor 2. Posta kodu alanının ekran genişliğinde olması, gereksiz bir belirsizlik yaratır.

Doğrulama zamanı: ne zaman, nerede, nasıl?

Hata önlemenin ardından ikinci katman doğrulamadır. Burada en sık yapılan hata, zamanlamadır.

NN/g, kullanıcı alanı bitirip bir sonraki alana geçene kadar hata göstermemeyi öneriyor 1. Kullanıcı e-posta adresinin ilk harfini yazdığı anda "Geçersiz e-posta" uyarısı görmek, henüz yanlış bir şey yapmamış birini uyarmaktır. Apple da aynı ayrımı yapıyor: e-posta adresi gibi alanlarda kontrolü kullanıcı başka bir alana geçtiğinde yapın; kullanıcı adı ya da şifre oluşturmada ise kuralların kullanıcı alandan ayrılmadan görülmesi gerekir 2.

Doğrulama mesajının yeri ve dili için NN/g'nin yönergeleri şöyle özetlenebilir 1:

1. Mesajı hatalı alanın yanına koyun. Kullanıcı düzeltirken mesajı görmeye devam etmeli; mesajı akılda tutmak zorunda kalmamalı.
2. Hatayı yalnız renkle değil, simgeyle de belirtin. Kırmızı en yaygın hata rengidir, ama tek başına yetmez; mesajın yanındaki simge dikkati çeker.
3. Açık, kibar ve yol gösteren bir dil kullanın. "Hatalı giriş" yerine "Telefon numarası 10 haneli olmalı, örneğin 0532 123 45 67" gibi ne yapılacağını söyleyen bir cümle yazın.
4. Girilen veriyi koruyun. Hata sonrası form sıfırlanırsa kullanıcı her şeyi yeniden girmek zorunda kalır.
5. Hata özetini tek gösterge yapmayın. Uzun formlarda üstteki özet yararlı olabilir, ama her hata kendi alanının yanında da görünmelidir.

Hata mesajlarının dili, en az zamanlaması kadar önemlidir. "İşlem başarısız" ile "Kart numarası eksik görünüyor, son haneleri kontrol edin" arasındaki fark, kullanıcının formu bırakması ile düzeltmesi arasındaki farktır. Bu konuyu boş durum ve hata mesajları yazısında örneklerle ele alıyoruz.

WCAG 2.2'nin form ölçütleri: tekrar ve kimlik doğrulama

WCAG 2.2 ile gelen iki başarı ölçütü doğrudan formları ilgilendirir.

3.3.7 Tekrarlı Giriş (A düzeyi). Aynı süreç içinde kullanıcının daha önce girdiği ya da kendisine verilmiş bir bilgi yeniden istenecekse, bu bilgi ya otomatik doldurulmalı ya da seçilebilir olmalıdır. İstisnalar; tekrar girişin zorunlu olduğu durumlar, güvenlik gereği istenen bilgiler ve önceki bilginin artık geçerli olmamasıdır 5. W3C'nin verdiği tipik örnek, teslimat ve fatura adresinin aynı olduğunu tek bir onay kutusuyla belirtebilmektir 5. Çok adımlı başvuru ve ödeme akışlarında bu ölçüt, özellikle bilişsel engelli kullanıcıların yükünü azaltır.

3.3.8 Erişilebilir Kimlik Doğrulama, Asgari (AA düzeyi). Kimlik doğrulamanın hiçbir adımı, şifre hatırlamak ya da bulmaca çözmek gibi bir bilişsel işlev testine dayanmamalı; dayanıyorsa alternatif bir yöntem ya da kullanıcıya yardım eden bir mekanizma sunulmalı 6. W3C'nin açıklamasına göre şifre yöneticilerinin alanı doldurması ya da kopyala-yapıştır engellenirse, alternatif sunulmadıkça ölçüt karşılanmaz. Tek kullanımlık kodlarda da kullanıcı kodu en azından yapıştırabilmeli ve alanlar otomatik doldurulabilmelidir 6.

Uygulama tasarımında bunun pratik karşılığı açık: şifre alanında yapıştırmayı engellemeyin, şifre yöneticisinin çalışmasına izin verin, SMS kodunu dört ya da altı ayrı kutuya bölüyorsanız tek seferde yapıştırılabildiğini test edin.

Türkiye'ye özgü alanlar: telefon, kimlik numarası, tarih ve tutar

Türkçe arayüzlerde bazı alanlar ayrı dikkat ister.

Telefon numarası. Kullanıcılar aynı numarayı "0532 123 45 67", "+90 532 123 45 67" ya da "5321234567" diye yazabilir. GOV.UK Design System'ın önerisi, numaranın kullanıcıya tanıdık biçimde girilmesine izin vermek; ek boşluk, tire ve parantezleri kabul etmek ve ülke kodunu karşılayabilmek 7. Aynı kaynak, hata durumunda doğru biçimi örnekle gösteren bir mesaj yazmayı ve gerekiyorsa cep telefonu mu, sabit hat mı istendiğini etikette belirtmeyi öneriyor 7. Türkiye için pratik yaklaşım: bütün bu biçimleri kabul edin, arka planda tek bir biçime çevirin, kullanıcıya hata yalnız numara gerçekten eksik ya da fazla haneliyse gösterin.

T.C. kimlik numarası. Bu alan, birçok formda gerekmediği hâlde "nasılsa lazım olur" diye bulunur. Fatura, sözleşme ya da yasal bir yükümlülük gibi somut bir gerekçe yoksa sormayın; bu, KVKK'nın sınırlı ve ölçülü işleme ilkesiyle de uyumludur 8. Gerekliyse etiketin yanında kısa bir gerekçe yazın ("Fatura düzenlemek için gereklidir.") ve alanı sayısal klavyeyle sunun.

Tarih ve tutar. Türkçede tarih gün.ay.yıl sırasıyla, ondalık ayırıcı ise virgülle yazılır. Apple, sayısal alanlarda biçimlendirici kullanmayı ama verinin nasıl görüneceğini varsaymamayı, çünkü biçimin yerel ayara göre çok değiştiğini hatırlatıyor 2. "1.250,50" yazan bir kullanıcının girişini hata saymak, tasarımın Türkiye bağlamını hesaba katmadığını gösterir. Doğum tarihi gibi alanlarda, uzun bir kaydırmalı tarih seçici yerine gün, ay ve yıl için ayrı sayısal alanlar çoğu zaman daha hızlıdır.

Formu test etmek

Form tasarımının doğruluğu, ancak gerçek kullanıcılar gerçek cihazlarda doldurduğunda görülür. Masaüstündeki bir tasarım dosyasında kusursuz görünen form, telefonda klavye açıldığında "Devam" butonunu gizleyebilir, hata mesajı klavyenin altında kalabilir ya da otomatik doldurma yanlış alana adres yazabilir.

Test planına şunları ekleyin: formu yalnız ekran klavyesiyle ve tek elle doldurmak, otomatik doldurmayı açık ve kapalı denemek, bilerek hatalı veri girip mesajları okumak, ekran okuyucuyla hata mesajlarının duyurulup duyurulmadığına bakmak ve en büyük yazı boyutunda formun bozulup bozulmadığını görmek. Kısa, moderasyonlu bir kullanılabilirlik testi, katılımcının hangi alanda duraksadığını doğrudan gösterir. Erişilebilirlik tarafındaki ayrıntılar için mobil uygulama erişilebilirliği yazısına bakabilirsiniz.

SaaS ürünlerinde formlar çoğu zaman ürünün kendisidir: kayıt, ayarlar, kayıt düzenleme ekranları ve çok adımlı sihirbazlar. Bu tür ürünlerde form kalıplarını nasıl standartlaştırdığımızı SaaS ürün tasarımı sayfamızda bulabilirsiniz.