Kullanıcı Deneyimi Ekosistemi: Tutarlılık, Senkronizasyon ve Test Yükü
Ekosistem yaklaşımı; siteyi, uygulamayı, e-postayı ve mağazayı tek bir sistemin parçaları olarak ele alır. İlke doğru, uygulama iki yerde tıkanıyor: tutarlılık aynılık sanılıyor, cihazlar arası veri akışı ise tasarım toplantısında konuşulup altyapı tarafında çözülmeden bırakılıyor. İkisinin de kaynağı aynı: tasarım kararının uygulamaya ne mal olduğunun hesaplanmaması.
Ekosistem, ürünlerin toplamı değil
Bir marka kullanıcısıyla tek bir yerde karşılaşmıyor. Arama sonucu, uygulama bildirimi, destek e-postası, kasadaki ekran; hepsi aynı ilişkinin parçası. Ekosistem yaklaşımı bunları ayrı projeler olarak değil, ortak bir veri modeli ve ortak bir dil üzerinden konuşan parçalar olarak kurmak demek.
Kurgunun üç ayağı var: kullanıcılar, üzerinde çalıştığı teknoloji ve ikisi arasında dolaşan bilgi. Pratikte en çok ihmal edileni sonuncusu. Arayüzler ayrı ekiplerce güzelce tasarlanır, aynı müşterinin adresi üç sistemde üç farklı biçimde durur ve kullanıcı bunu ilk siparişte fark eder.
Tutarlılık, aynılık demek değil
Ekosistem yazılarının çoğu “her temas noktasında aynı deneyim” der. Bu cümle olduğu gibi uygulanırsa zarar verir. iOS’ta geri hareketi ekranın kenarından sürüklemektir, Android’de sistemin kendi geri davranışı vardır, web’de tarayıcı geçmişi işler. Aynı navigasyon bileşenini üçüne birden aynen taşıyan tasarım tutarlı olmaz; üç platformda da yabancı durur.
Sabit kalması gereken şey etkileşimin biçimi değil. Terminoloji, veri, durum adları ve marka dili sabit kalır. Kullanıcının uygulamada “bekleyen sipariş” olarak gördüğü kayıt web’de “işlemde” görünüyorsa sorun kelime tercihi değil, iki ekibin aynı duruma farklı isim vermesidir. Bunun çözümü ortak bir durum sözlüğü, tasarım rehberine eklenen bir sayfa değil.
“Anında senkronize olur” cümlesinin kodda karşılığı
Ekosistem vaadinin en kırılgan yeri burası. Kullanıcı telefonda sepete ürün ekler, uçakta tabletinde aynı sepetten bir ürün siler, ikisi de çevrimdışıdır. Bağlantı geri geldiğinde iki farklı sepet durumu sunucuya birden ulaşır. Ne olacağına önceden karar verilmemişse en son yazan kazanır ve kullanıcının bir işlemi sessizce kaybolur.
Çakışma kuralı ürün kararıdır, sonradan eklenecek bir teknik ayrıntı değil. Sepette birleştirme mantıklıdır; yarım kalmış bir form taslağında “iki sürüm var, hangisini tutalım” diye sormak daha dürüsttür; ödeme adımında ikinci isteği reddetmek tek doğru davranıştır. Sıralamayı tek bir sunucu saatine bağlamayı, istemcilerin kendi saatine güvenen çözümlerden belirgin biçimde güvenilir bulurum; kullanıcının telefonundaki saat yanlışsa kaybolan kaydı kimse geri getiremiyor.
Test yükü doğrusal büyümüyor
Ekosistem büyüdükçe kontrol edilecek yüzey de büyüyor, üstelik toplayarak değil çarparak. Dört platform, beş kritik akış ve iki oturum durumu (giriş yapmış, yapmamış) kırk senaryo eder. Beşinci platform eklendiğinde sayı elliye çıkar. Listeye tek bir kritik akış eklemek ise bir kerede on senaryo getirir.
“Tüm ekosistemi test edin” tavsiyesi bu yüzden tek başına işe yaramaz. Akışları önceliklendirmek gerekir: para hareketi, hesap erişimi, cihaz değiştirerek devam etme. Geri kalanı platform başına tek bir duman testiyle geçilebilir. Bu ayrımı yapmayan ekipler her sürümde her şeyi kısmen test eder, hiçbirini tam etmez.
Başlarken üç adım
- Kullanıcının cihaz değiştirdiği anları listele. Ekosistem sorunları neredeyse tamamen bu geçişlerde çıkıyor.
- Aynı nesnenin (sipariş, üyelik, sepet) her sistemdeki adını ve durum kümesini tek bir tabloya yaz. Farklılıklar orada görünür hale gelir.
- Her kritik akış için çakışma davranışını yazılı hale getir: birleştir, sor, reddet.
Ekosistem tasarımı çoğu şirkette strateji sunumu olarak kalıyor. Sunumun işe yarayan kısmı bu üç maddeyle başlıyor; tutarlı marka dili de, kesintisiz geçiş de bunların üstüne kuruluyor.
Kaynaklar