Diş kliniği sitesinde randevu almayı zorlaştıran tasarım hataları arasında belirsiz randevu butonları, anlaşılmayan alan etiketleri, mobilde zor kullanılan kontroller ve yetersiz hata mesajları bulunur. Çözüm, ziyaretçinin randevu yolunu bulmasını, formu tamamlamasını ve gönderim sonucunu anlamasını birlikte değerlendirmektir. Bunlar genel kullanılabilirlik sorunlarıdır; belirli bir kliniğin randevu kaybettiğini veya kaybın tek nedeninin tasarım olduğunu kanıtlamaz.
İçerikte Neler Okuyacağım?
Diş kliniği randevu butonu tasarımı: Kullanıcı nereye yönlendiriliyor?
Ziyaretçi, ana sayfadan değil doğrudan bir tedavi sayfasından siteye girebilir. Bu nedenle randevuya ulaşma yolunu yalnızca ana sayfada kontrol etmek yeterli değildir. Randevu bağlantısı belirsiz bir menü adı altında kalıyorsa kullanıcı işlemi nereden başlatacağını anlamayabilir.
Kontrolün metni, gerçekleşecek eylemi açıklamalıdır. Telefon aramasını başlatan bağlantıda “Kliniği ara”, talep formunu açan bağlantıda “Randevu talep formu”, doldurulan formu gönderen butonda ise “Randevu talebini gönder” gibi ifadeler kullanılabilir. Bunlar örnek metinlerdir; seçim sitenin gerçek işleyişine göre yapılmalıdır. Aynı “Randevu al” ifadesini farklı sonuçlar doğuran bütün kontrollere vermek beklentiyi belirsizleştirir.
Başka sayfaya götüren bağlantı ile form gönderen butonun davranışı ve görünümü tutarlı olmalıdır. Her site için geçerli tek bir renk veya konum yoktur. Önemli olan kontrolün çevresinden ayırt edilmesi ve ne yaptığının anlaşılmasıdır. Mobilde sabit bir randevu butonu kullanılıyorsa ekran klavyesi açıldığında da form alanlarını veya gönderim butonunu kapatmadığı kontrol edilmelidir.
Randevu formunda hangi alanlar kullanıcıyı durduruyor?
Formun uzunluğunu yalnızca alan sayısıyla değerlendirmeyin. Her alan için “Bu bilgi olmadan ilk talebi işleyebilir miyiz?” sorusunu sorun. Yanıt, kliniğin talep değerlendirme sürecine bağlıdır. İlk iletişimde gerekmeyen ayrıntılı sağlık geçmişini zorunlu istemek yerine, gerçekten gerekli bilgiyi uygun aşamada toplamak daha anlaşılır bir akış sağlayabilir. Bu öneri, kişisel veri işleme veya mevzuat uygunluğu değerlendirmesinin yerine geçmez.
Görünür etiketler ile form alanlarının ilişkisi
Alan içinde görünen örnek metin, kullanıcı yazmaya başladığında kaybolabilir. Bu nedenle “Telefon numarası” gibi alanın amacını belirten görünür alan etiketleri, yalnızca bu geçici metne bırakılmamalıdır. Kullanıcı bilgi girdikten sonra da neyi doldurduğunu anlayabilmelidir.
Etiketin ekranda görünmesi ile kodda ilgili alana bağlanması farklı kontrollerdir. Açık ilişkilendirmede label öğesinin for değeri, ilgili giriş alanının id değeriyle tam eşleşmelidir. Geliştiriciden bu eşleşmeyi incelemesini isteyin. Böylece yardımcı teknolojiler, örneğin ekran okuyucular, alanı doğru etiketiyle sunabilir. Bu ilişki, form etiketlerinin alanlarla ilişkilendirilmesi açıklamasında da ele alınır.
Metin alanlarının etiketlerini alanın üstüne koymak, mobilde ve büyütülmüş görünümde yatay kaydırma ihtiyacını azaltmaya yardımcı olabilir. Ancak etiketin hangi alana ait olduğu, çevredeki boşluklarla birlikte değerlendirilmelidir. Etiketlerin doğru görünmesi tek başına formun bütünüyle erişilebilir olduğunu göstermez.
Tek sütunlu düzen ve zorunlu alanların açıklığı
Kısa randevu formlarında tek sütunlu form düzeni, sıradaki alanı bulmayı kolaylaştırır. Kullanıcı soldan sağa mı, yoksa aşağı doğru mu ilerleyeceğine karar vermek zorunda kalmaz. Bu, çok sütunlu her formun kullanılamaz olduğu anlamına gelmez; özellikle mobil görünümde ve klavyeyle gezinirken izlenen sıra önemlidir.
Zorunluluğu yalnızca renk veya açıklamasız yıldızla belirtmeyin. Alan etiketinde “zorunlu” ya da “isteğe bağlı” açıklaması kullanın. Alanların çoğu zorunluysa formun başında bu kuralı açıklayıp istisnaları etiketlemek de mümkündür.
Varsayımsal bir talep formunda “Mesajınız (isteğe bağlı)” etiketi ve “Talebinizle ilgili kısa bir not ekleyebilirsiniz” açıklaması, kullanıcının burayı boş bırakabileceğini anlatır. Gereksiz alanları kaldırmak yükü azaltabilir; ancak tek başına daha fazla randevu alınacağını garanti etmez.
Mobil randevu formunda dokunma ve veri girişi sorunları
Formun telefon ekranına sığması, rahat kullanılabildiği anlamına gelmez. Bir alanı seçerken yanındaki kontrolün açılması, klavyenin gerekli karakterleri sunmaması veya sonraki alanın sabit bir panel altında kalması da mobil kullanım sorunudur. Değerlendirmeyi yalnızca ekran görüntüsüyle değil, bilgi girerek yapın.
Randevu butonunun dokunma alanı ve çevresindeki boşluk
Küçük ve birbirine çok yakın kontroller yanlış dokunmayı kolaylaştırabilir. web.dev, mobil form kontrolleri için dokunma alanı önerileri kapsamında butonlarda en az 48 piksel dokunma hedefi ve kontroller arasında yeterli boşluk önerir. Bu değer bir tasarım önerisidir; burada WCAG erişilebilirlik uygunluk eşiği olarak kullanılmamalıdır.
Görünen simgenin boyutu ile dokunulabilen alan aynı olmayabilir. Küçük bir telefon simgesinin çevresinde daha geniş bir etkileşim alanı bulunabilir; bunu görünüşten değil gerçek davranıştan değerlendirin. Arama, mesajlaşma ve randevu kontrollerini birlikte deneyin. Birine ulaşırken diğerini yanlışlıkla açmak, boyut veya aralıkların yeniden ele alınması gerektiğini gösterir.
Telefon ve tarih girişine uygun mobil kontroller
Veri türüne uygun giriş alanı, mobil klavyeyi ve yazma kolaylığını etkileyebilir. Telefon numarası hesaplama yapılacak bir sayı değildir. Geliştiriciyle telefon alanında type=”tel” kullanımını değerlendirin ve açılan klavyeyi gerçek cihazlarda deneyin. Bu alan türü, telefon numarasının geçerliliğini tek başına doğrulamaz.
Yerel tarih seçicinin görünümü ve kullanımı cihaz ile tarayıcıya göre değişebilir. Özel tasarlanmış bir takvim kullanılıyorsa ay değiştirme, tarih seçme ve klavyeyle ilerleme ayrıca sınanmalıdır. Kullanıcının hangi tarihi seçtiği, takvim kapandıktan sonra da açıkça görünmelidir.
Tarih alanının işlevini doğru adlandırın. Form yalnızca kullanıcının tercihini topluyorsa “Tercih ettiğiniz tarih” gibi bir etiket uygundur. Takvimde bir günün seçilebilmesi, o günün klinik takviminde boş olduğunu göstermez. Müsaitlik bilgisi ancak ilgili sistemden gerçekten alınıyorsa bu şekilde sunulmalıdır.
Form hatası ve gönderim sonucu neden açık olmalı?
Form doldururken sorun yaşayan ziyaretçinin iki soruya yanıt bulması gerekir: “Neyi düzeltmeliyim?” ve “Gönderdiğim bilgiye ne oldu?” Bu yanıtları vermeyen bir arayüz, kullanıcıyı formu tekrar doldurmaya veya aynı talebi yeniden göndermeye yöneltebilir.
Hata mesajı, ilgili alanı ve düzeltme yolunu göstermeli
Sayfanın üstünde beliren “Bir hata oluştu” uyarısı, hangi bilginin düzeltilmesi gerektiğini anlatmaz. Mesajı ilgili alanın yanında gösterin ve yapılacak işlemi açıklayın. Varsayımsal bir formda zorunlu telefon alanı boş bırakılmışsa “İletişim için telefon numaranızı girin” mesajı kullanılabilir. Sistemin istemediği bir uzunluk veya biçim kuralını mesajda dayatmayın.
Gönderim sırasında doğrulama hatası bulunursa klavye odağını ilk geçersiz alana yönlendirmek, düzeltmeye başlamayı kolaylaştırır. Hata yalnızca kırmızı çerçeveyle anlatılmamalıdır. Geliştiriciden hata metnini ilgili alanla kod düzeyinde ilişkilendirmesini ve ekran okuyucuyla anlaşılabildiğini kontrol etmesini isteyin. Örneğin aria-describedby, alanı açıklama metnine bağlamak için kullanılabilir.
Gönderim bildirimi gerçek randevu durumunu yansıtmalı
“Gönderiliyor”, “Gönderim tamamlanamadı” ve “Talebiniz alındı” farklı durumları anlatır. Başarı mesajı yalnızca butona tıklanınca değil, sistemin gerçek işlem sonucu doğrulandığında gösterilmelidir. İşlem sürerken kullanıcıya durum bildirilmeli; başarısızlıkta yeniden deneme yolu açık olmalıdır. Sonuç mesajı, ekran okuyucu kullanan ziyaretçilere de iletilmelidir.
Sonraki adım yalnızca kliniğin doğrulanmış işleyişine göre açıklanmalıdır. Sistem gerçekten sağlamıyorsa SMS veya e-posta bildirimi vaat etmeyin. Belirlenmiş bir geri dönüş süresi yoksa arayüze tahmini bir süre eklemeyin.
Talep alındı bildirimi, kesin randevu onayı değildir. Form yalnızca randevu talebi topluyorsa gönderim bildirimi talebin alındığını söylemelidir. Kesin gün ve saat onayı, ancak kullanılan sistem ve kliniğin işleyişi bunu gerçekten sağlıyorsa gösterilmelidir.
Randevu akışını test edin ve düzeltmeleri önceliklendirin
Denemeleri varsa test ortamında yapın. Canlı site kullanılacaksa klinik yetkilisiyle koordinasyon kurun ve gerçek hasta verisi kullanmayın. Aşağıdaki kontrol listesi temel sorunları belirlemeye yardımcı olur; kapsamlı bir erişilebilirlik denetiminin yerine geçmez.
- Telefonda bir tedavi sayfasından başlayın ve randevu kontrolünü kullanın. Açılan hedefin, kontrolün metninde anlatılan işlemle eşleşmesini bekleyin.
- Alanlara test bilgileri girin. Etiketlerin görünür kaldığını, veri türüne uygun klavyenin açıldığını ve sabit öğelerin alanları veya gönderim kontrolünü örtmediğini kontrol edin.
- Bilgisayarda fare kullanmadan Tab ve Shift+Tab tuşlarıyla ilerleyin. Odağın hangi kontrolde olduğunun görünmesini, sıranın form akışını izlemesini ve işlemin klavyeyle tamamlanabilmesini bekleyin.
- Zorunlu bir alanı boş bırakıp formu göndermeyi deneyin. Hata mesajının ilgili alanı göstermesini ve nasıl düzeltileceğini açıklamasını gözlemleyin.
- Hatalı alanı düzeltin. Diğer bilgilerin gereksiz yere silinmeden işleme devam edilebildiğini kontrol edin.
- Kontrollü test talebini gönderin. Kaydın ilgili sisteme ulaştığını yetkiliyle doğrulayın ve ekrandaki bildirimin gerçek durumla eşleştiğini kontrol edin.
- Uygun test ortamında geliştiriciden gönderim başarısızlığını sınamasını isteyin. Başarısız işlemin başarı mesajı üretmemesini ve kullanıcıya anlaşılır bir devam yolu sunulmasını bekleyin.
Önce gönderimi engelleyen veya yanlış başarı bildirimi üreten sorunları ele alın. Ardından formun tamamlanmasını zorlaştıran erişilebilirlik ve mobil kullanım sorunlarını düzeltin. Her değişiklikten sonra aynı senaryoyu yeniden çalıştırın; yalnızca görünümün değişmesini sorunun çözüldüğüne kanıt saymayın.
Düzeltme için dışarıdan hizmet alacaksanız, teklifin yalnızca görsel yenilemeyi değil form doğrulamasını, gönderim akışını ve yeniden testi de kapsayıp kapsamadığını sorun. Bu ayrımı değerlendirmek için web tasarım tekliflerini kapsam ve teknik kalite açısından karşılaştırma ölçütlerinden yararlanabilirsiniz.
Geliştiriciye ileteceğiniz ilk kayıt, başarısız olan adımı somutlaştırmalıdır: Hangi sayfada, hangi cihaz ve tarayıcıda, hangi işlem yapıldı; ne olması bekleniyordu ve ne oldu? Bu bilgiler, “Randevu formu zor kullanılıyor” demekten daha açık bir düzeltme hedefi verir.
