Web Tasarım Firması Nasıl Seçilir? 10 Kriter ve Puan Kartı

Web Tasarım Firması Nasıl Seçilir? 10 Kriter ve Puan Kartı

Yazar: Kumsal AjansOluşturulma: Güncellenme: 8 dk okuma
5.0 · 1 oy Puanınız:

Blog yazısı içeriği

Web tasarım firması seçerken yalnız portföyün görünümüne veya ilk teklif tutarına bakmak, projenin asıl risklerini görünmez bırakır. Doğru seçim; ihtiyacı anlama, gerçek proje kanıtı, kullanıcı deneyimi, teknik kalite, içerik ve SEO hazırlığı, hesap sahipliği, test, destek ve devir koşullarının birlikte değerlendirilmesiyle yapılır.

Bu rehber, farklı web tasarım firmalarından gelen teklifleri aynı ölçütlerle incelemeniz için hazırlanmıştır. Amaç “en iyi firma” şeklinde doğrulanamaz bir liste sunmak değil; kendi projeniz için uygun iş ortağını kanıta dayalı biçimde seçmenizi sağlamaktır.

Kısa Cevap: Web Tasarım Firması Nasıl Seçilir?

  1. İş hedefinizi ve kullanıcıların tamamlaması gereken görevleri yazın.
  2. Aynı ihtiyaç dokümanını bütün aday firmalarla paylaşın.
  3. Benzer kapsamlı canlı projeleri ve ekibin gerçek rolünü doğrulayın.
  4. Teklifte kapsam, hariçler, teslimatlar ve kabul kriterlerini arayın.
  5. Tasarım kadar erişilebilirlik, hız, güvenlik ve SEO hazırlığını değerlendirin.
  6. Alan adı, sunucu, kaynak kod, veri ve üçüncü taraf hesaplarının sahipliğini netleştirin.
  7. Bakım, garanti, destek ve yeni geliştirme sınırlarını ayırın.
  8. Adayları aynı puan kartıyla karşılaştırın ve kritik maddeleri sözleşmeye taşıyın.

1. Firma Aramadan Önce İhtiyacı Tanımlayın

“Modern, hızlı ve mobil uyumlu bir site istiyoruz” karşılaştırılabilir teklif almak için yeterli değildir. Web sitesinin neden yenilendiğini, kimlerin kullanacağını, kullanıcıların hangi işleri tamamlayacağını ve başarının nasıl ölçüleceğini yazın. Sayfa listesi, içerik sorumlulukları, diller, formlar, üyelik, ödeme, CRM veya ERP bağlantıları, mevcut verinin taşınması ve yasal gereksinimler kapsamı doğrudan etkiler.

Hazırlığa sıfırdan başlıyorsanız web sitesi ihtiyaç dokümanı hazırlama rehberini kullanın. Bütün adaylara aynı güncel dokümanı vermek, biri yalnız tasarım ekranlarını diğeri içerik, yazılım ve taşıma dâhil tüm projeyi fiyatladığında oluşan sahte fiyat farkını azaltır.

2. Portföyü Görünümden Fazlası İçin İnceleyin

Portföy, firmanın yaptığı işi göstermeli; yalnızca tanınmış markaların ekran görüntülerinden oluşmamalıdır. İncelediğiniz projenin canlı adresini, yayın tarihini, firmanın üstlendiği rolü ve bugün hâlâ destek verip vermediğini sorun. Tasarım, yazılım, içerik veya kampanya başka ekiplerce yapılmışsa katkının sınırı açıkça belirtilmelidir.

Referans projesini masaüstü ve telefonda deneyin. Navigasyon anlaşılır mı, önemli bilgi kolay bulunuyor mu, formlar çalışıyor mu, hata mesajları yol gösteriyor mu, metin okunuyor mu ve klavye ile temel işlemler yapılabiliyor mu? Tek bir etkileyici ana sayfa, çok sayfalı ve işletilen bir sistemin kanıtı değildir.

Referans görüşmesinde sorulabilecek sorular

  • Proje ilk kapsamına ve kararlaştırılan sürece ne ölçüde uydu?
  • Değişiklik talepleri nasıl kayıt altına alındı?
  • Yayın öncesi test ve içerik kontrolü kim tarafından yapıldı?
  • Yayın sonrasında destek taleplerine nasıl yanıt verildi?
  • Hesaplar, kaynak dosyalar ve dokümantasyon teslim edildi mi?

3. Projede Çalışacak Ekibi ve Sorumlulukları Öğrenin

Satış görüşmesini yapan kişi ile projeyi teslim edecek ekip aynı olmayabilir. Proje yöneticisi, içerik sorumlusu, arayüz tasarımcısı, ön yüz ve sunucu geliştiricisi, test sorumlusu ve SEO danışmanının hangi aşamada görev alacağını sorun. Küçük projelerde bir kişi birden fazla rol üstlenebilir; önemli olan sorumluluğun ve iletişim yolunun görünür olmasıdır.

“Sınırsız revize” gibi sınırı belirsiz vaatler yerine karar ve onay noktalarını arayın. İhtiyaç analizi, site haritası, wireframe, görsel tasarım, geliştirme, içerik girişi, test, kullanıcı kabulü ve canlı geçiş için hangi teslimatın kim tarafından onaylanacağı teklif veya proje planında bulunmalıdır.

4. Teklifte Kapsamı, Hariçleri ve Kabul Kriterlerini Arayın

İyi bir teklif yalnız yapılacakları değil, yapılmayacakları ve hangi varsayımlara dayandığını da açıklar. Kaç farklı sayfa şablonu hazırlanacağı, içerikleri kimin sağlayacağı, dil girişleri, lisanslar, entegrasyonlar, veri taşıma, görsel üretimi, eğitim, test ve yayın desteği ayrı maddeler olmalıdır.

“İletişim formu yapılacak” yerine form alanları, alıcılar, veri saklama, spam önlemi, hata durumu ve başarılı gönderimin nasıl doğrulanacağı tanımlanabilir. Benzer biçimde “SEO uyumlu” ifadesi; taranabilir bağlantılar, başlık ve meta alanları, canonical ve dil etiketleri, yönlendirme planı, sitemap, yapılandırılmış veri sorumluluğu ve performans kontrolleri gibi sınanabilir teslimatlara çevrilmelidir.

Teklifleri satır satır değerlendirmek için 12 kriterlik web sitesi teklifi karşılaştırma puan kartını kullanabilirsiniz.

5. Tasarım Sürecinin Kullanıcı Kanıtına Dayanıp Dayanmadığını Kontrol Edin

Firmanın sizi dinlemesi gerekir; fakat yalnız beğeni listenizi uygulaması yeterli değildir. Hedef kitle, görevler, içerik önceliği ve ölçüm verileri tasarım kararlarına dönüşmelidir. Site haritası ve wireframe, renk ve görsel detaylardan önce bilgi mimarisini test etmeye yardımcı olur. Prototip incelemesi yalnız “beğendiniz mi?” sorusuyla değil, belirli bir bilgiyi bulma veya formu tamamlama gibi görevlerle yapılabilir.

Erişilebilirlik sonradan eklenecek bir rozet değildir. Renk karşıtlığı, klavye kullanımı, görünür odak, anlamlı başlık yapısı, form etiketleri ve hata açıklamaları tasarım ve geliştirme boyunca ele alınmalıdır. W3C'nin Web Content Accessibility Guidelines belgesi, web içeriğini daha erişilebilir kılmak için test edilebilir başarı ölçütleri sunar. (WCAG 2.2)

6. Teknik Kaliteyi Ölçülebilir Teslimatlara Çevirin

“Çok hızlı”, “tam güvenli” veya “Google'da üst sıra garantili” gibi mutlak ifadeler yerine ölçüm yöntemi isteyin. Performans; sayfa türü, cihaz, ağ, üçüncü taraf kodlar ve gerçek kullanıcı koşullarıyla değişir. Hangi sayfaların hangi ortamda test edileceği, kritik sorunların nasıl kapatılacağı ve yayın sonrası izlemenin kapsamı yazılmalıdır.

Google, Core Web Vitals için LCP, INP ve CLS ölçülerini kullanır ve iyi bir kullanıcı deneyimi için gerçek kullanıcı verilerinin 75. yüzdelik diliminde önerilen eşiklerin karşılanmasını belirtir. Bunlar tek başına bütün kaliteyi açıklamaz; yine de performans konuşmasını ölçülebilir hâle getirir. (Web Vitals)

Güvenlik gereksinimleri projenin işlevine göre değişir. Üyelik, kişisel veri, ödeme veya yönetim paneli bulunan bir sistem, basit tanıtım sitesinden farklı risk taşır. OWASP Application Security Verification Standard, web uygulaması güvenlik gereksinimlerini ve doğrulama düzeylerini yapılandırmak için bir temel sunar. (OWASP ASVS)

7. İçerik, SEO ve Yönlendirme Sorumluluğunu Netleştirin

Yeni tasarım kötü veya eksik içerik sorununu tek başına çözmez. Mevcut sayfaların hangisinin korunacağı, güncelleneceği, birleştirileceği veya kaldırılacağı proje başında belirlenmelidir. Her sayfanın amacı, ana konusu, uzman katkısı, görselleri ve onay sahibi bulunmalıdır.

Adres yapısı değişecekse eski URL'ler yeni karşılıklarına 301 ile yönlendirilmelidir. Çok dilli projelerde Türkçe ve İngilizce adresler ayrı ayrı eşlenmeli; canonical, hreflang, dil değiştirici ve sitemap kontrolleri yayın planına alınmalıdır. Google'ın SEO başlangıç rehberi anlaşılır site yapısı, yararlı içerik ve arama motorlarının sayfaları keşfedebilmesi için temel uygulamaları açıklar. (Google SEO Starter Guide)

8. Kaynak Kod, Veri ve Hesap Sahipliğini Sözleşmeden Önce Çözün

Alan adı, DNS, sunucu, kaynak kod deposu, veri tabanı, medya dosyaları, e-posta servisi, analiz araçları ve üçüncü taraf API hesaplarının sahibi ile yöneticisi yazılı olmalıdır. Kurumun yalnız ajans hesabına bağlı kalması, sağlayıcı değişikliğinde veya acil durumda erişim riskine dönüşebilir.

Kumsal Ajans'ın devir yaklaşımında önce hosting/panel, alan adı ve DNS, kaynak kod, veri tabanı, FTP/SSH ve üçüncü taraf servis erişimleri doğrulanır. Devirden önce site dosyaları, veri tabanı, medya ve mevcut canlı sürümün tam yedeği alınır. Kaynak kod, veri tabanı veya kritik erişimler eksikse canlı taşıma ya da kapsamlı müdahale başlatılmaz; eksikler tamamlandıktan sonra site, formlar, e-posta gönderimi, SSL, DNS, yönlendirmeler ve temel işlevler kontrol edilir. Nihai geçiş müşteri onayıyla kesinleştirilir.

Teslim listesinde bulunması gerekenler

  • Güncel kaynak kod ve sürüm geçmişi
  • Veri tabanı, medya ve yapılandırma yedekleri
  • Alan adı, DNS, sunucu ve sertifika erişimleri
  • Üçüncü taraf servis, lisans ve yenileme listesi
  • Kurulum, yayın ve geri alma dokümantasyonu
  • Yönetim paneli eğitimi ve kullanıcı yetkileri
  • Bilinen sorunlar, test sonuçları ve açık işler

9. Bakım, Garanti ve Yeni Geliştirmeyi Birbirinden Ayırın

Garanti, kabul edilen kapsam içindeki kusurların hangi koşullarda giderileceğini açıklar. Bakım; güncelleme, yedekleme, izleme, uyumluluk veya süreklilik gibi sözleşmede tanımlanan hizmetleri kapsayabilir. Yeni özellik, yeni entegrasyon veya kapsam değişikliği ise ayrı geliştirmedir.

Destek kanalını, çalışma saatlerini, öncelik sınıflarını, ilk yanıt hedefini, çözüm veya geçici önlem sürecini ve ücretlendirme modelini sorun. “Her zaman destek” ifadesi ancak kapsam ve sorumluluklar açık olduğunda anlamlıdır. İlk yatırımın yanında yenileme, lisans, barındırma, bakım ve gelecekteki geliştirmeleri görmek için toplam sahip olma maliyetini değerlendirin.

10. Adayları Aynı Puan Kartıyla Değerlendirin

KriterAğırlıkİstenecek kanıt
İhtiyacı anlama ve kapsam%20Varsayımlar, hariçler, kullanıcı görevleri ve kabul ölçütleri
Benzer proje deneyimi%15Canlı referans, gerçek rol ve doğrulanabilir iletişim
UX, UI ve erişilebilirlik%15Akış, wireframe, prototip ve erişilebilirlik kontrolü
Teknik kalite ve güvenlik%15Mimari yaklaşım, test planı, performans ve güvenlik kontrolleri
İçerik, SEO ve taşıma%10İçerik sorumluluğu, URL envanteri, 301 ve çoklu dil planı
Proje yönetimi ve iletişim%10Takvim, sorumlular, onay ve değişiklik yönetimi
Sahiplik ve devir%10Kod, veri, hesap, yedek ve dokümantasyon teslimi
Toplam maliyet ve destek%5İlk proje, yenileme, bakım ve yeni geliştirme sınırları

Ağırlıkları projenize göre değiştirin. Üyelik ve hassas veri içeren bir platformda güvenlik ağırlığı artabilir; yoğun içerikli çok dilli bir sitede içerik operasyonu ve taşıma daha önemli olabilir. Kritik bir sahiplik veya güvenlik koşulunu karşılamayan adayı, toplam puanı yüksek olsa bile ayrıca değerlendirin.

Kaçınılması Gereken Uyarı İşaretleri

  • İhtiyacı dinlemeden tek paket ve kesin süre sunulması
  • Canlı ve doğrulanabilir referans yerine yalnız ekran görüntüsü gösterilmesi
  • Arama sırası, satış veya dönüşüm için koşulsuz garanti verilmesi
  • Teklifte içerik, entegrasyon, test ve taşıma sorumluluklarının bulunmaması
  • Alan adı, kaynak kod veya veri tabanının teslim koşullarının belirsiz olması
  • Kritik hesapların yalnız tedarikçi adına açılması
  • Bakım, garanti ve yeni geliştirme kavramlarının tek belirsiz hizmette toplanması
  • Türkçe ve İngilizce URL değişiklikleri için ayrı 301 planı yapılmaması

Sonuç

Doğru web tasarım firması, en gösterişli sunumu veya en düşük ilk tutarı sunan ekip olmak zorunda değildir. Uygun firma; ihtiyacı ortak bir kapsama dönüştüren, kararlarını kanıtlayan, kaliteyi test eden ve koddan hesaba kadar teslim sahipliğini açıkça tanımlayan iş ortağıdır.

Önce ihtiyaç dokümanını hazırlayın, sonra aynı kapsamı paylaşarak adaylardan yazılı teklif alın. Portföy, ekip, süreç, teknik kalite, içerik, sahiplik ve toplam maliyeti aynı puan kartıyla değerlendirin. Seçimden önce kritik koşulları sözleşmeye ve teslim listesine taşıyın.

Anasayfa

Projelerimiz

Ürünlerimiz

Hizmetlerimiz