Site Yenilemesini Aşamalı Yeniden Tasarım Olarak Yönetmek

Bir butonun metnini değiştiren ekip bunu bir hipotez olarak ele alıp test planı kurabiliyor. Aynı ekip, yüzlerce kararın birlikte değiştiği yeni siteyi tek gecede herkese açabiliyor.

Bir butonda “Teklif Al” mı yazmalı, “Hemen Teklif Al” mı? Form dört alan mı olmalı, altı mı? Dijital pazarlama, CRO, UX, ürün ve web ekipleri bu sorulara bir fikirle yaklaşır ama fikri kanıt saymaz. Mümkünse test eder, ölçer, sonra karar verir.

Konu bütün siteyi yenilemeye geldiğinde ise tasarım, navigasyon, metinler, formlar, URL yapısı, içerik yönetim sistemi ve ölçüm altyapısı aylarca birlikte değiştiriliyor. Sonra eski site bir gün kapatılıp yenisi herkese açılıyor.

Yeni web sitemiz yayında.

Bir buton için “Bunun daha iyi olduğundan emin miyiz?” diye soran ekipler, yüzlerce kararın toplamı olan yeni sitenin daha iyi olacağını neden daha kolay varsayıyor?

💡 TL;DR: Özet ve Anahtar Çıkarımlar
Eski sitenin değişmesi gerekebilir. Bu, yeni sitedeki bütün kararların doğru olduğunu göstermez.
Site yenilemesi tek bir değişiklik değildir. Tasarım, taşıma ve iş akışlarının birleşimidir.
Ana çözüm, değişiklikleri ayırmak, korunacak davranışları sözleşme gibi yazmak ve her aşamayı kendi sonucu üzerinden ölçmektir.

Eski site kötü olabilir. Bu, yeni sitenin iyi olduğu anlamına gelmez

Eski site yavaş, mobilde zor veya marka için yetersiz olabilir. İçerik yönetmek eziyete dönüşmüş, erişilebilirlik ya da güvenlik borcu birikmiş olabilir. Bazı sitelerde yenileme ertelenemeyecek bir ihtiyaçtır.

Fakat “eski siteyi değiştirmeliyiz” ile “yerine koyduğumuz sitedeki yüzlerce karar doğru” iki ayrı cümledir. İlkinin doğru olması ikincisini kanıtlamaz.

Eski sitenin sorunları görünür ve tanıdıktır. Yeni sitenin sorunları henüz yaşanmadığı için görünmez. Temiz tasarım, hızlı teknoloji ve daha iyi yazılmış metin makul bir beklenti yaratır. Makul beklenti, kanıtın yerini tutmuyor.

Site yenilemesi tek bir değişiklik değildir

Kohavi ve çalışma arkadaşlarının Microsoft'taki büyük ölçekli deneyler üzerine çalışması, test edilen fikirlerin yaklaşık üçte birinin hedeflediği metrikleri iyileştirdiğini aktarıyor. Bu bulgudan “site yenilemelerinin üçte biri başarılı olur” sonucu çıkmaz. Araştırma, Microsoft ürünlerindeki fikirleri ve önceden belirlenmiş metrikleri inceliyor. Yine de çalışma, deneyimli ekiplerin mantıklı bulduğu fikirlerin sık sık beklenen sonucu vermediğini gösteriyor.

Bir butonu değiştirdiğinizde neyi sınadığınız bellidir. Bütün site değiştiğinde tasarımın yanında bilgi mimarisi, sayfa hiyerarşisi, içerik, URL'ler, analitik olaylar, çerez izin davranışı, reklam dönüşümleri, CRM alanları ve entegrasyonlar da değişebilir.

Form gönderimleri düşerse sebebi yeni akış, fazla bir alan, tarayıcıdaki doğrulama hatası, kaybolan dönüşüm olayı veya CRM bağlantısı olabilir. Hepsi aynı gün değiştiğinde nereden başlayacağınızı bilemezsiniz. Site iyi sonuç verse bile hangi kararın işe yaradığını öğrenmek zorlaşır.

Web sitesi yenilemek bu nedenle tasarım işi kadar taşıma işidir. Google, alan adı, içerik yönetim sistemi ve sayfa düzeni gibi değişiklikleri aynı anda yapmamayı öneriyor. Yeni siteyi önceden test etmeyi, eski ve yeni URL'leri eşlemeyi ve taşıma sonrasında trafiği izlemeyi de istiyor. Resmî site taşıma rehberi, SEO için yazılmış olsa da daha geniş bir proje dersini destekliyor: Aynı anda değişen unsur sayısı arttıkça teşhis zorlaşıyor.

Ana çözüm: aşamalı yeniden tasarım

Ben çözümün siteyi birbiriyle ilişkili ama ayrılabilir değişiklikler dizisi olarak ele almakta yattığını düşünüyorum. Buna aşamalı yeniden tasarım, yani progressive redesign diyebiliriz.

Önce neyin gerçekten değişmek zorunda olduğunu ayırın. CMS mi ihtiyacı karşılamıyor? Tasarım mı sorunlu? Bilgi mimarisi mi kullanıcıyı yanlış yere götürüyor? Marka mı değişiyor? URL yapısı mı teknik bir engel yaratıyor? Her biri geçerli bir neden olabilir. Hepsinin aynı gün değişmesi gerekmiyor.

CMS değişikliği zorunluysa yeni sistem önce mevcut sitenin önemli davranışlarını yeniden üretebilir. Bu geçiş doğrulanınca navigasyon değişebilir. Ardından önemli açılış sayfaları yeniden tasarlanabilir. Formdaki alanlar ve akış ise ayrı bir aşamada ele alınabilir.

Bu sıra her projede mümkün olmaz. Yeni arka uç eski ön yüzü desteklemeyebilir. Bilgi mimarisindeki iki bölüm birbirinden ayrılamayabilir. Yeni marka, iki görsel kimliğin birlikte yaşamasını istemeyebilir. Yine de ayrılabilen değişiklikleri ayırabilir, birlikte kalması gerekenlerin nedenini açıkça yazabilirsiniz.

Değişmeyecekleri yazın, değişecekleri sıraya koyun

Bir site yenilemesinin gereksinimleri genellikle yeni sitenin ne yapacağını anlatır. İlk aşamada neyin değişmeyeceğini de yazmak gerekir.

URL yapısı zorunlu olarak değişmiyorsa adresler korunabilir. Değişiyorsa her önemli eski URL'nin yeni karşılığı önceden belirlenebilir. Aynı kullanıcı davranışı aynı analitik olayı üretmeli. Başarılı bir form gönderimi, kaynak ve kampanya bilgileriyle CRM'de beklenen kayda dönüşmeli.

Bu maddeler niyet olarak kalmamalı. Yayından önce ve sonra doğrulanabilen sözleşmelere dönüşmeli. “Form çalışıyor” zayıf bir kabul ölçütüdür. “Form başarılı yanıt veriyor, CRM'de doğru alanlarla tek bir lead oluşturuyor ve dönüşüm olayı sadece başarılı gönderimde çalışıyor” daha kullanışlıdır.

Teknik taşımanın ilk başarı ölçütü daha yüksek dönüşüm oranı değildir. Önce eski sistemin iş için ürettiği önemli davranışların yeni sistemde kaybolmadığını doğrularsınız. Sonra navigasyon, sayfa mesajı veya form uzunluğu gibi davranışsal kararları sırayla değiştirirsiniz.

Bu ayrım geri dönüşü de kolaylaştırır. Yeni CMS çalışıyor, yeni navigasyon çalışmıyorsa bütün taşımayı geri almak yerine navigasyon kararını düzeltebilirsiniz.

Her aşamada doğru şeyi ölçün

Teknik taşıma sırasında 404 ve 5xx hatalarına, taranabilirliğe, canonical etiketlerine, analitik olaylara, form başarı oranına ve CRM kayıtlarının bütünlüğüne bakarsınız. Amaç büyümeyi kanıtlamak değil, sürekliliği doğrulamaktır.

Davranışsal bir değişiklikte dönüşüm, görev tamamlama, navigasyon kullanımı veya nitelikli lead oranı önem kazanabilir. Organik trafik, hata oranı ve form teslimi gibi koruyucu metrikleri de izlemeye devam edersiniz.

Her şeyi A/B test etmeniz gerekmiyor. Hangi değişikliğin hangi sonucu doğurmuş olabileceğini anlayabilmek gerekiyor. Kampanyalar, sezonsallık ve arama motorlarının sayfaları yeniden işlemesi kusursuz nedenselliği engelleyebilir. Aşamaları ve tarihlerini kaydetmek yine de belirsizliği azaltır.

Kademeli açılış araçtır, ana model değil

Canary, yani sınırlı açılış, bir değişikliği üretimin küçük bir bölümüne açıp sonucunu değerlendirme yöntemidir. Google SRE rehberi, yüksek trafikli hizmetlerde hata oranı veya gecikme gibi hızlı sinyaller bulunduğunda bunun değerini gösteriyor.

Her web sitesi aynı koşullara sahip değil. Düşük trafikli bir B2B sitesinde anlamlı kontrol grubu oluşturmak uzun sürebilir. Organik görünürlüğü kullanıcı yüzdesine göre bölmek kolay değildir. Arama motorlarının URL'leri yeniden işlemesi, marka algısı ve yeni bilgi mimarisinin etkisi de bir sunucu hatası kadar hızlı görünmez.

Google'ın site taşıma rehberi burada önemli bir nüans taşıyor. Farklı değişiklikleri sıraya koymayı önerirken, küçük ve orta büyüklükteki sitelerde URL taşımasının genellikle bütün URL'ler için aynı anda yapılmasını söylüyor. Büyük siteler ise bölüm bölüm ilerleyebilir.

Aşamalı yeniden tasarım, proje kararlarını ayırma ilkesidir. Kademeli açılış ise teknik olarak uygunsa kullanılabilecek araçlardan biri. Bazı değişiklikleri ayırmanın maliyeti faydasını aşabilir. Google Drive ve Spotify vakaları, büyük arayüz değişikliklerinde kullanıcı tepkisinin nasıl araştırılıp yönetilebileceğini anlatıyor. Bu iki vakadan benim çıkardığım ders, ilk tepkiyi kalıcı kalite kararıyla eşitlememek. Buradaki görev, hangi belirsizlikleri neden birlikte taşıdığınızı görünür kılmaktır.

Yarın sabah nereden başlanır?

Yeni site için daha ayrıntılı bir özellik listesi açmadan önce projeyi şu tabloyla parçalayabilirsiniz:

Alan	İlk karar	Korunacak sözleşme	Doğrulama
CMS ve altyapı	Değişmek zorunda mı?	Önemli URL, içerik, form ve ölçüm davranışı korunur.	Tarama karşılaştırması, hata kayıtları, form ve olay testleri.
URL ve içerik	Gerçekten değişmeli mi?	Her önemli eski URL korunur veya anlamlı bir karşılığa yönlenir.	URL eşlemesi, durum kodları, canonical etiketleri ve iç bağlantılar.
Navigasyon ve tasarım	Hangi iş sonucunu değiştirecek?	Önemli içerik, eylem ve ölçüm noktaları kaybolmaz.	Görev tamamlama, dönüşüm, organik girişler ve erişilebilirlik.
Form, ölçüm ve CRM	İlk aşamada neden değişsin?	Başarılı gönderim doğru alanlarla tek iş kaydı oluşturur.	Uçtan uca deneme, CRM kontrolü, hata ve başarı oranları.

Her satırı üç gruptan birine koyun: şimdi değişmek zorunda, ilk aşamada korunmalı veya daha sonra denenebilir. Ardından başlangıç düzeyini, kabul ölçütünü ve ne olursa duracağınızı yazın. Sonraki aşamaya takvim geldiği için değil, önceki değişikliğin sözleşmeleri koruduğunu gördüğünüz için geçin.

Site hazır olabilir. Bu, daha iyi olduğunu göstermiyor. Yayına alma toplantısında iki soru daha gerekiyor:

Hangi değişikliği yayına alıyoruz?
Bu aşamada değişmemesi gereken davranışlar hâlâ çalışıyor mu?

Bir Butonu Test Konusu, Bütün Bir Site Değişikliğini Kesin Çalışacak Çılgın Proje Olarak Görmek