Maslow'un İhtiyaçlar Hiyerarşisi Ürün Tasarımında Nereye Kadar İşler
Maslow'un ihtiyaçlar hiyerarşisi UX metinlerinde sürekli karşımıza çıkar: önce temel işlev, sonra güven, en sonda estetik. Model bir öncelik listesi kurmakta işe yarar, katı bir sıra olarak alındığında yanıltır. Aradaki farkı bilmek, hangi işi önce yapacağınızı belirler.
Piramit Maslow'un çizimi değil
Maslow 1943 tarihli makalesinde ihtiyaçları sıralar, ama piramit çizmez. Üçgen görsel sonradan, 1960'ların yönetim literatüründe modele eklendi. Ayrıntı gibi duruyor, değil: piramit biçimi "alt kat dolmadan üst kata çıkılmaz" fikrini görselleştirip modelin en tartışmalı kısmını en akılda kalan kısmı haline getirdi. Maslow'un kendi metni daha esnek, katmanların iç içe geçebileceğini ve kısmen karşılanmış ihtiyaçlarla üst basamağa geçilebileceğini söyler.
Tasarım tarafında bu, şu anlama gelir: hiyerarşiyi bir kontrol listesi olarak değil, bir tartışma dili olarak kullanın.
Tasarıma çevrilmiş hali
Stephen Bradley'in Smashing Magazine'de önerdiği uyarlama, Maslow'un basamaklarını ürün diline taşır:
- Fonksiyonellik: ürün, var olma sebebi olan işi yapıyor mu?
- Güvenilirlik: aynı işi her seferinde aynı şekilde yapıyor mu?
- Kullanılabilirlik: kullanıcı o işi yardım almadan tamamlayabiliyor mu?
- Üretkenlik: kullanıcıyı sadece engellememekle kalmayıp hedefine daha hızlı götürüyor mu?
- Yaratıcılık: geri dönmek için işlevsel olmayan bir sebep veriyor mu?
Bu listenin asıl değeri sırasında değil, kelime dağarcığında. Bir toplantıda "kullanılabilirlik" ile "üretkenlik" farklı şeylerdir demek için ortak bir isim veriyor, yoksa ikisi de "kullanıcı deneyimi" torbasına girip kayboluyor.
Sıra nerede bozulur
Model, üst katmanın alt katman olmadan taşınamayacağını varsayar. Pratikte bu her zaman doğru çıkmıyor. Twitter yıllarca düzenli olarak çöktü, hata sayfasındaki balina resmi kültürel bir şakaya dönüşecek kadar sık göründü, ve kullanıcı sayısı aynı dönemde büyümeye devam etti. Güvenilirlik katmanı delikti; sosyal katmanın değeri o deliği kapattı.
Tersi de var. Birçok kurumsal yazılım fonksiyonellik ve güvenilirlik basamaklarını geçer, kullanılabilirlikte durur, yine de yıllarca kullanılır. Sebep tasarım değil, alternatifin olmaması.
Buradan çıkan kural şu: hiyerarşinin sırası, kullanıcının gidebileceği başka bir yer olduğu ölçüde geçerlidir. Rekabetin yoğun olduğu bir üründe alt basamağı atlayamazsınız. Tekel konumundaki bir üründe piramit bir öncelik listesi değil, olsa olsa bir borç listesidir.
Önceliklendirmeyi pratikte kurmak
Üç şey yeterli:
Ürünün var olma sebebi olan tek görevi yazın ve o görevi baştan sona ölçün. Kaç adım, kaç saniye, kaç hata. Bu ölçüm yoksa alt basamağın karşılandığı iddiası tahminden ibarettir.
MVP'yi "az özellik" diye okumak yaygın hata. Doğrusu, tüm katmanlardan ince bir dilim: çalışan, tutarlı, anlaşılır ve içinde küçük de olsa bir tane hoş an barındıran bir sürüm. Sadece en alt katmandan kalın bir dilim çıkarırsanız test edecek bir deneyiminiz olmaz.
Öncelik sırasını genelde hata kayıtları ve destek taleplerindeki tekrarla kurarım; persona dokümanı bu ikisiyle çelişiyorsa yanılan taraf çoğunlukla doküman oluyor. Kullanıcı araştırması ne yapmak istediklerini söyler, loglar nerede takıldıklarını gösterir. İkincisi daha ucuz ve daha az yorum gerektirir.
Kültürel uyarı
Hiyerarşi bireysel motivasyon üzerine kurulu. Aidiyetin bireysel başarının önüne geçtiği bağlamlarda basamakların sırası değişir, ürünün sosyal katmanı en baştan gerekli hale gelir. Farklı pazarlara açılan bir üründe piramidi olduğu gibi taşımak yerine sıralamayı o pazarda yeniden sormak gerekiyor.
Kaynaklar