İçeriğe atla
Semih Taliİletişim

Ana Sayfa / Blog / Ürün

Ürün · 2 Ağustos 2026 · 3 dk okuma

Ürün Briefi Nasıl Yazılır? (Şablon + Doldurulmuş Örnek)

Geliştiriciye veya ajansa verilecek ürün briefi nasıl yazılır? Tek sayfalık 5 soruluk brief şablonu, doldurulmuş örnek ve sık yapılan hatalarla pratik rehber.

Ürün Briefi Nasıl Yazılır? (Şablon + Doldurulmuş Örnek)

Kötü brief, yazılım projelerinin en pahalı ve en sessiz maliyetidir: yanlış anlaşılan kapsam, sprint ortasında "aslında şöyle demek istemiştim" konuşmaları, üç kez yeniden yapılan ekranlar...

İyi haber: iyi brief bir yetenek değil, bir şablon disiplinidir. Bu rehberde yıllardır kullandığım tek sayfalık şablonu, doldurulmuş bir örnekle birlikte veriyorum.

İyi briefin tek kuralı

Brief, geliştiriciye nasıl yapacağını değil, neyi neden yaptığınızı anlatır.

Veritabanı şeması önermek, kütüphane seçmek, mimari tarif etmek briefin işi değildir. Bunlar geliştiricinin uzmanlık alanıdır. Briefin işi, geliştiricinin o teknik kararları doğru verebilmesi için gereken bağlamı eksiksiz taşımaktır.

5 soruluk brief şablonu

Her brief şu beş sorunun cevabıdır. Toplamı bir sayfayı geçmemelidir:

1. PROBLEM: Ne oluyor, neden sorun? Tek paragraf. Özellik değil, problem yazın. ("X butonu ekleyelim" değil; "kullanıcı şu durumda takılıyor" evet.)

2. KULLANICI: Kim, hangi senaryoda yaşıyor? İki cümlelik gerçek bir durum. Persona romanı gerekmez.

3. BAŞARI: Bittiğinde neyin değiştiğini nereden anlayacağız? Ölçülebilir bir sinyal: bir metrik, bir davranış değişimi, bir şikâyetin azalması.

4. KAPSAM: Bu sürümde ne var, ne YOK? Şablonun en değerli bölümü. "Yok" listesi, günler süren gereksiz işi ve kapsam büyümesini baştan iptal eder.

5. SERBEST ALAN: Hangi kararlar uygulayıcının? Görsel detaylar, teknik seçimler, mikro etkileşimler... Açıkça devretmek güven verir ve gereksiz onay turlarını bitirir.

Doldurulmuş örnek

Özellik: Yükleme durumu göstergesi

1. Problem: Kullanıcı fotoğraf yükledikten sonra işlemin sürdüğünü anlamıyor; ekranın donduğunu sanıp uygulamayı kapatıyor. Destek mesajlarının önemli kısmı "yükleme çalışmıyor" şikâyeti, oysa işlem arka planda tamamlanıyor.

2. Kullanıcı: İlk haftasındaki yeni kullanıcı; büyük dosya yüklüyor, mobil bağlantısı yavaş. İşlemin 30-60 saniye süreceğini bilmiyor.

3. Başarı: Yükleme sırasında uygulamadan çıkma oranı düşer; "yükleme çalışmıyor" içerikli destek mesajları azalır.

4. Kapsam: VAR: yükleme ekranında ilerleme göstergesi + "bu işlem ~1 dakika sürebilir" metni + tamamlanınca ekran içi bildirim. YOK: push bildirim, arka plan yükleme, yükleme geçmişi ekranı (sonraki sürüm adayları).

5. Serbest alan: Göstergenin biçimi (bar/halka/animasyon) ve metnin tam ifadesi uygulayıcıda. Marka renklerine sadık kalınması yeterli.

Bu briefin tamamı bir sayfanın yarısı. Ve içinde tartışma çıkaracak belirsizlik yok.

Sık yapılan brief hataları

  1. Çözümü problem gibi yazmak. "Bildirim sistemi lazım" bir problem değil, bir çözüm varsayımıdır. Önce problem: kullanıcı neyi kaçırıyor, bunun bedeli ne?
  2. "Yok" listesini atlamak. Kapsam dışı yazılmadıysa, kapsam herkesin hayal gücü kadar geniştir.
  3. Ölçüsüz başarı tanımı. "Daha iyi UX" ölçülemez; "çıkma oranı düşsün" ölçülür.
  4. Teknik görünmeye çalışmak. Yarım teknik bilgi, ya yanlış yönlendirir ya güven kaybettirir. Ürün dilinde kalın.
  5. Briefi konuşmanın yerine koymak. Brief, konuşmayı kaldırmaz; kaliteli kılar. Yazın, sonra 15 dakika birlikte üzerinden geçin.

Briefin gizli faydası

Şablonun asıl gücü şurada: brief yazamıyorsanız, özellik hazır değildir.

"Başarı" sorusuna cevap veremiyorsanız fikir henüz olgunlaşmamıştır; "yok" listesini yazamıyorsanız kapsamı siz de bilmiyorsunuzdur. Brief, geliştiriciden önce yazan kişiyi test eder. Bu da en ucuz test aşamasıdır.

Sık sorulan sorular

Her küçük iş için brief mi yazmalı? Hayır. Kural: birden fazla kişinin yorumuna açık her iş için evet; tek satırlık düzeltmeler için hayır.

Ajansla çalışırken de bu şablon geçerli mi? Evet, hatta daha kritik. Dış ekip, iç bağlamı bilmez; 4. ve 5. sorular (kapsam ve serbest alan) sözleşme netliği kazandırır.

Brief ile PRD (ürün gereksinim dokümanı) farkı ne? PRD, büyük kapsamlı işlerin detaylı dokümanıdır; brief, tek özelliğin tek sayfalık netleştirmesidir. Çoğu ekibin ihtiyacı, daha uzun PRD değil, daha net brieftir.


Şablonu kopyalayıp doğrudan kullanabilirsiniz. Bu rehber, geliştiricilerle ürün kurarken edindiğim deneyimden derlenmiştir.

Etiketler

briefurun gelistirmeproduct ownersablonrehber
( İlgili )Bunları da okuyun

Çözülmeyi bekleyen bir sorununuz mu var?

Ürün fikrinizi konuşalım. Sorunu birlikte netleştirip nasıl bir çözüme dönüşebileceğine bakalım.

İletişime geç