Özellik İsteği Aslında Hangi Problemi Saklıyor?

Özellik isteği çözüm cümlesidir

Bir kullanıcı “takvime sürükle-bırak ekleyin” dediğinde bana problem söylemiş olmaz. Bir çözüm önerisi söylemiş olur.

“Mobilde ayrı bir buton olsun.” “Notlar için klasör ekleyelim.” “AI burayı otomatik doldursun.” “Dashboard’u özelleştirilebilir yapalım.”

Bunların hepsi değerlidir. Çünkü kullanıcı bir sürtünme yaşamıştır. Ama ürün tarafında yapılacak ilk hata, cümlenin sonundaki çözümü doğrudan backlog’a yazmaktır.

Ben önce şunu ayırırım:

• Kullanıcı ne yapmaya çalışıyordu?
• Nerede durdu?
• Hangi bilgiye sahip değildi?
• Hangi kararı veremedi?
• Sistem hangi state’i yanlış veya eksik gösterdi?
• Mevcut akış neden yetmedi?
• İstenen özellik bu problemi gerçekten çözüyor mu, yoksa sadece etrafından mı dolaşıyor?

Bu ayrım küçük görünür. Ürün mimarisini belirleyen şey de çoğu zaman budur.

“Daha fazla kontrol” talebi bazen daha az karar ihtiyacıdır

Ordovia gibi çok domain’li bir üründe görevler, notlar, alışkanlıklar, planlama, ritüeller ve kişisel bilgi aynı kullanıcı altında birleşir. Böyle bir sistemde kullanıcıya her yüzeyi istediği gibi düzenleme özgürlüğü vermek ilk bakışta güçlü görünebilir.

Fakat kontrol talebinin altında bazen başka bir problem vardır: kullanıcı günün başında hangi bilgiye bakması gerektiğini bilmiyordur.

Bu durumda sınırsız dashboard özelleştirmesi problemi çözmez. Karar yükünü kullanıcıya geri verir.

Doğru soru “kaç widget ekleyebiliriz?” değil, “kullanıcının bu anda hangi kararı vermesi gerekiyor?” olur.

Bu nedenle feature request’i değerlendirirken çözümün yüzeyine değil, karar noktasına bakarım.

Feature request’i dört katmana ayırıyorum

Bir istek geldiğinde önce hangi katmana ait olduğunu anlamaya çalışırım.

1. Interaction problemi Kullanıcı doğru işlemi yapabiliyor ama arayüz bunu zorlaştırıyor olabilir. Touch target küçük, buton yanlış yerde, gesture çakışıyor veya bilgi görsel olarak zayıf olabilir.

2. Flow problemi Tek tek bileşenler çalışıyordur ama işlemin sırası yanlıştır. Kullanıcı gereksiz karar veriyor, geri dönüyor veya context kaybediyordur.

3. Domain problemi UI aslında daha derindeki model sorununu saklıyor olabilir. Örneğin “notu arşivle” ve “notu sil” davranışları domain’de net ayrılmamışsa, doğru buton tasarımı problemi çözmez.

4. System problemi Sorun state ownership, synchronization, permission, platform parity veya source-of-truth seviyesindedir. UI’daki feature request sadece semptomdur.

Bu sınıflandırma kusursuz bir metodoloji olmak zorunda değil. Faydası şu: beni doğrudan komponent yazmaya koşmaktan alıkoyuyor.

İstekten önce evidence

Bir isteğin gerçekten ne anlattığını anlamak için elimde ne olduğuna bakarım:

• ekran kaydı,
• hata tekrar adımları,
• kullanıcı davranışı,
• mevcut route ve state,
• network/data akışı,
• ürünün canonical modeli,
• benzer yüzeylerdeki davranış,
• canlı ürün ile beklenen davranış arasındaki fark.

Bazen cevap gerçekten yeni feature’dır.

Bazen de feature yazmadan çözülür.

Örneğin kullanıcı bir içeriği bulamıyorsa yeni bir filtre eklemek yerine bilgi mimarisini düzeltmek gerekebilir. Kullanıcı sık sık “kaydet” arıyorsa sorun kaydet butonunun eksikliği değil, autosave state’inin görünmez olması olabilir. Bir ekran sürekli eski veri gösteriyorsa refresh butonu eklemek yerine invalidation veya synchronization katmanı çözülmelidir.

Ne zaman “evet, bu feature” diyorum?

Benim için üç koşul önemlidir.

Birincisi, problem açık olmalı. “Kullanıcı bunu istiyor” tek başına yeterli değil.

İkincisi, istenen davranış mevcut ürün modeline nereye oturduğu belli olmalı. Yeni özellik yeni bir ada yaratmamalı.

Üçüncüsü, başarı kriteri tanımlanabilmeli. Feature yayınlandıktan sonra neyin daha iyi olması gerektiğini söyleyemiyorsak, büyük ihtimalle problemi yeterince tanımlamamışızdır.

Başarı kriteri her zaman metrik olmak zorunda değil. “Kullanıcı aynı işi tek akışta tamamlayabiliyor”, “state platformlar arasında tutarlı”, “geri tuşu beklenen hiyerarşide çalışıyor”, “yanlış destructive action ihtimali ortadan kalktı” gibi doğrulanabilir davranışlar da başarı kriteridir.

Feature backlog değil, problem backlog

Ürünlerde backlog’un zamanla çözüm mezarlığına dönüşmesi kolaydır.

“AI özet.” “Yeni görünüm.” “Drag and drop.” “Daha fazla filtre.” “Yeni entegrasyon.”

Aylar sonra bunların neden yazıldığını kimse hatırlamaz.

Daha dayanıklı model şudur:

Problem: Kullanıcı planlama sırasında günlük bağlamı kaybediyor. Evidence: Aynı bilgi için üç yüzey arasında geçiş gerekiyor. Constraint: Mobilde tek ana karar yüzeyi korunmalı. Possible interventions: Flow değişikliği, context panel, domain birleşimi veya yeni feature. Decision: Kanıta göre seçilir.

Bu yapı, “feature yapalım mı?” tartışmasını daha erken doğru seviyeye taşır.

Sonuç

Feature request’i küçümsemiyorum. Tam tersine, onu ham sinyal olarak daha ciddiye alıyorum.

Kullanıcının söylediğini aynen yapmak müşteri odaklı görünür. Ama bazen ürün sorumluluğunu kullanıcıya devretmektir.

Benim işim istek ile problem arasındaki mesafeyi kapatmak.

Çünkü yanlış problem için kusursuz feature üretmek hâlâ yanlış ürünü iyileştirmektir.