Web tasarım briefi nasıl hazırlanır? İşletmeler için ayrıntılı rehber

Bir web sitesi projesi çoğu zaman aynı soruyla başlar: Nasıl bir tasarım istiyoruz? Oysa teklifin doğruluğunu ve projenin günlük işlere katkısını belirleyen sorular daha erkendedir. Kim siteyi kullanacak, hangi bilgiyi arayacak, hangi işlemi tamamlayacak ve bu işlemin ardından işletmede ne olacak? Brief, bu soruların cevaplarını ortak bir çalışma belgesine dönüştürür. Güzel görünen referansları da içerir; fakat yalnız görsel beklentileri anlatan bir dosya değildir.

İyi bir brief hazırlamak için bütün teknik çözümleri önceden bilmeniz gerekmez. Bilinenleri, açık kararları ve araştırılması gereken noktaları ayırmanız yeterlidir. Böylece ajans aynı belgede hem ihtiyacınızı hem de belirsizliklerinizi görür. Bu rehberde, hayali bir endüstriyel ekipman üreticisinin sitesi üzerinden, teklif toplamadan tasarım onayına kadar kullanılabilecek bir briefin nasıl kurulacağını ele alıyoruz.

Önce işletmedeki ihtiyacı tarif edin

“Sitemiz eskidi” gerçek bir gözlem olabilir; ancak tek başına proje hedefi değildir. Nelerin eskidiğini açın. Satış ekibi ürün özelliklerini sürekli epostayla mı gönderiyor? Yurt dışındaki distribütörler güncel kataloğa ulaşamıyor mu? Ziyaretçiler hangi hizmeti sunduğunuzu anlayamadan mı arıyor? Her sorunun farklı bir içerik, yapı veya iş akışı karşılığı vardır. İlk toplantıya mevcut sıkıntılardan üç somut örnekle gelmek, uzun bir özellik listesinden daha yararlı olabilir.

Örneğin üretici firmanın hedefini şöyle yazabiliriz: Teknik satın alma sorumluları, ürün ailelerini karşılaştırabilsin, ilgili teknik dokümanı bulabilsin ve uygun ürün grubunu belirterek teklif talep edebilsin. Bu ifade, bütün ziyaretçileri hemen satışa zorlamaz. Önce bilgiye erişimi, sonra anlamlı bir talebi tarif eder. Başarı değerlendirmesinde de yalnız form sayısına değil, gelen taleplerin doğru ürün grubunu içerip içermediğine bakılmasını sağlar.

Hedef kitleyi unvan listesinden çıkarın

Hedef kitleniz “KOBİ ve kurumsal firmalar” ise tasarım ekibi henüz yeterli bilgiye sahip değildir. Aynı işletmede teknik mühendis, satın alma uzmanı ve genel müdür farklı kaygılarla siteye girebilir. Mühendis uyumluluk detayını, satın alma ekibi teslim koşullarını, yönetici ise tedarikçinin devamlılığını anlamaya çalışabilir. Briefte her grubun öncelikli görevi, mevcut bilgisi ve karar vermesini engelleyen eksik bilgi ayrı yazılmalıdır.

Bu bilgiyi toplamak için satış görüşmelerinde sık sorulan soruları dinleyin. Müşteri destek ekibinin tekrar tekrar açıkladığı konuları çıkarın. Eldeki gerçek sorular, varsayımsal kişilik kartlarından daha kullanışlı bir başlangıç sunar. Yine de müşteriler adına kesin konuşmayın. “Satış ekibinin gözlemine göre” veya “müşteri görüşmeleriyle doğrulanacak” gibi notlar, varsayım ile kanıtın karışmasını önler.

Sayfa envanterini içerik göreviyle birlikte hazırlayın

Briefte yalnız “ana sayfa, hakkımızda, ürünler, iletişim” yazması, sayfaların ne anlatacağını açıklamaz. Her sayfa için amaç, ana ziyaretçi grubu, gerekli içerik ve beklenen sonraki adım bulunmalıdır. Ürün grubu sayfasının işi seçenekleri tanıtmak olabilir; tekil ürün sayfası ise ölçüleri, kullanım sınırlarını ve ilgili belgeleri gösterebilir. Bu ayrım yapılmadığında tasarım aşamasında bütün detayların aynı ekrana sıkıştırılması riski doğar.

Mevcut sitenin her adresini yeni yapıya taşımak zorunda değilsiniz. Önce kullanılabilir bilgiyi belirleyin. Geçerliliğini kaybetmiş bir hizmeti, yalnız eski sitede var diye korumayın. Öte yandan satış ekibinin düzenli kullandığı teknik dokümanı yeni tasarımın dışında bırakmayın. Sayfalar arasındaki ilişkiyi ayrıca düşünmek için kurumsal site sayfa mimarisi rehberinden yararlanabilirsiniz.

Hayali üretici için kısa kapsam örneği

Örnek işletmemiz pompa ve kontrol ekipmanı üretiyor olsun. Briefte ürünlerin doğrudan internetten satılmayacağı, fiyatların proje koşullarına göre belirleneceği ve sitenin bir teklif toplama kanalı olduğu açıkça yazılır. Başlangıç kapsamına ana sayfa, üç ürün ailesi, ürün detayları, doküman merkezi, şirket bilgileri, uygulama alanları ve teklif formu alınır. Bayi paneli ise ilk yayının dışında değerlendirilir.

Bu örnekte ürün detaylarında açıklama, teknik tablo, çizim dosyası, görsel ve ilgili ürün alanları gerekir. Teklif formunda ziyaretçinin ürün ailesini seçebilmesi istenir. Ancak üretim planlama sistemine otomatik bağlantı olup olmadığı henüz belli değilse brief bunu hazır bir özellik gibi sunmaz. “İlk sürümde talep epostayla satış sorumlusuna iletilecek; sistem bağlantısı ayrıca incelenecek” cümlesi, hem beklentiyi hem geliştirme sınırını belirler.

İçerik üretimini görünür bir iş paketi yapın

Web projelerinde gecikmenin nedenlerinden biri, metin ve görsellerin kendiliğinden hazır olacağının varsayılmasıdır. Briefte her içerik türünün sahibi belirtilmelidir. Ürün verisini teknik ekip sağlayabilir, metni ajans düzenleyebilir, son doğrulamayı ürün yöneticisi yapabilir. Bu üç görevi tek bir “müşteri içeriği gönderecek” satırına sıkıştırmak, işin gerçek yükünü gizler.

İçerik durumunu hazır, düzenlenecek, yeniden üretilecek ve karar bekliyor şeklinde sınıflandırabilirsiniz. Hazır denilen bir dosyanın gerçekten yayınlanabilir olduğundan emin olun. Eski katalogdaki düşük çözünürlüklü görseller veya üzerinde başka kampanyanın tarihi bulunan bir sunum, kullanılabilir kaynak olabilir ama doğrudan web içeriği sayılmaz. Ajansın bunları dönüştürmesi bekleniyorsa bu emek kapsamda yer almalıdır.

Entegrasyonları isimleriyle değil işlevleriyle açıklayın

“CRM bağlantısı olacak” cümlesinin arkasında çok farklı işler bulunabilir. Yeni talebin sisteme kaydedilmesi, var olan kişiyle eşleştirilmesi, doğru satış temsilcisine atanması ve hatalı aktarımın bildirilmesi birbirinden ayrı ihtiyaçlardır. Kullandığınız sistemi ve beklenen veri akışını anlatın. Erişim, teknik doküman ve test ortamını kimin sağlayacağını da yazın. Henüz incelenmemiş bir bağlantı için kesin süre istemek teklifleri yanıltabilir.

Formdan toplanacak alanları, verinin gideceği yeri ve işletme içindeki takip sorumluluğunu birlikte planlayın. Bir talep sisteme ulaşıyor ama kimse tarafından görülmüyorsa teknik bağlantı tek başına yeterli değildir. Brief, teknik çözümün yanında operasyonu da tarif etmelidir. İhtiyaç duyulmayan bilgileri baştan toplamak yerine, ilk görüşme için gerçekten gerekli alanları belirlemek daha anlaşılır bir deneyim oluşturur.

Tasarım beklentisini referansın nedenleriyle anlatın

Beğendiğiniz siteleri paylaşırken “bunun gibi olsun” demek yerine hangi özelliğin işe yaradığını belirtin. Büyük başlıklar mı, sade ürün karşılaştırması mı, sakin renk kullanımı mı, menünün açıklığı mı? Aynı referansta sevmediğiniz noktaları da yazabilirsiniz. Böylece tasarımcı, başka markanın görünümünü kopyalamaya çalışmadan sizin beklentinizi çözebilir. Mevcut logo, renkler, yazı karakterleri ve korunacak görsel öğeler ayrıca teslim edilmelidir.

Marka dili konusunda da örnek verin. Teknik doğruluk önemliyse bunun soğuk veya anlaşılmaz cümleler gerektirmediğini açıklayın. “Uzman kişiye detay sunarken ilk kez gelen ziyaretçiyi kaybetmeyelim” gibi bir beklenti, içerik hiyerarşisini etkiler. Tasarım briefi bu nedenle yalnız tasarım ekibinin değil, metin yazarı ve geliştiricinin de ortak başvuru belgesidir.

Kapsam dışını yazmak projeyi daraltmak değildir

Çok dilli yayın, fotoğraf çekimi, animasyon, ürün verisi temizliği, bakım, reklam kampanyası ve mevcut içeriklerin aktarılması ayrı iş paketleri olabilir. Hangilerinin teklifin içinde olduğunu açıkça yazın. Kapsam dışı bırakılan işlerin mutlaka gereksiz olduğu söylenmez; yalnız bu sürümde kimin sorumluluğunda olduğu veya daha sonra ele alınacağı belirlenir. Böylece iki taraf da farklı varsayımlarla ilerlemez.

Değişikliklerin nasıl değerlendirileceği de briefte yer alabilir. Yeni bir ürün ailesi eklemek, mevcut bir başlığı düzeltmekle aynı iş değildir. Değişiklik talebinin kapsam, süre ve içerik etkisi konuşularak onaylanması, projenin ilerlemesini kolaylaştırır. Hedefi değiştiren yeni bilgiler ortaya çıkabilir; önemli olan bunları sessizce eklemek yerine ortak kayıtla değerlendirmektir.

Takvimde yalnız yayın gününü göstermeyin

Bir fuara yetişecek site için yayın tarihi önemlidir. Ancak ürün bilgilerinin teslimi, tasarım kararları, geliştirme kontrolleri ve son içerik onayı da tarih gerektirir. Briefte bu kilometre taşlarının taslak sırası bulunmalıdır. Bütün kararların en son haftaya bırakıldığı bir takvim, geliştirme süresini kısaltsa bile içerik doğrulamasını hızlandırmaz. Karar verecek kişinin o tarihlerde ulaşılabilir olması da planın parçasıdır.

Kritik bağımlılıkları belirtin. Yeni ürün fotoğrafları çekilmeden ana sayfa görselleri tamamlanamayabilir. Teknik tablolar onaylanmadan ürün sayfaları gerçek içerikle kontrol edilemeyebilir. Bu durumları görünür kılmak, gecikmelerde suçlu aramaktan daha verimlidir. Projenin kimden ne beklediğini bilmek, işletme içindeki hazırlığı da düzenler.

Teklifleri aynı sorularla karşılaştırın

Farklı ajansların tekliflerini yalnız toplam tutar üzerinden okumayın. Tasarım çalışmasının kaç sayfa türünü kapsadığını, metin üretiminin kimde olduğunu, veri aktarımını, eğitim ve yayın desteğini karşılaştırın. Bir teklifte bulunmayan hizmet diğerinde ayrıntılı biçimde yer alıyorsa fiyat farkının bir bölümü buradan kaynaklanabilir. Açık bırakılan kalemleri sormak, en uzun teklifi otomatik olarak en iyi teklif kabul etmekten daha sağlıklıdır.

Görüşmede “Bu briefte henüz net olmayan hangi noktalar teklifinizi etkiliyor?” sorusunu sorun. İyi bir değerlendirme, her şeye hemen kesin yanıt verilmesini değil, belirsizliklerin doğru görülmesini içerir. Karar verirken iletişim düzenini, proje sahibini ve onay mekanizmasını da inceleyin. Siteyi yayına getirecek şey yalnız tasarım becerisi değil, birlikte karar verebilme düzenidir.

Teslimin kabul koşullarını önceden konuşun

“Site tamamlandı” ifadesinin herkes için aynı anlama gelmesi gerekir. Tasarımın onaylanması, içeriklerin girilmiş olması ve işletmenin günlük kullanıma hazır olması farklı aşamalardır. Üretici örneğinde yayın kabulü için temsilî bir ürünün teknik tablosu, çizim dosyası ve teklif formuyla birlikte çalışması beklenebilir. İkinci bir ürün ailesinde farklı alanlar bulunuyorsa onun da örneği kontrol edilir. Böylece yalnız en kolay sayfanın çalışmasına bakılarak bütün sistem hakkında karar verilmez.

Kabul koşulları, uzun bir hata arama listesi haline gelmek zorunda değildir. Ziyaretçinin yapacağı işi ve ekibin düzenleyeceği içeriği açıkça tanımlamak yeterlidir. “Yetkili editör bir ürüne yeni doküman ekleyebilmeli; ziyaretçi dosyayı doğru ürün sayfasında görebilmeli” ifadesi iki tarafın da anlayacağı bir kontroldür. Bu kontrolün kim tarafından, hangi örnek veriyle yapılacağını yazmak, son gün yapılan genel bir göz gezdirmeden daha güvenilir sonuç verir.

Yayın sonrasındaki sahipliği briefte bırakmayın

Yeni sitenin tesliminden sonra kimlerin içerik düzenleyeceği, hangi erişimlerin işletmede tutulacağı ve destek taleplerinin hangi kanaldan iletileceği de başlangıçta konuşulmalıdır. Teknik ekip değiştiğinde alan adı, barındırma ve panel bilgilerinin bulunamaması, tasarım kararlarından bağımsız bir yönetim sorunudur. Brief bu bilgileri herkesin okuyacağı şekilde içermek zorunda değildir; fakat sahiplerinin ve teslim yönteminin belirlenmesini istemelidir. Gizli erişim bilgilerini açık proje belgelerine koymayın.

Eğitim ihtiyacını da görevlerle anlatın. Editörün yalnız giriş yapmayı öğrenmesi yeterli olmayabilir; yeni hizmet eklemek, menü sırasını değiştirmek veya eski bir dokümanı güncellemek gerekebilir. Bu görevler için kısa bir uygulama oturumu ve anlaşılır kullanım notları talep edebilirsiniz. İlk yayın döneminde hangi kontrollerin ajans tarafından yapılacağını, hangi taleplerin ek çalışma sayılacağını bilmek ilişkinin devamını düzenler. Böylece proje, bir dosya tesliminden işletmenin kullanabildiği bir sisteme dönüşür.

Briefin son sürümüne karar tarihi ve belge sorumlusu ekleyin. Toplantıda değişen bir hedefin yalnız konuşma notlarında kalması, ekiplerin farklı beklentilerle üretime devam etmesine neden olabilir. Ortak sürüm, hangi kararın geçerli olduğunu gösterir.

Briefi tamamlamak için cevaplanacak sorular

• Siteye gelen kişi bugün hangi bilgiyi bulmakta zorlanıyor?
• İlk yayında mutlaka çalışması gereken üç ziyaretçi görevi nedir?
• Hangi içerikler hazır, hangileri uzman kontrolü veya yeni üretim gerektiriyor?
• Formlar, dokümanlar ve sistem bağlantılarının işletme içindeki sahipleri kim?
• Hangi işleri bu sürümün dışında tutuyoruz ve bu kararın gerekçesi ne?
• Yayına hazır olduğumuza hangi somut kontrollerden sonra karar vereceğiz?

Bu cevaplar ilk gün kusursuz olmak zorunda değildir. Brief, proje ilerledikçe kararları kaydeden yaşayan bir belge olabilir. Önemli olan, değişen cevapların herkese ulaşmasıdır. Digitalismo’nun web tasarım ve geliştirme çalışmasını değerlendirirken de başlangıç noktası budur: İşletmenin gerçek ihtiyacını, ziyaretçinin görevlerini ve ekibin üretim kapasitesini aynı plan içinde buluşturmak.