Web Sitesi Kaç Günde Yapılır? Süreç ve Takvim

"Site kaç günde biter?" sorusunun dürüst cevabı, "kapsam ve içerik takvimi belli olduğunda söylenebilir" olmalıdır. Bu yazıda gün sayısı vermiyoruz. Bunun yerine bir web sitesi projesinin aşamalarını, her aşamanın neye bağlı olduğunu ve takvimi uzatan ya da kısaltan etkenleri anlatıyoruz. Amaç, size verilen bir takvimi okuyabilmeniz ve kendi tarafınızdaki işleri baştan planlayabilmenizdir.

Bir web sitesi projesinin aşamaları

Aşamalar projeden projeye birleşebilir ya da kısalabilir, ama sıralama çoğunlukla aynıdır.

1. Keşif: Hedef, hedef kitle, kısıtlar ve kapsam netleşir. GOV.UK Service Manual, bir şeyi inşa etmeye karar vermeden önce çözülecek problemi anlamak gerektiğini ve keşif aşamasında hizmeti inşa etmeye başlanmaması gerektiğini söylüyor 1.
2. Bilgi mimarisi: Sayfa listesi, menü yapısı ve sayfalar arası bağlantılar belirlenir. Site haritası bu aşamanın çıktısıdır.
3. Tasarım: Önce taslak yerleşimler, sonra görsel tasarım. GOV.UK'ın alfa aşaması için önerisi burada da işe yarar: farklı fikirleri prototiplerle denemek ve en riskli varsayımları önce sınamak 2.
4. İçerik: Metinler, ürün bilgileri, görseller, çeviriler hazırlanır ve onaylanır. Bu aşama tasarımla paralel yürümelidir.
5. Geliştirme: Tasarım koda aktarılır, yönetim paneli kurulur, entegrasyonlar bağlanır.
6. Test: Farklı tarayıcı ve cihazlarda görünüm, formlar, entegrasyonlar, erişilebilirlik ve performans kontrol edilir.
7. Yayın: Alan adı yönlendirilir, yönlendirmeler kurulur, arama motoru ayarları yapılır; ilk hafta izlenir.

Aşamaların ayrıntılı işleyişini süreç sayfamızda anlatıyoruz.

Her aşamanın süresi neye bağlı?

Bir takvimi okurken her aşamanın neye bağlı olduğunu bilmek, hangi tarihin gerçekçi olduğunu anlamanızı sağlar.

Keşif sizin hazırlığınıza bağlıdır. Hedef, hedef kitle ve sayfa listesi yazılı bir brief'le geliyorsa keşif birkaç görüşmeye iner. Nielsen Norman Group'a göre keşfin amacı kullanıcıların kim olduğunu ve neye ihtiyaç duyduğunu, hangi problemlerin neden önemli olduğunu ve hangi çözümlerin uygulanabilir olduğunu anlamak, ayrıca paydaşlar arasında ortak bir başarı tanımı kurmaktır 3. Bu sorular şirket içinde yanıtlanmamışsa keşif uzar.

Bilgi mimarisi sayfa sayısına ve sayfalar arası ilişkilerin karmaşıklığına bağlıdır. On sayfalık bir kurumsal site ile yüzlerce ürünü kategorilere ayıran bir katalog aynı sürede planlanamaz.

Tasarım şablon sayısına ve onay turlarına bağlıdır. Ana sayfa, hizmet sayfası ve iletişim sayfası gibi birkaç şablonla kurulan bir site, her sayfası ayrı tasarlanan bir siteden daha az tasarım turu gerektirir. GOV.UK'ın alfa aşaması önerisi de bu aşamada bitmiş ürün değil, fikirleri sınamaya yetecek kadar karmaşık prototipler kurulmasıdır 2.

İçerik neredeyse tamamen müşteri tarafındadır: metni kimin yazacağı, kimin onaylayacağı, çevirinin ne zaman başlayacağı.

Geliştirme entegrasyon sayısına ve teknik erişimlerin ne zaman hazır olduğuna bağlıdır. Bir CRM bağlantısı, gerekli erişim bilgileri gelene kadar başlayamaz.

Test ve yayın önceki aşamaların kalitesine bağlıdır. Erişilebilirlik ve form testleri her aşamada yapılmışsa son test turu kısa sürer; yapılmamışsa test aşaması bir düzeltme aşamasına dönüşür.

Süreyi uzatan ve kısaltan etkenler

Aşağıdaki tablo, takvimi en çok etkileyen kalemleri iki yönüyle gösteriyor.

Erişilebilirlik satırı özellikle önemlidir. W3C'nin planlama rehberi, erişilebilirlik kontrollerinin yalnız site tamamlandığında değil her aşamada yapılabileceğini ve erken başlayıp proje boyunca kontrol etmenin, sonradan değiştirmesi pahalı olan erken tasarım kararlarına takılma riskini azalttığını söylüyor 5. Test aşamasında fark edilen bir renk karşıtlığı sorunu bütün bileşenlerin yeniden ele alınmasını gerektirebilir.

En çok gecikme yaratan şey: içerik ve onay döngüleri

Web sitesi projelerinde tasarım ve kod genellikle planlanan aşamalardır; içerik ise çoğu zaman "biz hazırlarız" diye bırakılan ve takvimde ayrı bir satırı olmayan iştir. Sonuç tanıdıktır: tasarım onaylanmış, geliştirme bitmek üzeredir ama sayfaların yarısında hâlâ yer tutucu metin vardır.

Nielsen Norman Group, yerleşim ile içeriğin birbirine doğru birlikte geliştirilmesi gerektiğini ve yer tutucu metinle yapılan tasarımın gerçek içerikle uyuşmayan boşluklar ve yanlış varsayımlar doğurduğunu belirtiyor; sitenin tasarımı ile içeriğinin birlikte büyümesi gerektiğini vurguluyor 4. Takvim açısından bunun anlamı şudur: içerik, tasarım bittikten sonra başlayan bir iş değil, tasarımla aynı anda yürüyen bir iştir. Gerçek metin geldiğinde tasarımın yeniden düzenlenmesi gerekiyorsa, bu ek bir tasarım ve onay turu demektir.

Onay döngüleri de benzer bir etki yaratır. Her tasarım turunda geri bildirimin farklı kişilerden, farklı zamanlarda ve bazen birbiriyle çelişerek gelmesi, tek bir turu birkaç tura çevirir. Bu gecikmeyi önlemenin yolları basittir ama baştan kararlaştırılmalıdır:

• Son onayı verecek tek bir kişi belirleyin.
• Geri bildirimleri kendi içinizde birleştirip tek seferde, yazılı olarak iletin.
• Her onay için takvimde bir tarih ayırın; onay gecikirse sonraki aşamaların da kayacağını kabul edin.
• Ürün, hukuk ya da çeviri gibi uzmanlık gerektiren onayları ayrı bir satır olarak takvime yazın.

Yayın tarihi ile görünürlük tarihi aynı değildir

Takvim planlarken sık atlanan bir nokta, sitenin yayına girdiği gün ile arama sonuçlarında görünmeye başladığı gün arasındaki farktır. Google, taramanın birkaç günden birkaç haftaya kadar sürebileceğini, bu süreyi dizin durumu raporu ya da URL Denetimi aracıyla izlemenin mümkün olduğunu ve aynı adresi tekrar tekrar göndermenin taramayı hızlandırmayacağını söylüyor 6. Yeni siteler ve site taşımalarında çok sayıda adres için site haritası göndermeyi öneriyor 6.

Bir fuar, kampanya ya da ürün lansmanına yetişmesi gereken bir site için bu, yayın tarihini hedef tarihin hemen öncesine değil, arada izleme ve düzeltme payı bırakacak şekilde planlamak demektir. Yayın öncesi kontrollerin tam listesi için web sitesi yayına alma kontrol listesi yazısına bakabilirsiniz.

Gerçekçi bir takvim nasıl planlanır?

Takvimi sondan başa doğru kurmak, en kritik tarihlerin gözden kaçmasını önler.

1. Hedef tarihi ve nedenini yazın. Tarih bir fuara ya da kampanyaya bağlıysa bunu belirtin; tarih esnekse onu da belirtin.
2. Yayın sonrası izleme payını ayırın. Hedef tarihten geriye doğru, yayın ile hedef arasında düzeltme için zaman bırakın 6.
3. Keşfi kısa ama eksiksiz tutun. Hedef, hedef kitle, sayfa listesi ve kısıtlar yazılmadan tasarıma başlamayın 1 3.
4. İçerik takvimini tasarım takvimine bağlayın. Her sayfa grubu için içerik teslim tarihini, o sayfanın tasarım onayından önceye koyun 4.
5. Onay tarihlerini takvime yazın. Her tasarım ve içerik turu için onay gününü ve karar vericiyi belirleyin.
6. Entegrasyon erişimlerini başta toplayın. CRM, ERP, ödeme ve kargo için gereken teknik belge ve erişimleri geliştirme başlamadan hazırlayın.
7. Testi ayrı bir aşama olarak planlayın. Erişilebilirlik kontrollerini yalnız sona bırakmayın, her aşamaya yayın 5.
8. Kapsamı fazlara bölün. Hedef tarihe yetişmesi gerekmeyen sayfa ve özellikleri ikinci faza taşıyın.

Brief'i hazırlamak için web sitesi brief'i nasıl hazırlanır yazısından, sayfa ve özellik listenizi çıkarmak için site planlayıcı aracından yararlanabilirsiniz. Projenin kapsamını birlikte netleştirmek için kurumsal web sitesi hizmetini inceleyebilirsiniz.