UX Debt: Borcu Puanlamayla Değil Sabit Kapasiteyle Ödemek

UX debt, hızlı teslim etmek için verilen tavizlerin arayüzde birikmesidir. Teknik borçtan bir noktada kesin olarak ayrılır: faizini ekip değil kullanıcı öder, bu yüzden geri bildirim hem gecikir hem seyrelir. Tek tek puanlanan borç kalemleri her zaman yeni özelliklere yenilir; işleyen tek yöntem, her sprintte bu işe sabit kapasite ayırmaktır.

Faizi kim ödüyor

Teknik borcun maliyeti ekibin kendi günlük işine yansır. Build yavaşlar, testler kırılganlaşır, basit bir değişiklik üç dosyaya dokunmayı gerektirir. Bu yüzden teknik borç kendini sürekli hatırlatır.

UX borcunda böyle bir mekanizma yok. Tutarsız buton hiyerarşisi, yarım kalan hata mesajı, klavyeyle gezilemeyen bir adım geliştiricinin hızını hiç düşürmez. Bedeli kullanıcı öder, o da çoğunlukla şikâyet etmez: akışı yarıda bırakır, başka kanaldan dener ya da bir daha gelmez. Ekip tarafında hiçbir gösterge kıpırdamadığı için borcun takibi tamamen elle yapılan bir iştir. Otomatik uyarı beklemek buradaki tek gerçek hatadır.

Borç kalemi nasıl yazılır

Kalemler ölçülebilir yazılmazsa liste birkaç sprint içinde ölür. "Erişilebilirlik iyileştirilmeli" bir borç kalemi değil, bir niyet beyanıdır. Kullanılabilir hali şuna benzer: ödeme adımında doğrulama hatası basıldığında odak mesaja taşınmıyor, ekran okuyucu kullanıcısı formun başında hatayı duymadan kalıyor.

Kalemleri üç yerden toplamak yeterli:

• Destek kayıtlarında tekrar eden cümleler. Aynı soru ayda beş kez geliyorsa o arayüz anlatamıyor demektir.
• Kullanıcı testi notlarının içinde "çözüldü" diye kapatılmamış gözlemler.
• Bileşen envanteri: aynı işi yapan kaç farklı buton, kaç farklı boş durum ekranı var.

Envanter çıkarmak sıkıcı görünür ama en çok kalem buradan çıkar (işin ağır tarafı CSS'i düzeltmek değil, aynı bileşenin üç kopyasını tek yerde toplamaktır).

Etki-efor puanlaması burada tıkanır

Yaygın tavsiye, borç kalemlerini etki ve efor eksenlerinde puanlayıp yeni özelliklerle aynı backlog'da yarıştırmaktır. Bu yöntem UX borcunda çalışmaz, çünkü borcun zararı kalem başına değil toplamda ortaya çıkar. Tek bir tutarsız ikon ölçülebilir bir kayıp üretmez; kırk tanesi arayüzü öğrenilemez hale getirir. Her kalem tek tek puanlandığında hepsi eşiğin altında kalır ve liste hiç ilerlemez.

Puanlama yine de bir yerde işe yarar: borç listesinin kendi içinde sıralama yapmak için. Yarışı özelliklerle değil, diğer borç kalemleriyle kurun.

Sabit kapasite ve doğru ölçüm

Her sprintte kapasitenin belirli bir yüzdesi (pratikte yüzde on ile on beş arası yeterli) borç kalemlerine ayrılır ve o işin sahibi isimle belirlenir. Sahipsiz ayrılan kapasite ilk acil işte buharlaşır.

Çeyrekte bir yapılan toplu temizlik haftaları bunun yerine geçmez. Bir haftada açılan yüz dosyalık değişiklik tek seferde review edilemez, regresyon da aylar sonra ortaya çıkar. Küçük ve sürekli akan temizlik hem gözden geçirilebilir hem geri alınabilir kalır.

Başarı ölçüsü kapatılan kalem sayısı değil. Doğru gösterge, aynı şikâyetin destek kayıtlarına tekrar düşme sıklığıdır. Sayı düşmüyorsa düzeltme kullanıcının yaşadığı sorunu değil, ekibin o sorun hakkındaki varsayımını çözmüştür.