Web Tasarım Firmasından Teklif Alırken Neler Sorulmalı?

Web Tasarım Teklifi Öncesinde Nasıl Hazırlık Yapılır?

Web tasarım teklifi istemeden önce işletme; projenin iş hedeflerini, hedef kitlesini, öncelikli kullanıcı görevlerini ve başarı ölçütlerini tanımlamalıdır. Firma ancak hangi problemi çözmesi gerektiğini bildiğinde gerçekçi bir kapsam önerebilir. İlk sorulması gereken soru, hizmet sağlayıcının ihtiyaç analizi yapıp yapmadığı değil, bu analizi hangi yöntemle ve hangi teslimatla sonuçlandıracağıdır.

Firmaya Hangi Proje Bilgileri Verilmelidir?

Mevcut sitenin sorunları, beklenen sayfa türleri, diller, entegrasyonlar, içerik durumu ve kurum içi sorumlular ortak bir ihtiyaç dokümanında toplanmalıdır. Başarı; yalnızca sitenin yayınlanmasıyla değil, talep formu tamamlama, nitelikli başvuru veya içerik erişimi gibi iş sonuçlarıyla tanımlanmalıdır. Her firmaya aynı dokümanın gönderilmesi, alınan tekliflerin karşılaştırılabilirliğini artırır.

• “İhtiyaç analizinde kimlerle görüşecek ve hangi çıktıları teslim edeceksiniz?” diye sorun.
• “Hedef kitle ve kullanıcı gereksinimlerini nasıl doğrulayacaksınız?” sorusunu yöneltin.
• “Teklifiniz hangi kapsam varsayımlarına dayanıyor?” açıklamasını yazılı olarak isteyin.
• “Kurumdan hangi içerik, erişim ve onay sorumluluklarını bekliyorsunuz?” diye sorun.
• “Projenin başarısı hangi dönüşüm ve performans göstergeleriyle ölçülecek?” sorusunu netleştirin.

İyi tasarım, mümkün olduğunca az tasarımdır. - Dieter Rams

Tasarım Kapsamı İçin Hangi Sorular Sorulmalıdır?

Tasarım kapsamı; yalnızca ana sayfanın görünümünü değil, bilgi mimarisini, kullanıcı akışlarını, benzersiz sayfa şablonlarını ve farklı ekranlardaki davranışları içermelidir. Toplam içerik sayısı ile özgün tasarım gerektiren şablon sayısı aynı değildir. Teklifte kaç sayfa bulunduğundan önce kaç farklı sayfa türünün araştırılacağı, tasarlanacağı ve onaylanacağı sorulmalıdır.

Hazır Tema ile Özgün Tasarım Nasıl Netleştirilir?

Hazır tema, standart kapsamlı projelerde uygun olabilir; ancak tema adı, lisansı, özelleştirme sınırı ve güncelleme bağımlılığı açıklanmalıdır. Özgün UX/UI tasarımı sunuluyorsa site haritası, wireframe, prototip, tasarım sistemi ve responsive ekranların teslimata dahil olup olmadığı sorulmalıdır. “Özel tasarım” ifadesi, somut çıktı ve süreç belirtilmediğinde tek başına yeterli değildir.

• “Hazır tema mı kullanılacak, yoksa arayüz projeye özel mi tasarlanacak?” diye sorun.
• “Kaç benzersiz sayfa şablonu ve kaç responsive görünüm hazırlanacak?” sorusunu yöneltin.
• “Site haritası, wireframe ve tıklanabilir prototip teslim edilecek mi?” açıklamasını isteyin.
• “Tasarım kararlarını hedef kitle ve kullanıcı yolculuklarıyla nasıl ilişkilendireceksiniz?” diye sorun.
• “Tasarım dosyaları ve kullanılan görsel varlıkların hakları nasıl devredilecek?” konusunu netleştirin.

Yazılım Altyapısı Teklifte Nasıl Sorgulanmalıdır?

Yazılım altyapısı, firmanın alışkanlığına göre değil; içerik yönetimi, kullanıcı rolleri, entegrasyonlar, güvenlik ve ölçeklenebilirlik ihtiyaçlarına göre seçilmelidir. WordPress, Laravel veya özel web yazılımı farklı kullanım senaryolarında uygun olabilir. Önemli olan teknoloji adı değil, önerilen yapının gereksinimleri nasıl karşıladığı ve uzun vadede nasıl sürdürüleceğidir.

Front-end ve Back-end Kapsamında Neler Bulunmalıdır?

Front-end çalışması, onaylanan tasarımın responsive ve erişilebilir arayüze dönüştürülmesini; back-end ise veri modeli, yönetim paneli, kullanıcı rolleri, formlar ve iş kurallarını kapsar. Teklifte yalnızca “yönetim paneli” yazması yeterli değildir. Hangi içeriklerin yönetileceği, kimlerin hangi yetkilere sahip olacağı ve özel modüllerin nasıl işleyeceği açıklanmalıdır.

• “Önerdiğiniz altyapıyı hangi iş ve kullanıcı gereksinimleri nedeniyle seçtiniz?” diye sorun.
• “Front-end ve back-end geliştirmeyi hangi ekip rolleri yürütecek?” sorusunu yöneltin.
• “Yönetim panelinde hangi içerik türleri ve kullanıcı yetkileri bulunacak?” açıklamasını isteyin.
• “Özel modüllerin işleyişi ve kabul ölçütleri nerede tanımlanacak?” diye sorun.
• “Versiyon kontrolü, test ortamı ve teknik dokümantasyon teslim edilecek mi?” konusunu netleştirin.

İçerik ve Entegrasyonlar İçin Neler Sorulmalıdır?

İçerik üretimi, görsel hazırlığı, içerik girişi, çeviri ve kalite kontrol ayrı iş kalemleridir. Teklifte “içerik desteği” ifadesi bulunması, tüm bu hizmetlerin dahil olduğu anlamına gelmez. Kurumun sağlayacağı malzemeler ile firmanın üreteceği teslimatlar ayrılmalı; onay, revizyon ve yayın sorumlulukları her içerik türü için belirlenmelidir.

Çok Dillilik ve Entegrasyon Kapsamı Nasıl Açıklanır?

Çok dilli web sitesi; çevirinin yanında dil bazlı URL, meta alanı, içerik eşleştirmesi ve eksik çeviri davranışı gerektirir. Entegrasyonlarda ise yalnızca bağlanacak sistemin adı yeterli değildir. CRM, ERP veya API bağlantısının veri yönü, çalışma sıklığı, kimlik doğrulaması, hata yönetimi ve üçüncü taraf ücretleri teklifte açıklanmalıdır.

• “Metin üretimi, görsel hazırlığı ve içerik girişinden kim sorumlu olacak?” diye sorun.
• “Mevcut içeriklerin aktarılması ve kalite kontrolü kapsamda mı?” sorusunu yöneltin.
• “Her dil için çeviri, yerelleştirme ve yayın onayını kim yönetecek?” açıklamasını isteyin.
• “Entegrasyonda hangi veriler, hangi yönde ve hangi sıklıkta aktarılacak?” diye sorun.
• “API erişimi, test ortamı ve üçüncü taraf servis ücretlerini kim sağlayacak?” konusunu netleştirin.

SEO, GEO ve Mobil Performans Nasıl Sorgulanır?

Teknik SEO, GEO ve mobil performans soyut vaatler yerine somut teslimat ve testlerle tanımlanmalıdır. “SEO uyumlu” ifadesi; tarama kuralları, URL yapısı, yönlendirmeler, site haritası, yapılandırılmış veri ve ölçüm kurulumunun hangilerini kapsadığını göstermez. Teklifte yapılacak çalışma, kullanılacak yöntem ve yayın öncesi kontrol sorumluluğu ayrı ayrı sorulmalıdır.

Core Web Vitals ve Erişilebilirlik Nasıl Test Edilir?

Mobil uyumluluk yalnızca sayfaların küçük ekrana sığması değildir; menüler, formlar, dokunma alanları ve içerik öncelikleri de test edilmelidir. Core Web Vitals sonuçları içerik, kod, font, hosting ve üçüncü taraf servislerden etkilenebilir. Kesin skor garantisi yerine test edilecek sayfalar, kullanılacak araçlar ve tespit edilen sorunların kim tarafından düzeltileceği açıklanmalıdır.

• “Teknik SEO kapsamında hangi somut teslimatlar bulunuyor?” diye sorun.
• “GEO için içerik yapısı ve entity tutarlılığı nasıl planlanacak?” sorusunu yöneltin.
• “Analytics, Search Console ve dönüşüm olaylarını kim kuracak?” açıklamasını isteyin.
• “Core Web Vitals testleri hangi sayfa türleri ve cihazlarda yapılacak?” diye sorun.
• “Klavye kullanımı, kontrast ve form etiketleri nasıl kontrol edilecek?” konusunu netleştirin.

Güvenlik, Test ve Yayın İçin Neler Sorulmalıdır?

Güvenlik, test ve yayına geçiş kapsamı geliştirme tamamlandıktan sonra ele alınacak ek işler değildir. Güvenli kodlama, erişim yetkileri, güncelleme politikası, yedekleme ve form verilerinin korunması başlangıçta planlanmalıdır. Tam güvenlik garantisi yerine riskleri azaltan kontroller, sorumlular ve olay müdahale yöntemi teklif ile sözleşmede tanımlanmalıdır.

KVKK ve Kullanıcı Kabul Testi Kimin Sorumluluğundadır?

KVKK ve çerez metinlerinin hukuki uygunluğu kurumun hukuk danışmanıyla doğrulanabilir; web tasarım firması ise onay mekanizmasının teknik uygulamasını açıklamalıdır. Kullanıcı kabul testi, kurumun gerçek iş senaryolarını sistem üzerinde doğrulamasıdır. Cihaz, tarayıcı, form, bağlantı ve içerik kontrollerinin kapsamı ile yayına izin verecek kabul ölçütleri önceden belirlenmelidir.

• “Güvenlik güncellemeleri, erişim yetkileri ve kayıtlar nasıl yönetilecek?” diye sorun.
• “Yedekler nerede tutulacak ve geri yükleme testi yapılacak mı?” sorusunu yöneltin.
• “KVKK ve çerez yönetiminde teknik ve hukuki sorumluluklar nasıl ayrılacak?” açıklamasını isteyin.
• “Hangi cihaz, tarayıcı ve kullanıcı senaryoları test kapsamına alınacak?” diye sorun.
• “Canlıya geçiş, geri dönüş ve yayın sonrası hata düzeltme planı nedir?” konusunu netleştirin.

Revizyon ve Teslim Süresi Nasıl Tanımlanmalıdır?

Revizyon ve teslim süresi, yalnızca bir adet ve bitiş tarihi yazılarak yönetilemez. Proje; analiz, tasarım, geliştirme, içerik, test, kabul ve yayın kilometre taşlarına ayrılmalıdır. Her aşamada teslim edilecek çıktı, onay verecek kişi, geri bildirim süresi ve bir sonraki aşamaya geçiş ölçütü açıkça belirlenmelidir.

Kapsam Değişiklikleri Teklife Nasıl Yansıtılır?

Revizyon, onaylanan kapsam içindeki bir teslimatın düzeltilmesidir; yeni sayfa türü, modül veya entegrasyon talebi ise kapsam değişikliği olabilir. Teklifte revizyonun hangi aşamada ve hangi büyüklükte değişiklikleri içerdiği açıklanmalıdır. Kurumun geciken içerik ve onayları ile hizmet sağlayıcının geciken teslimatlarının takvime etkisi ayrı ayrı tanımlanmalıdır.

• “Proje takvimi hangi aşama ve teslimat kilometre taşlarından oluşuyor?” diye sorun.
• “Her aşamada kim onay verecek ve geri bildirim süresi ne olacak?” sorusunu yöneltin.
• “Revizyon hakkı hangi teslimatları ve değişiklik büyüklüğünü kapsıyor?” açıklamasını isteyin.
• “Yeni talepler nasıl analiz edilecek, onaylanacak ve fiyatlandırılacak?” diye sorun.
• “Taraflardan kaynaklanan gecikmeler proje planına nasıl yansıtılacak?” konusunu netleştirin.

Lisans, Kaynak Kodu ve Bakım Nasıl Sorgulanır?

Alan adı, hosting hesabı, kaynak kodu, veri tabanı, tasarım dosyaları ve üçüncü taraf lisansları farklı dijital varlıklardır. Bunların aynı sahiplik modeline tabi olduğu varsayılmamalıdır. Her varlık için kimin adına kayıt açılacağı, kullanım ve değiştirme hakkı, teslim biçimi ve sağlayıcı değişikliğinde uygulanacak devir süreci yazılı olarak sorulmalıdır.

Garanti, Bakım ve Teknik Destek Arasındaki Fark Nedir?

Garanti, sözleşmedeki teslimat hatalarının giderilmesini; web bakım hizmeti, sistemin güncellenmesini ve izlenmesini; teknik destek ise kullanıcı soruları veya yeni olaylara müdahaleyi kapsayabilir. Yeni özellik geliştirme genellikle ayrı bir hizmettir. Kapsam, çalışma saatleri, destek kanalı, müdahale yöntemi ve yenileme maliyetleri açıklanmadığında yayın sonrasında anlaşmazlık yaşanabilir.

• “Alan adı, hosting ve yönetici hesapları kimin adına açılacak?” diye sorun.
• “Tema, eklenti, font ve servis lisanslarının yenilemesini kim üstlenecek?” sorusunu yöneltin.
• “Kaynak kodu, veri tabanı ve tasarım dosyaları hangi koşullarda teslim edilecek?” açıklamasını isteyin.
• “Garanti, bakım, teknik destek ve yeni geliştirme nasıl ayrılıyor?” diye sorun.
• “Başka bir sağlayıcıya geçişte hangi veri, erişim ve dokümanlar verilecek?” konusunu netleştirin.

Teklifler ve Ödeme Planı Nasıl Karşılaştırılmalıdır?

Web tasarım teklifleri, toplam fiyat üzerinden değil, aynı gereksinimler karşılığında sunulan teslimatlar ve sorumluluklar üzerinden karşılaştırılmalıdır. “Özel tasarım”, “SEO”, “güvenlik” veya “destek” gibi ortak başlıklar her firmada farklı kapsam taşıyabilir. Tekliflerin satır bazında incelenmesi, görünüşte düşük fiyatın hangi hizmetleri dışarıda bıraktığını veya yüksek fiyatın hangi ek değeri sunduğunu gösterir.

Ödeme Planı Hangi Teslimatlara Bağlanmalıdır?

Ödeme planı yalnızca takvim tarihlerine değil, doğrulanabilir proje kilometre taşları ve kabul ölçütlerine bağlanmalıdır. İlk proje bedelinin yanında hosting, lisans, bakım, geliştirme ve olası sağlayıcı değişikliği giderleri değerlendirilmelidir. Doğru karar; fiyat, kapsam, ekip yeterliliği, sahiplik koşulları ve toplam sahip olma maliyetinin birlikte incelenmesiyle verilir.

• Her firmaya aynı ihtiyaç, teslimat ve kabul ölçütleri listesini gönderin.
• Dahil edilen hizmetleri, kapsam dışı işleri ve üçüncü taraf giderlerini karşılaştırın.
• Ödeme aşamalarını tamamlanan ve kabul edilen teslimatlarla ilişkilendirin.
• Portföyü, doğrulanabilir referansları ve projede çalışacak ekibi inceleyin.
• İlk proje bedelinin yanında lisans, hosting, bakım ve geçiş giderlerini hesaplayın.
• Yerel erişim önemliyse Ankara web tasarım firması seçeneklerini çalışma modeliyle değerlendirin.