Kullanıcı İhtiyaçlarını Önceliklendirirken Sıklık Yanıltır

Önceliklendirme sorusunun cevabı çoğu ekipte hazır bekliyor: kullanım verisine bak, en çok kullanılanı öne al. Bu yöntem ilk sürümde işe yarar, sonra sistematik biçimde aynı hatayı üretmeye başlar. Nadir ama kritik görevleri sıklık verisi göremez, çünkü ölçtüğü tek şey ürünün bugünkü hali.

Analitik yalnızca var olanı ölçer

Kullanım verisi geçmişin kaydı. Henüz yapılmamış bir özelliğin talebi hiçbir panelde görünmez. Ürünü bırakıp gitmiş kullanıcının ihtiyacı da görünmez, çünkü o kullanıcı artık ölçüm kümesinde değil. İki kör nokta aynı yöne bakıyor: veriye dayanarak önceliklendirdiğinde, ürünün zaten güçlü olduğu tarafı daha da güçlendirirsin.

Nicel veri öncelik listesini tek başına kuramaz. Kurabileceği şey doğrulama: elindeki hipotezi test eder, hipotezi üretmez. Hipotez, kullanıcıyı iş yaparken izlemekten ve terk edenlerle konuşmaktan çıkıyor.

Sıklık ile kritiklik ayrı eksenler

Bir görev günde kırk kez yapılıyor olabilir ve yanlış yapılması hiçbir şeye mal olmayabilir. Bir başkası yılda bir kez yapılır, yanlış yapılırsa kullanıcı beyan süresini kaçırır. İkisini tek bir “en çok ihtiyaç duyulan on görev” listesine koyduğunda ikincisi her seferinde kaybeder.

Sık kullanılan görevleri hızlandır, nadir ve kritik olanları görünür tut. Bunlar farklı tasarım problemleri: birincisinde tık sayısı ve gecikme, ikincisinde bulunabilirlik ve hata önleme. Bunu bir yönetim panelinde yakından gördüm: sadeleştirmeyi kullanım sıklığına göre yapınca yılda bir açılan belge ekranı menünün üç kat dibine indi, sonraki dönemde destek taleplerinin en kalabalık başlığı o ekran oldu.

Aşamalı sunum bir saklama kararıdır

Progressive disclosure kulağa nazik geliyor, yaptığı şey ise net: bazı özellikleri, onları arayacağını varsaydığın kullanıcılar dışında herkesten gizliyorsun. Gizlenen özellik, varlığını bilmeyen kullanıcı için yok demektir.

Kural basit: geri alınabilir olanı gizle, geri alınamaz olanı gizleme. Filtre seçenekleri, görünüm tercihleri, gelişmiş sıralama rahatça derine inebilir. Hesap kapatma, veri dışa aktarma, yetki devri gibi sonucu kalıcı işlemler ikinci seviyeye inmez. Kullanıcı onları aradığında bulamazsa ya yanlış olanı yapar ya da destek hattını arar, ikisinin de faturası sende.

Bir özelliğin maliyeti geliştirme süresi değil

Önceliklendirme tartışmalarında maliyet genelde “kaç gün sürer” diye soruluyor. Yanlış soru. Forma eklenen tek bir alan; doğrulama katmanında, API sözleşmesinde, dışa aktarma çıktısında, mobil istemcide, veritabanı göçünde ve o günden sonraki her regresyon koşusunda yaşamaya devam eder.

“Küçük ama bir kullanıcı istedi” özellikleri bu yüzden listenin en pahalı kalemi. Geliştirme süresi iki saat, taşıma maliyeti ürünün ömrü kadar. Maliyet sütununa geliştirme tahminini değil, özelliğin kaç yerde iz bırakacağını yaz.

Listeyi kesme kuralı

İlk sürüme neyin gireceğini seçerken tek ölçüt yeter: bu özellik olmadan kullanıcı başladığı işi bitirebiliyor mu? Bitiremiyorsa girer. Bitirebiliyor ama canı sıkılıyorsa ikinci sürüme kalır, notu düşülür ve gerçekten geri dönülür.

Geri bildirimi temalara ayırmak ve segment bazlı kişiselleştirme kurmak, ürünün bir sürümü sahada çalıştıktan sonra anlamlı. Önce işini bitiren bir şey çıkar, sıralamayı sonra gerçek kullanımla düzelt.