Çözüm Tasarımı ve Öncelik

Açılış sahnesi

Aydın'da zeytinyağından krem ve sabun üreten bir markanın internet mağazasında çalışan üç kişi, engel haritasını tamamlamış ve ürün sayfasında bir bilgi boşluğu bulmuş: müşteriler kremlerin hangi cilt tipine uygun olduğunu bilmiyor. Tasarımcı ertesi gün yeni bir ürün sayfası taslağı getiriyor. Sayfa baştan sona yenilenmiş: yeni fotoğraflar, yeni renkler, bir cilt tipi testi, bir video, müşteri yorumları için yeni bir düzen ve daha büyük bir satın al düğmesi.

Taslak herkesin hoşuna gidiyor. Ama dönüşüm sorumlusu bir soru soruyor: bu değişikliklerin hangisi, haritadaki hangi soruna cevap veriyor? Cilt tipi testi bilgi boşluğuna dokunuyor; ama yeni renkler, yeni fotoğraflar ve büyük düğme hangi kanıta dayanıyor? Bir de şu var: bütün bu değişiklikler aynı anda yayına alınırsa ve dönüşüm değişirse, hangisinin işe yaradığını nasıl bileceğiz?

Ekip taslağı bir kenara koyuyor ve baştan başlıyor. Bu kez her değişikliğin yanına bir satır yazılıyor: hangi soruna dayanıyor, o sorunu gösteren kanıt nerede ve müşterinin davranışını neden değiştirecek? Satırı doldurulamayan değişiklikler taslaktan çıkıyor. Geriye kalan, çok daha küçük ama her parçası bir sorunla bağlantılı bir tasarım.

Bu derste ne olacak

Kozmetik sitesinin tasarımcısı iyi bir sayfa çizmişti, ama sayfa bir sorunun çözümünden çok, yeni bir zevk önerisiydi. Değişikliklerin çoğu hiçbir kanıta dayanmıyordu; birlikte sınanırlarsa hiçbiri tek başına öğrenilemezdi. Siteyi de dersteki öbür markaları da hayal gücüyle kurduk. Bir çözüm taslağında kaç değişikliğin bir arada sınanabileceği için bir sayı vermiyorum; bu, değişikliklerin birbirine ne kadar bağlı olduğuna ve sitenin trafiğine göre değişir.

Önceki derste engelleri türlerine göre bir haritaya yerleştirdik. Bu ders o haritadan çözüm tasarlamayı ele alıyor: her çözümü bir kanıta bağlamayı, çözüm fikirlerini yaygın kullanılabilirlik ilkeleriyle beslemeyi, çözümü tam olarak geliştirmeden önce kaba bir prototiple sınamayı ve bir çözümün başka yerlerde yaratabileceği yan etkileri önceden taramayı.

Sıfır noktası

Bu derste elimizde olacak araçların çoğu daha önce kuruldu. Bir değişikliği sınamadan önce aranan sorun kanıtı, fırsat büyüklüğü ve test kuyruğu e-ticaret biriminden; büyüme hipotezi, davranış kaldıracı, çözüm yelpazesi ve öncelik puanı büyüme temellerinden; ayırt edici varyant deney kursundan; kullanılabilirlik testi, sorun şiddeti ve engel haritası da bu kurstan geliyor. Bir yenilik kötüleştirmesin diye izlenen koruyucu ölçüt ise metin biriminde tanımlanmıştı.

Büyüme temellerinde fikirleri bir havuzda toplayıp bir hipotez cümlesiyle yazmayı, e-ticaret biriminde de bir dönüşüm testine başlamadan önce sorun kanıtını aramayı öğrenmiştik. Dönüşüm optimizasyonunda çözüm tasarımı bu iki alışkanlığı birleştirir: her değişiklik, engel haritasında bir hücreye ve o hücreyi gösteren bir kanıta bağlanır. Ardından çözüm, kullanıcılara kabaca sınatılır, olası yan etkileri düşünülür ve ancak ondan sonra deney kuyruğuna girer. Bu sıra, tasarım ekibinin yaratıcılığını kısıtlamaz; yaratıcılığı, kanıtlanmış bir sorunun etrafında toplar.

Mekanizma — her değişikliği bir kanıta bağlamak

Bir çözüm taslağı çoğu zaman birçok değişikliği bir arada taşır. Bu değişikliklerin bazıları bir soruna dayanır, bazıları ise tasarımcının zevkine, bir rakibin sayfasına ya da genel bir iyileştirme isteğine. İkinci türden değişiklikler, sınandıklarında neyi öğrettiklerini söyleyemez.

Rakibin sayfası, kanıt değil.

İz, deneyin kapsamını belirliyor.

Mekanizma — çözümü yaygın ilkelerle beslemek

Her dönüşüm sorunu yeni değildir. Kullanıcıların arayüzlerde nerede zorlandığına dair yıllardır birikmiş, sektörde yaygın olarak kabul gören ilkeler vardır. Bir çözüm tasarlanırken bu ilkelerden yola çıkmak, sıfırdan fikir üretmekten daha hızlıdır ve daha az hataya açıktır.

Hatırlamak yerine görmek.

Tutarlılık, beklentiyi koruyor.

Mekanizma — geliştirmeden önce kaba bir sınama

Bir çözümü tam olarak geliştirip deneye almak zaman ve emek ister. Bazı çözümler ise ilk kullanıcıyla karşılaştıkları anda yanlış anlaşılır. Çözümü tam olarak geliştirmeden önce kaba bir hâliyle birkaç kullanıcıya göstermek, en belirgin hataları ucuza yakalar.

Prototip, pahalı bir hatayı önlüyor.

Prototip, dönüşümü ölçmüyor.

Usta katmanı — çözümün yan etkilerini önceden taramak

Bir dönüşüm adımını iyileştiren bir çözüm, başka bir adımı, başka bir grubu ya da başka bir ekibi etkileyebilir. Bir bilgi eklemek sayfayı uzatabilir, bir güvence iptalleri artırabilir, bir sadeleştirme bazı müşterilerin ihtiyaç duyduğu seçeneği gizleyebilir. Bu yan etkiler deneyden sonra görülür; ama çoğu, önceden düşünülürse tahmin edilebilir.

Güvence, operasyonu etkileyebiliyor.

Sadeleştirme, bazı müşterileri dışarıda bırakabiliyor.

Yan etki, başka bir ekibin masasında.

Yaygın hatalar

Aklında kalsın

Çözüm tasarımı, engel haritasındaki bir sorunu, o sorunu gösteren kanıtı ve müşterinin davranışını değiştirecek bir değişikliği birbirine bağlar. Yaratıcılık, kanıtlanmış bir sorunun etrafında toplanır.

Kanıt izi, bir çözümdeki her değişikliğin hangi soruna ve hangi kanıta dayandığının yazılmasıdır. İzi olmayan değişiklik taslaktan çıkar; izleri farklı sorunlara giden değişiklikler ayrı sınanır.

Kullanılabilirlik ilkesi, arayüz tasarımında yaygın olarak kabul gören genel kurallardır: görünürlük, tanıdık dil, hata önleme, geri alınabilirlik, tutarlılık ve hatırlamak yerine görmek. İlke bir çözümün biçimini verir, doğruluğunu kanıtlamaz.

Prototip sınaması, bir çözümün tam olarak geliştirilmeden önce kaba bir hâliyle birkaç kullanıcıya gösterilmesidir. Anlaşılmayan çözümleri ucuza ayıklar, ama dönüşüme etkisini ölçmez.

Yan etki taraması, bir çözümün başka adımlar, gruplar ve ekipler üzerindeki olası etkilerini deneyden önce düşünmektir. Taramadan çıkan riskler, deneyin koruyucu ölçütlerine dönüşür.

Sonraki derse köprü

Bu derste çözümü kanıta bağladık: kanıt izi, kullanılabilirlik ilkesi, prototip sınaması ve yan etki taraması. Kök Kahve'nin üç soruluk çekirdek seçimi akışı, kâğıt prototipten geçmiş ve koruyucu ölçütleriyle birlikte deney kuyruğuna girmiş durumda.

Bu kursta Kök Kahve bir kez teşhis yaptı, bir kez harita çizdi, bir kez çözüm tasarladı. Ama dönüşüm optimizasyonu bir kerelik bir proje değil. Yarın yeni bir sayfa, yeni bir ürün, yeni bir kampanya gelecek; yeni sorunlar çıkacak, yeni deneyler kurulacak. Araştırmanın ne sıklıkla yapılacağı, deneylerin nasıl kaydedileceği, öğrenilenlerin diğer ekiplerle nasıl paylaşılacağı ve bütün bunların kim tarafından sürdürüleceği belirlenmediğinde, her yeni sorun ilk kez görülüyormuş gibi ele alınır.

Sıradaki ders optimizasyon programını ele alıyor: araştırma, deney, kayıt ve paylaşım ritmini sürekli bir sisteme nasıl dönüştüreceğimizi orada göreceğiz.