Form tasarımı: kurallar ve örnekler

Kısaca

Form, ürünün kullanıcıdan bir şey istediği yerdir. Kayıt, ödeme, başvuru ya da iletişim: asıl iş çoğu üründe bu ekranlarda görülür.

Bir formda iki şeye bakarım: sorulara ve kullanıcı yanlış girince ne olduğuna. Aşağıdaki 23 kuralın sekizi doğrudan hatalarla ilgili.

Baymard Institute'un 2024 yazısına göre kullanıcıların %17'si ödemeyi karmaşık bulduğu için yarıda bırakmış. Aynı yazı, ortalama ödeme akışını 5,1 adım ve 11,3 alan olarak verir.

Ne zaman kullanılır

Kullanıcıdan yazılı bilgi istediğiniz her yerde bu kalıp geçerlidir. Tek alanlı bir bülten kaydı da, on adımlı bir kredi başvurusu da formdur.

• Kayıt ve giriş. Alan sayısı azdır, ama kullanıcı ürüne bu kapıdan girer.
• Ödeme ve adres. Adres ve kart bilgisi alan sayısını hızla artırır.
• Başvuru ve kamu hizmeti. GOV.UK Design System her soru sayfasında tek soru sormayı önerir. Gerekçesi, kullanıcının o soruya ve cevabına odaklanabilmesidir.
• İletişim ve destek. Kullanıcı buraya çoğu zaman bir sorunla gelir. Form o sorunu büyütmemeli.

Formu kurmadan önce kendime şunu sorarım: bu bilgiyi kullanıcıya sormadan bulabilir miyim? Cevap evetse alanı hiç çizmem. Alan sırasını da önce kâğıtta, kaba bir wireframe ile kurarım.

Form tasarım kuralları

Her kural tek cümle, altında kısa bir gerekçe var. Kaynağı olan kuralın kaynağını yanına yazdım, tam künye sayfanın sonunda.

1. Yalnızca gerçekten gereken alanları sorun. NN/g'den Kathryn Whitenton, başka yoldan bulunabilen, sonra daha rahat sorulabilen ya da hiç sorulmasa da olacak alanları çıkarmanızı ister. Baymard'ın 2024 verisine göre ortalama ödeme akışında 11,3 alan var. Çoğu site 8 alanla yetinebilir.
2. Alanları tek kolonda dizin. Whitenton'a göre birden fazla kolon, formda aşağı doğru ilerleyişi böler. Şehir ve posta kodu gibi kısa, ilişkili alanlar aynı satırı paylaşabilir.
3. İlgili alanları gruplayın ve etiketi kendi alanına yakın koyun. Whitenton etiketin anlattığı alana yakın durmasını ister. Etiket iki alanın ortasında kalırsa kullanıcı onun hangi alana ait olduğunu tahmin etmek zorunda kalır.
4. Etiketi alanın üstüne, alanın dışına yazın. NN/g'den Katie Sherwin en iyi çözümün, boş alanın dışında duran görünür etiket olduğunu yazar.
5. Yer tutucu metni etiket yerine kullanmayın. GOV.UK'ye göre yer tutucu, kullanıcı yazmaya başlayınca kaybolur ve her ekran okuyucu onu okumaz. Sherwin, kullanıcının onu dolu bir değer sanıp alanı atlayabildiğini de ekler.
6. Biçim kuralını hata çıkmadan önce, alanın dışında söyleyin. Whitenton, alan belirli bir biçim istiyorsa talimatın tam olarak yazılmasını ister. Şifre kurallarını kullanıcıya tahmin ettirmemenizi de ekler. Kuralı ancak hata mesajında öğrenen kişi aynı alanı iki kez doldurur.
7. Etiketi kısa ve doğrudan yazın, yalnızca ilk harfi büyük olsun. GOV.UK, etiketin sonuna iki nokta konmamasını da söyler. "E-posta" yeter, "E-Posta Adresiniz:" gerekmez.
8. Zorunlu alanları tek tek işaretleyin. NN/g'den Raluca Budiu'ya göre formun başındaki "Tüm alanlar zorunludur" notu kolayca gözden kaçar. Her zorunlu alanı işaretlemenizi ister. Yıldızı etiketin önüne koymanın taramayı kolaylaştırdığını da yazar.
9. İsteğe bağlı alan azsa onu "isteğe bağlı" diye yazın. Whitenton isteğe bağlı alanları bir ya da ikiyle sınırlamanızı ve açıkça etiketlemenizi ister. Böylece kullanıcı kuralı deneme yanılmayla öğrenmez.
10. Alanın genişliğini beklenen cevabın uzunluğuna göre seçin. GOV.UK'nin örneği şöyle: posta kodu alanı, posta kodu boyunda olmalı. Doğru boyut, kullanıcının ne yazacağını anlamasına yardım eder.
11. İki ya da üç seçenek varsa açılır liste yerine radyo düğmesi kullanın. Whitenton bu öneriyi verir. Seçenekler açıkta durunca kullanıcı listeyi açmadan karar verir.
12. Alanları alışılmış sırayla dizin ve Tab sırasını görsel sırayla aynı tutun. Whitenton klavyeyle Tab sırasının test edilmesini ister. Odak ekranda zıplarsa klavye kullanıcısı yolunu kaybeder.
13. Kullanıcı yazarken hata göstermeyin. NN/g'den Rachel Krause, alandan çıkılana kadar beklemenizi söyler. Baymard'a göre erken çıkan hata, kullanıcının doğru girdiği değeri yanlış sanmasına yol açabilir.
14. Hata mesajını alanın hemen yanına koyun. Krause'a göre bu, kullanıcının hatayı düzeltirken mesajı okuyabilmesini sağlar. Mesajı hatırlamak zorunda kalmaz.
15. Kullanıcı hatayı düzelttiği anda mesajı kaldırın. Baymard, düzeltmeden sonra kalan mesajın özellikle şifre tekrarı gibi birbirine bağlı alanlarda kafa karıştırdığını yazar.
16. Hatayı yalnızca renkle göstermeyin. Krause kırmızı rengin yanına bir ikon eklenmesini ister. WCAG 2.2'nin 3.3.1 ölçütü de hatanın metinle anlatılmasını şart koşar.
17. Mesajda ne olduğunu ve nasıl düzeltileceğini söyleyin. GOV.UK "Bu alan zorunludur" gibi genel mesajlardan kaçınmanızı ister. Boş alan için "Adınızı yazın" gibi bir talimat yazın.
18. Mesajda suçlama, özür ve "geçersiz" kelimesi kullanmayın. "Unuttunuz", "lütfen", "üzgünüz" ve "geçersiz" kelimelerinin İngilizceleri GOV.UK'nin kaçınılacaklar listesinde var. Bu kelimeler kullanıcıya neyi düzelteceğini söylemez.
19. Gönderimde hata varsa formun üstünde bir özet gösterin ve odağı oraya taşıyın. GOV.UK Validation kalıbı böyle çalışır. Krause yalnızca özete güvenmemenizi de ekler, çünkü kullanıcı her alanı yine aramak zorunda kalır.
20. Kullanıcının yazdıklarını silmeyin. GOV.UK hem doğru hem yanlış cevapların yerinde kalmasını ister. Kullanıcı neyin yanlış gittiğini ancak böyle görür.
21. Formun sonuna Sıfırla ya da Temizle düğmesi koymayın. Whitenton'a göre yanlışlıkla her şeyi silmenin zararı, baştan başlamak isteyene sağladığı kolaylıktan büyüktür.
22. Kullanıcıya ait alanlara autocomplete ekleyin. GOV.UK'ye göre böylece tarayıcı, kullanıcının daha önce girdiği bilgiyi kendisi doldurur. GOV.UK, WCAG 2.2'nin 1.3.5 ölçütünü karşılamak için de bunun gerektiğini yazar.
23. Aynı süreçte aynı bilgiyi ikinci kez yazdırmayın. WCAG 2.2'nin 3.3.7 ölçütü, daha önce girilen bilginin otomatik doldurulmasını ya da seçilebilmesini ister.

Kural 18 için bir not: GOV.UK'nin listesi İngilizce kelimelerden oluşur. Ben aynı mantığı Türkçe karşılıklarına uyguluyorum.

Yap ve yapma

Kötü ve iyi form örneği

Aşağıda aynı üç alanı soran iki form var. Solda kötü örnek, sağda bu sayfadaki kuralları izleyen form duruyor. Dar ekranda iki form alt alta dizilir.

Kötü ve iyi form

Kötü

Yer tutucu etiket, erken hata

GönderTemizle

Yazarken: ilk harfte alan kırmızıya döner. Yanında bir açıklama yoktur.

Gönder'e basınca: üstte genel bir uyarı çıkar ve bütün alanlar boşalır. Telefon numarasında boşluk olmaması gerektiği hiçbir yerde yazmaz.

İyi

Üstte etiket, alanın yanında hata

Ad soyad

E-posta

Size bu adresten döneceğim

Telefon (isteğe bağlı)

Örnek: 0532 123 45 67

Gönder

Yazarken: hata göstermez. Alandan çıkınca biçimi kontrol eder, düzelttiğiniz anda mesajı kaldırır.

Gönder'e basınca: üstte sorunların listesi çıkar ve odak oraya gider. Her mesaj kendi alanının yanında durur, yazdıklarınız silinmez.

İki formda aynı üç alan var. Önce iki formu boş bırakıp Gönder'e basın. Sonra e-postaya "ali@" yazıp telefonu boşluklu girin ve tekrar deneyin. JavaScript kapalıysa her formun altındaki not, Gönder'e basınca ne olacağını anlatır.

İki formun farkını en hızlı Gönder'e basınca görürsünüz. Kötü form "bir şey yanlış" der ve sizi baştan başlatır. İyi form neyin yanlış olduğunu ve nereye bakacağınızı söyler.

Telefon alanında fark daha net. Kötü form "0532 123 45 67" yazımını reddeder ve nedenini söylemez. İyi form aynı yazımı kabul eder, boşlukları ve parantezleri kendisi temizler.

Aynı mantık IBAN, kart numarası ve T.C. kimlik numarası gibi uzun sayılarda da geçerlidir. Kullanıcı bunları grup grup yazabilir. Form bu grupları kabul etmeli, kaydederken boşlukları atmalıdır.

Benim notum

Canlı doğrulamanın ne zaman yapılacağında kaynaklar aynı şeyi söylemiyor. NN/g ve Baymard alandan çıkınca kontrol etmeyi önerir. GOV.UK ise kontrolü kullanıcı Gönder ya da Devam'a bastığında yapmanızı ister.

GOV.UK yazarken doğrulamaya tek bir koşulla izin verir. Kullanıcı araştırması, bunun çözdüğü sorunların yarattıklarından fazla olduğunu göstermelidir. Örnek olarak karakter sayacını verir.

Yukarıdaki iyi formda ikisini birleştirdim. Boş alanı gönderimde uyarırım, çünkü kullanıcı o alana birazdan dönebilir. Yazılmış ama yanlış biçimli bir değeri ise alandan çıkınca gösteririm.

Bence en pahalı form hatası, hatadan sonra alanların boşaltılmasıdır. GOV.UK da alanların kullanıcının doldurduğu haliyle geri gösterilmesini ister. Boşaltmak, Nielsen'in 10 kullanılabilirlik ilkesinin dokuzuncusuna da aykırıdır: kullanıcı hatayı tanıyabilmeli, anlayabilmeli ve düzeltebilmelidir.

Erişilebilirlik notu

Erişilebilirlik denetiminde formlar ilk baktığım yerlerdendir. Bir formda önce şu dört WCAG 2.2 ölçütünü kontrol ederim.

• 3.3.2 Etiketler ya da talimatlar (A düzeyi). Kullanıcıdan girdi alan her yerde etiket ya da talimat olmalıdır. W3C'ye göre yalnızca yardımcı teknolojiye görünen bir ad bu ölçütü karşılamayabilir.
• 3.3.1 Hata tanımlama (A düzeyi). Otomatik bulunan hatada hatalı alan belirtilmeli ve hata metinle anlatılmalıdır. W3C'ye göre renk gibi görsel ipuçları ancak bu metne ek olarak kullanılır.
• 1.3.5 Girdi amacını belirleme (AA düzeyi). Kullanıcı hakkında bilgi toplayan alanın amacı makinece okunabilmelidir. W3C'nin HTML için gösterdiği yeterli teknik autocomplete özniteliğidir.
• 3.3.7 Tekrarlı giriş (A düzeyi). Aynı süreçte daha önce girilen bilgi tekrar istenirse otomatik doldurulmalı ya da seçilebilmelidir.

GOV.UK hata mesajının başına ekranda görünmeyen bir "Error:" öneki koyar. Ekran okuyucu kullanıcısı önce bunun bir hata olduğunu duyar. Validation kalıbı, hata olunca sayfa başlığının başına da "Error: " eklenmesini ister.

Türkçe sayfada bu öneki "Hata:" diye yazıyorum. Bir formu baştan sona nasıl denetlediğimi erişilebilirlik denetimi rehberinde, ölçütlerin tamamını WCAG rehberinde anlattım.

Uygulama notu

İyi formdaki e-posta alanının sade HTML hali aşağıda. Etiket, ipucu ve hata satırı alana for ve aria-describedby ile bağlı.

<form action="/basvuru" method="post" novalidate>
  <div class="field">
    <label class="field__label" for="eposta">E-posta</label>
    <p class="ipucu" id="eposta-ipucu">Size bu adresten döneceğim</p>
    <!-- Hata yoksa bu satır gizli kalır. -->
    <p class="hata" id="eposta-hata" hidden>
      <span class="sr-only">Hata: </span>E-posta adresini [email protected] biçiminde yazın
    </p>
    <input class="field__control" id="eposta" name="eposta"
           type="email" autocomplete="email" spellcheck="false"
           aria-describedby="eposta-ipucu eposta-hata">
  </div>
  <button class="btn btn--primary" type="submit">Başvuruyu gönder</button>
</form>

Formdaki novalidate, tarayıcının kendi hata baloncuklarını kapatır. GOV.UK bunu ister ve alanlara required eklenmemesini söyler. Hata metnini böylece kendiniz yazarsınız.

Tarayıcıdaki kontrol her zaman çalışmayabilir. GOV.UK bu yüzden sunucuda da her zaman doğrulama yapılmasını ister.

Hata olunca alana aria-invalid="true" eklerim ve hata satırındaki hidden özniteliğini kaldırırım. Formu tasarımdan koda kadar benim yapmamı isterseniz bu iş Tasarla ve Yayınla Sprinti kapsamına girer.

Kontrol listesi

Bir formu yayına almadan önce bu listeden geçerim. Kendi formunuzu bu listeyle benim kontrol etmemi isterseniz UX Audit bunların hepsini kapsar.

• Her alanın neden sorulduğunu bir cümleyle söyleyebiliyorum.
• Alanlar tek kolonda, ilgili olanlar gruplu.
• Her alanın üstünde görünür bir etiket var, yer tutucu etiket değil.
• Biçim kuralları, hata çıkmadan önce alanın yanında yazıyor.
• Zorunlu ve isteğe bağlı alanlar ayırt ediliyor.
• Yazarken hata çıkmıyor, düzeltilen hata hemen kalkıyor.
• Her hata alanının yanında, metin ve ikonla görünüyor.
• Gönderimde üstte bir özet çıkıyor ve odak oraya gidiyor.
• Hata sonrası hiçbir alan boşalmıyor.
• Kullanıcıya ait alanlarda autocomplete var.
• Tab sırası görsel sırayla aynı.
• Sunucu tarafında da doğrulama var.