Ürün ve UX Terimleri: Hangi Kelime Hangi Kararı Değiştirir?

Terimler ekipte tanımı bilinmediği için değil, aynı kelimeyi iki kişi farklı anlamda kullandığı için sorun çıkarır. "MVP çıkaralım" cümlesinde tasarımcının anladığıyla yazılımcının anladığı çoğu zaman aynı şey değildir. Aşağıdaki terimleri tanımlamak yerine şunu sormak daha verimli: bu kelimeyi kullandığımda hangi karara mecbur kalıyorum?

MVP: en az özellik mi, en az öğrenme mi?

MVP çoğu ekipte "bütçesi kısılmış sürüm" anlamında kullanılıyor. Oysa tanımın ağırlık merkezi minimum değil viable tarafında: ürünün, hakkında karar vermeye yetecek kadar gerçek olması gerekiyor.

Pratik bir ayraç var. MVP'yi çıkardıktan sonra hangi soruya cevap alacağınızı bir cümleyle yazamıyorsanız, elinizdeki şey MVP değil, ürünün birinci fazı. Peki ya cevap almak istediğiniz soru "insanlar bunu kullanır mı" ise? O soruyu ölçmek için canlı bir ürün gerekmeyebilir; sahte kapı testi ya da tek ekranlık bir akış çoğu zaman aynı bilgiyi haftalar önce verir.

CAC ve CLV'nin tasarım kararlarına değen yeri

"CLV, CAC'den yüksek olmalı" cümlesi doğru ama tek başına hiçbir tasarım kararını değiştirmiyor. Değiştiren şey, iki metriğin zaman ekseninde aynı yerde durmaması. Kullanıcı edinme maliyeti peşin ödenir, yaşam boyu değer aylara yayılarak birikir.

Bunun arayüze yansıması şu: kayıt akışındaki bir iyileştirme sonucunu haftalar içinde gösterir, elde tutmayı hedefleyen bir iyileştirme (bildirim tercihleri, boş durum ekranları, ikinci hafta geri dönüş akışı) aynı sürede neredeyse hiçbir şey göstermez. İkisini aynı çeyrekte aynı ölçüyle karşılaştırırsanız, ikincisi hep kaybeder. Ekipler elde tutma tarafına yatırım yapmaktan bu yüzden vazgeçiyor, sonucu yanlış olduğu için değil, ölçüm penceresi kısa olduğu için.

UX borcu neden teknik borçtan daha zor takip edilir?

Teknik borcun kendini gösteren belirtileri var: derleme süresi uzar, aynı dosyada tekrar tekrar hata çıkar, test kapsamı düşer. Bunlar araçlarla ölçülüyor ve kimse hatırlatmasa da rapora düşüyor.

UX borcunun böyle bir uyarısı yok. Kısa yoldan eklenmiş bir onay ekranı, sürüm notunda "tamamlandı" görünür ve orada kalır. Ancak biri aynı görevi bir kullanıcıya yeniden yaptırdığında ortaya çıkar. Bu yüzden UX borcunu ayrı bir dokümanda değil, hataların durduğu listenin içinde tutmak daha iyi çalışıyor: aynı öncelik alanları, aynı sprint, üstüne bulgunun geldiği araştırma kaydının bağlantısı. Ayrı bir listede duran borç, birkaç ay içinde kimsenin açmadığı bir dosyaya dönüşüyor.

Feature flag: tasarım kararını erteleme aracı mı?

Özellik bayrağı, iki tasarımı aynı anda canlıda tutmayı mümkün kılıyor. Cazip tarafı bu, ama bedeli de burada. Her bağımsız bayrak kod yollarını ikiye katlar; k tane bayrak 2^k kombinasyon demektir. Beş bayrakta otuz iki olası arayüz durumu çıkar ve bunların hepsini ne test edebilirsiniz ne de tasarım tarafında gözden geçirebilirsiniz.

Bayrak, kararı ertelemek için değil, kararı ölçüp kapatmak için kurulmalı. Ölçüm için de trafik gerekir: günde birkaç yüz oturum alan bir ekranda A/B testi anlamlı bir fark üretmez, o durumda bayrak yerine beş kişiyle yapılan bir kullanıcı testi daha hızlı ve daha net cevap verir. Kapatma tarihi belirlenmemiş her bayrak, birkaç sürüm sonra kalıcı bir çatallanmaya dönüşüyor.

Kararın sahibi kim?

RACI matrisinin UX tarafında işe yarayan tek satırı, "Accountable" satırı. Tasarım incelemesi döngüye giriyorsa sebep genellikle kavramsal bir anlaşmazlık değil, aynı karar için iki kişinin kendini son söz sahibi sanmasıdır. Toplantıdan önce bunu tek cümleyle yazmak, kalan üç harfin tamamından daha fazla iş görüyor.

Bir terimi öğrenmeye değip değmediğinin ölçüsü de aslında bu: kelime, ekipte bir kararı değiştiriyorsa faydalı. Değiştirmiyorsa sunum süsü.