Web Tasarım
Web Sitesi Briefi Nasıl Hazırlanır?
Web sitesi briefinde amaç, hedef kitle, sayfa yapısı, içerik, işlev, teknik gereksinim, kapsam ve kabul ölçütlerinin nasıl yazılacağını ele alıyoruz.
Briefi tasarım tarifi değil karar belgesi olarak kurun
Web sitesi briefi tasarım sıfatlarını değil kararları içermeli: sitenin amacı, öncelikli kullanıcı, sayfalar, içerik sorumluları, işlevler, teknik sınırlar, teslimler ve kabul ölçütleri. Kesin kararlarla açık soruları ayrı yazın. “Modern ve şık” demek yerine ziyaretçinin mobilde hizmeti bulup form göndermesi gibi bir görevi tarif edin. Böylece teklif ve takvim aynı kapsam üzerinden konuşulur.
Amaç ve başarı ölçütlerini açıkça yazın
Önce sitenin neden yenilendiğini veya sıfırdan neden kurulduğunu bir paragrafta açıklayın. Eski site mobilde zor mu kullanılıyor, hizmetler anlaşılmıyor mu, nitelikli talepler yanlış kanaldan mı geliyor, yeni bir marka yapısı mı tanıtılıyor? Ardından birkaç öncelikli sonuç seçin. Bunlar “güzel görünmek” yerine hizmet kapsamının anlaşılması, doğru teklif taleplerinin gelmesi veya başvuru sürecinin tamamlanması gibi gözlenebilir sonuçlar olmalıdır. Ölçüm aracı ve mevcut başlangıç verisi yoksa kesin artış oranları vaat etmeyin. Hangi davranışın başarı sayılacağı, ölçümün nerede tutulacağı ve kimin değerlendireceği yazılsın. Bu çerçeve daha sonra sayfa yapısı, içerik ve çağrı kararları için ortak ölçü hâline gelir.
Hedef kitleyi gerçek görevleriyle tanımlayın
Hedef kitle bölümünü yalnızca yaş, şehir ve meslek bilgileriyle doldurmak yeterli değildir. Ziyaretçinin siteye hangi soruyla geldiğini, karar verirken neye ihtiyaç duyduğunu, hangi terimleri kullandığını ve hangi engellerle karşılaştığını anlatın. Örneğin bir satın alma sorumlusu teknik kapsam ve teslim sürecini karşılaştırırken, küçük işletme sahibi önce hizmetin kendi ihtiyacına uygun olup olmadığını anlamaya çalışabilir. Aynı sitede aday çalışan, basın veya mevcut müşteri gibi ikincil gruplar da bulunabilir; fakat ana gezinme herkese eşit ağırlık vermek zorunda değildir. GOV.UK içerik tasarımı yaklaşımında olduğu gibi içeriği kullanıcı ihtiyacından başlatmak, formatı alışkanlığa göre değil göreve göre seçmeyi sağlar. Gerçek müşteri soruları bu bölüm için güçlü girdidir.
Sayfa ve içerik envanterini erkenden çıkarın
Bir sayfa envanteri açın ve her satıra şunları yazın: sayfanın amacı, ana kitle, sorumlu kişi, mevcut metin, eksik görsel veya video, onay durumu ve eski URL. İçerikleri “kopyalanacak, güncellenecek, birleştirilecek, kaldırılacak” diye işaretleyin. Metin, fotoğraf, logo, kullanım izni ve çeviriyi kimin sağlayacağını da ekleyin; “içerikler sonra gelir” notu tasarım ekibine ölçü veya hiyerarşi vermez.
İşlevleri ve entegrasyonları senaryolarla açıklayın
Form, rezervasyon, ödeme, çoklu dil, arama, üyelik, harita, canlı destek veya CRM bağlantısı gibi işlevleri yalnızca adlarıyla yazmayın. Kullanıcı senaryosunu, gerekli alanları, başarı ve hata durumunu, bildirim alacak kişiyi ve tutulacak veriyi tanımlayın. Örneğin “teklif formu” maddesi; zorunlu alanlar, dosya yükleme sınırı, aydınlatma bağlantısı, spam önlemi, gönderim sonrası mesaj ve iç bildirim akışıyla birlikte düşünülmelidir. Entegrasyonun hesabını kimin açacağı, lisans maliyetinin kime ait olduğu ve test ortamına erişim de briefte yer almalıdır. W3C form rehberleri basit yapı, görünür etiket, anlaşılır talimat ve hata geri bildirimi önerir. İşlevin yalnızca çalışması değil farklı cihaz ve yardımcı teknoloji koşullarında anlaşılması hedeflenmelidir.
SEO, erişilebilirlik ve performansı kapsama alın
Teknik bölümde alan adı ve barındırmanın yanı sıra taranabilirlik, güvenlik, mobil uyum, temel performans, analitik, erişilebilirlik ve yedekleme beklentilerini belirtin. Google’ın geliştiriciler için Arama rehberi, sayfaların bağlantılarla bulunabilmesini, güvenli, hızlı, erişilebilir ve tüm cihazlarda çalışır olmasını temel uygulamalar arasında sayar. Core Web Vitals hedefleri konuşulacaksa ölçüm ortamı ve içerik koşulları da tanımlanmalıdır; laboratuvar sonucu ile gerçek kullanıcı verisi aynı şey değildir. Başlıklar, meta alanları, kanonik adresler, site haritası ve yapılandırılmış veri sorumluluğu açıklığa kavuşmalıdır. Çerez ve kişisel veri süreçleri için kullanılan araçlar listelenmeli, hukuki metinler yetkin kişi tarafından sağlanmalıdır. “SEO dâhil” gibi geniş bir ifade yerine teslim edilecek teknik ve içerik işleri adlandırılmalıdır.
Teslim, sorumluluk ve kabul koşullarını netleştirin
Son sayfada dört bölüm olsun: kapsam içi ve dışı işler, sorumlular ve onay akışı, teslimler ve revizyon, kabul kontrolü. Kabul satırlarını test edilebilir yazın: ana akışlar belirlenen tarayıcılarda çalışıyor mu, formlar doğru alıcıya gidiyor mu, kırık iç bağlantı var mı, onaylı içerikler ve yönlendirmeler yerinde mi? Takvime müşteri içerik ve onay tarihlerini de ekleyin. Şifreleri brief içine yazmayın; erişimleri güvenli bir yöntemle paylaşın.
SSS
Bu konuyla ilgili sık sorulanlar
Kaynaklar ve ileri okuma
İlgili rehberler
Bu konuyu tamamlayan yazılar
Kurumsal Web Sitesinde Hangi Sayfalar Olmalı?
Kurumsal bir web sitesinin ihtiyaç duyduğu temel sayfaları, her sayfanın görevini ve gereksiz sayfa kalabalığından kaçınmanın yolunu açıklıyoruz.
Web ve DönüşümWeb Sitesi Ne Zaman Yenilenmeli?
Web sitesini sırf eski göründüğü için değil; iş modeli, içerik, teknik bakım, mobil deneyim ve dönüşüm ihtiyacına göre yenileme rehberi.
Kreatif TasarımKreatif Brief Nasıl Hazırlanır?
Kreatif briefte problem, hedef kitle, beklenen davranış, ana mesaj, kanıt, zorunluluk, format, onay ve ölçüm kararlarının nasıl yazılacağını anlatıyoruz.
Sonraki Adım