Konu Başlıkları
Yükleniyor...

Antisipatif Tasarım İşletmelerde Neden Tutmuyor

Antisipatif tasarımda hata maliyeti ve kullanıcı onayının yeri

Antisipatif tasarım, kullanıcı talebini iletmeden ihtiyacını karşılamayı hedefler. Vaat güçlü, sahadaki karne zayıf. Digit, Mint ve LifeBEAM Vi Sense gibi örnekler tahmin teknolojisi yetersiz kaldığı için değil, yanlış tahminin bedelini kullanıcıya ödettikleri için tökezledi.

Asıl sorun isabet oranı değil, hatanın bedeli

Bir öneri sistemi konuşulurken ilk sorulan şey isabet oranı olur. Yanlış soru. Yüzde 95 isabetle çalışan ve kullanıcı adına günde 20 kez harekete geçen bir sistem, günde ortalama bir yanlış iş yapar. Kullanıcı 19 doğru tahmini fark bile etmez, hesabından habersiz çekilen parayı aynı gün fark eder.

Tahmin hatası iki yöne eşit dağılmaz. Sistem harekete geçmesi gerekirken geçmezse kullanıcı küçük bir gecikme yaşar, geçmemesi gerekirken geçerse geri alınması zor bir sonuç doğar. Tek bir isabet yüzdesi bu iki durumu aynı kefeye koyar, o yüzden ölçerken ikisini ayrı sayın.

Üç örnek, tek desen

  • Digit: kullanıcının nakit akışını yanlış modelleyip hesaptan otomatik para çekti, düzeltmek kullanıcının işi oldu.
  • LifeBEAM Vi Sense: kişisel koç vaat etti, herkese benzeyen genel tavsiyeler verdi.
  • Mint: bütçe önerisini kullanıcının kendi hedefine değil ortalama davranışa göre kurdu.

Üçünde de kararı sistem verdi, sonucu kullanıcı taşıdı. Amazon ve Netflix tarafındaki öneri motorları hâlâ ayakta, çünkü orada yanlış tahminin bedeli bir kaydırma hareketinden ibaret. Aynı algoritma sınıfı, çok farklı sonuç.

Onay istemek vaadi çürütür mü?

Kullanıcıya danışın tavsiyesi ilk bakışta antisipatif tasarımın kendi sözüyle çelişir. Sıfır efor vaat edip her adımda onay kutusu çıkarırsanız elinizde yavaş çalışan bir sihirbaz kalır. Ayrım eylemin geri alınabilirliğinde: geri alınabilen şeyi sessizce yapın, geri alınamayanı sorun. Para transferi, dışarıya giden mesaj, iptal edilen randevu sorulur; liste sıralaması, ön yükleme, taslak hazırlama sorulmaz.

Bir projede öneri motorunun yüksek güven skoru verdiği aksiyonları kullanıcıya sormadan uygulattık, iki hafta sonra ürünün en çok tıklanan bileşeni geri al düğmesiydi.

Onay kutusunu tamamen kaldırmak isteyen ekipler için ara yol var: eylemi yap, ama geri almayı bir tıka indir ve bunu görünür tut. Bildirimin içinde duran geri al bağlantısı, önceden sorulan onaydan daha az sürtünme yaratır ve hata maliyetini yine sıfıra yaklaştırır.

Tahminden çok geri planlama işe yarar

Forecasting geçmiş davranışa bakar ve bir sonraki adımı tahmin eder. Sorun şu ki kullanıcının ulaşmak istediği yer geçmiş davranışında yazmıyor. Borcunu kapatmaya çalışan biriyle harcamasını sürdüren biri aynı işlem geçmişini üretebilir, ikisine aynı öneri gitmemeli.

Backcasting bunu tersinden kurar: hedefi kullanıcıdan al, oraya giden yolu geriye doğru çöz, sistem de o yolun adımlarını önersin. Hedefi bir kez sormak, davranıştan yıllarca tahmin etmeye çalışmaktan ucuz. Delphi gibi uzman görüşü teknikleri de trend belirlemede işe yarar, ama bunu tasarım kararının merkezine koymayın; birkaç uzman görüşü, iki hafta çalışan bir onay akışı kadar bilgi vermez.

Sıra dışı senaryoları da baştan listeleyin. Tahmin modelleri ortalama kullanıcıda iyi çalışır, sistemi batıran hep kenar durumlar olur: hesabı ortak kullanan aile, tatilde harcaması ikiye katlanan kullanıcı, cihazını başkasına veren kişi.

Kaynaklar