Web Tasarım Projelerinde Brief Süreci ve Şablonu

Üç ajansa aynı dokümanı gönderiyorsunuz. Üç teklif geliyor, fiyatlar birbirinden çok farklı ve yakından bakınca hiçbirinin aynı işi teklif etmediğini görüyorsunuz. Biri yeni bir web sitesi tasarlamayı öneriyor, biri mevcut sistemin üzerine bir arayüz yapmayı, üçüncüsü önce araştırma yapmayı. Hangisinin daha iyi olduğuna karar veremiyorsunuz, çünkü ortada karşılaştırılabilir bir şey yok.

Çoğu zaman sorun ajanslarda değil, brief'tedir. Web tasarım projelerinde brief süreci, teklif istemeden önce kurumun içinde sorunu, hedefi ve sınırları netleştirme işidir. Bu iş iyi yapılmadığında her ekip boşlukları kendi tahminiyle doldurur ve teklifler de bu tahminler kadar dağınık olur.

Bu rehberde kurumsal şirketlerde brief'in kim tarafından yazılıp kim tarafından onaylandığını, iyi bir brief'te hangi bölümlerin bulunması gerektiğini ve en sık yapılan hataları anlatıyoruz. Yazının sonunda kopyalayıp doldurabileceğiniz bir şablon var.

Brief nedir ve web tasarım projelerinde neden bu kadar önemlidir?

Brief, bir işi başka bir ekibe ya da ajansa vermeden önce hazırlanan kısa bir belgedir. Çözülecek sorunu, hedefi ve başarının nasıl ölçüleceğini, kapsamı, bütçe ile takvimi ve kararın nasıl verileceğini anlatır. Amacı, işi yapacak ekibin doğru sorunu doğru sınırlar içinde çözmesini sağlamaktır.

Kelime İngilizceden gelir ama Türkçede yerleşmiştir; "proje özeti" diye de düşünebilirsiniz.

Web tasarım projelerinde brief süreci önemlidir, çünkü bu projeler dışarıdan göründüğünden daha fazla belirsizlik taşır. "Kurumsal sitemizi yenileyelim" cümlesi bir ekip için iki haftalık görsel bir güncelleme, başka bir ekip için içerik yönetim sistemi değişikliğiyle birlikte aylarca sürecek bir proje anlamına gelebilir. İkisi de makul bir yorumdur. Brief bu yorum alanını daraltmazsa sonuç genellikle üç biçimde karşınıza çıkar:

Karşılaştırılamayan teklifler. Her ekip farklı bir işi fiyatlar. Satın alma en düşük rakamı seçmeye yönelir, ama o rakam çoğu zaman en dar yorumun fiyatıdır.
Kapsam kayması. Proje başladıktan sonra "bunu da kapsıyor sanıyorduk" konuşmaları başlar. Her ek iş, ek bütçe ve ek süre demektir.
Uzayan revizyonlar. Başarının tanımı yazılmadığı için tasarım bir hedefe göre değil, toplantıdaki kişilerin beğenisine göre değerlendirilir. Bu da bitmeyen bir döngüye dönüşür.

Bunların hiçbiri kötü niyetten doğmaz. Hepsi, yazılmadan bırakılan bir kararın sonradan ve daha pahalıya verilmesidir.

Kurumsal bir şirkette brief'i kim yazar, kim onaylar?

Küçük bir şirkette brief'i tek kişi yazıp gönderebilir. Kurumsal şirketlerde ise brief, birkaç birimin üzerinde uzlaştığı bir belgedir. Bu birimleri baştan masaya almazsanız brief, dışarı çıktıktan sonra her biri tarafından ayrı ayrı değiştirilir. Tipik bir paydaş haritası şöyledir:

İş birimi: Sorunun sahibidir. Neyin çalışmadığını ve neyin değişmesi gerektiğini en iyi o bilir.
IT: Entegrasyonları, güvenlik gerekliliklerini ve altyapı kısıtlarını belirler. ERP, CRM ya da kimlik doğrulama sistemleriyle bağlantı varsa ilk soruları IT sorar.
Hukuk ve KVKK: Projede kişisel veri işlenecekse bunun hangi koşullarla yapılacağını belirler. Bu konu proje ortasında ortaya çıkarsa takvimi ciddi şekilde etkileyebilir.
Satın alma: Tekliflerin hangi formatta isteneceğini ve nasıl karşılaştırılacağını belirler.
Üst yönetim: Bütçeyi ve önceliği onaylar.

Bizim önerimiz iki adımdan oluşuyor. Birincisi, tek bir brief sahibi seçin. Bu kişi belgeyi yazar, görüşleri toplar ve dış ekiplerin tek muhatabı olur. İkincisi, brief'i dışarı göndermeden önce bu birimlerle bir paydaş toplantısı yapın. Bir saatlik bir toplantı, sonradan haftalarca sürebilecek yazışmaları önleyebilir. Büyük kurumlarda yeniden tasarım projelerinin nasıl yönetileceğini kurumsal ürün yeniden tasarımı rehberimizde daha ayrıntılı anlattık.

İyi bir brief'te hangi bölümler olmalı?

İyi bir brief uzun olmak zorunda değildir. Ama aşağıdaki soruların her birine kısa da olsa bir cevap vermelidir.

Kurum ve ekip. Projenin hangi birimden çıktığı, brief sahibinin kim olduğu ve onaya hangi birimlerin dahil olacağı. Dış ekip, kiminle konuşacağını ve kararın kaç masadan geçeceğini bilmelidir.

Sorun. Bugün ne çalışmıyor, bundan kim etkileniyor ve bunu nereden biliyorsunuz?

✗ "Modern bir uygulama istiyoruz."
✓ "Bayilerimiz sipariş vermek için telefonla arıyor. Uygulamayı kullananlar da siparişi tamamlamakta zorlandıklarını söylüyor. Destek kayıtlarında en sık gelen şikâyet bu."

Hedef ve başarı ölçütü. Proje bittiğinde ne değişmiş olmalı ve bunu hangi rakamla ölçeceksiniz?

✗ "Kullanıcı deneyimini iyileştirmek."
✓ "Bayilerin sipariş verme süresini kısaltmak. Bugün ortalama X dakika sürüyor, hedefimiz Y dakika." Bugünkü değeri bilmiyorsanız bunu da yazın; ölçmek projenin ilk işi olabilir.

Kapsam. İş türü, platform ve en önemlisi kapsam dışında kalanlar. "Mobil uygulama bu projede yok" gibi tek bir cümle, tekliflerin karşılaştırılmasını çok kolaylaştırır.

Mevcut durum. Mevcut bir ürün, tasarım sistemi ya da marka kılavuzu var mı? Hangi sistemlerle entegrasyon gerekiyor? Kişisel veri işleniyor mu?

Kullanıcılar. Birincil kullanıcılar kimler ve araştırma için onlara ulaşılabilir mi? Kurumsal projelerde kullanıcılar çoğu zaman yalnızca müşteriler değildir; saha ekipleri, bayiler ve iç operasyon çalışanları da kullanıcıdır.

Bütçe ve takvim. Bir aralık ve sabit tarihler. Bu konuyu aşağıda ayrıca ele alıyoruz.

Karar süreci. Teklifler nasıl değerlendirilecek ve karar ne zaman verilecek? Bunu bilen ekip, teklifini sizin ölçütlerinize göre hazırlar.

Çözüm mü yazmalı, sorun mu?

En sık yapılan hata, brief'i bir ekran ya da özellik listesine dönüştürmektir: "Ana sayfa, ürün sayfası, bayi girişi, kampanya modülü…" Bu liste somut olduğu için güven verir. Ama aslında çözümü önceden belirlemiş olursunuz ve çalışacağınız ekibin en değerli katkısını, yani sorunu farklı bir açıdan görmesini, baştan engellersiniz.

İyi bir brief sorunu ve ölçütü tarif eder, çözümü ekibe bırakır. "Bayi girişi sayfası tasarlayın" yerine "bayilerin sipariş süreci uzun ve hata oranı yüksek" yazdığınızda, ekip belki de bir sayfaya değil, sipariş akışının kendisine bakmanız gerektiğini söyleyebilir.

Sorunun kendisi net değilse bunu da yazabilirsiniz. "Satışlar düşüyor ama sebebini bilmiyoruz" geçerli bir başlangıç noktasıdır. Bu durumda doğru ilk adım tasarım değil, keşif ya da bir UX denetimidir (mevcut ürünün kanıta dayalı olarak değerlendirilmesi). Ne zaman doğrudan yeniden tasarıma geçmek, ne zaman önce denetim yapmak gerektiğini UX audit ve yeniden tasarım kararı yazımızda anlattık.

Bütçe ve takvimi brief'e yazmalı mısınız?

Evet, aralık olarak. Bütçeyi saklamak pazarlıkta avantaj sağlıyormuş gibi görünebilir. Pratikte ise her ekip bütçeyi kendisi tahmin eder ve teklifini bu tahmine göre kurar. Sonuçta biri en küçük, biri en kapsamlı versiyonu fiyatlar ve teklifler yine karşılaştırılamaz hale gelir. Bir aralık vermek kimseyi bağlamaz; yalnızca herkesin aynı ölçekte düşünmesini sağlar.

Bütçeyi hiç bilmiyorsanız bunu açıkça yazın ve ekiplerden seçenekli bir teklif isteyin. Bir ürün tasarımı projesinin maliyetini neyin belirlediğini ürün tasarımı maliyeti yazımızda ayrıntılı olarak ele aldık.

Takvim tarafında kurumsal şirketlerin kendine özgü gerçekleri vardır ve bunları brief'e yazmak herkesin işini kolaylaştırır:

Bütçe döngüsü: Bütçe hangi dönemde onaylanıyor? Proje yıl sonuna sarkarsa ne oluyor?
Satın alma onay süresi: Tedarikçi kaydı, sözleşme ve onay adımları ne kadar sürüyor? Bu süre projenin başlangıç tarihini doğrudan etkiler.
Tatil ve yoğun dönemler: Bayram tatilleri, yıl sonu kapanışı ve kampanya dönemleri, hem karar alma hem de kullanıcı araştırması için uygun olmayabilir.
Sabit tarihler: Bir lansman, yönetim kurulu sunumu ya da kampanya tarihi varsa açıkça yazın.

Brief'i gönderdikten sonra ne olmalı?

İyi bir ekip brief'inizi olduğu gibi fiyatlamaz, önce soru sorar. Sorunu nereden bildiğinizi, kullanıcılara erişim olup olmadığını, hangi sistemlerle konuşulacağını, başarının nasıl ölçüleceğini merak eder.

Bu sorular aynı zamanda bir değerlendirme ölçütüdür. Hiç soru sormadan, brief'i aldıktan kısa süre sonra fiyat gönderen bir ekip, büyük ihtimalle sorununuzu değil, kendi standart paketini fiyatlıyordur. Doğru soruları soran bir ekip ise henüz başlamadan sizinle birlikte düşünmeye başlamıştır.

Brief'i gönderdikten sonra soru-cevap için kısa bir görüşme planlayın ve tüm ekiplere aynı bilgiyi verin. Bir ekibin sorduğu iyi bir sorunun cevabını diğerleriyle de paylaşmak, tekliflerin adil bir şekilde karşılaştırılmasını sağlar. Ekipleri değerlendirirken neye bakmanız gerektiğini UX tasarım ortağı nasıl seçilir yazımızda bulabilirsiniz.

Web tasarım projelerinde brief süreci için şablon: kopyalayın ve doldurun

Aşağıdaki şablonu kopyalayıp kendi projenize göre doldurabilirsiniz. Her alanı doldurmak zorunda değilsiniz; boş bıraktığınız alanlar da dış ekibe hangi konuların henüz netleşmediğini gösterir.

PROJE BRIEF'İ

1. Kurum ve ekip
   - Kurum / iş birimi:
   - Brief sahibi (ad, rol, e-posta):
   - Onaya dahil olacak birimler (IT, hukuk/KVKK, satın alma, diğer):

2. Sorun
   - Bugün ne çalışmıyor? (1–3 cümle)
   - Bu sorundan kim etkileniyor? (müşteri, çalışan, bayi, saha ekibi…)
   - Bunu nereden biliyorsunuz? (veri, şikâyet, araştırma, gözlem)

3. Hedef ve başarı ölçütü
   - Proje bittiğinde ne değişmiş olmalı?
   - Bunu hangi rakamla ölçeceksiniz? (bugünkü değer → hedef)

4. Kapsam
   - İş türü: Ürün tasarımı / Marka ve kimlik / Yazılım geliştirme / Hareket tasarımı / Uçtan uca ortaklık
   - Platform: Web / iOS / Android / iç sistem / diğer
   - Kapsam DIŞINDA kalanlar:

5. Mevcut durum
   - Mevcut ürün veya sistem var mı? (bağlantı ya da kısa açıklama)
   - Tasarım sistemi veya marka kılavuzu var mı?
   - Entegre olunacak sistemler (ERP, CRM, kimlik doğrulama…):
   - Kişisel veri işleniyor mu? (KVKK açısından not)

6. Kullanıcılar
   - Birincil kullanıcılar kim?
   - Kullanıcılara araştırma için erişim var mı?

7. Bütçe ve takvim
   - Bütçe aralığı: <$50k / $50–150k / $150–500k / $500k+ / Retainer
   - Takvim: Hemen / 3 aydan kısa / 3–6 ay / 6 aydan uzun / Keşif aşaması
   - Sabit tarihler (lansman, yönetim kurulu, kampanya):

8. Karar süreci
   - Teklifler nasıl değerlendirilecek?
   - Karar tarihi:
   - Görüşülen diğer ekipler (isteğe bağlı):

9. Ekler
   - Var olan araştırma, rapor, ekran görüntüsü, örnek beğenilen işler:

Brief'inizi hello@things.ist'e gönderin. Şablonu doldurup e-postaya eklemeniz yeterli; 48 saat içinde dönüyoruz.

Sık sorulan sorular

Brief kaç sayfa olmalı? Genellikle bir ila üç sayfa yeterlidir. Önemli olan uzunluk değil, netliktir. On sayfalık bir brief'te asıl sorun kaybolabilir; bir sayfalık net bir brief ise ekibe ihtiyaç duyduğu her şeyi verir.

Bütçeyi bilmiyorsak brief gönderebilir miyiz? Evet. Bunu açıkça yazın ve ekiplerden farklı kapsamlar için seçenekli teklif isteyin. Bu, bütçeyi hiç belirtmemekten çok daha karşılaştırılabilir sonuçlar verir.

Brief ile RFP arasındaki fark nedir? RFP (Request for Proposal, teklif çağrısı) satın alma sürecinin resmî belgesidir; teklif formatını, değerlendirme ölçütlerini ve sözleşme koşullarını tanımlar. Brief ise işin içeriğini anlatır: sorun, hedef, kullanıcılar ve kapsam. Çoğu kurumda brief, RFP'nin içine ya da ekine konur.

Gizlilik sözleşmesini (NDA) brief'ten önce mi imzalamalıyız? Brief'te hassas bilgi, iç veri ya da henüz duyurulmamış planlar varsa evet. Brief'in genel bir versiyonunu NDA olmadan paylaşıp ayrıntıları imza sonrasına bırakmak da sık başvurulan bir yoldur. Bu konuda kurumunuzun hukuk biriminin görüşünü alın.

Brief'i hazırlarken dış ekipten destek alınabilir mi? Alınabilir. Sorunun kendisi henüz net değilse, brief'i dış ekiple birlikte kısa bir keşif çalışmasıyla netleştirmek iyi bir başlangıç olabilir. Bu çalışmanın çıktısı, sonraki aşama için karşılaştırılabilir bir brief olur.

Projenizi konuşalım

Things, İstanbul merkezli bir UX & UI tasarım ve yazılım stüdyosu. Kurumlarla çalışırken ilk işimiz, sorunu birlikte netleştirmek oluyor.

Brief'inizi hello@things.ist'e gönderin. Hazır değilse sorun değil. Yarım bir brief de gönderebilirsiniz; eksikleri ilk görüşmede birlikte tamamlarız. İsterseniz iletişim sayfamızdan da bize ulaşabilirsiniz.

Design. Code. Mastery.