Web sitesi projelerinde gecikme, revizyon döngüsü ve bütçe sapması çoğu zaman tasarımdan değil, eksik bir brief’ten kaynaklanır. İyi hazırlanmış bir brief; hedefi, kapsamı, içerik sorumluluklarını ve teknik ihtiyaçları daha en başta görünür hale getirir. “Kurumsal site istiyoruz” cümlesi tek başına yeterli olmaz. Kaç sayfa olacağı, hangi formların çalışacağı, CRM’e veri akıp akmayacağı, çok dilli yapının gerekip gerekmediği, yönetim panelinin hangi ekibin kullanımına uygun olacağı gibi başlıklar netleşmezse proje ilerledikçe varsayımlar artar.
Web tasarım brief hazırlama süreci yalnızca ajansa bir doküman göndermek için yapılmaz. Aynı zamanda pazarlama, satış, operasyon ve BT ekiplerini içeride aynı masada buluşturur. 60 ila 90 dakikalık tek bir toplantıda alınan notlar bile sonradan haftalar sürebilecek belirsizliği azaltabilir. Özellikle KOBİ’lerde kaynaklar sınırlıdır; kurumsal firmalarda ise onay zinciri uzundur. Her iki yapıda da iyi bir brief, karar kalitesini artırır.
Bu rehberde, hedef tanımından sayfa kapsamına; entegrasyonlardan teslim kriterlerine kadar pratik bir çerçeve sunuyoruz. Amaç, estetik istek listesi hazırlamak değil; iş sonucuna bağlı bir doküman oluşturmaktır.
Brief neden kritik: 3 yaygın proje riski
Bir web projesinde brief yetersizse sorunlar genellikle ilk 2 haftada görünmeye başlar. Tasarım ekibi farklı bir kullanıcı akışı önerir, şirket tarafı ise başka bir içerik yapısı bekler. Ardından revizyonlar çoğalır.
- Kapsam kayması: Başta 12 sayfa denilen proje; blog, kariyer alanı, bayi başvuru formu ve çoklu dil ihtiyacı eklendikçe 20+ sayfaya çıkabilir.
- Onay gecikmesi: Marka, hukuk, BT ve yönetim ekipleri sonradan devreye girerse teslim planı 2-4 hafta uzayabilir.
- Entegrasyon sürprizleri: Form verisinin yalnızca e-posta ile gelmesi planlanırken son aşamada CRM, ERP ya da e-fatura sistemine aktarım beklentisi ortaya çıkabilir.
Brief bu riskleri tamamen ortadan kaldırmaz; ama görünür kılar. Önemli olan da budur. Görünür risk yönetilebilir, gizli risk ise büyür.
İlk bölüm: Projenin hedefini tek cümlede yazın
Brief’in ilk sayfasında proje hedefi mutlaka yer almalı. “Modern bir site istiyoruz” bir hedef değildir. Ölçülebilir bir iş sonucu ya da açık bir kullanım amacı gerekir. Örneğin:
- Mevcut sitedeki teklif formu dönüşüm oranını artırmak
- 3 farklı ürün grubunu daha anlaşılır sunmak
- Yurt dışı satış için İngilizce içerikli kurumsal vitrini yayına almak
- Bayi başvurularını tek merkezde toplamak
İdeal yaklaşım, 1 ana hedef ve en fazla 2 destek hedef yazmaktır. 7-8 hedef içeren brief’ler karar almayı zorlaştırır. Kurumsal yapılarda her birimin talebi metne eklenir; bir noktadan sonra öncelik sırası kaybolur.
Hedefi netleştiren kısa soru seti
Aşağıdaki 5 soru, ilk toplantı için çoğu zaman yeterlidir:
- Bu site neden şimdi yenileniyor?
- Başarı 6 ay sonra nasıl anlaşılacak?
- Birincil kullanıcı kim: potansiyel müşteri, bayi, aday, yatırımcı?
- En kritik aksiyon ne: form doldurma, arama, demo talebi, başvuru?
- Mevcut sitede korunması gereken ne var?
Bu bölüme tarihi de ekleyin. Örneğin: “Yeni ürün lansmanı 15 Eylül 2026.” Tek bir satır bile tasarım, içerik ve test planını etkileyebilir.
Sayfa kapsamını belirsiz bırakmayın
Web tasarım brief hazırlama sürecinde en sık atlanan alanlardan biri sayfa kapsamıdır. “Kurumsal site” ifadesi tek başına bir iş tanımı değildir. En azından ilk sürüm için bir site haritası hazırlanmalı. 10 sayfalık bir vitrin sitesi ile 35 sayfalık çok dilli bir yapı arasında emek, içerik ve kalite kontrol farkı ciddi boyuttadır.
Örnek kapsam tablosu mantığı
Brief içinde şu yapıda bir liste yer almalı:
- Ana sayfa
- Hakkımızda
- Hizmetler ana sayfası + 6 hizmet detayı
- Sektörler sayfası + 4 sektör detayı
- Referanslar
- Blog liste + yazı detayı
- İletişim
- KVKK / çerez / aydınlatma metinleri
Bu örnekte toplam 16-18 şablon ya da içerik ekranı ortaya çıkabilir. Çünkü bazı sayfalar liste ve detay yapısı içerir. Tasarım tarafında “tek sayfa” gibi görünen bir ihtiyaç, geliştirme tarafında farklı bileşenler anlamına gelebilir.
Şunu da baştan netleştirin: hangi sayfalar ilk yayında olacak, hangileri 2. fazda açılacak? Faz ayrımı yapılmadığında ekip, tüm talepleri aynı takvime sıkıştırmaya çalışır.
İçerik sorumluluğunu baştan belirleyin
Bir web projesinin gecikmesinin başlıca nedenlerinden biri, metin ve görsel üretiminin kime ait olduğunun açıkça yazılmamasıdır. Tasarım hazır olur, içerik gelmez. Yayın tarihi ertelenir.
Brief’te her içerik türü için sahiplik tanımı yer almalı:
- Metinler: Şirket sağlayacak / ajans düzenleyecek / sıfırdan üretilecek
- Görseller: Mevcut arşiv kullanılacak / yeni çekim yapılacak / stok görsel kullanılacak
- Çeviri: İç kaynak / profesyonel çeviri / AI destekli ilk taslak + insan kontrolü
Somut bir örnek düşünelim. 2 dilde, 14 sayfalı bir sitede her sayfanın ortalama 250-400 kelime metin içerdiğini varsayalım. Bu durumda yalnızca gövde metni için yaklaşık 7.000 ila 11.000 kelime arasında içerik ihtiyacı oluşur. Bu rakam abartılı değildir; çoğu kurumsal projede metin hacmi tahmin edilenden fazladır.
Fonksiyonları “istek” değil “senaryo” olarak yazın
“Teklif formu olsun” ifadesi eksiktir. Hangi alanlar olacak, veri nereye düşecek, kim yanıtlayacak, dosya yükleme gerekecek mi? İşlevler kısa senaryolarla tanımlandığında ekip yanlış varsayımlar üretmez.
Net yazılmış fonksiyon örnekleri
- İletişim formu: Ad, şirket, telefon, e-posta, mesaj alanları; reCAPTCHA; form kaydı hem e-posta hem CRM’e düşecek.
- Bayi başvuru formu: PDF yükleme, şehir seçimi, onay kutusu; başvuru durumu panelden dışa aktarılabilecek.
- Ürün kataloğu: Kategori filtreleme, PDF indirme, ürün detayında teknik özellik tablosu.
Gerekiyorsa kısa bir teknik not da ekleyin. Örneğin:
POST /api/leads
{
"name": "Ayşe Yılmaz",
"email": "[email protected]",
"source": "website-contact-form"
}Böylesine basit bir örnek bile entegrasyon mantığını herkes için anlaşılır hale getirir.
Entegrasyon ihtiyaçlarını ayrı başlıkta toplayın
Kurumsal web projelerinde en kritik alanlardan biri entegrasyondur. Tasarım kusursuz olabilir; ancak form verisi içerideki sistemlere akmıyorsa iş yükü azalmaz. Bu yüzden brief’te “entegrasyonlar” bölümü ayrı bir başlık olarak yer almalı.
En sık görülen entegrasyon başlıkları
- CRM: HubSpot, Salesforce, Zoho veya özel CRM
- ERP: Müşteri, ürün ya da bayi verisi senkronizasyonu
- E-posta pazarlama: Mailchimp, Insider, benzeri platformlar
- Canlı destek ve chatbot araçları
- Analitik: GA4, Search Console, tag yönetimi, olay takibi
- Kimlik doğrulama: SSO, Azure AD, özel kullanıcı girişi
Bu noktada teknik derinlik önemlidir. “CRM entegrasyonu” demek tek başına yeterli olmaz. Tek yön mü, çift yön mü? Gerçek zamanlı mı, saatlik mi? API mevcut mu? Test ortamı var mı? Yetkilendirme OAuth2 mi, API key mi? Bu 4-5 bilgi, teklif ve planlamayı doğrudan etkiler.
Gerçek bir senaryo düşünün: bayi başvuru formu web sitesinden alınıyor, başvuru önce bir ön değerlendirme havuzuna düşüyor, ardından satış ekibi CRM içinde durum değiştiriyor. Bu akış baştan yazılmazsa ekip yalnızca form gönderimini geliştirir; operasyon tarafı yine Excel ile takip yapmak zorunda kalır.
Tasarım beklentisini örneklerle sınırlandırın
“Modern, sade, premium” gibi sıfatlar tek başına yeterince yön vermez. Brief’te beğenilen 3 site ve beğenilmeyen 2 örnek paylaşmak çok daha işlevseldir. Her örnek için neden belirtin: menü yapısı, tipografi, ürün sunumu, animasyon dozu, mobil kullanım kolaylığı.
Marka tarafında sabit kurallar varsa mutlaka ekleyin: logo kullanım alanı, renk kodları, font ailesi, fotoğraf dili, kurumsal kimlik PDF’i. Eğer bunlar yoksa bunu da açıkça yazın. Çünkü “marka rehberi yok” bilgisi bile proje yaklaşımını değiştirir.
Mobil öncelik de ayrıca not edilmeli. Pek çok B2B sitede trafik mobilde yüksekken, dönüşüm masaüstünde daha güçlü olabilir. Bu ayrım; menü kurgusu ve form uzunluğu gibi kararları doğrudan etkiler. En azından son 3 aylık cihaz dağılımı verisi varsa brief’e eklenmesi fayda sağlar.
Teknik çerçeve: CMS, performans, güvenlik, SEO
Bu bölüm çoğu brief’te 3 satırla geçilir. Oysa sonradan en fazla karar değişikliği genellikle burada yaşanır. İçerik yönetimi için WordPress, headless CMS ya da özel panel mi isteniyor? Şirket içinde içerik girecek kişi sayısı 1 mi, 12 mi? Rol ve yetki gerekecek mi?
- CMS ihtiyacı: Blog, sayfa, ürün, referans, dil yönetimi
- Performans beklentisi: Görsel optimizasyonu, önbellekleme, CDN kullanımı
- Güvenlik: SSL, form koruması, loglama, KVKK uyumu için veri işleme notları
- SEO temeli: Meta alanları, yönlendirmeler, schema gereksinimleri, site haritası
Ölçü koyabiliyorsanız mutlaka koyun. Örneğin “yayın öncesi 301 yönlendirme listesi hazırlanacak” ya da “mevcut sitedeki 40 kritik URL korunacak”. Bu tür somut notlar, özellikle yeniden tasarım projelerinde organik görünürlük kaybı riskini azaltır.
Takvim, onay mekanizması ve teslim kriterleri
İyi bir brief yalnızca ne yapılacağını değil, nasıl onaylanacağını da tarif eder. Tek karar vericinin olmadığı projelerde bu bölüm gerçekten hayat kurtarır.
Kısa bir teslim planı örneği
- Hafta 1: brief onayı, keşif toplantısı, içerik envanteri
- Hafta 2-3: bilgi mimarisi, wireframe, ana sayfa yönü
- Hafta 4-5: görsel tasarım, içerik girişi hazırlığı
- Hafta 6-7: geliştirme, entegrasyon, test
- Hafta 8: UAT, eğitim, yayın
Bu plan her proje için sabit değildir; ancak aşama mantığının tanımlanması gerekir. Ayrıca her aşamada onay verecek kişi veya ekip adı da belirtilmeli. Örneğin “Pazarlama müdürü + BT sorumlusu”.
Teslim kriterleri de mutlaka yazılmalı: mobil ve masaüstü temel tarayıcı testleri tamamlanmış olacak, formlar çalışacak, analytics kodları eklenecek, 404 ve yönlendirmeler kontrol edilecek, yönetim paneli eğitimi verilecek. Belirsiz bir “site yayına hazır olacak” cümlesi yerine kontrol listesi kullanmak çok daha faydalıdır.
KOBİ ve kurumsal firmalar için farklı brief yaklaşımı
Her şirket aynı ayrıntı seviyesine ihtiyaç duymaz. 20 çalışanlı bir KOBİ ile çok markalı bir holdingin brief yapısı aynı olmamalıdır.
KOBİ’ler için pratik yaklaşım
6-8 sayfalık temel bir doküman çoğu zaman yeterlidir. Burada hız önemlidir. Karar verici sayısı az olduğu için hedef, sayfa listesi, form ihtiyaçları ve içerik sorumluluğu net yazıldığında proje sağlıklı ilerler. Eğer CRM yoksa ilk fazda e-posta + panel kayıt modeli tercih edilebilir.
Kurumsal firmalar için genişletilmiş yaklaşım
Burada 12+ sayfalık brief normal kabul edilir. Marka standartları, hukuk metinleri, erişilebilirlik beklentileri, güvenlik incelemeleri, test ortamları ve çoklu entegrasyonlar baştan toplanmalıdır. Özellikle satın alma süreçlerinde kapsam dışı maddelerin ayrıca tanımlanması yararlı olur.
Brief’i 1 günde tamamlamak için kontrol listesi
Uzun uzun yazmak zorunda değilsiniz. Doğru başlıkları doldurmanız yeterlidir. Tek bir çalışma oturumunda şu alanları tamamlayabilirsiniz:
- Proje hedefi ve yayın tarihi
- Hedef kullanıcı profilleri
- Sayfa listesi ve faz ayrımı
- Fonksiyon senaryoları
- Entegrasyon listesi ve teknik notlar
- İçerik sahipliği
- Tasarım referansları
- Takvim, onaycılar, teslim kriterleri
Eksiksiz bir brief, daha pahalı proje anlamına gelmez. Çoğu durumda tam tersi olur; çünkü tahminler yerine net kapsam konuşulur. Ekipler aynı hedefe odaklandığında kalite yükselir, revizyon azalır, yayın süreci daha kontrollü yürür.
Kapanışta şunu vurgulamak gerekir: web sitesi, görsel bir vitrin olmanın ötesinde iş süreçlerine bağlı bir dijital varlıktır. Bu nedenle brief’i yalnızca tasarım dili için değil; veri akışı, içerik üretimi ve operasyon etkisi için de hazırlayın. İyi bir başlangıç dokümanı, projenin geri kalanında çıkabilecek birçok sorunu daha ortaya çıkmadan çözer.
