Web sitesi yaptırmadan önce vermeniz gereken kararlar

Web sitesi yaptırmadan önce üç kısa belge hazırlayın: bir sayfalık brif, sahiplik listesi ve teslim senaryoları. Bu belgelerle kararlarınız yazıya geçer ve teklifleri aynı iş üzerinden karşılaştırabilirsiniz. Aşağıda her belgeye ne yazacağınızı ve firmaya neleri soracağınızı sırayla anlatıyorum.

Brif, tasarımcıya ya da geliştiriciye işi anlatan kısa yazılı özettir. Sahiplik listesi hesapların ve içeriğin kimde olduğunu, teslim senaryoları da teslimde neyi deneyeceğinizi gösterir.

Beğendiğiniz siteleri gösterip “buna benzer bir şey istiyoruz” demek görüşmeyi başlatır, ama teklif almaya yetmez. O örnekler ziyaretçinizin ne yapacağını ve siteyi yayından sonra kimin yöneteceğini söylemez. Her şeyi baştan bilmeniz gerekmiyor. Hangi soruların henüz cevapsız olduğunu bilmeniz gerekir.

Web sitesi yaptırmadan önce sitenin ne işe yarayacağına karar verin

İlk olarak ziyaretçinin sitenizde ne yapmasını istediğinize karar verin. Hizmetinizi mi anlasın, teklif mi istesin, ürün mü alsın, yoksa müşterileriniz belge mi indirsin? Bunu seçince ana sayfadaki bölümlerin sırası, menü ve formdaki alanlar da değişir. Sayfa sayısı sonra gelir.

Diyelim ki bir muhasebe bürosunuz var. Ziyaretçi hizmetlerinizi ve kiminle çalışacağını görüp kısa bir talep bırakmak ister. Bir mobilya mağazasında ise kategori, stok bilgisi, teslimat ve ödeme öne çıkar. İkisi aynı “beş sayfalık paket” ile çözülmez.

Bir sayfalık brife neler yazılır

Brifte şu sorulara kendi işiniz için kısa cevaplar yazın:

• Siteye öncelikle kim gelecek, aklında hangi soru var?
• Ziyaretçinin ne yapmasını istiyorsunuz? Tek bir ana eylem seçin, örneğin uygun hizmet için iletişime geçmek.
• Ziyaretçiyi neyle ikna edeceksiniz? Gerçek iş örnekleri, nasıl çalıştığınız, ürün bilgisi ya da ekibinizin uzmanlığı.
• Hangi içerik hazır, eksikleri kim tamamlayacak? Metin, fotoğraf, marka dosyaları, ürün bilgisi, çeviri.
• Neler kapsam dışında kalacak? Üyelik, çoklu dil, rezervasyon ya da başka programlarla bağlantı gibi, sonradan sürpriz olmaması gereken işler.

Kesinleşmemiş konulara “karar bekliyor” yazın. Metinleri kimin yazıp onaylayacağını sahiplik listesine de ekleyin. Bu belli değilse, takvimi tasarımdan çok içerik geciktirebilir.

Alan adı ve hesaplar sizin kontrolünüzde kalsın

Sitenin temel hesapları şirketinizin adına açılsın. Firmayla yollarınız ayrılırsa alan adınızı ve sitenizi geri almak için ona bağlı kalmazsınız. Alan adı kaydı, DNS (alan adını sunucuya yönlendiren ayarlar) ve barındırma (sitenin dosyalarının durduğu sunucu) bunların başında gelir. Yönetim paneli (metin ve görselleri değiştirdiğiniz ekran) ve ziyaretçileri ölçen analiz araçları da bu gruba girer.

Hesapları şirketinizden yetkili biri açsın ve işi yapan firmaya gerektiği kadar yetki versin. Şifreleri e-posta eklerinde ya da ortak tablolarda paylaşmayın. Devirde erişimleri ve hesap kurtarma yöntemlerini (şifre unutulunca kullanılan e-posta ve telefon) birlikte kontrol edin.

Sahiplik listesine her hesap için şunları yazın:

• Kimin adına kayıtlı
• Günlük işlerle kim ilgileniyor
• Kim, hangi yetkiyle girebiliyor
• Firma değişirse hesap nasıl devredilecek

Sitede parayla alınmış bir tema (hazır tasarım şablonu) ya da eklenti (siteye özellik ekleyen küçük yazılım) varsa onu da listeye ekleyin. Ücretli yazı tipi ve stok fotoğraf için de aynısı geçerli. Lisans kimin adına, yenileme bedeli ne kadar, firma değişirse ne olacak? Site dosyalarının size teslim edilmesi, ücretli temanın lisansının da size geçtiği anlamına gelmeyebilir.

Site, firmanın ya da başka bir hizmetin kapalı sisteminde çalışıyorsa kodunu dışarı alamayabilirsiniz. O zaman metinlerinizi ve görsellerinizi dosya olarak alıp başka yere taşıyabilir misiniz, sorun.

Tasarımı telefonda kullanarak deneyin

Tasarımı onaylarken renk ve düzen kadar kullanım kolaylığına da bakın. Ziyaretçi doğru hizmeti bulabiliyor mu? Mobil menüyü açınca nereye gideceğini anlıyor mu? Uzun bir formu telefonda doldurabiliyor mu?

Masaüstü tasarımı küçültmek yetmez, tasarımı gerçek bir telefonda açın. Menü, ekranda sabit duran butonlar (örneğin “Hemen ara”) ve formlar birbirinin üstüne biniyor mu? Bir tablo ya da görsel ekrandan taşıp sayfayı yana kaydırıyor mu? En azından ana sayfadan bir hizmete, oradan iletişime giden yolu kendi telefonunuzda tıklayarak izleyin.

Erişilebilirliği baştan isteyin

Erişilebilirlik, sitenizi görme ya da hareket güçlüğü olanlar dahil herkesin kullanabilmesi demek. Şunlar tasarım kararlarıdır, o yüzden en baştan konuşun:

• Fare kullanamayan biri menüyü ve formları yalnız klavyeyle (örneğin Tab tuşuyla) kullanabiliyor mu? İlerlerken hangi bağlantıda ya da kutucukta olduğu ekranda belli oluyor mu?
• Yazı ile arka plan arasında yeterli kontrast var mı, metin rahat okunuyor mu?
• Görsellerin alternatif metni, yani göremeyen kişi için yazılmış kısa açıklaması var mı?
• Bazı kişiler cihaz ayarlarından animasyonları azaltır. Bu kişiler kayan ya da hareketli bir bölümdeki bilgiyi yine görebiliyor mu?

WCAG, web standartlarını belirleyen kuruluş W3C’nin erişilebilirlik kurallarıdır. W3C’nin WCAG genel bakışı bu kuralları dört ilkede toplar: içerik algılanabilir, kullanılabilir, anlaşılabilir ve sağlam olmalı. Sağlam, tarayıcıların ve ekran okuyucu gibi yardımcı araçların içeriği doğru okuyabilmesi demek. Buradaki kontroller bir uygunluk sertifikası yerine geçmez.

Yine de tasarımcıya yalnız “mobil uyumlu olacak mı?” diye sormayın. Şunu da sorun: “Siteyi hangi ekranlarda, hangi işlemlerle test edeceğiz? Klavyeyle kullanımı ve hareketi azaltma ayarını nasıl kontrol edeceğiz?”

SEO, site yapısıyla birlikte başlar

Hangi hizmetin ayrı sayfası olacağına tasarım başlamadan karar verin. SEO, sitenizin Google gibi arama motorlarında bulunabilmesi için yapılan çalışmadır. Bu çalışma, bitmiş siteye birkaç başlık eklemekten çok önce, sayfa yapısına karar verirken başlar.

Örneğin bir diş kliniği implant ile ortodontiyi tek blokta anlatırsa, iki farklı ihtiyaçla gelen ziyaretçi aradığını zor bulabilir.

Önemli her sayfa için (örneğin her hizmet sayfası) şunu sorun: Bu sayfa kimin hangi ihtiyacını karşılıyor? Sayfanın başlığını ve içeriğini buna göre kurun. Sayfaları konu yakınlığına göre birbirine bağlayın, her sayfadan her sayfaya link vermeye gerek yok. Bu sayfa listesini brifinize ekleyin.

Google Search Central’ın SEO başlangıç rehberi de anlaşılır içeriği, mantıklı site yapısını ve açıklayıcı bağlantıları öne çıkarıyor. Google’ın sayfanızı kendi listesine eklemesine indeksleme denir. Rehber ne indekslemeyi ne de ilk sırayı garanti ediyor.

Teknik tarafta şunları konuşun:

• Arama sonuçlarında görünebilen sayfa başlığını ve açıklamasını kendiniz düzenleyebilecek misiniz?
• Hizmet adları ve adresiniz gibi önemli bilgiler sayfada yazı olarak mı duruyor, yoksa yalnız bir görselin içinde mi?
• Açık olması gereken sayfalar taramaya, yani Google’ın sayfaları gezip okumasına açık mı?
• Site haritası (sayfaları listeleyen dosya) olacak mı? Her içeriğin tek bir adresi var mı?

Bu liste sonraki SEO çalışmasının temelidir. Yayından sonra düzenli içerik ve SEO çalışması gerekecekse, bunu site yapımından ayrı bir iş olarak planlayın. GEO ise yapay zekânın yazdığı cevaplarda işletmenizin doğru anlatılması için yapılan çalışmadır. İkisinin kapsamını SEO ve GEO danışmanlığı sayfasında görebilirsiniz.

Site yenileniyorsa eski sayfa adreslerini yenileriyle eşleştirin

Firmadan eski sitedeki bütün sayfa adreslerinin (URL) listesini ve her birinin yeni sitedeki karşılığını isteyin. Adresi değişen sayfalar için yönlendirme kurulsun, yani eski adrese gelen kişi otomatik olarak yeni sayfaya gitsin. Her eski adresi ana sayfaya göndermek, ziyaretçiyi aradığı içeriğe ulaştırmaz.

Test ortamı, sitenin yayından önce denendiği kopyasıdır. Orada arama motorlarını engelleyen bir ayar kullanıldıysa, site yayına alınırken kaldırıldığını firmayla birlikte kontrol edin. Bu ayar açık kalırsa siteniz Google’da görünmeyebilir.

Site hızını tasarım aşamasında konuşun

Teklifte “hızlı site” yazması tek başına yetmez. Hangi sayfanın, hangi cihazda ve hangi internet bağlantısıyla ölçüleceği de yazılı olmalı.

Sayfa açılınca ilk görünen kısma ilk ekran denir. Buraya ağır bir video, birkaç yazı tipi dosyası ve üst üste animasyonlar yığılırsa, sonradan birkaç görseli sıkıştırmak yetmeyebilir. Canlı sohbet aracı ya da ölçüm kodu gibi başka firmalardan gelen kodlar da bu yüke eklenir. Bunlara üçüncü taraf kod denir.

Tasarım sırasında ilk ekranda neyin görüneceğini konuşun. Oradaki büyük görsel gerçekten gerekli mi, dosyası çok mu büyük, sorun. Sade bir kapak görseli bazen hem güçlü bir tasarım kararıdır hem de yüklemeyi kolaylaştırır. Animasyon bir bilgiyi anlatıyorsa kalsın, süs olarak dikkati dağıtıyorsa çıkarın.

web.dev’in Core Web Vitals açıklaması üç ölçü kullanır. Hız raporlarında bu kısaltmaları görebilirsiniz:

• LCP, ilk ekrandaki en büyük görselin ya da yazı bloğunun ne kadar sürede göründüğünü ölçer. 2,5 saniye veya altı iyi sayılır.
• INP, sayfanın tıklama ya da dokunma gibi bir etkileşime ne kadar hızlı tepki verdiğini ölçer. 200 milisaniye veya altı iyi sayılır.
• CLS, sayfadaki içeriğin beklenmedik kaymasını ölçer. Tam tıklayacakken bir butonun aşağı kayması buna örnektir. CLS bir puandır, 0,1 veya altı iyi sayılır.

Mobil ve masaüstü ayrı değerlendirilir. İyi sayılmak için bu değerlerin gerçek ziyaretlerin en az dörtte üçünde tutturulması gerekir (75. yüzdelik dilim). Bir test aracının tek seferlik puanı herkesin deneyimini göstermez.

Yayından önce yapılan ölçüm sorunları bulmaya yarar. Site yeterince ziyaretçi aldıktan sonra gerçek ziyaretçi verisine de bakın.

Teklifte “performans optimizasyonu” (hız iyileştirmesi) yazıyorsa şunları sorun: Hangi sayfalar ya da sayfa türleri dahil? Hangi cihazda ve hangi bağlantıyla ölçülecek? İş bittikten sonra tekrar ölçülecek mi?

Yayından sonra video, canlı sohbet aracı ya da ölçüm kodu eklemek isterseniz, hıza etkisini önceden firmayla konuşun. Hızın nasıl ölçüleceğini yazılı isteyin ve bu ölçümü teslim senaryolarınıza ekleyin.

Siteyi yayından sonra kim güncelleyecek?

Platform, sitenin üzerine kurulduğu yazılımdır. Metinleri bir panelden değiştirmenize yarayan türüne içerik yönetim sistemi denir. Platformu seçerken ekibinizin sitede kendi başına neleri değiştirebileceğine bakın.

Firmadan size canlı olarak yeni bir hizmet sayfası açmasını ve bir blog yazısı yayımlamasını isteyin. Bu gösterimde siteyi güncelleyecek çalışanınız da olsun, mümkünse denemeyi kendisi yapsın. Bir hizmetin çalışma saatlerini değiştirebiliyor mu, görsel ekleyebiliyor mu? Yanlışlıkla bozduğu bir şeyi geri alabiliyor mu?

Eğitimin birkaç ekran görüntüsünden mi ibaret olacağını da bu gösterimde anlarsınız. Basit bir güncelleme için her seferinde geliştiriciye gidecekseniz, bunu bakım bütçesine yazın.

Hazır şablonla size özel tasarım ve geliştirme arasında herkese uyan tek bir seçenek yok. Tekrar eden sayfalarda şablon, çok özel bir işlem için ayrı geliştirme mantıklı olabilir. Seçerken ne sıklıkla içerik ekleyeceğinize ve ekibinizin ne kadar teknik olduğuna bakın.

Sitenin randevu ya da muhasebe yazılımı gibi başka programlarla bağlantı kurması gerekecek mi? Bu bağlantılara entegrasyon denir. İleride yapacağınız değişiklikleri de hesaba katın. Platformun sınırlarını ve başka yere taşınıp taşınamayacağını yazılı sorun.

Bakımı kimin yapacağını yazın

Yayından sonra yazılım güncellemelerini, yedeklemeyi, sorun çıkınca yedekten geri dönmeyi ve desteği kimin üstleneceği belli olsun. “Bakım dahil” deniyorsa hangi işlerin dahil olduğunu, neyin yeni geliştirme sayılacağını sorun. Satış sitesinde ödemeleri, sipariş bildirimlerini ve stok değişikliklerini kimin izleyeceğini de belirleyin. Bu sorumluları sahiplik listenize yazın.

Siteyi teslim alırken adım adım deneyin

Siteyi bir ziyaretçi gibi baştan sona kullanın. Hatalar çoğu zaman ziyaretçinin başladığı işi bitiremediği yerde çıkar. Sitenin yayına alınması da teslimi kabul ettiğiniz anlamına gelmez.

Brifteki ana eylem için birkaç teslim senaryosu yazın. Her senaryoya ne yapacağınızı, ne olması gerektiğini ve kanıtı yazın. Örneğin hizmet sayfasındaki iletişim formu için:

Ne yapıyorsunuz	Ne olmalı	Kanıt
Telefonda formu, zorunlu bir alanı boş bırakıp gönderin	Açıklayıcı bir uyarı çıkar	Ekran görüntüsü
Doğru doldurulmuş bir deneme talebi gönderin	Onay ekranı çıkar, bildirim doğru kişiye gider	Onay ekranı ve gelen bildirim

“Gönderildi” mesajı, talebin doğru kişiye ulaştığını tek başına kanıtlamaz. Denemelerde gerçek müşteri bilgisi kullanmayın.

Aynı yöntemle şunları da kontrol edin:

• Menüye yalnız klavyeyle ulaşmayı deneyin.
• Küçük ekranda yana taşan bir bölüm var mı, bakın.
• Eski bir adresi açın, karşılığı olan yeni sayfaya gittiğini görün.
• İçerik sorumlunuz bir başlığı kendisi değiştirsin.
• Ödeme varsa bir deneme siparişi verin. Sipariş yönetim ekranına düşüyor mu, bildirim geliyor mu, bakın.

Site yedekleniyorsa, bir sorun çıktığında siteyi yedekten kimin geri yükleyeceğini ve bunun ne zaman deneneceğini yazıya geçirin.

Siteye analiz aracı kurulacaksa, telefon numarasına tıklama ile gönderilen form ayrı sayılsın. Numaraya tıklayan herkes sonunda aramayabilir. Deneme talebinizin raporda göründüğünü ve yanlışlıkla iki kez sayılmadığını firmayla kontrol edin. Formdaki kişisel bilgilerin analiz aracına gitmesine gerek yok.

Teslimde bulunan hatalar düzeltilecek işlerdir. Sonradan aklınıza gelen yeni bir istek ise kapsam değişikliğidir ve ayrıca konuşulur. Yayın sonrası destek de ayrı bir kalemdir. Eksikleri not edin, her birinin sorumlusunu belirleyin, onayı ondan sonra verin.

Teklifleri aynı kapsam üzerinden karşılaştırın

Fiyatları yan yana koymadan önce iki teklifte aynı işlerin olup olmadığına bakın. Şu kalemler ayrı satırlarda görünmeli:

• Sayfa ve şablon listesi
• Metin ve görsel hazırlığı
• Mobil test
• Erişilebilirlik kontrolleri
• Temel SEO
• Performans ölçümü
• Eski siteden geçiş
• Entegrasyonlar
• Yönetim eğitimi
• Bakım

Teklifte yazmayan bir iş için sonradan ayrıca ödeme istenebilir. O işi sizin ya da başka bir firmanın yapması da gerekebilir.

Her projeye uyan tek bir fiyat ya da süre yoktur. Bu yüzden teklif görüşmesinde şunları da sorun:

• Değişiklik (revizyon) hangi aşamada ve ne kadar yapılabilecek?
• Sonradan gelen yeni istekler nasıl ele alınacak?
• Metinleri ya da onayı geç verirsek takvim nasıl değişecek?
• Alan adı, lisans ve barındırma giderleri yapım bedelinden ayrı mı?

Görüşmeye brifinizi, sahiplik listenizi ve teslim senaryolarınızı götürün. Firmadan belgeleri okuyup katılmadığı ya da eksik gördüğü yerleri söylemesini isteyin. Sonra tam olarak neyi yapacağını yazılı versin. İyi bir teklifte sizden beklenenler de yazar, örneğin metinleri ve fotoğrafları ne zamana kadar vereceğiniz.

Sık sorulan sorular

Bir firma Google’da ilk sırayı garanti edebilir mi?

Hayır. Google’ın SEO başlangıç rehberi de sıralama ya da indeksleme garantisi vermiyor. Site yapımı SEO’nun temelini kurar, düzenli çalışma gerekiyorsa onu ayrıca planlayın.

Site dosyaları bana teslim edilirse her şey benim olur mu?

Her zaman değil. Ücretli tema, eklenti ya da yazı tipi lisansı, dosyalardan farklı bir hak olabilir. Lisansın kimin adına olduğunu ayrıca sorun.

Hizmetinizi anlatıp talep toplayacak bir site planlıyorsanız kurumsal web sitesi, ürün satacaksanız e-ticaret sitesi sayfasına bakabilirsiniz.