Bir Butonu Test Konusu, Bütün Bir Site Değişikliğini Kesin Çalışacak Çılgın Proje Olarak Görmek
Sayfayı kopyala
Bugün aklıma şu çelişki geldi.
Dijital pazarlama, CRO, UX, product ve web dünyasında çalışan bazı insanlar neredeyse her küçük değişikliği test ederek yapmak istiyor.
Bir butonda “Teklif Al” mı yazmalı, “Hemen Teklif Al” mı? Form dört alan mı olmalı, altı mı? Hero bölümündeki mesaj mı yanlış, CTA'nın rengi mi? Bu insanların bir fikri olabilir ama fikrin yeterli kanıt olduğunu düşünmezler. Mümkünse test eder, sonucu ölçer, sonra karar verirler.
Bu refleks küçük değişikliklerde sağlıklıysa, bütün bir site değiştiğinde daha az gerekli olmuyor. Tam tersine, daha da önemli hâle geliyor.
💡 TL;DR: Özet ve Anahtar Çıkarımlar
- Bir buton hipotez, site yenileme proje oluyor. Küçük kararlar için istediğimiz kanıtı, yüzlerce kararın birleştiği yenilemede çoğu zaman aynı disiplinle istemiyoruz.
- Risk yalnızca yeni deneyimin daha kötü olması değil. Yönlendirmeler, analitik, formlar, SEO ve entegrasyonlardaki küçük kırılmalar iş sonucunu sessizce bozabiliyor.
- Çıkarım “yenileme yapmayın” değil. Büyük değişiklik gerekiyorsa onu ölçülebilir aşamalara bölmek, kritik davranışları korumak ve geri dönüş yolunu önceden hazırlamak gerekiyor.
Fakat konu bütün web sitesini yenilemeye geldiğinde aynı insanlar bazen bambaşka davranıyor.
Aylarca yeni bir tasarım hazırlanıyor. Arayüz değişiyor, sitede gezinme düzeni değişiyor, metinler değişiyor, formlar değişiyor, URL yapısı değişiyor, içerik yönetim sistemi değişiyor, ölçüm altyapısı yeniden kuruluyor. SEO tarafında yönlendirmeler, canonical etiketleri, yapılandırılmış veri, site içi bağlantılar ve hız davranışı da değişebiliyor.
Sonra bir gün eski site kapatılıyor ve yeni site herkese açılıyor.
Yeni web sitemiz yayında.
Buradaki çelişki şu: Bir buton için “bunun daha iyi olduğundan emin miyiz?” diye soran ekipler, yüzlerce kararın toplamı olan yeni sitenin eskisinden daha iyi olacağını neden daha kolay varsayıyor?
Eski site kötü olabilir. Bu, yeni sitenin iyi olduğu anlamına gelmez
Bunun ilk cevabı kolay: Eski site gerçekten kötü olabilir.
Yavaş olabilir. Mobilde çalışmak zor olabilir. Marka için yetersiz kalmış olabilir. İçerik yönetmek eziyete dönüşmüş olabilir. Erişilebilirlik veya güvenlik borcu birikmiş olabilir. Bazı siteler için site yenilemek keyfi bir tasarım hevesi değil, ertelenemeyecek bir ihtiyaçtır.
Ama burada iki ayrı cümle var.
Birincisi, “eski siteyi değiştirmeliyiz.”
İkincisi, “yerine koyduğumuz sitenin içindeki yüzlerce karar doğru.”
İlki doğru olduğunda ikincisi kendiliğinden doğru olmuyor.
Bu ayrım ilk bakışta çok basit görünüyor. Ama site yenileme projelerinde ikisini birbirine karıştırmak kolay. Eski sitenin sorunları görünür, can sıkıcı ve herkes tarafından bilinir. Yeni sitenin sorunları ise henüz yaşanmadığı için görünmez. Hazırlanan tasarım temiz görünür. Yeni teknoloji daha hızlıdır. Yeni metin daha iyi yazılmıştır. Bütün bunlar, yeni sitenin gerçekten daha iyi çalışacağına dair makul bir beklenti yaratır.
Makul beklenti ile kanıt aynı şey değil.
Küçük fikirler konusunda neden bu kadar temkinliyiz?
Kohavi ve çalışma arkadaşlarının Microsoft'taki büyük ölçekli deneyler üzerine çalışması, test edilen fikirlerin yalnızca yaklaşık üçte birinin hedeflediği metrikleri iyileştirdiğini aktarıyor. Bu oranı alıp “site yenilemelerinin üçte biri başarılı olur” diye kullanmak yanlış olur. Araştırma, Microsoft ürünlerindeki fikirlerden ve bu fikirler için önceden belirlenmiş metriklerden söz ediyor.
Yine de önemli bir şeyi gösteriyor: Deneyimli ekiplerin mantıklı bulduğu fikirler sık sık beklenen sonucu vermiyor. Çalışmanın kendisi tam da bu nedenle değerli. Sezginin kötü olduğunu söylemiyor. Sezginin, kullanıcı davranışı hakkında tek başına yeterli bir karar standardı olmadığını söylüyor.
Küçük bir testte yanıldığınızda, en azından neyin işe yaramadığını öğrenme şansınız vardır. Büyük bir site yenilemesinde bu şans aynı ölçüde kalmıyor.
Çünkü site yenilemesi bir noktadan sonra araştırılan bir fikir gibi değil, tamamlanması gereken bir iş gibi davranılmaya başlanıyor. Gereksinimler yazılıyor, tasarım onaylanıyor, geliştirme başlıyor, yayına alma tarihi konuyor. Sonra soru değişiyor: “Bu daha iyi mi?” yerine “Ne zaman bitecek?” deniyor.
Bir web sitesini yenilediğinizde aslında neyi değiştirmiş oluyorsunuz?
Bir butonun metnini değiştirdiğinizde neyi test ettiğiniz bellidir.
Bütün web sitesini değiştirdiğinizde ise ortada tek bir değişiklik yoktur. Kullanıcının gördüğü tasarım değişir. Ama onunla birlikte bilgi mimarisi, sayfa hiyerarşisi, metinler, görseller, formlar, URL'ler, analitik olaylar, çerez izin davranışı, reklam dönüşümleri, CRM alanları ve farklı entegrasyonlar da değişebilir.
Yeni site daha iyi sonuç verirse hangi kararın işe yaradığını bulmak zorlaşır. Yeni site daha kötü sonuç verirse de neyin kırıldığını bulmak zorlaşır.
Diyelim ki form gönderimleri düştü. Kullanıcılar yeni formu mu daha az anladı? Formdaki bir alan mı fazla geldi? Safari'de çalışan bir doğrulama mı bozuldu? Google Ads dönüşümü mü kayboldu? CRM'e veri gönderen bağlantı mı sessizce hata vermeye başladı?
Birkaç ayda hazırlanan bu paketi tek gecede açtığınızda, soruların hepsi aynı anda geliyor.
Buradaki sorun yalnızca risk değil. Yeni site iyi gitse bile neden iyi gittiğini; kötü giderse de nereden başlayıp düzelteceğimizi öğrenmek zorlaşıyor.
Web sitesini yenilemek, tasarım işi kadar taşıma işidir
Araştırmada bunu en açık biçimde Google'ın site taşıma rehberinde gördüm.
Google, alan adı, içerik yönetim sistemi ve sayfa düzeni değişikliğini aynı anda yapmamayı öneriyor. Mümkünse geçişi parçalara bölmeyi; URL eşlemesi, yönlendirmeler, canonical etiketleri, robots kuralları, site haritası ve site içi bağlantılar gibi alanları ayrı ayrı kontrol etmeyi istiyor. Resmi migration rehberi bunu oldukça açık anlatıyor.
Bu tavsiyeyi yalnızca SEO tavsiyesi gibi okumamak gerekiyor.
Web sitesini yenilemek, güzel görünmeyen eski bir tasarımı yenisiyle değiştirmekten ibaret değil. Aynı zamanda bir taşıma işi. Eski sistemin çalıştırdığı pek çok şeyi yeni sisteme fark ettirmeden taşımaya çalışıyorsunuz.
Bir yönlendirme unutulabilir. Yapılandırılmış veri kaybolabilir. Analitik bir olay çalışmayabilir. Çerez izin davranışı değişebilir. Bir formdan gelen kaynak bilgisi CRM'e ulaşmayabilir. Bunların her biri tek başına küçük hata gibi görünür. Hepsi aynı anda olduğunda, yeni sitenin “daha iyi” olup olmadığını anlamayı neredeyse imkânsız hâle getirebilir.
Yazılımda yaptığımız şeyi site yenilerken neden yapmıyoruz?
Yazılım ekipleri büyük değişiklikleri canlı ortama alırken yıllardır aynı dersi öğreniyor: Test ortamı, gerçek hayatın tamamı değildir.
Bu yüzden değişikliği önce küçük bir kullanıcı grubunda açmak, trafiği kademeli olarak artırmak ve gerekirse geri almak gibi yöntemler var. Bir şey ters giderse bütün kullanıcıları aynı anda etkilemeden durdurabilirsiniz.
Google SRE'nin canary yaklaşımı bu fikri basit biçimde anlatıyor: Değişiklik büyüdükçe, bir şey ters giderse etkilenecek kullanıcı sayısını küçültmeye çalışıyorsunuz.
Bir web sitesini yenilemekle arka uçtaki bir değişikliği yayına almak aynı şey değil. Arka uçtaki bir hatayı hata oranı veya gecikme süresi üzerinden kısa sürede görebilirsiniz. Yeni bir site içi gezinme düzeninin, marka algısının veya organik görünürlüğün etkisi daha yavaş ortaya çıkar. Bazen kullanıcılar yeni tasarım kötü olduğu için değil, alışkanlıkları bozulduğu için tepki verir.
Bu yüzden “her site yenilemesini iki varyant hâlinde aylarca çalıştırın” gibi kolay bir sonuç yok.
Ama SRE tarafındaki düşünceyi tamamen bir kenara bırakmak da doğru değil. Canlı ortamda neyle karşılaşacağınızı önceden tam olarak bilmiyorsanız, bütün kullanıcı deneyimini tek gecede değiştirmek neden varsayılan seçenek olsun?
Bu, her site yenilemesinin A/B testi gerektirdiği anlamına gelmiyor
Bazı değişiklikler parça parça yapılamaz.
Yeni arka uç eski ön yüzü desteklemiyor olabilir. Bilgi mimarisi birbirine o kadar bağlı olabilir ki, yalnızca menünün bir bölümünü değiştirmek anlamsız kalabilir. Marka konumlandırması iki farklı görsel kimliği aynı anda yaşatmayabilir. Düşük trafikli bir B2B sitenin, küçük farkları A/B testle anlaması aylar sürebilir.
Bunların her biri gerçek bir karşı argüman.
Ayrıca kısa vadeli veri her zaman doğru cevabı vermez. Google Drive ve Spotify'ın büyük arayüz değişimleri üzerine yapılan çalışmalar, kullanıcıların değişime gösterdiği ilk tepkinin yanıltıcı olabileceğini gösteriyor. Yeni deneyim daha iyi olsa bile, insanlar önce eski alışkanlıklarını arayabiliyor. Google Drive vakası ve Spotify'ın çalışması bunu daha dikkatli ele almak gerektiğini hatırlatıyor.
O yüzden buradan “site yenilemeyin” sonucu çıkmıyor.
Daha gerçekçi olan, site yenilemesini üç ayrı iş gibi düşünmek.
İlki, kararın kendisi: Neyi iyileştirmeye çalışıyoruz? Dönüşüm oranı mı, konumlandırma mı, erişilebilirlik mi, teknik borç mu?
İkincisi, taşıma: URL'ler, SEO sinyalleri, ölçüm altyapısı, formlar ve entegrasyonlar gerçekten taşındı mı?
Üçüncüsü, kademeli açılış: Yeni deneyimi kim, ne zaman görecek? Ne kötü giderse duracağız? Geri dönüş mümkün mü?
Yüksek trafikli bir SaaS veya e-ticaret ürünü, belirli kullanıcı gruplarıyla kademeli açılış ve bir kontrol grubu kullanabilir. Düşük trafikli bir lead toplama sitesi için ise mevcut metrikleri kaydetmek, analitik olayların eşliğini doğrulamak, tarama karşılaştırması yapmak, form ve CRM'i test etmek, küçük bir pilot grupla başlamak ve yayından sonra sıkı takip daha gerçekçidir.
Her sitenin kullanacağı araç farklı olabilir. Asıl mesele, yayına alma kararını vermeden önce hangi soruya cevap aradığınızı ve neyin bozulduğunu nasıl anlayacağınızı bilmek.
Hazır olmak ile daha iyi olmak
Site yenileme projelerinde “hazır” kelimesi çoğu zaman tartışmayı erken bitiriyor.
Tasarım hazır olabilir. Sayfalar hazır olabilir. Yeni içerik yönetim sistemi hazır olabilir. İçerikler girilmiş, yönlendirmeler yazılmış, yayına alma tarihi yaklaşmış olabilir.
Hazır olması, daha iyi olduğu anlamına gelmiyor.
Bu yüzden büyük bir site yenileme projesinde yalnızca “yeni site hazır mı?” diye sormak yetmiyor. Sormamız gereken soru şu:
Yeni siteyi eskisinden daha iyi olduğu için mi yayına alıyoruz, yoksa artık yayına almak zorunda olduğumuz bir projeye dönüştüğü için mi?
Bir butonu değiştirirken istediğimiz kanıt, bütün web sitesini değiştirdiğimizde ortadan kalkmıyor. Tam tersine, yanlış çıkmasının bedeli büyüyor.
