Arayüz Değişikliği: Ne Zaman Değer, Ne Zaman Zarar

Arayüz yenilemelerinin gerekçesi çoğu zaman "tasarım eskidi" oluyor. Bu bir gerekçe değil, bir his. Kullanıcı tarafında ise durum daha somut: çalışan bir alışkanlık bozuluyor ve yerine gelenin daha iyi olduğunu kanıtlama yükü sizde.

Değişimin faturasını kullanıcı öder

Bir arayüzü düzenli kullanan insan, o arayüzü okumayı bırakır. Düğmenin nerede olduğunu hatırlamaz, eli oraya gider. Üç tıklamalık bir işi düşünmeden yapan bu kullanıcı, yerleşim değiştiğinde okumaya geri döner ve aynı işi iki katı sürede tamamlar.

Bu maliyet geçicidir, doğru. Ama kimin ödediğine bakmak gerekir: ürünü en çok kullananlar, yani alışkanlığı en derin olanlar. Yeni tasarımdan en çok şikâyet edenlerin en sadık kullanıcılar çıkması tesadüf değil, matematiğin kendisi.

Buradan çıkan sonuç "hiç değiştirmeyin" değil. Değişikliğin bir problemi çözmesi gerekir: ölçülmüş bir terk oranı, destek ekibine sürekli gelen aynı soru, yeni bir özelliğin mevcut düzene sığmaması. Görsel tazelik bu listede yok.

Kademeli geçiş her zaman daha yumuşak değil

Standart tavsiye şudur: büyük değişikliği parçalara böl, tek seferde şok yaşatma. Bu tavsiyenin sessizce atladığı bir şey var. Yenilemeyi altı sürüme yayarsanız kullanıcı bir kez değil altı kez adapte olur, üstelik aradaki her ara durumda yarısı eski yarısı yeni bir arayüzle çalışır. O ara durumların hiçbiri tasarlanmamıştır; kimse "eski tablo düzeni + yeni filtre çubuğu" kombinasyonunu masaya yatırıp test etmez.

Ayrım şurada: değişiklik birbirinden bağımsız ekranlara dağılıyorsa kademeli gitmek mantıklı, çünkü kullanıcı bir ekranı öğrenirken diğeri yerinde duruyor. Tek bir akışın içindeki yerleşim değişiyorsa bölmeyin. O akışı yarım yenilemek, kullanıcıyı iki farklı mantık arasında gidip gelmeye zorlar ve şikâyetler tam da bu ara dönemde patlar.

Yeni tasarımı ölçerken düşülen tuzak

Yenilemeden sonraki ilk hafta verisi neredeyse her zaman kötüdür. Tamamlama süreleri uzar, destek talepleri artar, bazı metrikler düşer. Bu veriyi "tasarım başarısız" diye okumak yaygın bir hata; gördüğünüz şey büyük ölçüde adaptasyon gürültüsü.

Ters tarafı da var. Bekleyip iki ay sonra baktığınızda rakamlar toparlanmış olur, ama bu da tasarımın iyi olduğunu göstermez: insanlar her düzene sonunda alışır. Yani hem erken hem geç ölçüm yanıltıyor.

Bu ikilemden çıkmanın pratik yolu, mevcut kullanıcıyla yeni kullanıcıyı ayırmak. Ürünü ilk kez açan birinin öğrenilmiş alışkanlığı yok, dolayısıyla onun tamamlama oranı eski ve yeni tasarım arasında doğrudan karşılaştırılabilir. Mevcut kullanıcı grubunda ise tek anlamlı soru, adaptasyon eğrisinin ne zaman eski seviyeye döndüğü. Dönmüyorsa sorun gürültü değildir.

Keşfi teşvik etmek adına yer değiştiren düğmeler

"Kullanıcı arayüzü keşfetsin diye ara sıra şeyleri oynatıyoruz" fikrini pek inandırıcı bulmuyorum. Keşif, kullanıcının bir ihtiyacı olduğunda gerçekleşir; ihtiyaç yokken taşınan düğme keşif değil, arama üretir. Rozet ve sürpriz içerik gibi öğeler de boşlukta çalışmaz, ancak kullanıcının zaten peşinde olduğu bir hedefi işaretlediklerinde işe yarar.

Bir özelliğin görülmediğini düşünüyorsanız önce ölçün: kaç kişi o ekrana geliyor, gelenlerin kaçı özelliği kullanıyor. İkinci sayı düşükse problem yerleşimdir. Birinci sayı düşükse arayüzü oynatmak hiçbir şeyi değiştirmez.

URL yapısı da değişiyorsa

Arayüz yenilemesi sıklıkla içerik mimarisini de değiştirir ve buradaki kayıp geri alınması en zor olanı. Her eski adres, içerik olarak en yakın yeni adrese yönlendirilmeli; toplu halde ana sayfaya atmak, arama motoru için sayfayı silmekle aynı kapıya çıkar. Yönlendirme zinciri ve döngüsü bırakmayın, dahili bağlantıları da yeni adreslere güncelleyin.

Eşleştirmeyi genelde elle hazırlanmış bir yönlendirme tablosuyla çözerim, tek bir regex kuralıyla değil. Regex kuralı yazması on dakika sürer, yanlış eşleşen kenar durumları aylarca fark edilmez; tabloda ise hangi adresin nereye gittiğini tek tek görürsünüz ve eksik kalan satır ilk kontrolde ortaya çıkar. Yenilemeden önce mevcut adreslerin listesini trafik verisiyle birlikte dökmek, bu işi bir güne indirir.

Değiştirmeye değdiği an

Bir yenilemeyi savunmanın tek sağlam yolu, çözdüğü problemi değişiklikten önce adıyla yazabilmek. Hangi ekranda, hangi kullanıcı grubunda, hangi sayıda iyileşme bekliyorsunuz. Bunu yazamıyorsanız elinizde bir tasarım kararı değil bir tercih var, ve o tercihin bedelini ürünü her gün kullanan insanlar ödeyecek.