Web Sitesi Yaptırmadan Önce İhtiyaç Dokümanı Nasıl Hazırlanır?

Web Sitesi Yaptırmadan Önce İhtiyaç Dokümanı Nasıl Hazırlanır?

Üzeyir Hakan Ceylan

Blog yazısı içeriği

Web sitesi yaptırmadan önce hazırlanacak ihtiyaç dokümanı; projenin amacını, hedef kullanıcılarını, sayfalarını, içeriklerini, işlevlerini, entegrasyonlarını, tasarım beklentilerini, teknik gereksinimlerini ve sorumlularını tek yerde toplar. Böylece ajanslar aynı kapsam üzerinden teklif verebilir, proje başladıktan sonra ortaya çıkabilecek belirsizlikler azalır ve hangi çalışmanın ne zaman tamamlanacağı daha kolay planlanır.

İyi bir ihtiyaç dokümanı teknik terimlerle dolu olmak zorunda değildir. Önemli olan, şirketinizin ulaşmak istediği sonucu ve kullanıcıların web sitesinde ne yapabilmesi gerektiğini açık biçimde anlatmasıdır.

Web Sitesi İhtiyaç Dokümanı Nedir?

Web sitesi ihtiyaç dokümanı, şirket ile projeyi gerçekleştirecek ekip arasında ortak bir çalışma çerçevesi oluşturur. Sıklıkla proje briefi olarak da adlandırılır. Bu belge, “modern bir web sitesi istiyoruz” gibi yoruma açık talepleri somut hedeflere, sayfalara, işlevlere ve teslim kriterlerine dönüştürür.

İhtiyaç dokümanı ile teknik şartname aynı şey değildir. İhtiyaç dokümanı öncelikle iş hedeflerini, kullanıcı beklentilerini ve proje kapsamını açıklar. Teknik şartname ise kullanılacak sistemlerin, entegrasyonların, güvenlik seviyelerinin ve kabul koşullarının daha ayrıntılı tanımlandığı bir belgedir. Küçük bir kurumsal web sitesi için sade bir brief yeterli olabilirken üyelik, ödeme, rezervasyon veya farklı sistemlerle veri alışverişi içeren projelerde daha ayrıntılı bir teknik kapsam gerekir.

Önce Web Sitesinin İş Hedefini Belirleyin

Web sitesi ihtiyaç dokümanı hazırlama sürecinin aşamaları
İş hedefinden onay sürecine uzanan ihtiyaç dokümanı hazırlama akışı.

İhtiyaç listesini sayfalardan veya tasarım örneklerinden önce iş hedefiyle başlatın. Yeni web sitesinin neden gerekli olduğunu açıklayamadığınızda hangi özelliklerin gerçekten önemli olduğunu belirlemek zorlaşır.

Projenin temel amacı aşağıdakilerden biri veya birkaçı olabilir:

  • Markaya duyulan güveni artırmak
  • Hizmetleri ve ürünleri daha anlaşılır sunmak
  • Nitelikli teklif veya iletişim talebi toplamak
  • Satış, rezervasyon ya da başvuru işlemi gerçekleştirmek
  • Bayi, müşteri veya iş ortaklarına özel bilgi sağlamak
  • İşe alım ve kariyer başvurularını yönetmek
  • Mevcut web sitesindeki teknik veya içerik sorunlarını gidermek

Hedefi belirledikten sonra başarının nasıl ölçüleceğini yazın. Örneğin yalnızca “daha fazla ziyaretçi” istemek yerine nitelikli form başvuruları, tamamlanan rezervasyonlar, ürün incelemeleri veya satış ekibine ulaşan uygun talepler gibi iş sonuçları tanımlanabilir. Google da bir web sitesinin kullanıcılar düşünülerek hazırlanmasını ve içeriğin insanların karar vermesine yardım etmesini önerir; yalnızca arama motorlarına yönelik çalışmalar sürdürülebilir bir hedef değildir. (Google SEO Başlangıç Rehberi)

Hedef Kullanıcıları ve Yapacakları İşlemleri Tanımlayın

“Hedef kitlemiz herkes” ifadesi tasarım ve içerik kararlarına yardımcı olmaz. İhtiyaç dokümanında web sitesini kullanacak ana grupları ve her grubun tamamlamak istediği işi ayrı ayrı belirtin.

Şu sorularla başlayabilirsiniz:

  • Kullanıcılarımız kimlerdir?
  • Web sitesine hangi bilgi veya ihtiyaçla gelirler?
  • Hangi sorularına hızlıca cevap bulmaları gerekir?
  • Hangi işlemi tamamlamalarını istiyoruz?
  • Karar vermeden önce hangi kanıtları görmek isterler?
  • Siteyi ağırlıklı olarak hangi cihazlardan kullanırlar?
  • Farklı dil veya erişilebilirlik ihtiyaçları var mı?

Örneğin bir satın alma yöneticisi teknik yeterlilik ve teslim kapasitesi ararken, son kullanıcı fiyat, kullanım kolaylığı veya destek bilgisine odaklanabilir. Aynı sayfa yapısı iki grubun da ihtiyacını karşılamayabilir.

Sayfa ve İçerik Kapsamını Oluşturun

Web sitesinde bulunmasını istediğiniz sayfaları listeleyin; ancak yalnızca sayfa adlarını yazmakla yetinmeyin. Her sayfanın amacı, hedef kullanıcısı ve beklenen aksiyonu da belirtilmelidir.

Kurumsal projelerde ana sayfa, şirket hakkında, hizmet veya ürün sayfaları, projeler ya da referanslar, blog, kariyer ve iletişim gibi bölümler kullanılabilir. Fakat her projede bu sayfaların tamamı zorunlu değildir. Kullanıcı yolculuğuna katkı sağlamayan sayfaları sırf rakiplerde bulunduğu için eklemek içerik üretimini ve yönetimini gereksiz yere zorlaştırabilir.

İçerik sorumluluklarını da başlangıçta belirleyin:

  • Şirket, hizmet ve ürün metinlerini kim hazırlayacak?
  • Fotoğraf, video ve kataloglar hazır mı?
  • Çeviriler kim tarafından hazırlanacak ve onaylanacak?
  • Yasal metinler ilgili uzman tarafından sağlanacak mı?
  • Mevcut siteden hangi içerikler taşınacak, güncellenecek veya kaldırılacak?

Mevcut bir web sitesi yenileniyorsa korunacak URL’ler ve uygulanacak yönlendirmeler ayrıca planlanmalıdır. Bu çalışma, kullanıcıların ve arama motorlarının eski adreslerden doğru yeni sayfalara ulaşabilmesi açısından önemlidir.

İşlevleri ve Entegrasyonları Somutlaştırın

“İletişim formu olacak” demek çoğu zaman yeterli değildir. Formu kimin dolduracağını, hangi alanların gerekli olduğunu, bildirimin kime gideceğini, verinin nerede tutulacağını ve işlem başarısız olduğunda ne yaşanacağını düşünün.

Aynı yaklaşımı aşağıdaki ihtiyaçlara da uygulayın:

  • Site içi arama ve filtreleme
  • Çoklu dil
  • Üyelik ve kullanıcı rolleri
  • Ödeme, rezervasyon veya başvuru
  • CRM ve ERP bağlantıları
  • Harita, kargo, e-posta veya SMS servisleri
  • Analitik, reklam ve dönüşüm ölçümü
  • Dosya yükleme veya belge oluşturma

Entegrasyon kullanılan projelerde hangi sistemin hangi veriyi göndereceği, güncelleyeceği ve koruyacağı açıklanmalıdır. Bu bilgiler teklifin kapsamını ve teknik planlamayı doğrudan etkiler.

Tasarım ve Marka Beklentilerini Açıklayın

Beğendiğiniz web sitelerini paylaşmak yararlıdır, ancak yalnızca bağlantı göndermek yeterli değildir. Her örnekte hangi yönü beğendiğinizi veya uygun bulmadığınızı açıklayın: içerik hiyerarşisi, renk kullanımı, hareketler, menü, tipografi ya da genel marka hissi gibi.

Logo, kurumsal kimlik kılavuzu, marka renkleri ve yazı tipleri varsa briefle birlikte iletilmelidir. Markanın görsel dünyası henüz tanımlanmamışsa bunun da proje kapsamına dahil edilmesi gerekir.

Kumsal Ajans’ta ilk görüşmeler proje yöneticisinin koordinasyonunda yürütülür. Proje yöneticisi kapsamı ve iş planını oluştururken art director markanın görsel yaklaşımını ve yaratıcı yönünü değerlendirir. Tasarım ve yazılım ekipleri ise kullanıcı deneyimini, uygulanabilirliği ve teknik gereksinimleri inceler. Yaklaşık 17 kişilik ekip yapısında bu görevlerin başlangıçta netleşmesi, farklı uzmanlıkların aynı hedef etrafında çalışmasını kolaylaştırır. Bu sorumlulukların proje içindeki yerini değerlendirirken web tasarım ajansının çalışma alanlarını da inceleyebilirsiniz.

SEO, Erişilebilirlik ve Güvenliği Başlangıçta Planlayın

SEO, erişilebilirlik ve güvenlik yalnızca proje tamamlandıktan sonra eklenecek kontrol maddeleri değildir. İhtiyaç dokümanında bunlara ilişkin hedefler ve sorumluluklar bulunmalıdır.

SEO kapsamında sayfaların taranabilir olması, anlamlı başlık ve açıklama alanları, site haritası, yönlendirmeler, görsel açıklamaları, yapılandırılmış veri ihtiyaçları ve ölçüm araçları ele alınabilir. Google Search Essentials, taranabilir bağlantılar ve kullanıcıya faydalı içerik gibi temel uygulamaları öne çıkarır; bu gereksinimleri başlangıçta konuşmak sonradan yapılacak değişiklikleri azaltır. (Google Search Essentials)

Erişilebilirlik için hedeflenen standart, klavye kullanımı, renk kontrastı, form etiketleri, alternatif metinler ve kabul testleri tanımlanabilir. W3C, erişilebilirlik hedefleriyle görevlerin planlama aşamasında belirlenmesini ve kontrollerin yalnızca proje sonuna bırakılmamasını önerir. (W3C Web Erişilebilirliği Planlama Rehberi)

Güvenlik bölümünde kullanıcı rolleri, kişisel veri akışları, yedekleme, geri yükleme, bakım, güncelleme ve teknik erişim sahipliği ele alınmalıdır. Karmaşık web uygulamalarında güvenlik gereksinimlerini doğrulanabilir maddeler halinde tanımlamak için OWASP ASVS gibi standartlardan yararlanılabilir. (OWASP ASVS)

Bütçe, Takvim ve Sorumlulukları Netleştirin

Bütçe aralığı, proje ekibinin hangi özelliklerin ilk aşamada yer alacağını ve hangilerinin sonraki faza bırakılacağını önermesine yardımcı olur. Bütçeyi paylaşmamak her zaman daha düşük teklif sağlamaz; birbirinden tamamen farklı kapsamların teklif edilmesine neden olabilir.

Hedef yayın tarihinin yanında bu tarihe bağlı koşulları da belirtin. İçerikler, çeviriler, kurumsal dosyalar, entegrasyon bilgileri ve onaylar geciktiğinde proje takvimi de etkilenir.

Karar vericilerin başlangıçta belirlenmesi özellikle önemlidir. Farklı kişilerden birbiriyle çelişen geri bildirimler gelmesi tasarım, içerik ve yazılım aşamalarında tekrar çalışmaya yol açabilir. Kimlerin görüş bildireceği, kimin son onayı vereceği ve geri bildirimlerin nasıl birleştirileceği briefte yer almalıdır.

Web Sitesi İhtiyaç Dokümanı Kontrol Listesi

15 maddelik web sitesi proje briefi kontrol listesi
Teklif almadan önce netleştirilmesi önerilen 15 proje başlığı.

Dokümanınızı paylaşmadan önce şu 15 alanı kontrol edin:

  1. Şirket ve proje özeti
  2. Projenin iş hedefi
  3. Başarı göstergeleri
  4. Hedef kullanıcılar ve görevleri
  5. Sayfa listesi
  6. İçerik envanteri ve sorumluları
  7. İşlevler ve entegrasyonlar
  8. Dil ve bölge ihtiyaçları
  9. Marka dosyaları ve tasarım beklentileri
  10. SEO ve mevcut URL gereksinimleri
  11. Erişilebilirlik hedefleri
  12. Güvenlik, veri ve kullanıcı rolleri
  13. Analitik hesapları ve erişim sahipliği
  14. Bütçe, takvim, öncelikler ve onay süreci
  15. Test, teslim, bakım ve destek sorumlulukları

Başlangıç dosyaları arasında vektörel logo, kurumsal kimlik kılavuzu, metinler, görseller, videolar, kataloglar, sayfa listesi, iletişim bilgileri ve onaylanmış çeviriler bulunabilir. Mevcut site, alan adı, DNS, sunucu, analitik ve üçüncü taraf servis erişimleri gerekiyorsa ana şifreleri paylaşmak yerine ajansa özel, sınırlandırılmış ve gerektiğinde iptal edilebilen hesaplar oluşturulması daha güvenli bir yöntemdir.

Eksik Brief Hangi Sorunlara Yol Açar?

Kumsal Ajans’ın proje deneyiminde eksik bilgiyle başlayan çalışmalarda üç konu öne çıkar. Birincisi, başlangıçta netleştirilmeyen sayfa ve işlevlerin süreç içinde eklenmesiyle kapsamın değişmesidir. Bu durum takvim ve kaynak planını etkiler.

İkincisi, kurumsal kimlik, gerçek metinler ve görseller hazır olmadığında yaratıcı yönün geç netleşmesidir. Geçici içerikle hazırlanan tasarımlar, gerçek içerik geldiğinde yeniden düzenleme gerektirebilir.

Üçüncüsü ise karar vericiler belirlenmediğinde farklı kişilerden çelişkili geri bildirimler gelmesidir. Bu durum revizyonları artırır ve ekipler arası ilerlemeyi yavaşlatır.

İyi hazırlanmış bir briefte bunun tersi yaşanır. Anonim bir kurumsal web sitesi projesinde müşteri; hedef kitlesini, rakiplerini, hizmetlerini, sayfalarını ve beğendiği tasarım örneklerini başlangıçta paylaşmış, kurumsal kimlik dosyalarıyla içerikleri de büyük ölçüde hazır hale getirmişti. Proje yöneticisi kapsam ve takvimi hızla oluştururken art director yaratıcı yönü belirleyebildi; yazılım ekibi de teknik planlamaya erken başladı. İlk tasarım sunumu beklentiyle büyük ölçüde örtüştü, revizyonlar küçük iyileştirmelerle sınırlı kaldı ve proje kapsam değişmeden planlanan takvimde tamamlandı.

Sonuç

Web sitesi ihtiyaç dokümanı, yalnızca ajansın teklif hazırlamasını kolaylaştıran bir dosya değildir. Şirketinizin hedeflerini ekipler arasında görünür hale getirir, öncelikleri belirler ve proje boyunca alınacak kararlar için referans oluşturur.

Belgeyi hazırlarken her teknik ayrıntıyı bilmeniz gerekmez. İş hedefini, kullanıcıyı, içerikleri, işlevleri, sorumluları ve kısıtları açıkça tanımlamanız yeterli bir başlangıç sağlar. Kumsal Ajans, hazırladığınız taslağı keşif görüşmesinde değerlendirerek web tasarım hizmeti, içerik ve projeye özel geliştirilecek web yazılım altyapısı açısından kapsamlandırabilir.

Sık Sorulan Sorular

Web sitesi ihtiyaç dokümanını kim hazırlamalı?

Doküman tek bir departmana bırakılmamalıdır. İş hedeflerini bilen yönetici veya proje sorumlusu; pazarlama, satış, içerik, operasyon ve teknik ekiplerden gerekli bilgileri toplamalıdır. Nihai belgenin tek bir sorumlu tarafından birleştirilmesi çelişkileri azaltır.

İhtiyaç dokümanı ile teknik şartname aynı şey midir?

Hayır. İhtiyaç dokümanı projenin iş hedefini, kullanıcılarını, kapsamını ve beklentilerini açıklar. Teknik şartname ise sistem, entegrasyon, güvenlik, performans ve kabul koşullarını daha ayrıntılı tanımlar. Projenin karmaşıklığına göre iki belge birlikte kullanılabilir.

Web sitesi briefinde bütçe belirtilmeli mi?

Bir bütçe aralığı paylaşmak, özelliklerin önceliklendirilmesini ve gerçekçi bir çözüm önerilmesini kolaylaştırır. Bütçe belirtilmediğinde ajanslar farklı kapsamlar varsayabilir ve gelen teklifleri karşılaştırmak zorlaşabilir.

Ajansa örnek veya rakip web siteleri göndermek yeterli midir?

Hayır. Örnek siteler görsel beklentiyi anlatmaya yardımcı olur; ancak hangi bölümlerin neden beğenildiği açıklanmalıdır. Ayrıca iş hedefi, hedef kullanıcılar, içerikler, özellikler ve teknik gereksinimler ayrı olarak tanımlanmalıdır.

İhtiyaçlar proje sırasında değişirse ne yapılmalıdır?

Yeni talep mevcut kapsam, takvim ve bütçe üzerindeki etkisiyle birlikte değerlendirilmelidir. Değişiklik onaylandıktan sonra kapsam ve teslim planı güncellenmelidir. Böylece yeni beklentiler sözlü veya belirsiz talepler olarak kalmaz.

Sık Sorulan Sorular

Doküman tek bir departmana bırakılmamalıdır. İş hedeflerini bilen yönetici veya proje sorumlusu; pazarlama, satış, içerik, operasyon ve teknik ekiplerden gerekli bilgileri toplamalıdır. Nihai belgenin tek bir sorumlu tarafından birleştirilmesi çelişkileri azaltır.

Anasayfa

Projelerimiz

Ürünlerimiz

Hizmetlerimiz

Sizi Arayalım

Aydınlatma Metnini okudum ve kabul ediyorum

TELEFON

E-POSTA