Giriş ve kayıt ekranı tasarımı

Kısaca

Giriş ve kayıt ekranları kısa formlardır, ama ürünün kapısıdırlar. Kapıda takılan kişi içeride ne olduğunu hiç görmez.

Bu kalıpta önce kapının gerekip gerekmediğine bakarım. Sonra şifre kurallarına ve hata mesajına geçerim. En son, tarayıcının alanları doldurabildiğini kontrol ederim. Alan yerleşimi ve doğrulama zamanı için genel kurallar form tasarımı sayfasında.

Kötü ve iyi giriş ekranı

Aşağıda aynı hesaba giren iki ekran var. Solda audit'lerde sık gördüğüm kötü örnek, sağda bu sayfadaki kuralları izleyen ekran duruyor. Dar ekranda ikisi alt alta dizilir.

Kötü ve iyi giriş ekranı

Deneme hesabı: [email protected], şifre mavi-kapi-42. Şifreyi kopyalayıp iki ekrana da yapıştırmayı deneyin.

Kötü

Kilitli şifre, belirsiz hata

Yapıştırınca: şifre alanı yapıştırmayı engeller. Göster düğmesi yok, autocomplete kapalı.

Giriş yap'a basınca: üstte "Hatalı işlem" yazar ve iki alan da boşalır. Şifremi unuttum bağlantısı hiç yok.

İyi

Görünür etiket, alan yanında hata

E-posta

ŞifreŞifremi unuttum

Yapıştırınca: şifre alana gelir. Şifreyi göster düğmesiyle yazdığınızı kontrol edersiniz.

Giriş yap'a basınca: boş ya da yanlış biçimli alanın yanında ne yapacağınız yazar. Bilgiler eşleşmezse yalnızca şifre alanı boşalır.

Şifremi unuttum: gerçek üründe e-posta soran tek alanlı bir sayfa açılır. Ardından "Bu adres kayıtlıysa sıfırlama bağlantısını gönderdik" yazar.

İki ekranda aynı iki alan var. Önce ikisini boş gönderin. Sonra şifreyi kopyalayıp yapıştırın ve yanlış bir şifreyle deneyin. Demo hiçbir yere veri göndermez.

Farkı en hızlı şifreyi yapıştırınca görürsünüz. Kötü ekran şifre yöneticisini dışarıda bırakır. İyi ekranda kopyala ve yapıştır çalışır, göster düğmesi de yazım hatasını yakalamanızı sağlar.

Giriş ve kayıt ayrı kapılar

Giriş yapacak kişi ile hesap açacak kişi farklı şeyler arar. Biri iki alan ister, diğeri neye kaydolduğunu bilmek ister. Bu yüzden iki akışı ayrı ekranlarda ya da açıkça ayrılmış iki sekmede kurarım.

Her ekranın başlığı ne yaptığını söylemeli: "Giriş yapın" ya da "Hesap oluşturun". Altında da öbür kapıya giden kısa bir yol durmalı: "Hesabınız yok mu? Hesap oluşturun."

Bu ayrımın neden önemli olduğunu Jared Spool'un 2009 yazısı gösterir. Bir e-ticaret sitesinde müşterilerin %45'inin sistemde birden fazla kaydı varmış. Bazılarında bu sayı 10'u buluyormuş. Tekrar gelen müşteriler de çoğu zaman hangi e-postayla ya da şifreyle kaydolduklarını hatırlamıyormuş.

Misafir seçeneği

Kullanıcı işini hesapsız bitirebiliyorsa ona hesap açtırmayın. Ödeme, randevu ya da tek seferlik başvuru bu gruba girer.

Spool'un anlattığı vakada tasarımcılar Kayıt ol düğmesini kaldırıp yerine Devam düğmesi koydu. Yanına da alışveriş için hesap açmanın gerekmediğini söyleyen bir not eklediler. Satın alan müşteri sayısı %45 arttı. Ek gelir ilk ayda 15 milyon dolar, ilk yılda 300 milyon dolar oldu. Hikayenin tamamı 300 milyon dolarlık buton sayfasında.

Baymard Institute'un sepet terk listesinde "sadece bakıyordum" cevabı ayrıldığında, sepeti bırakanların %18'i "site benden hesap oluşturmamı istedi" diyor. NN/g'den Raluca Budiu da 2014 yazısında misafir ödeme seçeneği önerir. Hesap teklifini alışveriş bittikten sonra yapmanızı söyler.

Bankacılık ya da e-posta gibi kişisel ürünlerde giriş duvarı kaçınılmazdır. Diğer ürünlerde kapıyı, ürünün değerini gösterdikten sonra kurmaya çalışırım. Ödeme sayfası kalıbında misafir akışının yerini ayrıca anlattım.

Şifre kuralları

Şifre kuralları için ABD'nin standartlar enstitüsü NIST'in SP 800-63B-4 belgesine bakarım. Belgenin son hali Temmuz 2025'te yayımlandı. Kayıt ekranını doğrudan etkileyen maddeler şunlar:

• Tek başına kullanılan şifre en az 15 karakter olmalı. Şifre yalnızca iki adımlı doğrulamanın bir parçasıysa alt sınır 8 karakter.
• En az 64 karakterlik şifreye izin verilmeli. Sistem şifreyi kesmeden, bütünüyle kontrol etmeli.
• "Büyük harf, rakam ve sembol içersin" gibi karışım kuralları konmamalı.
• Kullanıcı belirli aralıklarla şifre değiştirmeye zorlanmamalı. Hesabın ele geçirildiğine dair bir iz varsa değişiklik istenir.
• Yeni şifre, sık kullanılan ve sızmış şifrelerin listesiyle karşılaştırılmalı. Servisin adı ve kullanıcı adı da bu listeye girer.
• Şifre yöneticisi ve otomatik doldurma serbest olmalı. Yapıştırmaya izin verilmesi önerilir.
• Şifre ipucu saklanmamalı, güvenlik sorusu sorulmamalı.

Kuralı kullanıcıya baştan söyleyin. NN/g'den Katie Sherwin 2015 yazısında şifre koşullarının şifre oluşturulurken görünür olmasını ister. Koşulu etiketin içine sıkıştırmamanızı da ekler.

"Şifreyi tekrar girin" alanına da çoğu zaman gerek yok. GOV.UK Design System bu alandan kaçınmanızı söyler, çünkü göster düğmesi kullanıcının yazdığını kontrol etmesine yeter.

Şifreyi göster

Gizli şifre alanı yazım hatasını saklar. Kullanıcı yanlış yazdığını ancak hata mesajından öğrenir. NIST de şifre yazılırken onu gösterme seçeneği sunulmasını önerir.

Şifrenin baştan görünüp görünmeyeceğinde kaynaklar ayrışıyor. GOV.UK şifreyi varsayılan olarak gizler, çünkü kullanıcı herkese açık bir yerde olabilir. Sherwin ise mobilde ve tablette şifrenin baştan görünmesini, yanında bir Gizle düğmesi olmasını önerir.

Ben gizli başlatırım ve düğmeyi alanın hemen yanına koyarım. Düğmenin durumu ekran okuyucuya da gitmeli. Yukarıdaki örnekte bunu aria-pressed ile yaptım.

Şifremi unuttum

Bu bağlantı şifre alanının hemen yanında, her zaman görünür durur. Yalnızca hatadan sonra beliren bir bağlantı, ihtiyacı olan kişiye geç kalır.

Spool'un vakasındaki site günde yaklaşık 160.000 şifre talebi alıyormuş. Şifre isteyenlerin %75'i ise satın almayı bir daha denememiş. Yani unutulan şifre doğrudan satışa dokunur.

Sıfırlama ekranı tek alan sorar: e-posta. Gönderimden sonra çıkan mesaj, adresin kayıtlı olup olmadığını söylememeli. OWASP'ın kimlik doğrulama rehberi bunun için şu cevabı örnek verir: "Bu e-posta adresi veritabanımızdaysa şifre sıfırlama e-postası göndereceğiz." Çeviri benim.

Sosyal giriş

Google ya da Apple ile giriş, şifre yazmadan hesap açmayı sağlar. Ben bu düğmeleri e-postayla girişin yanında sunarım, onun yerine değil. Her kullanıcının o hesaplardan biri olmayabilir, olan da onu bağlamak istemeyebilir.

Audit'lerde gördüğüm sorun şu: kullanıcı geçen sefer hangi yolla girdiğini hatırlamıyor. Bu yüzden düğme sırasını her ekranda aynı tutarım. Mümkünse son kullanılan yolu da işaretlerim.

Sosyal girişten gelen kişiden bilgileri yeniden istemeyin. Hesaptan gelen ad ve e-postayı gösterin, kullanıcı yalnızca onaylasın.

E-posta doğrulama ne zaman istenmeli

Ben doğrulamayı kapıda değil, gerektiği yerde isterim. Kullanıcı kaydolunca ürünü hemen kullanmaya başlar. Doğrulama ise ödeme ya da paylaşım gibi bir adımdan önce ya da ilk birkaç günün içinde gelir.

Kaydın hemen ardından gelen bir "önce e-postanızı doğrulayın" duvarı, kullanıcıyı uygulamadan e-postaya gönderir. Oradan geri dönmeyen kişiyi kaybedersiniz.

Doğrulama e-postayla gelen bir bağlantıysa bu, W3C'nin 3.3.8 için saydığı yeterli tekniklerden biridir. Kodla doğrulamada kod alanı yapıştırmaya açık olmalı. Alana autocomplete="one-time-code" ekleyin.

Giriş hata mesajları

Giriş ekranında iki tür hata var ve ikisi farklı yazılır. Biçim hatası alanın yanında çıkar ve neyin yanlış olduğunu söyler: "E-posta adresini [email protected] biçiminde yazın."

Bilgiler eşleşmediğinde ise mesaj hangi alanın yanlış olduğunu söylememeli. GOV.UK, bu ayrıntının dolandırıcıların hesaplara girmesine yardım edebileceğini yazar. OWASP da hesabın var olup olmadığını ele vermeyen genel bir cevap ister.

GOV.UK başarısız girişten sonra şifre alanının temizlenmesini ister. E-posta alanını ise yerinde bırakırım. Mesajın sonuna da bir çıkış yolu eklerim: "Tekrar deneyin ya da şifrenizi sıfırlayın." Mesaj yazma kurallarını hata mesajları kalıbında topladım.

Autocomplete öznitelikleri

autocomplete tarayıcıya ve şifre yöneticisine alanın ne olduğunu söyler. Değer doğruysa şifre yöneticisi alanları kendisi doldurur. Değerlerin anlamı MDN'den:

Alan	Değer	Ne demek
Giriş: e-posta ya da kullanıcı adı	username	MDN'ye göre kullanıcı adı ya da hesap adı.
Giriş: şifre	current-password	Kullanıcının mevcut şifresi.
Kayıt ve şifre değiştirme: yeni şifre	new-password	Tarayıcı bunu, eski şifreyi yanlışlıkla doldurmamak ve güçlü şifre önermek için kullanabilir.
Kayıt: e-posta	email	E-posta adresi.
Doğrulama kodu	one-time-code	Girişte ek adım olarak istenen tek kullanımlık kod. Çoğu zaman SMS, e-posta ya da doğrulama uygulamasıyla gelir.

Girişte e-posta alanına username yazarım, çünkü o alan hesabın adıdır. MDN, giriş alanlarında tarayıcıların autocomplete="off" değerini yok sayabileceğini de not eder. Bence kapatmanın tek sonucu, şifre yöneticisi kullananların işini zorlaştırmak.

Erişilebilir kimlik doğrulama: WCAG 3.3.8

WCAG 2.2'deki 3.3.8 Erişilebilir Kimlik Doğrulama (Asgari) ölçütü AA düzeyindedir. Kimlik doğrulamanın hiçbir adımında bilişsel bir test zorunlu olmamalı. Şifre hatırlamak ya da bulmaca çözmek buna örnektir.

Ölçüt dört istisna tanır: bilişsel test içermeyen başka bir yol, teste yardım eden bir mekanizma, nesne tanıma ve kullanıcının kendi yüklediği içeriği tanıma. W3C, şifre yöneticisini ve kopyala yapıştırı bu mekanizmaya örnek verir.

W3C'nin açıklama sayfası sonuçları açıkça yazar:

• Şifre yöneticisini ya da yapıştırmayı engelleyen giriş, başka bir yol yoksa ölçütü geçemez.
• Doğrulama kodunu elle yazdıran servis uyumlu değildir. Kod alanı yapıştırmayı kabul etmelidir.
• Bulmaca türü doğrulama da bilişsel test içermeyen bir yol ister. Duyduğunu yazdıran sesli alternatif bu yolun yerine geçmez.

Ölçütü diğer WCAG 2.2 yenilikleriyle birlikte WCAG rehberinde anlattım.

Benim notum

Audit'lerde giriş ekranında en sık gördüğüm hata yapıştırma engeli. Ekip bunu güvenlik önlemi sanıyor. Oysa NIST yapıştırmaya izin verilmesini öneriyor, WCAG de başka bir giriş yolu yoksa engeli bir erişilebilirlik hatası sayıyor.

İkinci sırada "Hatalı işlem" gibi mesajlar var. Genel mesaj güvenlik için doğru, ama kullanıcıyı ne yapacağını bilmeden bırakmamalı. Sıfırlama bağlantısını mesajın içine koyarsanız ikisini birden sağlarsınız.

Kayıt ekranında ise sorulan alan sayısına bakarım. Ad, soyad, telefon ve doğum tarihi çoğu zaman ilk gün gerekmez. Yalnızca e-posta ve şifreyle başlatıp gerisini ihtiyaç anında sorarım.

Kontrol listesi

Bir giriş ve kayıt akışını yayına almadan önce bu listeden geçerim. Kendi ekranlarınızı bu listeyle benim kontrol etmemi isterseniz UX Audit bunların hepsini kapsar.

• Kullanıcı işini hesapsız bitirebiliyorsa misafir seçeneği var.
• Giriş ve kayıt ayrı, başlıkları ne yaptıklarını söylüyor.
• Şifre kuralı kayıt ekranında baştan yazıyor, karışım kuralı yok.
• Şifre alanına yapıştırma çalışıyor, şifre yöneticisi alanı dolduruyor.
• Şifreyi göster düğmesi var ve durumu ekran okuyucuya iletiliyor.
• Şifremi unuttum bağlantısı şifre alanının yanında, hep görünür.
• Biçim hatası alanın yanında, giriş hatası genel ama çıkış yolu gösteriyor.
• E-posta, şifre ve kod alanlarında doğru autocomplete değeri var.
• Doğrulama kodu yapıştırılabiliyor.