Web Sitesi Tasarımı ve Yazılımı
Web sitesi teklif briefi: Ajansın doğru kapsam çıkarması için
Web sitesi teklifi için amaç, içerik, sayfalar, işlevler ve onay sürecini açıklayan bir brief hazırlayın; belirsizlikleri ve kapsam varsayımlarını görünür kılın.

Ajansa “kurumsal bir site istiyoruz” diye mesaj gönderdiniz. Gelen teklif tasarım ve yazılımı kapsıyor, ancak hizmet metinlerinin kim tarafından hazırlanacağı, İngilizce sürümün kaç sayfa olacağı ve eski blogların taşınıp taşınmayacağı belli değil. Proje başladıktan sonra bu başlıkların her biri yeni karar ve ek iş haline geliyor. Web sitesi teklif briefi, bu belirsizlikleri tasarım başlamadan görünür kılan ortak çalışma belgesidir.
Briefin iyi olması çok uzun olması demek değildir. Doğru soruları cevaplaması, eksik bilgileri açık bırakması ve tedarikçiden hangi varsayımla teklif istendiğini göstermesi gerekir. Bu rehber kurgusal bir danışmanlık işletmesinin yeni site hazırlığı üzerinden ilerliyor. Amaç, teknik şartname yazamayan bir ekibin de karar vermeye yeterli başlangıç bilgisi hazırlayabilmesidir. Teknik çözüm, bu çerçeve üzerinden ajansla birlikte ayrıntılandırılabilir.
İş problemini mevcut durumla tarif edin
“Daha modern görünmek” anlaşılır bir beklenti, fakat neyin değişmesi gerektiğini tek başına anlatmaz. Mevcut sitede hizmetler birbirine mi karışıyor, içerik güncellemesi zor mu, doğru başvuru gelmiyor mu? Sorunu somut gözlemle tarif edin. Mümkünse örnek adres veya kullanıcı görevi ekleyin. Kanıt olmayan yorumları kesin sonuç gibi yazmayın.
Danışmanlık işletmesi örneğinde ziyaretçiler üç hizmeti aynı sayfada karıştırıyor olsun. Briefte “hizmetlerin uygunluk ve teslimat farkları bağımsız sayfalarda anlaşılır olmalı” denebilir. Bu ifade henüz tasarım çözümünü kilitlemez, fakat tasarımın hangi sorunu çözmesi gerektiğini gösterir. Proje ekibi daha sonra önerisini bu ihtiyaçla açıklayabilir. Başarıyı değerlendirecek görev de buradan çıkar: ziyaretçi kendi ihtiyacına uygun hizmeti tanıyabiliyor mu?
Hedef ziyaretçiyi karar ve bilgi ihtiyacıyla tanımlayın
Hedef kitle başlığına yalnızca sektör veya yaş aralığı yazmak hizmet sitesi için yetersiz kalabilir. Siteye gelen kişinin görevini ve karar aşamasını düşünün. Yeni tedarikçi araştıran satın alma sorumlusu, teknik uygunluk arayan uzman ve ilk kez hizmeti öğrenen işletme sahibi farklı ayrıntılara ihtiyaç duyabilir. Brief bu farkları kısa örneklerle gösterebilir.
Her grup için sitenin cevaplaması gereken temel soruyu yazın. Sonraki adım görüşme, doküman inceleme veya başvuru olabilir. Bütün ziyaretçilerden aynı anda aynı işlemi beklemek öncelikleri belirsizleştirir. Ana ve ikincil görevleri sıralayın. Bu sıralama ajansın bilgi mimarisi ve içerik önerisini etkiler. Hedefler arasında çelişki varsa bunu belgeden saklamayın; çözülmesi gereken karar olarak işaretleyin. Brief, bütün sorunların önceden bitirildiği belge olmak zorunda değildir.
Sayfa envanteri ile şablon ihtiyacını ayırın
Beklenen ana sayfaları ve hizmet ayrıntılarını listeleyin. Her satırda amaç, dil ve içeriğin hazır olup olmadığı bulunabilir. “Blog olacak” ifadesi yeterli olmayabilir; kategori, liste, ayrıntı ve arama gibi ihtiyaçlar ayrıca değerlendirilir. Projeler veya ekip bölümü de aynı şekilde içerik türü ve görünüm kararları içerir.
Sayfa sayısı tasarım sayısı değildir
On hizmet sayfası ortak bir tasarım şablonunu kullanabilir. Buna karşılık az sayıda sayfa farklı işlevler nedeniyle daha fazla geliştirme gerektirebilir. Teklifte içerik adedi, şablon sayısı ve özel bileşenler ayrı anlaşılmalıdır. Brief bu ayrımı kesinleştiremiyorsa adaydan varsayımını yazmasını isteyebilir. Böylece aynı başlık altındaki farklı işlerin fiyatı karşılaştırılırken görünmez kapsam farkı azalır. Her şablonun gerçek içerik örneğiyle değerlendirilmesi de kabul planına eklenebilir.
İçerik durumunu ve sahibini açıkça yazın
Metinler hazır mı, yeniden yazılacak mı, yoksa yalnızca düzenlenecek mi? Görsellerin kullanma izinleri var mı? Çeviri kim tarafından hazırlanacak ve kim onaylayacak? Bu sorular iş takvimini doğrudan etkiler. İçeriğin müşteri tarafından sağlanacağı varsayılıyorsa teslim edilecek biçim ve kontrol sorumlusu belirlenmelidir.
Eksik içeriği hazır gibi göstermek teklifin daha hızlı çıkmasını sağlayabilir ama proje belirsizliğini büyütür. Bir tabloyla her içerik türünün durumunu kaydedin. Ürün görselleri mevcut, hizmet açıklamaları taslak, İngilizce sürüm henüz yok gibi net notlar yeterli başlangıç olabilir. Örnek dosyaları erişilebilir ve onaylı bir yerde toplayın. Kaynağı belirsiz veya paylaşılmaması gereken belgeleri pakete eklemeyin. İçerik sorumluluğu teknik ekibin tahminine bırakılmamalıdır.
İşlevleri düğme adıyla değil senaryoyla anlatın
“İletişim formu, üyelik, entegrasyon” gibi başlıklar tek başına kapsam çıkarmaz. Form hangi bilgiyi alacak, nereye iletecek ve kim yanıt verecek? Üyelik hangi yetkiyi sağlayacak? Entegrasyon hangi veriyi hangi yönde aktaracak? Bu soruların kısa yanıtları geliştirme ihtiyacını somutlaştırır.
Bir işlev için başlangıç, kullanıcı eylemi ve beklenen sonuç yazılabilir. Danışmanlık örneğinde hizmet seçen kişi talep formu gönderir; ilgili ekip bilgiyi belirlenen kayıt alanında görür. Başarısız gönderim veya eksik alan durumunda ne olacağı da düşünülür. Teknik ayrıntıyı bilmiyorsanız bunu açıkça belirtin; ajans araştırma ve tasarım aşaması önerebilir. Web tasarım ve yazılım briefinde belirsiz işlevi hazır özellik gibi sunmak yerine araştırılacak soru olarak ayırmak daha doğru teklif zemini oluşturur.
Tasarım referansına beğeni nedenini ekleyin
Bir siteyi örnek göstermek hangi özelliğin istendiğini açıklamayabilir. İçerik sırası mı, yazı ölçeği mi, menü davranışı mı yoksa fotoğraf kullanımı mı beğeniliyor? Referansın yanına kısa bir not ekleyin. Görünümün kopyalanması yerine çözülmek istenen ilişki anlaşılır.
Birbirine zıt referanslar varsa öncelik verin. Yoğun bilgi gösteren bir panel ile çok boşluklu marka sayfası aynı ihtiyacı karşılamayabilir. Markanın mevcut kimlik dosyaları, kullanılacak logo sürümü ve görsel yaklaşımı ayrıca paylaşılabilir. Henüz karar verilmemiş alanları sabitlemeyin. Ajansın hangi konuda öneri üretmesinin beklendiği belli olsun. Brief, tasarımcıya düşünme alanı bırakırken işletmenin gerçekten koruması gereken sınırları da belirtmelidir.
Teknik çevreyi bilinen bilgilerle tarif edin
Alan adı, mevcut hosting, kullanılan yönetim paneli ve erişilebilir entegrasyon bilgileri değerlendirilebilir. Her teknik terimi bilmek gerekmez. Mevcut hizmet sağlayıcıdan onaylı bilgi alınabilir. Bilinmeyen alanlar araştırma gereksinimi olarak kaydedilir. Erişim bilgileri ise herkese açık teklif belgesine yazılmamalı; gerektiğinde uygun güvenli yöntemle paylaşılmalıdır.
Hesap ve varlık sahipliği de önemlidir. Alan adı kimin kontrolünde, yeni sistemin hesapları nasıl teslim edilecek, teknik bakım kimde olacak? Bu kararlar yalnızca yazılım tercihi değildir. Kurumun devamlılığıyla ilgilidir. Mevcut altyapının zorunlu korunması gerekiyorsa sebebini açıklayın. Böyle bir sınır yoksa sırf alışkanlık nedeniyle çözümü kilitlemeyin. Adayın önerdiği yaklaşımın ihtiyaç ve bakım düzeniyle ilişkisini anlatmasını isteyebilirsiniz.
Eski adresler ve veri geçişini teklif kapsamına alın
Yenileme projesinde mevcut sayfa, görsel ve belgelerin akıbeti belirlenmelidir. Hangi içerik korunacak, taşınacak veya kaldırılacak? Eski bağlantıların karşılıkları için adres eşleştirme işi gerekebilir. Bunu yayın gününde fark etmek takvim ve kalite sorunları yaratabilir. Briefte mevcut içerik miktarı ve erişilebilir kayıtlar belirtilmelidir.
Google'ın adres değişikliği rehberi, taşınan içerikler için planlama ve eşleştirme yaklaşımını açıklar. Ajansın bu işte neyi kontrol edeceği, hangi veriyi müşteriden beklediği ve yayından sonra nasıl doğrulama yapacağı teklifte görülebilir. Taşıma bedeli varsa neye göre hesaplandığı anlaşılmalıdır. Sadece dosyaların kopyalanmasıyla kullanıcı yolculuğunun korunması aynı teslim değildir. İçerik ilişkilerinin de ele alınması gerekir.
SEO beklentisini teslim edilebilir işlere çevirin
“SEO uyumlu” ifadesi farklı tekliflerde farklı anlam taşıyabilir. Başlık alanları, açıklamalar, bağlantı yapısı, site haritası, teknik erişim ve mevcut adreslerin yönetimi ayrı işlerdir. İçerik araştırması veya sürekli optimizasyon hizmeti sunulacaksa ayrıca belirtilmelidir. Böylece genel etiket yerine hangi çıktının teslim edileceği konuşulur.
Google'ın SEO başlangıç rehberi, içerik ve teknik keşfin temel ilişkisini anlatır. Belirli bir sıra garantisi teslim kriteri yapılmamalıdır. Bunun yerine üzerinde çalışılabilen ve doğrulanabilen işler tanımlanabilir. Hangi sayfalarda hangi bilgiler girilecek, kim inceleyecek ve teknik kontrol nasıl raporlanacak? Briefte bu soruların bulunması, satış vaatlerinin kapsam maddesine dönüşmesine yardımcı olur. Arama performansı ise uygun ölçüm ve devam eden değerlendirme gerektirir.
Takvimi tarihlerin arkasındaki bağımlılıklarla yazın
Yayın için gerçek bir etkinlik veya ticari tarih varsa belirtin. İçerik teslimi, onay, çeviri ve erişimlerin hazırlanması bu tarihle ilişkilidir. Sadece “bir ayda bitsin” demek hangi işin ne zaman hazır olacağını açıklamaz. İşletmenin karar verecek kişileri ve geri bildirim düzeni de takvimin parçasıdır.
Aşamalar arasında hangi onayların gerektiğini belirleyin. Birden fazla yöneticinin çelişen yorumları nihai kararı geciktirebilir. Tek bir onay sorumlusu veya açık karar yöntemi yararlı olabilir. Yeni kapsam talebinin takvime nasıl yansıyacağı da teklif ve sözleşmede değerlendirilir. Başlangıçta bütün değişiklikleri öngörmek mümkün olmayabilir; buna rağmen değişikliklerin nasıl karara bağlanacağı önceden bilinmelidir. Bu düzen iletişim yükünü azaltabilir.
Kabul ve teslimden sonraki işi tanımlayın
Site yayına alınmadan hangi görevler denenmeli? Hizmet bulma, dil değiştirme, form gönderme ve içerik güncelleme gibi gerçek işlemler kabul listesine girebilir. Mobil görünüm, kritik tarayıcılar ve hata senaryoları proje kapsamına göre seçilir. Kabul yalnızca ekranların beğenilmesi olmamalıdır.
Eğitim, hesap devri, dokümantasyon, hata düzeltme ve sonraki bakım ayrı sorumluluklar içerebilir. Destek süresinin kapsamı ve yanıt yöntemi açık olmalıdır. Kurumsal web sitesi teklifini bu maddelerle değerlendirmek, lansmandan sonra işletmenin neyi kendi yapacağını anlamasını sağlar. Belgeyi son kez okuyup varsayımlar, açık sorular ve onaylı kararları ayırın. İyi brief, ajansa her çözümü söylemez; doğru kapsamı üretmesi için gerekli gerçeği ve karar sınırlarını verir.
Örneğin “form çalışacak” maddesi, “geçerli hizmet talebi gönderildiğinde ilgili ekip kaydı görecek ve kullanıcıya onay gösterilecek” şeklinde açılabilir. Aynı satırda bu sonucu kimin deneyeceği belirtilir. Böylece teklif, geliştirme ve kabul toplantısı aynı beklenen davranış üzerinden konuşur.
Sık Sorulan Sorular
Teknik bilgimiz yoksa brief hazırlayabilir miyiz?
Evet. Mevcut sorun, kullanıcı görevleri, içerik durumu ve iş akışı başlangıç için değerlidir. Bilinmeyen teknik alanları araştırılacak soru olarak yazabilirsiniz. Yanlış kesinlik üretmek yerine adaydan varsayım ve araştırma kapsamını açıklamasını isteyin.
Brief ne kadar uzun olmalı?
Teklifin temel kararlarını destekleyecek kadar kapsamlı olmalıdır. Gereksiz kurum tarihi yerine amaç, sayfalar, içerik ve işlevlere odaklanın. Karmaşık işte ek belgeler gerekebilir; kısa olması veya uzun olması tek başına kalite ölçüsü değildir.
Örnek site bağlantısı vermek yeterli mi?
Hangi özelliğin beğenildiği açıklanmadığında yetersiz kalabilir. Menü, içerik sırası veya görsel yaklaşım gibi somut notlar ekleyin. Referans, başka tasarımı kopyalama talimatı değil ihtiyacın anlaşılmasına yardımcı bağlam olmalıdır.
Bütçeyi briefte belirtmeli miyiz?
Bilinen sınır veya öncelik paylaşılabilir; karar işletmenin yaklaşımına bağlıdır. Kapsamla bütçenin nasıl dengeleneceği açık konuşulmalıdır. Aynı bütçe içinde farklı aşamaların önerilmesi mümkün olabilir. Kesinleşmemiş rakamı bağlayıcı bilgi gibi sunmayın.
İçerikler hazır değilken teklif alınabilir mi?
Durum açıkça belirtilerek alınabilir. Metin, görsel ve çeviri sorumluluğu teklif varsayımlarında görülmelidir. Hazır olmayan içeriği tamamlanmış göstermek yerine üretim ve onay için ayrı iş kalemi veya aşama planlanabilir.
Brief yazıldıktan sonra değiştirilebilir mi?
Yeni bilgi çıktığında güncellenebilir. Değişikliğin tarihi, kapsam ve takvim etkisi kaydedilmelidir. Onaylı karar ile tartışılan öneri ayrılırsa ekipler aynı sürüm üzerinden çalışabilir. Belgenin değişmesi kontrolsüz kapsam büyümesine dönüşmemelidir.