Bir web sitesinin telefonda düzgün görünmesi, ziyaretçinin işini tamamlayabildiğini göstermez. Menü açılabilir fakat alt hizmet bağlantısına dokunmak zor olabilir. Teklif formu ekrana sığabilir fakat klavye açıldığında gönder düğmesi kaybolabilir. Hata mesajı gösterildiği hâlde kullanıcı hangi alanı düzelteceğini anlayamayabilir. Bu nedenle mobil kontrol, ekran görüntüsünü onaylamaktan daha kapsamlı bir çalışma gerektirir.
Web Tasarım Sistemleri olarak profesyonel web tasarım çalışmalarında menü ve formu aynı ziyaretçi yolculuğunun parçaları olarak değerlendiriyoruz. Kişi önce ihtiyacına uygun hizmeti bulur, ardından bilgi alır ve uygun görürse başvuru yapar. Bu rehber; gerçek telefon üzerinde uygulanabilecek görevleri, hata senaryolarını ve teslim ölçütlerini açıklıyor. Amaç yalnız sorun listesi çıkarmak değil, hangi davranışın düzeltilmesi gerektiğini ve sonucun nasıl kontrol edileceğini belirlemektir.
Kontrole Ekranlardan Değil, Ziyaretçi Görevlerinden Başlayın
“Mobil menü kontrol edilecek” ifadesi görevin nerede başlayıp biteceğini açıklamaz. Bunun yerine “Ana sayfadan belirli hizmeti bul, kapsamını oku ve görüşme talebine geç” gibi tamamlanabilir bir görev yazın. Böylece menü adı, hedef sayfa ve başvuru çağrısı birlikte incelenir. Kurumsal web sitesi planında öncelikli ziyaretçi ihtiyaçları tanımlanmışsa, test görevleri de bu ihtiyaçlardan çıkarılmalıdır.
Görev seçerken yalnız işletmeyi tanıyan çalışanların alışkanlıklarına dayanmayın. Yeni ziyaretçinin hangi menü başlığını anlayacağı ve hangi bilgiyi arayacağı düşünülmelidir. Başarının ölçütü her zaman en az dokunuş sayısı değildir; kişinin doğru hizmete ulaşıp ulaşmadığı ve kararını destekleyen bilgiyi bulup bulmadığı da önemlidir. Bu görevler web tasarım briefinde kabul ölçütleri olarak yazılabilir.
- Hizmet bulma: Ana menüden uygun ayrıntı sayfasına ulaşma ve geri dönebilme.
- Başvuru başlatma: Hizmet sayfasından doğru forma geçme ve gereken bilgileri anlama.
- Hatayı düzeltme: Yanlış girilen alanı bulma, düzeltme ve diğer bilgileri koruma.
- İşlemi bitirme: Sonucu görme, sonraki adımı anlama ve gerekirse güvenle vazgeçme.
Gerçek Telefonla Kullanım Koşullarını Kaydedin
Masaüstü tarayıcısındaki dar ekran görünümü, yerleşim sorunlarını erken fark etmeye yardımcı olur. Ancak telefon klavyesi, dokunma davranışı, tarayıcı çubukları ve cihaz üzerindeki kaydırma için gerçek kullanım da incelenmelidir. Test kaydına cihazı, işletim sistemini, tarayıcıyı ve görünüm yönünü yazın. Bir cihazdaki başarının bütün telefonları temsil ettiğini varsaymayın; öncelikli cihaz ve tarayıcı kapsamı proje ihtiyacına göre seçilmelidir.
Başlangıçta dikey görünümle çalışıp ardından yatay yönü kontrol edebilirsiniz. Metin boyutu artırıldığında menü etiketlerinin, alan açıklamalarının ve hata mesajlarının okunabildiğine de bakın. Ekranda başka bir katman açıkken aynı görevi tekrarlayın: çerez bildirimi, sabit iletişim çubuğu veya açılan form, kullanılabilir alanı değiştirebilir. Test sırasında bu katmanların hangisinin açık olduğu kaydedilirse aynı sorun yeniden üretilebilir.
Her denemeye aynı başlangıç noktasından dönmek karşılaştırmayı kolaylaştırır. İlk kontrolde menü kapalı ve form boşken başlayın; ikinci kontrolde alt menüyü açık, üçüncüde form hatasını görünür bırakın. Beklenmeyen davranış yalnız bu durumlardan birinde oluşuyorsa bunu kayda geçirin. Testin amacı ekranı sürekli zorlayarak rastgele bir hata bulmak değil, ziyaretçinin kullanabileceği yolları ve bu yollardaki belirli geçişleri sistemli biçimde incelemektir. Kontrol kapsamına sonradan eklenen durumları da listeye işleyin.
Menünün Açılmasını, Gezinmesini ve Kapanmasını Ayrı Deneyin
Menü simgesine dokunulduğunda ziyaretçi açılan alanı ve kapatma yolunu anlayabilmelidir. Alt menü bulunan bir öğede, başlığa dokunmanın sayfa açmak mı yoksa alt seçenekleri göstermek mi olduğu belirsiz kalmamalıdır. Uzun hizmet adları ve çok sayıda seçenekle de deneyin. Menüde aşağı kaydırırken arka sayfanın beklenmedik biçimde hareket etmesi veya son bağlantının ekran dışında kalması görev tamamlamayı zorlaştırabilir.
W3C'nin açılır gezinme örneği, açma düğmesinin durumunu bildirmesini, klavyeyle bağlantılar arasında ilerlemeyi ve Escape ile kapatınca odağın düğmeye dönmesini gösterir. Bu bir uygulama örneğidir; gerçek sistemde tarayıcı ve yardımcı teknoloji testinin yerini tutmaz. Telefonda dokunarak yapılan kontrole, klavye ve uygun yardımcı teknoloji kontrolleri de eklenmelidir.
Menü kapandıktan sonra görünmeyen bağlantıların odak almaya devam edip etmediğini kontrol edin. Hizmet bağlantısını seçince doğru sayfa açılmalı, geri dönüldüğünde gezinme anlaşılır kalmalıdır. Menü türleri ve içerik hiyerarşisi için web sitesi menüleri üzerine rehberimiz genel çerçeve sağlar; burada ise seçilen yapının gerçek görev sırasında nasıl çalıştığına odaklanıyoruz.
Örneğin “Hizmetler” yazısının yanında ayrı bir açma simgesi bulunuyorsa iki hedefi de deneyin. Yazıya basınca genel liste açılırken simge alt seçenekleri gösterebilir; bu ayrımın ziyaretçi tarafından anlaşılması gerekir. Bir alt hizmet seçip geri geldiğinizde menünün açık kalıp kalmaması tek başına hata değildir. Karar, kullanıcının bulunduğu yeri anlayabilmesi ve bir sonraki adımı sorunsuz gerçekleştirebilmesi üzerinden verilmelidir. Aynı davranışın benzer sayfalarda tutarlı olması da ayrıca kontrol edilir.
Dokunma Alanını Simgenin Görsel Boyutuyla Karıştırmayın
Küçük görünen bir simgenin çevresinde yeterli dokunma alanı bulunabilir; büyük görünen bir kutunun yalnız metni tıklanabilir olabilir. Bu nedenle görünüşle birlikte gerçek etkileşim alanı incelenmelidir. Yan yana duran açma, kapatma veya sonraki adım kontrollerinde yanlış öğenin seçilip seçilmediğine bakın. Özellikle dar ekranda birbirine yaklaşan menü bağlantıları, kutucuklar ve dosya kaldırma düğmeleri dikkatle değerlendirilmelidir.
W3C'nin asgari hedef boyutu açıklaması, WCAG 2.2 kapsamında genel olarak en az 24×24 CSS piksel hedefi veya tanımlanan istisnaları ele alır; yeterli aralık ve satır içi bağlantılar bunlar arasındadır. Bu değeri bütün düğmeler için ideal kullanım garantisi saymayın. Kontrol listesinde gerçek boyut, komşu kontrollerle mesafe ve dokunarak kullanım sonucu birlikte kaydedilmelidir.
Formun Ne İstediğini Alanı Doldurmadan Önce Anlaşılır Kılın
Ziyaretçi hangi bilgilerin zorunlu olduğunu ve neden istendiğini anlayabilmelidir. Alan etiketleri, açıklamalar ve örnekler birbirini desteklemelidir. Hizmet türünü seçmek için açılan listede işletme içi kısaltmalar yerine anlaşılır adlar kullanılmalıdır. Gereksiz bilgiler, kişinin formu tamamlamasını zorlaştırabilir; hangi alanın gerçekten iş sürecinde kullanılacağı içerik ve satış sorumlularıyla birlikte belirlenmelidir.
Her alana dokunarak açılan klavyeyi deneyin. Telefon, e-posta, tarih veya sayısal değer girişinde seçilen kontrolün göreve uygunluğu incelenmelidir. Otomatik doldurma kullanıldığında değerlerin doğru alanlara yerleştiğini ve biçim doğrulamasının geçerli girdileri gereksiz yere reddetmediğini kontrol edin. Başvuru çağrısının ne vaat ettiğiyle formun istediği bilgiler de tutarlı olmalıdır. Bu ilişki hizmet sayfasının kapsam ve çağrı yapısıyla birlikte değerlendirilir.
Alan Hatalarını Bilerek Oluşturup Düzeltin
Yalnız doğru bilgilerle yapılan test, formun en önemli durumlarından birini dışarıda bırakır. Zorunlu alanı boş bırakın, e-posta biçimini yanlış girin ve varsa dosya sınırını aşan bir seçim deneyin. Her hata için hangi açıklamanın göründüğünü, alanla ilişkisinin anlaşılır olup olmadığını ve düzeltmenin nasıl yapıldığını kaydedin. Test verileri sentetik olmalı, gerçek kişi bilgileri kullanılmamalıdır; gönderim işlemleri işletmenin yetkilendirdiği test düzeni içinde yürütülmelidir.
W3C'nin form sonucu ve hata bildirimleri rehberi, hatanın açıkça anlatılmasını, düzeltme yolunun belirtilmesini ve işlem sonucunun kullanıcıya bildirilmesini önerir. “Bir hata oluştu” ifadesi tek başına yeterli yönlendirme sağlamayabilir. Hata yalnız renkle gösterildiğinde veya ekranın görünmeyen bir bölümünde kaldığında ziyaretçi ne yapacağını anlayamayabilir. Alan yakınındaki açıklama ve gerekiyorsa genel hata özeti birlikte incelenmelidir.
- Eksik alan: Hangi bilginin gerekli olduğu ve nereden tamamlanacağı anlaşılır mı?
- Yanlış biçim: Kabul edilen giriş açık mı; hata düzeltildikten sonra durum güncelleniyor mu?
- Yeniden deneme: Diğer uygun alanlar gereksiz yere boşalıyor mu; kullanıcı kaldığı yerden devam edebiliyor mu?
Klavye ve Sabit Katmanlar Açıkken Görünürlüğü Denetleyin
Telefonda klavye açıldığında formun görülebilen kısmı değişir. Son alanı doldurun, açıklama metnini okuyun ve gönder düğmesine ulaşın. Klavye kapatılınca sayfa beklenmedik bir noktaya sıçrıyor mu diye bakın. Açılır form kullanılıyorsa içerideki kaydırma ile arka sayfanın kaydırması birbirine karışmamalıdır. Formun kapatma düğmesi de kısa ekranlarda ulaşılabilir kalmalıdır.
W3C'nin odağın tamamen örtülmemesi ölçütü, klavye odağı alan bileşenin site tarafından oluşturulan içerikle bütünüyle gizlenmemesini ele alır. Sabit başlık veya alt iletişim çubuğu bu nedenle kontrol edilmelidir. Ölçütün asgari şartını kontrol etmenin yanında, alanın ve açıklamasının rahatça okunabilmesini de değerlendirin. Tek bir kontrolün geçmesi, sitenin bütün erişilebilirlik gerekliliklerini karşıladığını göstermez.
Gönderim Anını ve Gerçek Sonucu Birbirinden Ayırın
Düğmeye dokunulması, talebin işletmeye ulaştığını tek başına kanıtlamaz. Bekleme durumu, hata ve başarı sonucu ayrı incelenmelidir. Yavaş bağlantıda kişi işlemin sürdüğünü anlayabiliyor mu? Yanıt geciktiğinde düğmeye yeniden basıyor mu? Başarı mesajı gerçekten kabul edilmiş bir başvuruya mı dayanıyor? Bu soruların yanıtı arayüz kontrolünün yanında, yetkili ortamda kayıt veya ilgili sistem çıktısının doğrulanmasını da gerektirebilir.
Aynı talebin yinelenmesini önleme, güvenli yeniden deneme ve ilgili ekibe yönlendirme ihtiyaçları varsa web yazılım işleyişi kapsamında tanımlanmalıdır. Düğmeyi geçici olarak etkisizleştirmek, bütün sunucu tarafı sorunlarını çözmüş sayılmaz. Talebin niteliği ve satış ekibine hangi bilgilerin aktarılacağı ise B2B teklif talebi akışı ile birlikte ele alınabilir.
Başvurunun sisteme kaydedilmesi ile ilgili kişinin e-posta kutusunda görülmesi de ayrı sonuçlardır. İşletmenin kullandığı yapıya göre kayıt, bildirim ve sonraki takip adımları farklı yerlerde gerçekleşebilir. Kabul testinde hangisinin doğrulandığı açıkça yazılmalıdır. Arayüzde başarı görülürken bildirim alınmıyorsa formun bütününü yeniden tasarlamak yerine ilgili aşama incelenir. Ziyaretçiye gösterilen mesaj, teknik olarak doğrulanmış sonucun ötesinde teslim veya dönüş süresi vaat etmemelidir.
Üç Gerçekçi Senaryoyla Uçtan Uca Kontrol Yapın
Senaryo 1: Hizmeti Bulup Doğru Forma Geçme
Varsayımsal bir eğitim danışmanlığı firmasının sitesinde ziyaretçi kurumsal eğitim hizmetini araştırıyor olsun. Telefonda ana sayfadan başlayıp menüyü açar, ilgili hizmeti bulur ve görüşme formuna geçer. Burada menü adı, sayfa başlığı ve formdaki hizmet seçeneğinin aynı kapsamı anlattığı kontrol edilir. Bu örnek bir müşteri sonucu değildir; uygulanabilecek bir test görevidir. İlk yönlendirmenin açıklığı ana sayfa mesaj sırasıyla ilişkilidir.
Senaryo 2: Hatayı Düzelterek Devam Etme
Aynı kişi formda e-posta alanını yanlış doldursun. Gönderim denemesinde hata görünür, açıklama ilgili alanı gösterir ve kişi düzeltme yapar. Firma adı ile mesaj metninin gereksiz yere silinmediği, klavye açıkken hata alanının görülebildiği ve yeniden denemenin anlaşılır olduğu kontrol edilir. Sonuç kaydına “Form çalışıyor” yerine bu adımların hangisinin geçtiği yazılır.
Senaryo 3: Dili Değiştirme veya İşlemden Vazgeçme
Çok dilli bir sitede hizmet incelenirken dil değiştirin; karşılık gelen sayfaya ve aynı dildeki forma ulaşın. Alan hataları ve başarı açıklamaları da seçilen dilde anlaşılır olmalıdır. Ardından formu kapatmayı veya geri dönmeyi deneyin; ziyaretçi çıkış yolunu bulabilmelidir. Dil alanlarının ve güncellemelerin takibi için çok dilli içerik yönetim planı bu senaryonun bakım tarafını tamamlar.
Sorun Kaydını Yeniden Üretilebilir Bir İş Tanımına Dönüştürün
“Mobilde form bozuk” ifadesi düzeltme için yeterli değildir. Kayıtta sayfa adresi, cihaz ve tarayıcı, başlangıç durumu, uygulanan adımlar, beklenen sonuç ve gözlenen davranış bulunmalıdır. Gerekli olduğunda ekran görüntüsü veya kısa kayıt eklenebilir; kişisel veriler kanıta taşınmamalıdır. Örneğin “Klavye açıkken son alandan sonra gönder düğmesine kaydırılamıyor” ifadesi, sorunun hangi koşulda oluştuğunu açıklar.
Öncelik, yalnız görünüşe göre verilmemelidir. Formun tamamlanmasını engelleyen sorunla menü simgesinin hizasını ayrı değerlendirin. Aynı hata farklı sayfalarda ortak bileşenden kaynaklanıyorsa düzeltmenin etkilediği alanlar da kaydedilmelidir. Düzeltme sonrası önce sorunlu görev tekrarlanır, ardından ilişkili menü ve form akışları kontrol edilir. Bu yaklaşım, yapılacak işin kapsamını ve kabulünü somutlaştırır.
Düzeltme kaydına son kontrolün hangi sürümde yapıldığını eklemek de yararlıdır. Bir geliştirici sorunu giderdiğinde içerik ekibi daha uzun bir menü etiketi veya ek form alanı yayımlamış olabilir. Kontrol edilen sürüm ve içerik durumu belirtilmediğinde iki ekip farklı ekranlardan söz edebilir. Kapanış notu, yapılan değişikliği ve tekrar uygulanan görevi kısa biçimde açıklamalıdır. Böylece sonraki bakımda aynı sorunun geri dönüp dönmediği daha kolay anlaşılır.
Teslim Onayını Kontrol Sonuçlarıyla Birlikte Verin
Kontrol listesinde her maddeye sonuç, sorumlu ve gerekiyorsa kanıt bağlantısı ekleyin. “Kontrol edilmedi” durumu da açıkça tutulmalıdır; denenmeyen bir cihaz veya akış başarılı sayılmaz. Web tasarım teslim planında mobil testlerin hangi aşamada yapılacağı belirtilirse, içerik ve form kararlarının son güne bırakılması önlenebilir. Test kapsamı işletmenin gerçekten kullandığı akışlarla eşleşmelidir.
- Yayın öncesi: Öncelikli ziyaretçi görevleri, hata durumları ve sonucun doğrulanması tamamlandı mı?
- Düzeltme sonrası: Sorunlu adım ve etkilenen diğer sayfalar yeniden denendi mi?
- Devir sırasında: Açık sorunlar, test edilmemiş alanlar ve sonraki kontrol sorumluları yazıldı mı?
Form alanları veya menü yapısı yayından sonra değişebileceği için, bakımın kim tarafından yapılacağı da belirlenmelidir. Kurumsal site teslim ve destek kapsamı, hangi değişikliklerin yeniden kontrol gerektirdiğini açıklamalıdır. Yeni bir hizmet seçeneği eklemek, daha uzun bir başlık yazmak veya iletişim çubuğunu yenilemek mobil akışı etkileyebilir. Önceki test sonucu, değişiklik sonrası otomatik olarak geçerli kabul edilmemelidir.
Mobil Kullanılabilirliği Düzenli İş Akışının Parçası Yapın
Menü ve form kontrolü, ziyaretçinin ihtiyacını bulmasından işlem sonucunu anlamasına kadar devam eder. Birkaç temel görevi açıkça tanımlamak, gerçek telefonla hata durumlarını denemek ve bulguları kanıtla kaydetmek iyi bir başlangıçtır. Her kontrolün sorumlusu ve sonucu görünür olduğunda tasarım kararları daha kolay değerlendirilebilir. Mevcut mobil akışınızı incelemek veya yeni projenizin kabul ölçütlerini belirlemek için Web Tasarım Sistemleri ile görüşme başlatabilirsiniz.
Bu makalenin uzunluğu 1814 kelimedir.
Bu makale 2026-10-16 tarihinde yayınlanmıştır.