Kullanıcı Odaklı Geliştirme: Özellik Eklemek ile Mevcut Sistemi Onarmak
Sektörün olgunlaştığı, artık özellik yarışı yerine mevcut sistemleri iyileştirmeye geçildiği sık söylenir. Sürüm notlarına bakınca bunun pek karşılığı yok: liste eklenen şeylerle dolu, düzeltilenler en altta tek satır. Kullanıcı odaklılık kendiliğinden gelen bir olgunlaşma değil, her sürümde yeniden verilen bir karar.
Optimizasyona dönüş çoğu zaman erdemden gelmez
Bir ekip mevcut sistemi iyileştirmeye ağırlık veriyorsa, arkasında genelde kullanıcıya duyulan yeni bir saygı değil, daralmış bir bütçe ya da küçülmüş bir ekip vardır. Kullanıcı açısından sonuç aynı yere çıktığı için gerekçeyi dert etmeye gerek yok. Dert edilecek olan şu: kısıt kalkınca aynı ekip özellik listesine geri döner. "Artık kullanıcıya odaklanıyoruz" cümlesini kalıcı bir dönüşüm olarak okumak fazla iyimser.
Her hata aynı ağırlıkta değil
Hatalı çalışan yazılımın kullanıcıda yanlış bir zihinsel model kurduğu doğru, ama bu her hata için aynı ölçüde geçerli değil. Her seferinde aynı biçimde patlayan bir işlev kullanıcıyı yalnızca engeller; kullanıcı onu bir kez öğrenir, etrafından dolaşır. Asıl zarar veren, yirmi denemenin birinde sessizce başarısız olan kaydetme işlemi gibi kararsız hatalardır. Kullanıcı buradan bir kural çıkaramaz, onun yerine bir ritüel geliştirir: kaydettikten sonra sayfayı yenileyip kontrol etmek. O ritüel, siz hatayı düzelttikten aylar sonra bile sürer. Bu yüzden bir hatanın maliyetini "kaç kullanıcıyı etkiliyor" ile ölçmek eksik kalıyor. Daha iyi ölçü şu: kullanıcıya hangi yanlış alışkanlığı öğretti?
"Hızlandırdık" ölçüsüz bir iddia
Optimizasyon anlatılırken en sık atlanan şey, hız kazancının doğrusal hissedilmemesi. Jakob Nielsen'in yanıt süresi eşikleri hâlâ geçerli: 0,1 saniyenin altı anlık hissedilir, 1 saniyeye kadar kullanıcının akışı korunur, 10 saniyeden sonra zaten başka işe geçmiştir. Yani 320 milisaniyeyi 210'a çekmenin kullanıcı tarafında karşılığı yok denecek kadar azdır; aynı emeği 4 saniyelik bir ekranı 900 milisaniyeye indirmek için harcarsanız fark edilir. Optimizasyon bütçesi ortalama yanıt süresine değil, eşiğin yanlış tarafında kalan ekranlara gider.
Yeniden yazmak mı, onarmak mı
Aynı süreyi sıfırdan yazmaya değil, mevcut sistemin hata listesini kapatmaya harcamayı daha güvenilir buluyorum. Sebebi duygusal değil: çalışan bir sistemin içinde, hiçbir şartnamede yazmayan onlarca uç durum çözümü birikmiştir. O bilgi kodun kendisinde ve eski hata kayıtlarında durur, kimsenin kafasında değil. Sıfırdan yazan ekip birikimi de siler ve aynı uç durumları iki yıl boyunca yeniden keşfeder. Yeniden yazmanın gerçekten haklı olduğu durum, sorunun tek tek hatalarda değil veri modelinde olmasıdır; orada onarım her seferinde bir öncekinin üstüne yama koymaya dönüşür.
Kullanıcı odaklılık söyleminin kendi çelişkisi
Bu tartışmada iki cümle çoğu zaman yan yana söylenir: yenilik kullanıcının adapte olabileceği hızda ilerlemeli, ve bilgi yükünü azaltacak yeni nesil bir işletim sistemi acilen gerekli. İkisi aynı anda savunulamaz. İşletim sistemi değişimi bir kullanıcının karşılaşabileceği en pahalı adaptasyon maliyetidir; dosya bulma, arama, pencere düzeni, bildirim yönetimi gibi yıllarda oturmuş alışkanlıkların hepsini birden sıfırlar. Bilgi yükü sorunu gerçekten varsa çözümü yeni bir katman eklemek değil, mevcut katmanlardan birini kaldırmak. Kullanıcı odaklı geliştirme çoğunlukla eksiltme işidir; eklenen her şey iyi niyetli olsa bile öğrenilmesi gereken bir şey daha demektir.