Tüm yazılar

Web Tasarım

Ankara Mobil Uyumlu Web Tasarım: Telefonda Teklif Almayı Kolaylaştırmak

Mobil uyum, masaüstündeki sayfanın dar ekrana sığmasından ibaret değildir. Telefonda hizmet araştıran kişinin bilgi bulması, belgeye ulaşması ve teklif isteğini tamamlaması ayrı bir kullanım senaryosudur. Menüden form alanlarına, teknik tablolardan hata mesajlarına kadar bu senaryoyu nasıl planlayıp kontrol edebileceğinizi anlatıyoruz.

16 Ekim 2026·91 Ajans·6 dk okuma

Mobil ziyaretçinin koşullarını hesaba katın

Telefondan web sitesine bakan herkes hızlıca bir şey satın almak istemez. Bir mühendis sahada ürün ölçüsünü kontrol ediyor, bir yönetici toplantı arasında ajans araştırıyor veya bir veli eğitim programını karşılaştırıyor olabilir. Eller serbest olmayabilir, bağlantı zayıf olabilir ve kullanıcı aynı anda başka bir iş yapıyor olabilir. Mobil tasarım bu koşullarda gerekli bilgiye ulaşmayı desteklemelidir. Ekrana sığan fakat görevi zorlaştıran bir sayfa, kullanım açısından yeterli sayılmaz.

Ankara'da teknik ürün satan bir işletme için teklif talebinin başlaması bazen ürünü bulmaktan daha kolaydır; asıl sorun ürün kodunu forma taşımak olabilir. Kullanıcı kodu kopyalamaya çalışırken sayfadan çıkar veya satış ekibine eksik bilgi gönderir. Bu nedenle mobil uyum çalışmasını genel görsel düzenle sınırlamayın. İnsanların telefonda yaptığı temel işleri listeleyin ve her birinin baştan sona nasıl tamamlandığını izleyin. Tasarımın önceliği bu görevlerden çıkmalıdır.

İçerik sırasını küçülen alana göre yeniden düşünün

Masaüstünde yan yana görünen bilgiler telefonda alt alta gelir. Bu sıralama rastlantıya bırakılırsa önemli teknik bilgi uzun bir tanıtım alanının altında kalabilir. Hizmet sayfasında kapsam, ürün sayfasında model bilgisi ve iletişim sayfasında ulaşım yöntemi farklı önceliklerdir. Mobil düzen, her sayfa türünün görevine göre kurulmalıdır. Başlık, özet ve sonraki adımın yakınlığı önemlidir; fakat gerekli ayrıntıları yalnızca ekranı kısaltmak için kaldırmak doğru değildir.

Duyarlı tasarım, düzenin ekran koşullarına uyarlanmasını ifade eder. web.dev medya sorguları rehberi, düzen değişimlerinin içerik ihtiyacına göre belirlenmesini açıklar. Projede tek bir telefon modelinin ölçüsünü hedeflemek yerine farklı genişliklerde içeriğin nerede bozulduğuna bakın. Uzun hizmet adı, iki satırlık düğme ve çok sütunlu tablo gibi gerçek içerikler kullanın. Boş veya kısa örnek metinlerle yapılan kontrol, yayın sırasında ortaya çıkan sorunları gizleyebilir.

Menü ve sabit düğmeler birbirini engellememeli

Mobil menüde bütün hizmetleri tek düzeyde sıralamak bazen uzun bir liste oluşturur. Gruplama yapılıyorsa grup adının anlaşılır olması gerekir; kurum içi birim isimleri ziyaretçiye yol göstermeyebilir. Menü açıldığında sayfada nerede olduğunuz anlaşılmalı, kapatma işlemi kolay bulunmalıdır. Bir alt sayfaya geçip geri döndüğünüzde beklenmedik sıçramalar yaşanması da kullanımı zorlaştırır. Bu davranışları tasarım dosyasında görmek kadar gerçek cihazda denemek de önemlidir.

Sabit telefon, mesaj ve teklif düğmeleri yararlı olabilir; ancak aynı anda çok sayıda sabit öğe içeriği kapatabilir. Çerez alanı, sohbet penceresi ve alt iletişim çubuğu birleştiğinde küçük ekranda okunabilir alan daralır. Hangi öğenin hangi durumda gösterileceğine karar verin. Özellikle form gönderme düğmesi başka bir katmanın altında kalmamalıdır. Kullanıcıya yardımcı olması beklenen araçların, temel görevi engellemediğini kontrol etmek mobil kalite değerlendirmesinin pratik bir parçasıdır.

Teklif formunda yalnızca gerekli bilgiyi isteyin

Form alanlarını satış ekibinin alışkanlığına göre değil, ilk değerlendirme için gerçekten gereken bilgiye göre seçin. Bir hizmet talebinde ad, iletişim kanalı, konu ve kısa açıklama yeterli olabilir; teknik üretimde çizim veya ürün kodu gerekebilir. Her iş için aynı uzun formu kullanmak gereksiz yük oluşturur. İlk görüşmede alınabilecek bilgiyi baştan zorunlu istemek yerine neden gerekli olduğunu sorgulayın. Alan azaltma kararı da talebin niteliğini düşürmeyecek biçimde verilmelidir.

Telefon ve e-posta alanlarında uygun klavye görünmesi, kullanıcının yazma işini kolaylaştırır. Fakat biçim kontrolü çok katıysa doğru bilgiyi reddedebilir; boşluk, ülke kodu veya farklı şirket e-postaları düşünülmelidir. Alan isimleri yazmaya başladıktan sonra da anlaşılır kalmalıdır. Hata mesajı yalnızca kırmızı çizgiyle verilmemeli, neyin düzeltilmesi gerektiğini söylemelidir. Form gönderimi başarısız olduğunda bütün metnin silinmesi, özellikle uzun proje açıklaması yazmış kişiye gereksiz iş çıkarır.

Dosya, tablo ve bağlantıları telefonla deneyin

Teknik ürün tabloları küçük ekranda en sık zorlanan alanlardandır. Sütunları rastgele gizlemek, karşılaştırma için gerekli bilgiyi kaldırabilir. Kaydırmalı tablo, özellik grupları veya ürünün temel bilgilerini öne alan farklı bir düzen kullanılabilir. Hangi yaklaşımın uygun olduğu, kullanıcının yapmak istediği karşılaştırmaya bağlıdır. Ürün ailesinin özelliklerini bilmeden tek bir görsel çözümü bütün tablolara uygulamayın. Satış ve teknik ekipten gelen gerçek sorular burada iyi bir test malzemesidir.

İndirilen dosyanın türü ve amacı bağlantı metninden anlaşılmalıdır. “Buraya tıklayın” yerine “Model A teknik ölçü çizimi” gibi açıklama daha yararlıdır. Dosyanın telefonda açılmasıyla siteye geri dönüş de denenmelidir. E-posta veya mesaj uygulamasına geçen kişi formdaki yazısını kaybediyor mu? Aynı bağlantı yeni sekme açtığında geri gelmek kolay mı? Bu ayrıntılar, kurumsal web sitesi içerik planında belge sorumluluklarıyla birlikte ele alınabilir.

Gönderimin tamamlandığını açıkça gösterin

Kullanıcı gönder düğmesine bastığında talebin alındığını bilmek ister. Yüklenme işareti, başarı mesajı ve hata durumu birbirinden açıkça ayrılmalıdır. İşlem sürerken düğmeye tekrar basılması yanlışlıkla birden fazla talep oluşturabilir; arayüz ve sunucu tarafındaki davranış birlikte düşünülmelidir. Görsel olarak başarı yazması, bildirimin doğru ekibe ulaştığını tek başına kanıtlamaz. Test planı form kaydını, yönlendirmeyi ve e-posta iletiminin durumunu ayrı ayrı kontrol etmelidir.

Yanıt süresi hakkında sayfada bir ifade kullanılacaksa işletmenin gerçek iş düzenine dayanmalıdır. Karşılanamayacak bir süre yazmak yerine sonraki adımı açıklamak daha doğrudur. Kullanıcının gönderdiği bilgiyi özetlemek veya talep numarası vermek bazı işlerde faydalı olabilir. Yazılım çalışmasının kapsamına bu davranışları baştan eklemek, formu son anda yapılan basit bir sayfa ayrıntısı olmaktan çıkarır. Teklif almak, sitenin temel işlevlerinden biriyse kabul ölçütlerinde de görünmelidir.

Kontrolü gerçek bir görevle bitirin

Yayından önce farklı telefonlarda bir görev senaryosu uygulayın: hizmeti bulun, kapsamı okuyun, ilgili belgeyi açın, forma dönün ve test talebini gönderin. Deneyen kişiye yol göstermeyin; zorlandığı noktaları kaydedin. Bu deneme bütün kullanıcıları temsil etmez ama belirgin engelleri ortaya çıkarabilir. Aynı işlemi mobil veriyle ve yatay ekranda da kontrol etmek yararlıdır. Tarayıcıdaki küçük ekran önizlemesi, fiziksel klavye ve dokunma davranışlarının tamamını göstermez.

Yeni site görüşmesinde teklif formunu yalnızca görünüm örneği olarak değil, bir iş akışı olarak değerlendirin. Hangi bilgi istenecek, talep kime gidecek, hata olduğunda ne olacak ve kaydın ulaştığı nasıl anlaşılacak? Bu sorulara verilen cevaplar, mobil uyumun ticari işlevini belirler. Kontrol listesinde “telefon görünümü tamam” demek yerine tamamlanan görevleri yazmak, teslimi daha açık ve daha kolay doğrulanabilir hale getirir.

Birlikte çalışalım

Okumak güzeldi.
Şimdi üretelim.

Projeyi anlat