Marissa Mayer ürün metrikleri yaklaşımının UX sürtünmesini sonuçlarla nasıl bağladığını, A/B testi disipliniyle hızı nasıl düzenlediğini ve ekiplerin kaos olmadan hızlı gönderim yapmasını nasıl sağladığını öğrenin.
Küçük UX sürtünmesi, kullanıcıların hissedip nadiren iyi tarif edebildikleri ufak şeylerdir. Bir formda ekstra bir adım olabilir, insanların duraksamasına neden olan bir buton etiketi, bir saniye fazla süren sayfa yüklemesi ya da sonraki adımı söylemeyen bir hata mesajı olabilir.
Maliyet, ölçekten gelir. Tek bir anlık kafa karışıklığı bir kişiyi bir kez etkilemez. Her ziyaretçi, her gün, huniniz boyunca tekrarlanır. Her adımda %1 düşüş, kayıtlar, satın almalar veya tekrar kullanımda anlamlı bir kayba dönüşür.
Bazı sürtünme desenleri tasarım değerlendirmesinde zararsız görünür ama sonuçlara sessizce zarar verir:
Somut bir örnek: ayda 100.000 kişinin kayıt akışına başladığını varsayın; küçük bir gecikme veya kafa karıştırıcı bir etiket tamamlamayı %30'dan %28'e çekerse, 2.000 kayıt kaybettiniz demektir. Bu, aktivasyon ve tutundurma etkileri hesaba katılmadan önce; bu alanlarda fark genellikle daha da büyür.
Bu yüzden sadece görüş yeterli değildir. Güçlü ürün ekipleri “bu sinir bozucu” hissini ölçülebilir bir soruya çevirir, sonra disipliniyle test eder. Kaos olmadan sık gönderebilirsiniz, ama hız kanıtla bağlantılı kaldığı sürece.
İnsanlar “Marissa Mayer tarzı” ürün liderliğinden bahsederken genellikle belirli bir alışkanlığı kastediyorlar: ürün kararlarını tartışma değil, test edilebilir sorular olarak ele almak. Kısa adı Marissa Mayer ürün metrikleri: küçük UX seçimlerinin bile ölçülmesi, karşılaştırılması ve kullanıcı davranışı mücadelesini gösterdiğinde tekrar gözden geçirilmesi gerektiği fikri.
Buradaki işe yarayan taraf kişilik veya mitoloji değil. Pratik bir zihniyettir: kullanıcı deneyimini temsil eden küçük bir sinyal seti seçin, temiz deneyler yürütün ve öğrenme döngülerini kısa tutun.
Ölçülebilir UX, “bu akış sinir bozucu” gibi bir hissi gözlemlenebilir hale getirmektir. Bir ekran kafa karıştırıcıysa davranışta görünür: daha az kişi bitirir, daha fazla kişi geri çıkar, daha fazla kullanıcı yardım ister veya görevlerin tamamlanması gerektiğinden daha uzun sürer.
Hızın bir takas olduğunu unutmayın. Kurallar yoksa hız gürültüye dönüşür. Ekipler sürekli gönderir, sonuçlar karışır ve kimse veriye güvenmez. Bu “tarz” yalnızca yineleme hızı tutarlı ölçümle bir arada olduğunda işe yarar.
Altında genellikle basit bir disiplin vardır: gönderimden önce başarıyı tanımlayın, aynı anda bir anlamlı değişiklik yapın ve rastgele dalgalanmalardan kaçınmak için testleri yeterince uzun çalıştırın.
İyi metrikler, panodaki etkileyici görünen şeyler değil, kullanıcıların gerçekten yaptıklarını tarif eder. Marissa Mayer ürün metrikleri fikri basittir: güvenebileceğiniz birkaç sayı seçin, bunları sıkça gözden geçirin ve kararları onlar şekillendirsin.
İnsanların değer alıp almadığını ve geri gelip gelmediğini gösteren küçük bir çekirdek ürün metriği setiyle başlayın:
Ardından ana akış içindeki sürtünmeyi açığa çıkaracak bir veya iki UX sağlık metriği ekleyin. Görev başarı oranı sağlam bir varsayılandır. Bunu hata oranı (insanların ne sıklıkla çıkmazla karşılaştığı) veya görev başına geçen süreyle eşleştirin.
Ayrıca önde gelen (leading) ve geride kalan (lagging) göstergeleri ayırmak yardımcı olur.
Önde gelen gösterge hızlı hareket eder ve doğru yöne gidip gitmediğinizi erken söyler. Kaydı basitleştirirseniz ve görev başarı oranı ertesi gün %72'den %85'e çıkarsa muhtemelen akışı iyileştirdiniz demektir.
Geride kalan gösterge ise uzun vadeli etkiyi doğrular, örneğin 4. haftadaki tutundurma. Bunu hemen görmezsiniz, ama gerçek değerin çoğu genellikle orada ortaya çıkar.
Görünüş metriklerine dikkat edin. Toplam kayıtlar, sayfa görüntülemeleri ve ham oturum sayıları artarken gerçek ilerleme sabit kalabilir. Bir metrik bir sonraki yaptığınız işi değiştirmiyorsa muhtemelen gürültüdür.
UX şikayetleri genellikle “Kayıt sinir bozucu” veya “Bu sayfa yavaş” gibi belirsiz hislerle gelir. Çözüm, hissi verilerle cevaplanabilecek bir soruya çevirmektir.
Seyahati gerçek şekilde çizin, akış şeması iddia ettiği gibi değil. İnsanların tereddüt ettiği, geri döndüğü veya ayrıldığı anlara bakın. Sürtünme genellikle küçük detaylarda saklıdır: kafa karıştırıcı bir etiket, ekstra bir alan, bir yükleme duraklaması veya belirsiz bir hata.
Adımdaki başarıyı basit terimlerle tanımlayın: hangi eylem olmalı, ne kadar hızlı ve ne kadar güvenilir. Örneğin:
Bir şikayeti ölçülebilir soruya dönüştürmenin pratik yolu, bariz düşüş olan bir adımı seçmek ve ardından şu gibi tek cümlelik bir test yazmaktır: “Alan X’i kaldırmak mobil kullanıcılar için tamamlama oranını Y artırır mı?”
Enstrümantasyon çoğu ekibin beklediğinden daha önemlidir. Adımı baştan sona tanımlayan eventlere ve ne olduğunu açıklayan bağlama ihtiyacınız var. Faydalı özellikler arasında cihaz türü, trafik kaynağı, form uzunluğu, hata tipi ve yükleme süresi aralıkları bulunur.
Tutarlılık, raporlamada kaosu önler. Basit bir adlandırma kuralı yardımcı olur: eventler için verb_noun kullanın (start_signup, submit_signup), her kavram için tek bir isim kullanın ("register" ve "signup" karıştırmayın), özellik anahtarlarını sabit tutun (plan, device, error_code) ve kaynak-otorite event listesini herkesin bulabileceği bir yerde dokümante edin.
Bunu iyi yaptığınızda, “Kayıt sinir bozucu” şöyle bir şeye dönüşür: “Adım 3 mobilde %22 oranında düşüşe neden oluyor, sebep parola hataları.” Bu testi yapıp düzeltebileceğiniz gerçek bir sorudur.
A/B testleri “bir şey dene ve ne olacağını gör” eylemine dönüştüğünde işe yaramaz hale gelir. Çözüm basit: her testi küçük bir sözleşme gibi ele alın. Bir değişiklik, bir beklenen sonuç, bir kitle.
Bir meslektaşınıza verebileceğiniz bir cümleyle başlayın: “Eğer X’i değiştirirsek, Z için Y iyileşir çünkü…” Bu netlik sağlar ve sonucu yorumlamayı imkansız hale getiren paketlemelerden saklar.
İlgilendiğiniz kullanıcı eylemine uyan bir birincil metrik seçin (kayıt tamamlama, ödeme tamamlama, ilk mesaj için geçen süre). Bir kazanım peşindeyken ürünü istemeden zedelememek için crash oranı, hata oranı, destek biletleri, iadeler veya tutundurma gibi küçük bir set koruyucu ölçüt ekleyin.
Süre ve örneklem büyüklüğünü pratik tutun. Yanlış zaferlerden kaçınmak için gösterişli istatistiğe gerek yok. Temel ihtiyaç, stabil sonuçlar için yeterli trafik ve belirgin döngüleri kapsamak üzere yeterli zamandır (hafta içi/hafta sonu, maaş günleri, tipik kullanım ritmi).
Her sonuçla ne yapacağınızı önceden karar verin. Bu, deneyleri sonradan hikâyeleştirmeye dönüşmekten kurtarır. Açık bir zafer yayınlanır ve izlenir; net bir kayıp geri alınır ve dokümante edilir; belirsiz sonuç ya uzatılır ya da bırakılır.
Hız, yalnızca olası zararları öngörebildiğinizde işe yarar. Hedef, küçük bir değişikliğin bir haftalık acil durumlara dönüşmemesini sağlayacak şekilde “güvenli”yi varsayılan yapmak.
Koruyucular başlangıç noktasıdır: iyileştirme peşindeyken sağlıklı kalması gereken sayılar. Gerçek acıyı erken yakalayan sinyallere odaklanın: sayfa yükleme süresi, çökme veya hata oranı ve temel erişilebilirlik kontrolleri. Bir değişiklik tıklama oranını yükseltiyorsa ama sayfayı yavaşlatıyorsa veya hataları artırıyorsa, bu bir kazanım değildir.
Uygulayacağınız koruyucuları yazılı hale getirin. Somut tutun: bir performans bütçesi, erişilebilirlik tabanı, hata eşiği ve yayın sonrası destek sinyallerini izleyecek kısa bir pencere.
Sonra etki alanını küçültün. Feature flagler ve kademeli açılımlar, değişikliği herkese zorlamadan erken gönderim yapmanızı sağlar. Önce iç kullanıcılara, sonra küçük bir yüzdeye açın; koruyucular yeşil kaldıkça genişletin. Geri alma bir anahtar olmalı, panik değil.
Ayrıca kimlerin ne gönderebileceğini tanımlamak yardımcı olur. Düşük riskli UI düzeltmeleri hafif incelemeyle hızla gidebilir. Kayıt, ödeme, hesap ayarları gibi yüksek riskli akışlar ekstra bir gözlem hakkı ve metrikler düşerse karar verecek açık bir sahip gerektirir.
Hızlı ekipler tahminle değil, küçük, tutarlı ve tekrar edilebilir döngü sayesinde hızlı hareket eder.
Bir hun içindeki bir sürtünme anıyla başlayın. Bunu tamamlama oranı veya bitirme süresi gibi sayılabilir bir şeye çevirin. Sonra sıkı bir hipotez yazın: hangi değişikliğin yardımcı olacağını düşündüğünüz, hangi sayının hareket etmesi gerektiği ve neyin kötüye gitmemesi gerektiği.
Değişikliği mümkün olduğunca küçük tutun ama anlamlı olsun. Tek bir ekran düzeltmesi, bir alan eksiltme veya daha net metin, göndermesi, test etmesi ve geri alması daha kolaydır.
Tekrarlanabilir bir döngü şöyle görünür:
Son adım sessiz bir avantajdır. Öğrenen ekipler sadece gönderen ekiplerden daha hızlı öğrenir.
Hızlı yayınlamak iyi hissettirir ama kullanıcıların başarılı olmasıyla aynı şey değildir. “Yayınladık” bizim içimizdendir. “Kullanıcılar görevi tamamladı” gerçek sonuçtur. Sadece sürümleri kutlarsanız küçük UX sürtünmesi destek biletleri, churn ve ayrılmalarda yavaşça büyürken görünmez kalır.
Pratik bir hız tanımı: bir şeyi değiştirdikten sonra gerçeği ne kadar çabuk öğrenebiliyorsunuz? Hızlı inşa ama hızlı ölçüm yoksa sadece daha hızlı tahmin ediyorsunuz demektir.
Sürekli bir ritim, ağır süreç eklemeden değişiklikleri hesap verebilir kılar:
Rakamların kör noktaları vardır; metrikler iyi görünür ama kullanıcılar rahatsız olabilir. Panoları hafif nitel kontrollerle eşleştirin. Bir avuç destek sohbetini gözden geçirin, birkaç oturum kaydını izleyin veya bir akışa odaklı kısa kullanıcı görüşmeleri yapın. Nitel notlar genellikle bir metriğin neden hareket ettiğini (veya etmediğini) açıklar.
Güveni kaybetmenin en hızlı yolu dağınık deneyler yürütmektir. Ekipler hızlı hareket eder ama hiçbir şey öğrenmez veya yanlış dersler çıkarır.
Değişiklikleri paketlemek klasik bir başarısızlık örneğidir. Yeni buton etiketi, düzen değişikliği ve onboarding adımı birlikte gönderilir çünkü verimli hissettirir. Test bir artış gösterir ve kimse nedenini söyleyemez. Tekrarlamaya çalıştığınızda “kazanç” kaybolur.
Deneyleri erken bitirmek başka bir tuzaktır. Erken grafikler gürültülüdür, özellikle küçük örneklem veya dengesiz trafik varsa. Çizgi yukarı çıktığı anda durdurmak deneyi falcılığa çevirir.
Koruyucuları atlamak gecikmiş acıya yol açar. Dönüşümü yükseltirken destek biletlerini, sayfa yüklemesini veya iadeleri artırabilirsiniz; maliyet takım zafere çoktan sevindikten sonra ortaya çıkar.
Sorun olup olmadığını görmek için basitçe sorun: yerel bir metriği optimize edip tam yolculuğu kötüleştirdik mi? Örneğin, “İleri” butonunu daha parlak yapmak tıklamaları artırabilir ama kullanıcılar gerekli alanları kaçırıp tamamlamayı düşürebilir.
Panolar faydalıdır ama insanların neden zorlandığını açıklamaz. Her ciddi metrik incelemesini biraz gerçeklikle eşleştirin: birkaç destek bileti, kısa bir görüşme veya akış kaydı izlemek gibi.
Hızlı ekipler her değişikliği açıklaması kolay, ölçmesi kolay ve geri alması kolay yaparak dramayı önler.
Yayınlamadan önce tek bir cümlede netlik zorunlu kılın: “X’i Y kullanıcıları için yapmanın Z’yi değiştireceğini düşünüyoruz çünkü…” Bunu açık yazamıyorsanız, deney hazır değildir.
Sonra ölçüm planını kilitleyin. Soruyu cevaplayan bir ana metrik ve kazara zararı önleyecek küçük bir koruyucu set seçin.
Yayınlamadan hemen önce dört şeyi doğrulayın: hipotez değişiklikle eşleşiyor mu, metrikler adlandırılmış ve bazlenmiş mi, geri alma gerçekten hızlı mı (feature flag veya bilinen geri alma planı) ve bir kişi karar tarihinden sorumlu mu?
Kayıt akışları genellikle pahalı sürtünmeyi saklar. Takımınız “Şirket büyüklüğü” gibi ek bir alan eklesin ve satış için lead nitelendirilecek bilgiyi almak istemiş olsun. Ertesi hafta kayıt tamamlama düşse, toplantelerde tartışmak yerine bunu ölçülebilir bir UX sorunu olarak ele alın.
Önce nerede ve nasıl kötüleştiğini netleştirin. Aynı kohort ve trafik kaynakları için takip edin:
Şimdi tek karar noktası olan temiz bir A/B testi yapın.
Varyant A alanı tamamen kaldırır. Varyant B alanı tutar ama isteğe bağlı yapar ve neden sorulduğuna dair kısa bir açıklama ekler.
Başlamadan önce kuralları koyun: kayıt tamamlama birincil başarı metriği; tamamlama süresi artmamalı; kayıtla ilgili destek biletleri artmamalı. Hafta içi/hafta sonu davranışını kapsayacak ve gürültüyü azaltacak kadar yeterince tamamlamaya ulaşana kadar çalıştırın.
A kazanırsa, şu an için alanın maliyeti değmeyecek demektir. B kazanırsa, açıklama ve isteğe bağlı yapmanın kaldırmaktan daha iyi olduğunu öğrendiniz. Her iki durumda da gelecekteki formlar için yeniden kullanılabilir bir kural elde edersiniz: her yeni alan yerini hak etmeli ya da kendini açıklamalı.
Kaos olmadan hız daha fazla toplantı gerektirmez. “Bu sinir bozucu” hissini hızlıca test edip öğrenebileceğiniz küçük bir alışkanlık gerektirir.
Gerçekten kullanılacak küçük bir deney bekleme listesi tutun: bir sürtünme noktası, bir metrik, bir sahip, bir sonraki eylem. Büyük bir istek listesi yerine bir avuç hazır öğe hedefleyin.
Her testi karşılaştırılabilir kılmak için bir sayfalık şablon standartlaştırın: hipotez, birincil metrik, koruyucu metrik, kitle ve süre, ne değişti ve karar kuralı.
Eğer ekibiniz Koder.ai (koder.ai) gibi platformlarda hızlı uygulamalar inşa ediyorsa, aynı disiplin daha da önem kazanır. Daha hızlı inşa daha fazla değişim miktarı demektir; bu yüzden anlık görüntüler (snapshots) ve geri alma özellikleri, denemeleri geri alınabilir tutarak metriklere göre yineleme yapmayı kolaylaştırır.
En yüksek hacimli veya en değerli akışla başla (kayıt, ödeme, yönlendirme). Kullanıcıların tereddüt ettiği veya ayrıldığı bir adım ara ve bunu nicelendir (tamamlama oranı, bitirme süresi, hata oranı). Yüksek trafikli bir adımı düzeltmek genellikle beş düşük trafikli ekranı parlatmaktan daha etkilidir.
Basit bir huni hesabı yapın:
Huni üstü büyükse 1–2 puanlık düşüş bile büyüktür.
İyi bir varsayılan set:
Sonra ana akışınıza bir ekleyin, örneğin görev başarı oranı veya hata oranı.
Bir şikayeti alıp onu ölçülebilir bir soruya çevirin:
Amaç gözlemlenebilen tek bir davranış değişikliğidir, genel bir his değil.
Adımın baştan sona izlenmesi için tutarlı event isimleri ve birkaç ana özellik takip edin.
Bir hun için asgari eventler:
start_stepview_stepSıkı tutun:
Böylece “bir sürü şeyi aynı anda gönderdik ve sonucu açıklayamıyoruz” hatası önlenir.
Normal kullanım döngülerini kapsayana kadar çalıştırın ve erken gürültüden kaçının.
Pratik bir varsayılan:
Bekleyemiyorsanız, risk azaltmak için kademeli dağıtım ve güçlü koruyucular kullanın.
Koruyucular + küçük etki alanı kullanın:
Hız, geri alma kolay olduğunda güvendedir.
Bir ana metrik seçin, sonra “ürünü bozmama” kontrolleri ekleyin.
Örnekler:
Ana metrik iyileşirken koruyucular kötüleşirse, bunun bir başarısız takas olduğunu kabul edin ve tekrar gözden geçirin.
Evet—daha hızlı üretim daha fazla değişiklik demektir, bu yüzden daha fazla disiplin gerekir.
Koder.ai üzerinde pratik yaklaşım:
Araç uygulamayı hızlandırır; metrikler hızı dürüst kılar.
submit_steperror_step (ile error_code)complete_stepFaydalı özellikler: device, traffic_source, load_time_bucket, form_length, variant.