Hick yasası (Hick-Hyman yasası)

Kısaca

Önünüzde iki buton varsa hemen seçersiniz. On altı buton varsa biraz durursunuz. Hick yasası, İngilizce adıyla Hick's law, bu durmanın seçenek sayısıyla nasıl büyüdüğünü anlatır.

Türkçede Hick kanunu ya da Hick-Hyman yasası diye de geçer. Üç ad da aynı ilkeyi anlatır.

Aşağıdaki testte bunu kendiniz ölçün. Önce 2 seçenekle, sonra 16 seçenekle birkaç tur yapın.

Canlı demo: doğru meyveyi bulun

Bir seçenek sayısı seçin ve Başla'ya basın. Üstte bir hedef adı çıkar, altta seçenekler. Hedefi bulup basın. Yanlış seçenek hata sayılır, tur devam eder.

Karar süresi testi

Bu test JavaScript ile çalışır. Kapalıysa aşağıdaki metin aynı fikri formül ve örneklerle anlatıyor.

Süre, Başla'ya bastığınız andan doğru seçeneğe bastığınız ana kadar ölçülür. Hedef adını okuma süresi de buna dahildir. Bu kontrollü bir deney değil: her sayıda birkaç tur yapıp ortalamaya bakın. Klavyede odak ilk seçeneğe gelir, Tab ile ilerlersiniz. O zaman süre, seçenekleri tek tek geçtiğiniz için daha hızlı artar.

16 seçenekte ortalamanız büyük olasılıkla 2 seçenektekinden uzun çıkar. Fark yine de seçenek sayısı kadar büyümez. Bunun nedeni aşağıdaki formülde.

Bu testin bir eksiği var: seçenekler her turda karışık sıralanıyor. Ölçtüğünüz sürenin bir kısmı bu yüzden aramaya gidiyor. Bu ayrıma sınırlar bölümünde döneceğim.

Formül: ne ölçülür?

Wikipedia'daki Hick yasası maddesi, eşit olasılıklı seçenekler için formülü şöyle verir:

T = b × log₂(n + 1)

• T: ortalama tepki süresi.
• n: eşit olasılıklı seçenek sayısı.
• b: veriden bulunan bir sabit.

Formüldeki +1'in bir nedeni var. Kullanıcı hangi seçeneğe basacağını bilmez, tepki verip vermeyeceğini de bilmez. +1 bu ikinci belirsizliği karşılar; madde bu açıklamayı Card, Moran ve Newell'in 1983 tarihli kitabına dayandırır.

Interaction Design Foundation ise formülü RT = a + b × log₂(n) diye yazar. Burada a ve b, göreve ve koşullara bağlı sabitlerdir. İki yazım aynı fikri anlatır: süre, seçenek sayısının logaritmasıyla büyür.

• 2 seçenek1,58 bit
• 4 seçenek2,32 bit
• 8 seçenek3,17 bit
• 16 seçenek4,09 bit

Şekil: log₂(n + 1) değerleri, demodaki dört seçenek sayısı için. Hesap benim. Seçenek sayısı 8 kat artarken değer 3 katına bile çıkmıyor.

Pratik sonucu şu: seçenekleri ikiye katlamak süreye aşağı yukarı sabit bir ek getirir. Grafikteki hesapta 8'den 16'ya çıkmak 0,92 bit, 2'den 4'e çıkmak 0,74 bit ekliyor.

Kökeni: Hick 1952, Hyman 1953

Yasanın ilk kaynağı psikolog William Edmund Hick'in makalesidir: “On the Rate of Gain of Information”. Makale Mart 1952'de Quarterly Journal of Experimental Psychology'de çıktı: 4. cilt, 1. sayı, 11-26. sayfalar.

Wikipedia'nın aktardığına göre Hick, deneyinde daire şeklinde dizili 10 lamba kullandı. Her lamba, ayrı bir parmakla basılan bir Mors anahtarına bağlıydı. Rastgele bir lamba yanıyor, denek doğru anahtara basıyordu.

İkinci kaynak psikolog Ray Hyman'ın 1953 tarihli makalesidir: “Stimulus information as a determinant of reaction time”. Journal of Experimental Psychology'nin 45. cildinde yer alır (3. sayı, s. 188-196).

Hyman, deneklerinden yanan ışığın adını söylemelerini istedi. Sonraki deneylerde her ışık türünün sayısı değiştirildi. Hyman, tepki süresi ile aktarılan bilgi miktarı arasında doğrusal bir ilişki buldu. Yasa bu yüzden iki adla birlikte anılır.

Aynı maddeye göre psikologlar bu olguyla bilgi kuramı arasında bir benzerlik gördü. Belli sayıda biti işlemek için geçen süreye “bilgi kazanma hızı” denir. Hick'in makalesinin başlığı da budur.

Arayüzde uygulama: Türkçe örnekler

Örnekler temsilidir, belirli bir uygulamayı hedef almaz. Her birinde şunu sorarım: kullanıcı burada hızlı bir karar mı veriyor, yoksa bildiği bir şeyi mi arıyor?

1. Bankacılık uygulamasının ana ekranı

Giriş yapan kullanıcı çoğu zaman tek bir iş için gelir: para göndermek ya da bakiyeye bakmak. Ana ekranda eşit büyüklükte yirmi kısayol varsa, her açılışta bunların arasından seçim yapar.

Laws of UX'in önerisi açık: hızlı yanıt önemliyse seçenekleri sınırlayın. Ben burada en sık kullanılan iki ya da üç işi büyük tutar, gerisini “Tüm işlemler” altında toplarım.

2. E-ticaret ödeme adımında kargo seçimi

Ödeme sayfası beş kargo seçeneğini ve iki teslimat zamanını aynı anda soruyorsa, kullanıcı ödemeden önce takılır. Laws of UX, önerilen seçeneği vurgulamayı önerir.

Bunun için bir seçeneği işaretli getirip “Önerilen” rozetiyle göstermek yeter.

Uzun formu adımlara bölmek de aynı mantıktır. Interaction Design Foundation, uzun bir ödeme formunu birkaç ekrana bölmeyi örnek verir. Form tarafını form tasarımı sayfasında anlattım.

3. Belediye uygulamasında hizmet listesi

Bir belediye uygulamasında su aboneliğinden otopark iznine kadar 60 hizmet olabilir. Bunları azaltmak çoğu zaman mümkün olmaz, çünkü her biri gerçek bir ihtiyaca karşılık gelir.

Kullanıcı ne istediğini zaten biliyorsa, sorun karar değil aramadır. Bu yüzden ben gruplama ve arama kutusunu birlikte öneririm. Grupları kurmak bir bilgi mimarisi işidir.

Sınırları ve yanlış anlaşılmaları

Yasa eşit olasılıklı seçenekler içindir. Interaction Design Foundation bunu açıkça yazar. Kullanıcı ne istediğini önceden biliyorsa, yasanın öngördüğünden hızlı davranır.

Karar ile arama aynı şey değildir. Wikipedia maddesine göre rastgele sıralı bir listede bir kelimeyi bulmak, öğeleri tek tek taramayı gerektirir. Bu doğrusal bir süredir ve yasa burada geçerli olmaz.

Alfabetik sıra durumu değiştirir. Aynı maddeye göre liste alfabetikse ve kullanıcı adı biliyorsa, listeyi bölerek logaritmik sürede bulabilir. Madde, yasanın menü tasarımı kararlarına gerekçe olarak anıldığını da not eder. Karışık sıralı listede ise yasa geçerli değildir.

Tanıdık öğelerde etki küçülür. Madde, tanıdık uyaranlara sözlü yanıt verilen çalışmaları istisna olarak aktarır. Orada tepki süresiyle öğe sayısı arasında ya hiç ilişki yoktu ya da artış çok küçüktü.

Uzun listelerde önemi azalır. Interaction Design Foundation'a göre yasa, rehber gibi uzun listelerde daha az, menü ve aksiyon butonu gibi kısa listelerde daha çok işe yarar.

Aşırı sadeleştirmenin de bir bedeli var. Laws of UX, fazla sadeleştirmenin anlamı silebileceği uyarısını yapar. Seçenekleri gizlemek, kullanıcının aradığını bulamamasına yol açabilir.

Bir not: Wikipedia maddesinin kendisi satır içi kaynaklarının yetersiz olduğunu belirtiyor. Bu yüzden oradaki bulguları genel eğilim olarak aldım. Künyeleri Crossref kayıtlarından ayrıca doğruladım.

Benim notum

Audit'lerde en sık gördüğüm Hick hatası, her şeyin aynı ağırlıkta gösterildiği ekranlardır. Sekiz eşit buton varsa kullanıcı hepsini okur. Bir tanesini birincil yapmak çoğu zaman kararı kısaltır.

İkinci hata, yasayı uzun listelere uygulamaktır. Ekipler 40 öğelik bir menüyü kısaltmaya çalışır, oysa sorun aramadır. Orada iyi bir gruplama ve arama kutusu, öğe silmekten daha çok iş görür.

Yasayı bir sayı kuralı olarak kullanmam. Bir ekranı incelerken bana tek bir soru sordurur: bu kullanıcı burada karar mı veriyor, yoksa arıyor mu? Bu soruyu heuristik değerlendirme sırasında her ekrana sorarım.

Bu soruyu kendi ürününüze bir dış gözle sordurmak isterseniz UX Audit sayfasına bakın.

İlgili sayfalar

Hick, kullanıcının neye basacağına karar verme süresini anlatır. Oraya ulaşma süresini Fitts yasası anlatır. İkisi bir butonun maliyetini birlikte açıklar.

Kullanıcının tanıdık kalıpları neden hızlı seçtiğini Jakob yasası ve zihinsel model sayfaları anlatır. Diğer yasalar UX yasaları listesinde.