Mobil Giriş ve Kayıt Tasarımı: Hesap Adımını Anlaşılır Kılın

Hesabın yararlı olduğu anı seçin

Kişinin yapmaya geldiği işten başlayın. Temel deneyim hesap olmadan çalışabiliyorsa önce keşfetmesine izin verin; kaydedilen tercihler, cihazlar arası erişim, iş birliği veya işlem gerektiren bir özelliğe ulaştığında giriş isteyin. Apple'ın Human Interface Guidelines rehberi mümkün olduğunda girişi ertelemeyi ve hesap gerektiğinde yararı açıklamayı önerir.

Bağlamsal istem, açılışta karşılaşılan duvardan daha kolay anlaşılır. Örneğin okuma uygulaması kişinin kitaplara göz atmasına izin verip okuma listesini eşitlemeyi seçtiğinde hesap oluşturmasını isteyebilir. Hesap başlangıçtan itibaren zorunluysa alanları göstermeden önce nedenini söyleyin. Açıklamayı somut ve ölçülü tutun: “Projelerinizi kaydedip başka cihazda açmak için hesap oluşturun”, “Topluluğumuza katılın” ifadesinden daha yararlıdır.

• Zorunlu bilgileri isteğe bağlı profil ayrıntılarından ayırın.
• Misafir olarak ödeme veya tek seferlik görevde hesap oluşturmanın, anlık değer sunulduktan sonraya kalıp kalamayacağını değerlendirin.
• Kimlik doğrulama başarılı olduktan sonra kişiyi tamamlamak istediği eyleme götürün.

Giriş seçeneklerini açık ve tanınabilir kılın

Kişi yeni hesap mı oluşturduğunu, yoksa mevcut hesabına mı döndüğünü anlayabilmelidir. İki yola farklı etiketler verin, birincil eylemi görsel olarak açık tutun ve alternatif yöntemleri ekranı bunaltmadan karşılaştırılabilecek yere koyun. Uygun olduğunda sağlayıcı adlarını ve platformun onayladığı düğme görünümlerini kullanın; tek başına genel “Devam et” etiketi sonra ne olacağını açıklamaz.

Yalnızca ürünün desteklediği ve sürdürebileceği yöntemleri sunun. E-posta, geçiş anahtarı veya platform kimliği farklı kitlelere uygun olabilir. Bunları tek yöntemin herkes için en kolay veya en güvenli olduğu iddiası olarak değil, seçenekler olarak sunun. Ek olarak gereken bilgileri açıklayın.

Geri dönen kullanıcılar giriş yöntemlerini hatırlamayabilir. Kurtarma ve alternatif giriş yollarını bulunabilir kılın; e-posta başka bir yöntemle ilişkilendirilmişse ne yapılacağını açıklayın. Hesap bağlama yönergeleri kişilerin mevcut hesaplarına erişimini korumasına yardımcı olabilir.

Formları odaklı ve kişilerin kullandığı araçlarla uyumlu tutun

Yalnızca hesabı oluşturmak veya hesaba erişmek için gereken alanları isteyin. Tek etiket olarak yer tutucu metne güvenmek yerine kalıcı etiketler kullanın, uygun giriş türü ve klavyeyi seçin ve sonraki eylemi açık kılın. Kayıt birden fazla bilgi gerektiriyorsa ilgili alanları gruplayın ve isteğe bağlı tercihleri kişinin ürüne ulaşmasından sonraya bırakın.

Kimlik doğrulama otomatik doldurma ve parola yöneticileriyle çalışmalıdır. Standart alan adlarını ve anlamsal özellikleri kullanın; kimlik bilgisi doldurmayı engelleyen özel davranışlardan kaçının. Parola yapıştırmayı engellemeyin: kişiler parola yöneticisi veya başka bir araç kullanabilir. WCAG rehberi, tarayıcıların ve üçüncü taraf parola yöneticilerinin giriş alanlarını doldurmasına izin verilmesini özellikle belirtir.

Davranış cihazlara ve parola yöneticilerine göre değişebilir; bu nedenle akışı desteklenen platformlarda kontrol edin ve elle düzeltmeye izin verin. Başarısız denemeden sonra uygun olduğunda e-posta adresi gibi hassas olmayan yararlı değerleri koruyun.

• “E-posta adresi” gibi görünür bir etiket ve açık parola etiketi kullanın.
• Uygun olduğunda kişilerin parolayı göstermesine veya kontrol etmesine izin verin; ancak bu denetimi girdiyi düzeltmenin tek yolu yapmayın.
• Birincil düğmeyi alanların yakınına koyun ve “Hesap oluştur” veya “Giriş yap” gibi eyleme özgü etiket verin.

Hataları, kurtarmayı ve sonraki ziyareti tasarlayın

Yararlı bir hata, etkilenen alanı veya başarısız adımı metinle belirler ve kişiye nasıl devam edeceğini söyler. E-posta biçimi geçersizken veya alan boşken “Bir şeyler yanlış gitti” yeterli değildir. WCAG 2.2 Başarı Ölçütü 3.3.1, saptanan giriş hatalarının metinle belirlenip açıklanmasını gerektirir; mesajı yalnızca renk veya simge taşımamalıdır.

Tarafsız dil kullanın ve alana özgü yönergeyi alanın yakınına koyun. Örneğin yanlış biçimlendirilmiş adres için varsayımsal metin şöyle olabilir: “E-posta adresini [email protected] biçiminde girin.” Başarısız girişte ürün şöyle diyebilir: “Bu bilgilerle giriş yapamadık. E-posta adresinizi ve parolanızı kontrol edin veya parolanızı sıfırlayın.” Hata mesajlarında hassas hesap bilgilerini açığa çıkarmayın; ürünün gizlilik ve kötüye kullanım önleme ihtiyaçlarına uygun ifadeler seçin.

Kişi sıfırlama isteğinde bulunduğunda ne olacağını açıklayın, girişe dönüş yolu sunun ve daha önce kullandığı yöntemi bulmasına yardımcı olun. Sonraki ziyaretlerde giriş yapılmış durumu açıkça gösterin; hesap ayarlarına, çıkışa ve yardıma erişim sağlayın. Hesap uygulamada oluşturulabiliyorsa hesap silme yolunu kolay bulunur kılın.

• Hatayı açıkladığı alanla ilişkilendirin ve yalnızca renge bağlı olmadan algılanmasını sağlayın.
• Kurtarma eylemlerini giriş formunun yakınında tutun ve kullanıcıları gereksiz yere baştan başlatmayın.
• Değişen e-posta adresleri ve kullanılamayan giriş yöntemleri dahil ilk kullanım ve geri dönen kullanıcı durumlarını inceleyin.

Pratik hesap akışı incelemesi

Akışı yeni kullanıcı, geri dönen kullanıcı ve erişimini kurtaran kişi olarak izleyin. Ekranları bağlam içinde kontrol edin. Mobil kalıplar kütüphanesi, ekiplerin formların girdileri, etiketleri ve eylemleri nasıl düzenlediğini karşılaştırmasına yardımcı olabilir.

• Hesap zorunlu değilse kişiler giriş yapmadan yararlı ürün değerine ulaşabiliyor mu?
• Ekran hesabın neden gerektiğini ve hangi bilgilerin zorunlu olduğunu söylüyor mu?
• Kişi kayıt, giriş, alternatif yöntemler ve hesap kurtarmayı ayırt edebiliyor mu?
• Alan etiketleri görünür kalıyor mu; otomatik doldurma ve yapıştırma kimlik bilgilerini girebiliyor mu?
• Hatalar sorunu metinle adlandırıyor, yararlı girdileri koruyor ve sonraki adımı öneriyor mu?
• Başarıdan sonra kişi başladığı göreve dönebiliyor mu?