Kullanıcı “Şu Özellik Olsun” Dediğinde Ne Anlamalı?

Uygulamalarımın destek kutusuna gelen mesajların büyük kısmı şu kalıpta: “Şuraya bir düğme koysanız.” “Filtreye şunu ekleseniz.” “Şöyle bir liste olsa.”

Uzun süre bunları bir yapılacaklar listesi gibi ele aldım. Sıraya diziyor, sırayla yapıyordum. Sonuç, birbiriyle konuşmayan özelliklerden oluşan bir arayüz ve hâlâ memnun olmayan kullanıcılar oldu.

Fark ettiğim şey basit ama etkisi büyük: kullanıcı size problemini değil, kendi bulduğu çözümü anlatıyor. Ve o çözüm, uygulamanın tamamını görmeyen birinin, elindeki sınırlı bilgiyle ürettiği bir öneri.

Örnek: “geçmiş listesi olsun”

Somut bir örnek üzerinden gideyim. Birkaç kullanıcıdan “baktığım ilanların geçmişi olsun” isteği geldi. İlk tepki, bir geçmiş ekranı yazmak.

Ama sordum: neden ihtiyaç duyuyorsunuz? Cevaplar birbirinden çok farklı çıktı:

• “Beğendiğim bir ilanı sonra bulamıyorum.” → Aslında istediği kaydetme.
• “Aynı ilanı tekrar tekrar açıyorum, hangisine baktığımı unutuyorum.” → İstediği, bakılanların listede işaretlenmesi.
• “Fiyat değişti mi diye kontrol ediyorum.” → İstediği, fiyat değişikliği bildirimi.

Üç kullanıcı da aynı cümleyi kurdu, üçü de bambaşka bir şey istiyordu. Geçmiş ekranı yazsaydım üçünü de kısmen çözer, hiçbirini tam çözmezdim — ve arayüze kalıcı bir ekran eklemiş olurdum.

Sorduğum sorular

Bir istek geldiğinde, doğrudan “tamam eklerim” demeden önce sorduklarım:

1. Bunu ne zaman yapmaya çalışıyordunuz? — Bağlamı ortaya çıkarıyor. Aynı özellik, farklı bağlamda farklı çözüm demek.
2. Şu an bunu nasıl hallediyorsunuz? — Kullanıcının kurduğu geçici çözüm, problemi en net anlatan şey. Ekran görüntüsü alıp saklıyorsa, kaydetme özelliği eksik demektir.
3. Olmadığında ne oluyor? — Etkinin büyüklüğünü ölçüyor. “Biraz zaman kaybediyorum” ile “işlemi tamamlayamıyorum” arasında öncelik farkı var.
4. En son ne zaman ihtiyacınız oldu? — Sıklığı ölçüyor.

Bu dört soru, destek yazışmasını uzatıyor gibi görünüyor. Pratikte tersi oluyor: doğru şeyi bir kere yapmak, yanlış şeyi yapıp sonra düzeltmekten kısa sürüyor.

Sessiz çoğunluk problemi

Yazan kullanıcılar, kullanıcıların tamamını temsil etmiyor. Yazanlar genelde ya çok memnun ya çok rahatsız olanlar ve neredeyse her zaman ortalamadan daha ileri seviye kullanıcılar.

Bunun sonucu şu: gelen isteklerin çoğu, uygulamayı yoğun kullanan azınlığın istekleri oluyor. Onları dinleyerek ilerlerseniz ürün giderek uzmanlaşıyor ve yeni kullanıcı için karmaşıklaşıyor.

Bunu dengelemek için isteklere bakarken iki şeyi ayırıyorum: kaç kişi yazdı ve kaç kişiyi etkiliyor. Onboarding akışındaki bir sürtünme hakkında kimse yazmıyor — çünkü orada takılan kullanıcı destek yazmıyor, uygulamayı siliyor. Ama etkilediği kişi sayısı, herhangi bir gelişmiş özellikten kat kat fazla.

İstekleri nasıl sıralıyorum

Her isteği tek bir yerde topluyorum ve üç alanla kaydediyorum: hangi problemi çözüyor, kaç farklı kullanıcıdan geldi, tahmini iş yükü.

Sıralamayı yaparken baktığım şey, isteğin popülerliği değil şu üçlü:

Bu üçlüde en sık atlanan, maliyetin “arayüzde yer açmak” kısmı. Her yeni özellik, mevcut her şeyi biraz daha bulunmaz hale getiriyor. Menüye eklenen beşinci öğe, ilk dördünün de tıklanma olasılığını düşürüyor. Bu yüzden bazı istekleri, iş yükü düşük olmasına rağmen yapmıyorum.

Hayır demenin biçimi

Bir isteği yapmayacaksam kullanıcıya bunu söylüyorum — ama “yapmayacağız” diye değil. İşe yarayan kalıp şu: problemi anladığımı göstermek, mevcut yolla nasıl çözülebileceğini anlatmak, gerçekten çözülemiyorsa da bunu açıkça söylemek.

Bunun beklenmedik bir faydası var: kullanıcı çoğu zaman cevaba karşılık daha fazla bilgi veriyor. “Öyle yapıyorum ama şu durumda çalışmıyor” diye devam ettiğinde, asıl problemi ilk mesajdan çok daha net görüyorum.

Ne zaman kullanıcıyı dinlememeli

Son olarak: bazı kararlar kullanıcının vermesi gereken kararlar değil. Kullanıcılar genelde daha fazla seçenek ister — daha fazla ayar, daha fazla filtre, daha fazla özelleştirme. Her birini tek tek uyguladığınızda ortaya çıkan şey, kimsenin isteyip de kullanmadığı bir ayarlar ekranı oluyor.

Ürünün ne olmayacağına karar vermek geliştiricinin işi. Kullanıcı size neyin eksik olduğunu gösterir; neyin gereksiz olduğunu ise ancak siz görebilirsiniz — çünkü tabloya bütün olarak bakabilen tek kişi sizsiniz.

• Ürün
• UX
• Kullanıcı Geri Bildirimi
• Mobil Geliştirme