İyi bir web sitesi brief’i, tasarım ekibine hangi renklerin sevildiğini anlatan bir form değildir. Projenin neden yapıldığını, kim için yapıldığını, hangi işlevleri taşıması gerektiğini ve teslim edildiğinde neyin “başarılı” sayılacağını netleştiren çalışma belgesidir.
Brief eksik olduğunda sorun genellikle ilk toplantıda ortaya çıkmaz. Tasarım ilerledikten sonra “Aslında bayi girişi de olacaktı”, içerikler beklendiğinde “Metinleri ajans hazırlamıyor muydu?” ya da yayın tarihi yaklaşırken “CRM entegrasyonunu da bu kapsamda düşünmüştük” gibi cümlelerle kendini gösterir. Bu aşamada değişen tek şey fikir değildir; takvim, bütçe ve teknik yapı da etkilenebilir.
Bu nedenle brief hazırlarken ilk hedef, olabildiğince uzun bir doküman oluşturmak değil, proje başlamadan önce verilmesi gereken kararları görünür hale getirmektir.
Önce sitenin neden yapıldığını netleştirin
“Yeni bir web sitesine ihtiyacımız var” proje hedefi değildir.
Yeni site neyi değiştirecek?
Kurumsal algıyı mı yenileyecek? Daha fazla teklif talebi mi toplayacak? Satış ekibinin sürekli gönderdiği ürün ve hizmet bilgilerini tek merkezde mi sunacak? Bayilerin sisteme giriş yapmasını mı sağlayacak? Mevcut sitenin teknik, mobil veya yönetim sorunlarını mı çözecek?
Bir projede birden fazla hedef bulunabilir. Yine de ana hedefin belirlenmesi gerekir. Çünkü ana sayfanın kurgusundan içerik sıralamasına, kullanılacak formlardan teknik altyapıya kadar pek çok karar buna göre değişir.
“Modern ve iyi görünen bir web sitesi istiyoruz” gibi ifadeler tasarım tercihini tarif eder; iş ihtiyacını değil.
Daha kullanışlı bir brief şöyle konuşur:
Web sitesi, kurumsal hizmetlerimizi karar vericilere açık biçimde anlatmalı ve nitelikli teklif taleplerini artıracak bir başvuru yapısı sunmalı.
Bu ifade hâlâ tek başına bütün projeyi çözmez ama ekibin neyi tasarladığını anlamasını sağlar.
Hedef kitleyi “herkes” olarak tanımlamayın
Bir endüstriyel üreticinin satın alma yöneticisine hitap eden sitesiyle son tüketiciye hizmet veren bir markanın sitesi aynı bilgi sırasıyla kurulamaz.
Brief içerisinde temel kullanıcı gruplarını açıkça yazın. Mümkünse her grup için siteye neden geleceğini de belirtin:
-
Yeni müşteri: Hizmetleri anlamak ve teklif almak istiyor.
-
Mevcut müşteri: Teknik dokümanlara veya destek kanallarına ulaşmak istiyor.
-
Bayi: Fiyat, stok, sipariş veya kendisine özel bilgilere erişmek istiyor.
-
İş adayı: Açık pozisyonları ve şirketi incelemek istiyor.
-
Yurt dışı ziyaretçisi: Ürünleri farklı dilde görüntülemek ve ihracat bilgilerine ulaşmak istiyor.
Bu ayrım menü yapısını dahi değiştirebilir. Bayi panelinin gerektiği bir proje artık yalnızca kurumsal web tasarım işi değildir; kullanıcı yetkilendirmesi, veri yönetimi ve başka sistemlerle entegrasyon gibi yazılım ihtiyaçları doğurabilir.
Piasoft da web tasarım projelerinde hazır bir şablondan başlamadığını, işletmenin hedeflerini ve ihtiyaçlarını analiz ederek proje yapısını buna göre planladığını belirtiyor. Kurumsal web sitesi yaklaşımını Piasoft Web Tasarım hizmeti sayfasında inceleyebilirsiniz.
Kapsamı sayfa listesinden ibaret görmeyin
Brief hazırlanırken genellikle şu liste çıkar:
Ana Sayfa
Hakkımızda
Hizmetler
Referanslar
Blog
İletişim
Bu liste gereklidir ama kapsamı tarif etmeye yetmez.
“Hizmetler” başlığı altında kaç farklı hizmet bulunacak? Her hizmet için ayrı sayfa hazırlanacak mı? Referanslar kategorilere ayrılacak mı? Blogda kategori, yazar, arama veya etiket yapısı olacak mı? İletişim formundan gelen talepler yalnızca e-posta mı gönderecek, yoksa CRM sistemine de aktarılacak mı?
Aynı isimdeki iki sayfa, teknik açıdan tamamen farklı iki iş olabilir.
Bu nedenle sayfa ve özellikleri birlikte düşünmek daha sağlıklıdır. Örneğin:
Referanslar
-
Listeleme sayfası
-
Sektöre göre filtreleme
-
Her proje için detay sayfası
-
Fotoğraf galerisi
-
Yönetim panelinden yeni referans ekleme
Bu seviyede bir tanım, teklif hazırlanırken de proje başladıktan sonra da tarafların aynı kapsamı konuşmasını kolaylaştırır.
Özel fonksiyonları baştan söyleyin
Teklif formu, ürün filtresi, üyelik sistemi, bayi paneli, rezervasyon, ödeme altyapısı, stok görüntüleme, ERP bağlantısı veya çok dilli içerik yönetimi gibi ihtiyaçları “ileride konuşuruz” bölümüne bırakmak pahalı bir alışkanlıktır.
Çünkü bazı fonksiyonlar sitenin teknik mimarisini doğrudan etkiler.
Örneğin ERP sistemindeki stok bilgilerinin web sitesinde gösterilmesi isteniyorsa yalnızca ekrana bir stok alanı eklenmez. Hangi sistemden veri alınacağı, entegrasyon yönteminin bulunup bulunmadığı, verinin ne sıklıkta güncelleneceği, hangi kullanıcıların hangi bilgileri görebileceği gibi kararlar ortaya çıkar.
İhtiyaç özel bir iş akışı gerektiriyorsa bunun standart web sitesi kapsamından ayrılması gerekebilir. Piasoft, kuruma özel paneller, veri yönetimi, süreç otomasyonları ve ERP/CRM entegrasyonlarını web yazılım projeleri kapsamında ele aldığını belirtiyor. Bu tür ihtiyaçlar için Piasoft ana hizmet sayfasındaki web yazılım çözümleri dikkate alınabilir.
Brief aşamasında teknik çözümü sizin belirlemeniz gerekmez. İhtiyacı açıkça tarif etmeniz yeterlidir.
“SAP ile REST API entegrasyonu yapılacaktır” demek yerine, teknik yöntem henüz bilinmiyorsa şöyle yazabilirsiniz:
Ürün stoklarının şirketin kullandığı ERP sisteminden alınarak web sitesinde güncel şekilde gösterilmesi gerekiyor. Entegrasyon yöntemi proje analizi sırasında mevcut ERP altyapısına göre belirlenecek.
Bilinmeyen şeyi biliyormuş gibi yazmaktan daha faydalıdır. İnsanlığın proje yönetiminde şaşırtıcı biçimde zorlandığı noktalardan biri de budur.
İçeriği kim hazırlayacak?
Web projelerindeki en yaygın gecikme kaynaklarından biri içeriktir.
Tasarım hazırdır ama hizmet metinleri gelmemiştir. Ürün fotoğrafları farklı klasörlerde dağınık duruyordur. İngilizce sayfalar planlanmıştır ancak çevirilerin kimin tarafından hazırlanacağı belli değildir. Ekip de doğal olarak telepatiyle çalışamadığı için proje bekler.
Brief şu sorulara açık cevap vermeli:
-
Mevcut sitedeki içerikler kullanılacak mı?
-
Yeni metinleri kim yazacak?
-
Fotoğraf ve videolar hazır mı?
-
Ürün veya hizmet verileri hangi formatta teslim edilecek?
-
Çevirileri kim hazırlayacak?
-
Logo ve kurumsal kimlik dosyalarının kullanılabilir sürümleri mevcut mu?
-
İçeriklerin teslim tarihi ne?
Ajansın içerik üretmesi isteniyorsa bunu da kapsamın parçası olarak baştan tanımlayın. “İçerikleri sonra hallederiz” cümlesi proje takvimlerinde genellikle sanıldığı kadar masum yaşamaz.
Beğendiğiniz siteleri paylaşın, ama neden beğendiğinizi de yazın
Referans site paylaşmak faydalıdır. “Bunun gibi olsun” demek pek faydalı değildir.
Bir sitede sevdiğiniz şey renkler mi, sayfa yapısı mı, menü kullanımı mı, görsellerin büyüklüğü mü, ürün filtreleme sistemi mi?
Aynı ekranı inceleyen müşteri ve tasarımcı tamamen farklı ayrıntılara bakabilir.
Referansları şu biçimde not etmek daha açıklayıcıdır:
X sitesindeki ürün kategori yapısını kullanışlı buluyoruz. Görsel tasarımının birebir benzemesini istemiyoruz.
veya:
Y sitesindeki sade tipografi ve geniş boşluk kullanımı markamızın istediği görsel dile yakın.
Böylece referans, kopyalanacak tasarıma değil, konuşulacak tercihe dönüşür.
Rakipleri yalnızca tasarım açısından incelemeyin
Brief içinde doğrudan rakiplerin veya aynı kullanıcı kitlesine ulaşan şirketlerin sitelerine yer vermek yararlıdır.
Amaç “rakibin sitesi mavi, bizimki yeşil olsun” seviyesinde kalmamalı.
Rakip sitelerinde hangi bilgilerin öne çıkarıldığına, kullanıcıların ürün veya hizmetlere nasıl ulaştığına, hangi özelliklerin sektör için standart hale geldiğine ve nerelerde bilgi eksikliği bulunduğuna bakın.
Bir rakibin sitesindeki her özellik sizin projenize eklenmek zorunda değildir. Hatta bazen rakibin yaptığı şeyi yapmamak daha doğru karardır. Brief’in görevi rakipleri taklit etmek değil, kararların hangi pazar ortamında verildiğini göstermektir.
Teknik gereksinimleri saklı varsayımlar olmaktan çıkarın
Bazı teknik ihtiyaçlar tasarım ekranlarından görünmez.
Örneğin şirketin zorunlu kullandığı bir hosting altyapısı olabilir. Alan adı başka bir tedarikçinin hesabında tutuluyor olabilir. Kurumsal e-posta sistemi DNS değişikliklerine bağlı olabilir. Google Analytics, reklam dönüşüm kodları, CRM, canlı destek veya başka üçüncü taraf servisler kullanılabilir.
Brief hazırlanırken bilinen teknik koşulların paylaşılması gerekir.
Özellikle şunları baştan belirtmek işleri kolaylaştırır:
Alan adı ve hosting mevcut mu?
Mevcut site hangi altyapıda çalışıyor?
Eski URL’lerin korunması gerekiyor mu?
Başka sistemlerle entegrasyon var mı?
Siteyi şirket içinde kim yönetecek?
Birden fazla yetki seviyesine ihtiyaç var mı?
Çoklu dil kullanılacak mı?
Yasal veya sektörel zorunluluklar bulunuyor mu?
Teknik kararların tamamını müşterinin vermesi beklenmez. Zaten uzman ekip tutulmasının sebeplerinden biri budur. Müşterinin görevi, mevcut koşulları ve ihtiyacı doğru aktarmaktır.
SEO beklentisini “Google’da ilk sırada çıkalım” diye yazmayın
SEO konusunda brief’e hedef yazılabilir, garanti yazılamaz.
Hangi ürün, hizmet veya konularda görünürlük istendiği; mevcut sitenin organik trafik alıp almadığı; URL değişikliği planlanıp planlanmadığı ve içerik üretiminin nasıl sürdürüleceği proje açısından çok daha kullanışlı bilgilerdir.
Mevcut bir site yeniden yapılacaksa eski sayfaların gelişigüzel kaldırılması veya adreslerinin değiştirilmesi arama görünürlüğünü etkileyebilir. Bu nedenle mevcut URL yapısı ve taşınacak içeriklerin proje başında değerlendirilmesi gerekir.
Piasoft, web tasarım projelerinde kullanıcı deneyimi, performans ve teknik SEO kriterlerini birlikte ele aldığını belirtiyor.
Başarı kriterlerini proje başlamadan belirleyin
Web sitesi “tamamlandığında” hangi sonucu bekliyorsunuz?
Başarı kriteri her projede satış olmak zorunda değildir.
Teklif formu gönderimleri, demo talepleri, ürün kataloglarının görüntülenmesi, bayi başvuruları, telefon aramaları, rezervasyonlar veya belirli hizmet sayfalarının ziyaret edilmesi gibi ölçülebilir davranışlar seçilebilir.
Burada yapılmaması gereken şey, dayanağı olmayan rastgele hedefler koymaktır:
Yeni site yayına girince satışlarımız yüzde 40 artmalı.
Mevcut veri, trafik hacmi, satış süreci ve dönüşüm oranları bilinmeden böyle bir sayı hedef olmaktan çok temenni olur.
Daha anlamlı bir brief, hangi hareketlerin ölçüleceğini tarif eder. Sayısal hedefler varsa mevcut verilere dayanarak ayrıca belirlenebilir.
Karar verecek kişileri baştan belirleyin
Tasarıma beş kişinin ayrı ayrı yorum yaptığı, altıncı kişinin de son aşamada projeyi ilk kez gördüğü yapı fazla tanıdıksa sebebi basit: Karar süreci tanımlanmamıştır.
Projede müşteri tarafında en azından şu roller belli olmalıdır:
Proje sorumlusu: Günlük iletişimi yürütür, gerekli bilgi ve dosyaları toplar.
Onay yetkilisi: Tasarım, kapsam veya kritik kararlar için son onayı verir.
İçerik sorumlusu: Metinlerin, görsellerin ve diğer materyallerin hazırlanmasını koordine eder.
Küçük bir şirkette bu rollerin tamamını aynı kişi üstlenebilir. Sorun değil. Önemli olan ajansın hangi konuda kimden geçerli karar alacağını bilmesidir.
Ajans tarafında da proje iletişimini kimin yönettiği, taleplerin nasıl iletileceği ve onayların hangi kanal üzerinden verileceği açık olmalıdır.
Revizyon kavramını proje başlamadan konuşun
“Revizyon yapılacak” ifadesi tek başına belirsizdir.
Bir butonun yerini değiştirmekle onaylanmış ana sayfanın tamamen yeniden tasarlanması aynı şey değildir. Bir metni güncellemekle projeye yeni bir üyelik sistemi eklemek de değildir.
Teklif veya proje planında şu ayrımın kurulması faydalıdır:
Revizyon: Mevcut ve onaylanmış kapsam içindeki düzenleme.
Kapsam değişikliği: Başlangıçta tanımlanmayan yeni sayfa, fonksiyon, entegrasyon veya iş ihtiyacı.
Kapsam değişikliklerinin nasıl fiyatlandırılacağı ve takvime nasıl yansıyacağı baştan konuşulursa proje sırasında gereksiz pazarlıkların önemli bölümü ortadan kalkar.
Takvim yalnızca ajansın teslim tarihinden oluşmaz
“Siteyi 1 Kasım’da yayına almak istiyoruz” bilgi verir ama proje planı oluşturmaz.
Bu tarihin gerçekçi olup olmadığını görmek için geriye doğru çalışmak gerekir:
Brief ve analiz ne zaman bitecek?
İçerikler ne zaman teslim edilecek?
Tasarım için müşteri geri bildirimleri kaç günde verilecek?
Yazılım geliştirme ne kadar sürecek?
Test için zaman ayrılacak mı?
Alan adı ve sunucu işlemlerini kim yapacak?
Yayın öncesi son onayı kim verecek?
Müşteri tarafındaki üç haftalık içerik gecikmesini ajansın son hafta üç kat hızlı çalışarak telafi edeceğini varsayan proje planı, plan değil iyimserliktir.
Piasoft kendi çalışma modelini ihtiyaç analizi, planlama, uygulama, test ve yayın adımlarıyla tanımlıyor; yayın sonrasında bakım ve teknik desteği de sürecin devamı olarak ele alıyor.
Yayın sonrası sorumlulukları da brief’e dahil edin
Web sitesi yayına alındığında teknik ihtiyaçlar bitmez.
Kim güncelleme yapacak? Yönetim panelini kim kullanacak? Teknik bir problem çıktığında destek modeli nasıl işleyecek? Yazılım ve güvenlik güncellemeleri kim tarafından takip edilecek? Yeni özellik talepleri mevcut anlaşmaya mı dahil olacak, ayrı mı değerlendirilecek?
Özellikle özel yazılım içeren projelerde bu bölüm ihmal edilmemelidir.
Piasoft, yayın sonrası bakım, güncelleme ve teknik destek hizmetleri sunduğunu ve bu süreci web projesinin devamı olarak ele aldığını belirtiyor. Firmanın çalışma yaklaşımı hakkında daha fazla bilgi Piasoft Kurumsal sayfasında bulunabilir.
Bir web tasarım brief’inde bulunması gereken temel bilgiler
Brief’in biçimi şirkete ve projeye göre değişebilir. Aşağıdaki bilgiler ise çoğu kurumsal web projesinde başlangıç için yeterli bir çerçeve oluşturur:
-
Şirketin ve markanın kısa tanımı
-
Projenin yapılma nedeni
-
Ana hedef ve varsa ikincil hedefler
-
Hedef kullanıcı grupları
-
Mevcut web sitesinin durumu
-
İstenen sayfalar ve temel içerik yapısı
-
Gerekli fonksiyonlar
-
Entegrasyon ihtiyaçları
-
Çoklu dil gereksinimi
-
İçerikleri kimin hazırlayacağı
-
Hazır fotoğraf, video ve kurumsal kimlik materyalleri
-
Beğenilen veya incelenmesini istediğiniz siteler
-
Rakipler
-
SEO açısından korunması gereken mevcut yapı
-
Ölçülmek istenen kullanıcı hareketleri
-
Teknik kısıtlar veya mevcut sistemler
-
Müşteri tarafındaki proje sorumlusu ve onay yetkilisi
-
Beklenen yayın tarihi
-
Bilinen bütçe sınırı veya bütçe aralığı
-
Yayın sonrası bakım ve destek beklentisi
Her başlığın uzun uzun doldurulması gerekmez. Bilinmeyen maddelerde “henüz belirlenmedi” yazmak da geçerli bir bilgidir. En azından hangi kararların açıkta kaldığı görülür.
Brief’in asıl faydası bütün cevapları ilk gün vermesi değildir. Hangi soruların cevaplanması gerektiğini erkenden ortaya çıkarmasıdır.
Web tasarım veya özel yazılım projesine başlamadan önce hedef, kapsam, içerik, teknik gereksinimler ve sorumluluklar netleştiğinde tasarım ekibi tahmin yürütmek yerine kararlar üzerinden ilerleyebilir. Piasoft’un ihtiyaç analiziyle başlayıp planlama, uygulama, test, yayın ve destek aşamalarıyla devam eden çalışma modeli de projeyi bu çerçevede ele alıyor.