Kullanıcılar bir uygulamanın yalnızca %20’sini önemser

• Kullanıcıların çoğu uygulama özelliklerinin yalnızca kendileri için gerekli olan yaklaşık %20’sini kullanır ve bu %20 her kullanıcıda farklıdır
• Kalan %80’lik özellikler dikkat dağıtıcı olarak görülebilir ve hatta rahatsızlık ya da memnuniyetsizlik yaratabilir
• Niş pazarı doğru hedeflerseniz güçlü bir kullanıcı tabanı oluşturabilirsiniz
• Kagi, Figma ve Notion gibi, büyük şirketlerin görmezden geldiği %20’yi iyi çözüp yüksek sadakatli bir pazar oluşturan örnekler, yeni pazar fırsatlarını gösteriyor
• VS Code, Slack ve Discord, genişletilebilirlik ve kişiselleştirme sayesinde kullanıcıların kendi %20’lerini kendilerinin optimize etmesini destekliyor
• Asıl mesele herkes için bir ürün yapmak değil, her kullanıcının istediği kısmı derinlemesine tatmin eden araçlar üretmek; bu da özellik şişmesi sorunundan kaçınmanın yolu

---

Çocukluk deneyimi ve yazılımı kullanma biçimi

• Yazar, çocukken 2 GB depolama alanını yönetmek için gereksiz dosyaları silerken bilgisayarını sık sık bozardı
  • .ini dosyaları gibi önemli sistem dosyalarını sildikten sonra Windows ve Office 97’yi baştan kurmak zorunda kalırdı
• Babası Excel’in mutlaka kurulmasını söylerdi, ama yazar için Excel yalnızca Word’e tablo yapıştırmak için kullanılan bir araçtı
• Excel’in sayısız özelliği arasında yalnızca tablo kopyalama/yapıştırma gerçekten anlamlıydı
• Bir tanıdığı da Excel’i yalnızca ev bütçesi tutmak için kullanmış, diğer özelliklerine hiç dokunmamıştı

Herkesin farklı %20’si

• Yazılım kullanımında bir '80/20 kuralı' vardır: Kullanıcıların çoğu tüm özelliklerin %20’sini kullanır
• Ancak her kullanıcının odaklandığı %20 farklıdır ve herkes kendi kullandığı kısmın en önemli bölüm olduğunu düşünür
  • Örnek: Word’de tablo kullanır ama mail merge kullanmaz; Excel’de pivot table kullanır ama script kullanmaz; PowerPoint’te animasyon kullanmaz
• Yeni özellik eklemeleri veya UI değişiklikleri içeren güncellemeler yüzünden uygulamanın yavaşladığı ya da gereksiz özelliklerle dolduğu hissi memnuniyetsizlik yaratır
• Kullanılmayan %80’lik özellikler, kullanılan %20’lik iş akışını engelleyen unsurlar olarak bile görülebilir

Mükemmel sonuca duyulan arzu

• Bu durum yalnızca Microsoft’ta değil, diğer BT şirketlerinde de aynı şekilde görülür
• Örneğin Google Search’te tam anahtar kelime araması yapmak isterken, gereksiz ilgili sonuçlar tam tersine memnuniyetsizlik doğurabilir
• Şirketler bunu "kullanıcıların %1’inin talebi" diye küçümseyebilir, ancak 1 milyar kişinin %1’i 10 milyon kişi demektir; bu da devasa bir pazardır
• Kagi, Google’ın gözden kaçırdığı küçük pazara odaklanıp gizliliği koruyan, reklamsız ve kalite odaklı arama ile farklılaşarak pazara girdi
• Büyük şirketlerin boşluklarını hedeflemek, küçük kullanıcı gruplarını memnun eden bir niş pazar oluşturmayı mümkün kılar
• Herkesi memnun etmek gerekmez; belirli bir grubun %20’lik deneyimini kusursuz karşılamaya yönelik bir strateji kurmak mümkündür

Unutulmuş %20’yi bulmak

• Pek çok yenilikçi şirket, büyük şirketlerin kaçırdığı belirli kullanıcı gruplarını yoğun biçimde hedefler
• Figma, işbirlikçi tasarım alanında Adobe’yi aşmaya odaklandı; Notion da belirli kullanıcı ihtiyaçlarına optimize edilmiş bir hibrit araç olarak konumlandı
• Başarılı yazılımlar zamanla daha fazla özellik kazanır, ancak bu süreçte bazı kullanıcıların %20’sinin gölgede kaldığı yeni nişler ortaya çıkar
• Açık kaynak yazılım, belirli iş akışlarına özel özelleştirilmiş build’ler üretilebildiği için bu alanda güçlüdür
  • Örneğin Blender için yalnızca mimari görselleştirmeye yönelik hafif bir sürüm geliştirilebilir

Doğru %20 için tasarım

• Bu felsefe VS Code’da iyi uygulanmıştır
  • Temel işlevler basit metin düzenlemeye odaklanır, ancak uzantılar sayesinde herkes kendi istediği geliştirme ortamını kurabilir
  • Yapı, tüm kullanıcıların kendi %20’lerini özelleştirebilmesine olanak tanır
• Slack entegrasyonları, Discord botları da aynı ilkeyle kullanıcıların deneyimi doğrudan özelleştirmesini destekler
• Başta tüm kullanıcıların %20’sini öngörmek zor olsa da, genişletilebilirlik ve özelleştirme sunulduğunda herkes kendi en iyi kullanım biçimini kurabilir

Sonuç: Tüm kullanıcılar için bir ürün yerine, herkesin 'ihtiyaç duyduğu %20’ye' odaklanmak

• Tüm özellikleri iyi yapmaya çalışmak, sonunda ağırlaşan ve memnuniyetsizlik üreten bir yazılıma dönüşür
• Önemli olan, her özelliğin o özelliği arayan belirli kullanıcı için kusursuz çalışmasına odaklanmaktır
• Kullanıcılar zaten tüm özelliklerin yalnızca bir kısmını kullanacağından, belirli özellikleri gerçekten olağanüstü hale getirmeye odaklanmak daha etkilidir
• Yazılımın öngörülmeyen biçimlerde kullanılabileceğini kabul etmek ve bu çeşitliliği kapsayan bir planlama yapmak gerekir
• Kullanıcıya her şeyi dayatmak yerine, yalnızca gerçekten sevilen bölümlere odaklanarak geliştirmek daha büyük memnuniyet sağlar

[shakespeares]

Hemen Pareto ilkesine yapıştırıyorlar zaten;; %15 de olabilir, değil mi? hahaha

[GN⁺]

Hacker News görüşleri

• Çalıştığım bir SaaS şirketinde, kullanıcıların gerçekten kullandığı özelliklerin yalnızca bir kısmını temel alarak analiz yapmaya çalışmıştık. Ürünün karmaşıklığını birkaç temel kullanıcı tipine göre azaltmak ve can sıkıcı özellikleri kaldırmak istiyorduk. Sonuçta giriş ekranı dışında herkesin önemli gördüğü %20 tamamen farklı çıktı. Analiz sonucu, ağırlıklandırılmış rastgele örneklemeden farksızdı

• Buna gerçekten katılıyorum. Ama ürünü enterprise müşterilere satmaya başladığınızda durum tamamen değişiyor. Tek bir "hijyen özelliği" eksikse anlaşma düşebiliyor. Üstelik her enterprise için vazgeçilmez özellik farklı. Buradaki hijyen özelliği, tuvalet gibi herkesin ihtiyaç duyduğu asgari zorunlu unsurları anlatan bir benzetme

  • Şimdiye kadar aynı ürünü iki kez satmışım gibi hiç hissetmedim. Ürün yol haritası en son kiminle konuştuğuma göre şekilleniyor. Müşterilerin olmazsa olmaz diye bastırdığı 5.000 kadar 'zorunlu' özelliği neredeyse production seviyesinde tutmanın yarattığı teknik borçla uğraşıyorum. Ama gerçekte müşteriler bunları neredeyse hiç kullanmıyor
  • Tuvaletler bugün büyük ölçüde standart ama dijital ürünlerde durum hiç öyle değil
  • "Tuvalet... günde sadece 3 dakika kullanılıyor" dedin ama ciddi ciddi bir sağlık kontrolü önermek isterim

• Bana Spolsky’nin blog yazılarını hatırlatan benzer bir yazı
  strategy-letter-iv-bloatware-and-the-8020-myth
  simplicity

  • Joel Spolsky’nin yazılarının yıllar geçse de ne kadar geçerli kalmasına şaşırıyorum. Bazılarının sonradan yanlış olduğu ortaya çıktı (örneğin ekran kartlarının düşük marjlı bir iş olacağını öngörmesi gibi bkz.) ama çoğu bugün hâlâ doğru. Hatta o zamankinden bile daha ikna edici olabilir
  • İkinci yazıya (sadelik) gerçekten çok benziyor. Yazar bu klasik gönderileri bilmiyor olabilir. Yeni nesil sanki bu tür klasikleri pek okumuyor. Bu arada Joel Spolsky, Steve McConnell, Don Norman ve daha birçok kişi yazılım geliştirme mesleği üzerine derinlemesine düşünüp bunları yazıya dökmüştü. Bir ara okumaya değer

• Kişisel bir hobi uygulamasını kendim yaptım ve bazen biraz cilalayıp yayımlamayı düşünüyorum. Ama uygulamamı tanıtmak ya da duyurmak için hiç isteğim olmadığından, yayımlamanın kendisinin anlamsız olduğunu düşünüyorum. Aslında daha büyük neden, kendim kullanmadığım kalan %80’lik özellikleri hayata geçirmeye hiç niyetim olmaması

• Pazarlama tarafında Modified Pareto diye bir kavram var. 80/20 değil, 60/20. Ağır kullanıcı olan %20, ürün değerinin %60’ını tüketiyor; hafif kullanıcı olan %80 ise %40’ını tüketiyor. Bu göz ardı edilemeyecek kadar büyük bir pay, dolayısıyla hafif kullanıcıları da mutlaka düşünmek gerekiyor
  value-paretos-bottom-80

  • Bu tür ilkeleri mutlak gerçekler olarak görmektense, tekrar eden bir geri bildirim döngüsünün parçası olarak görmek bana her zaman ilginç gelir.
    1. Gözlem: Kullanıcıların %80’i yazılımın yalnızca %40’ını kullanıyor
    2. Sonuç: O %60’ın bir kısmını keselim
    3. Gözlem: Kullanıcıların %80’i kalan %40’ın da yalnızca bir kısmını kullanıyor
    4. Sonuç: Yine keselim...
       Böyle gidiyor. Oysa gerçekte çok daha önemli olan, kullanıcının yazılımın kendi sorununu çözebileceğini 'algılaması'. Eğer para harcamalarını istiyorsanız, yazılımın potansiyel olarak kullanıcının farklı sorunlarını da çözebileceği hissini vermeniz gerekir. Bu farklı sorunlar, kullanıcının bizzat kullanmayacağı özelliklerle de ilgili olabilir. Örneğin 3D yazılımda gördüğüm bir rigging sistemi, kullanıcıların %2’si tarafından zamanın yalnızca %1’inde kullanılıyor olabilir; ama o özellik yoksa bazı insanlar ürünü değerlendirmeye bile almaz

• Ürettiklerimin gerçekte nasıl kullanılacağını öngörmekte iyi olmadığım için, genelde "Desire paths" diye anılan, ortaya çıkan güzergâhları asfaltlama yaklaşımını tercih ediyorum
  the-road-most-traveled-by-paving

  • BT politikası ve yönetişimin de bu tür Desire path temelli yazılmasını tavsiye ederim. Ama ortam karmaşıklaştıkça ölçeklenebilirlik veya maliyet açısından sorunlar çıkabilir
  • Bu, gerçek dünyada yapılan telemetriye (kullanıcı davranışı takibi) benziyor ve isteğe bağlı olarak çıkış yolu yok. Eğer öncü değilseniz, başkalarının açtığı yolları takip etmekten başka seçeneğiniz de olmayabilir

• Bence "özelliklerin artmasını engellemeye çalışmak yerine, yazılımın hayal bile edilmemiş şekillerde kullanılabileceğini kabul etmek gerekir" görüşü doğru. Bu yüzden birlikte çalışabilirliğin (interoperability) yazılımın en önemli unsuru olduğunu düşünüyorum. Metindeki temel sorun bana, yazılıma ve sürüme göre değişen kapalı dosya formatları gibi geliyor. Ben birden fazla aracı birleştirerek kullanmaktan çekinmem ama sorun, bu araçların bir pipeline içinde iyi iş birliği yapamaması. Unix rüyası gerçekten zor

• Bir ölçekteki uygulamalarda tüm özelliklerin %100 kullanılması neredeyse hiç olmaz. Benim deneyimime göre neredeyse her uygulamada tamamen kullanılmayan %10 ila %30 arasında bir bölüm vardır. Bunun nedeni genelde ya geliştirme ekibi dışında kimsenin anlayamayacağı kadar tuhaf olması, ya iş akışının kötü ve verimsiz olması ya da o kadar temel bir özellik olmasıdır ki, buna gerçekten ihtiyaç duyan şirketlerin zaten o yazılımı satın alacak ekonomik gücü olmaz

• Evet, ama birçok kullanıcının önemli gördüğü %20 farklı olduğu için, mevcut kullanıcı sayısını korumak adına tüm özellikleri elde tutmanız gerekir. Yine de bakım veya geliştirmede çok zaman yiyen ve neredeyse hiç kullanılmayan özellikleri kaldırmak ROI’yi artırır

• Ama kullanıcılar mutlaka aynı %20’yi önemli bulmuyor. Bir de şu var: kullanıcılar, uygulamayı gerçekten kullanmadan önce hangi özelliklerin bulunduğunu aslında pek bilmez. Kurulum kararı, uygulamada gerçekten olan özelliklere değil, kurulum öncesinde kullanıcının var olacağını düşündüğü özelliklere dayanır. Bu önemli bir fark. Özelliklere emek verseniz de bunun karşılığını çoğu zaman ancak kullanıcıyı kazandıktan sonra alırsınız.
  MVP (minimum viable product) yaparken bu özellikle önemlidir; çünkü çoğu durumda kurulumu ve sürekli kullanımı engelleyen şey özellik eksikliği değildir. Genelde sorun mesajın iletimi, pazarlama ya da kullanıcının ilgisini çekecek bir değerin baştan olmamasıdır. Rastgele özellik eklemek bunları çözmez. Basit görünür ama birçok şirket bunu gözden kaçırır.
  En basit MVP, daha hiçbir şey inşa etmeden insanları ön kayıt yaptırmaya ikna etmektir. Bu şekilde mesajınızın doğru iletilip iletilmediğini test edebilirsiniz. Kayıttan sonra hayal kırıklığına uğrarlarsa, en azından mesajın iyi iletildiğini anlamış olursunuz.
  Ama bu yaklaşım, MVP’nin vaat ettiğini henüz yerine getirmeden yayımlamak anlamına gelir ve tamamlanmamış vaatlerle hayal kırıklığı yaratma riski taşır. Ayrıca birçok özellik aslında gereksizdir; özellikle SaaS tarafında, insanların gerçekten para ödeyeceği kadar kritik olmayan çok sayıda özellik vardır. Müşterinin taleplerini hemen zorunlu gereksinim olarak almak yerine, onların bunu gerçekten 'değerli' bulup bulmadığını, gerçekten para ödemeye istekli olup olmadığını ve gerçekten önemli bir acı noktasını çözüp çözmediğini netleştirmek gerekir. Müşteri talebinin neden ortaya çıktığını anlamak, o özelliği hemen yapmaktan çok daha önemlidir

  • Sadece "kullanıcılar aynı %20’yi önemli bulmuyor" cümlesini görüp bu kadar uzun bir yorum mu yazdın diye merak ettim
  • "Kullanıcılar aynı %20’yi önemli bulmuyor" tam da bu yazının özü