Doherty eşiği (Doherty threshold)

Kısaca

Kullanıcı bir butona bastığında ekranda hemen bir şey olmalı. Sonuç hazır olmasa bile bir tepki gelmeli. Doherty eşiği bu "hemen" için bir sayı verir: 400 ms.

İşin ikinci yarısı algılanan hızdır. Gerçek süreyi kısaltamadığınızda bekleyişi daha kısa hissettirebilirsiniz. İskelet ekran, yani skeleton screen, bunun araçlarından biridir.

Aşağıdaki demoda gecikmeyi ve göstergeyi kendiniz seçin. 300 ms ile 2.500 ms arasındaki farkı birkaç denemede hissedersiniz.

Canlı demo: gecikmeyi siz seçin

Kaydırıcıyla gecikmeyi 0 ile 3.000 ms arasında ayarlayın. Sonra beklerken ne görüneceğini seçip Yükle'ye basın. Sonuç kutusu geçen süreyi ve bu sürenin hangi sınıra düştüğünü yazar.

Gecikme deneyi

Bu demo JavaScript ile çalışır. Kapalıysa aşağıda yalnızca yüklenmiş içeriği görürsünüz; metin aynı fikri anlatıyor.

Siparişlerim

• Kablosuz kulaklıkKargoda
• Spor ayakkabıTeslim edildi
• Kitap setiHazırlanıyor

Gecikme gerçek bir ağ isteği değil, seçtiğiniz süre kadar bekleyen bir zamanlayıcıdır. Süre yorumları Nielsen'in sınırlarına, gösterge notları NN/g'nin iskelet ekran makalesine dayanır. Bu eşleştirmeyi ben yaptım. NN/g parlayan iskelet animasyonlarının dikkat dağıtabileceğini yazdığı için iskeleti durağan bıraktım. Hareket azaltma açıksa spinner dönmez ve ilerleme çubuğu %10'luk adımlarla dolar.

Ben en çok 2.000 ms'de "Gösterge yok" ile "İskelet ekran" arasındaki farka bakmanızı öneririm. Süre aynıdır ama boş kartta beklemek daha uzun gelir.

Kökeni: Doherty ve Thadani, 1982

Laws of UX'e göre Walter J. Doherty ve Ahrvind J. Thadani, 1982'de IBM Systems Journal'da bir makale yayımladı. Makale, bilgisayarın tepki süresi için 400 ms'lik bir hedef koydu.

Aynı kaynağa göre o güne kadarki ölçüt 2.000 ms, yani 2 saniyeydi. Laws of UX, 400 ms'nin altında sonuç veren uygulamaların kullanıcıyı adeta bağımlı ettiğini yazar.

Makalenin kendisini açıp okuyamadım. Bu yüzden 400 ms rakamını ve künyeyi Laws of UX'in aktardığı haliyle veriyorum. Siz de bu sayıyı ekip içinde bir hedef olarak kullanın.

Nielsen'in üç sınırı: 0,1, 1 ve 10 saniye

Tepki süresi için bilinen bir başka çerçeve Jakob Nielsen'indir. Nielsen bu sınırları 1993'te Usability Engineering kitabının 5. bölümünde yazdı. 2014'te eklediği notta aynı sınırların web uygulamaları için de geçerli olduğunu söyledi.

1. 0,1 snAnındaNielsen: kullanıcı sistemin anında tepki verdiğini hisseder. Sonucu göstermek yeter.
2. 0,4 snDoherty eşiğiLaws of UX: geri bildirim bu sürede gelirse dikkat korunur, verimlilik artar.
3. 1 snAkış sınırıNielsen: düşünce akışı kesilmez. Bunun üstünde çalışıldığını gösteren bir işaret gerekir.
4. 10 snDikkat sınırıNielsen: kullanıcı beklerken başka işlere geçmek ister. Yüzde göstergesi ve işi durdurma yolu gerekir.

Şekil: Nielsen'in üç sınırı ve aralarına düşen Doherty eşiği. Ölçek eşit aralıklı değildir.

0,1 saniye: Kullanıcı sistemin anında tepki verdiğini hisseder. 2014 notuna göre bu sürede kullanıcı, arayüzdeki nesneleri doğrudan kendisi yönetiyormuş gibi hisseder.

1 saniye: Kullanıcı gecikmeyi fark eder ama düşüncesi kesilmez. Nielsen'in 2014 notuna göre gecikme 1 saniyeyi aşarsa bilgisayarın çalıştığını gösterin.

10 saniye: Kullanıcının dikkati bu süreye kadar ekranda kalır. Daha uzun işlerde bilgisayarın ne zaman bitirmeyi beklediğini gösterin. Kullanıcıya işi durdurma yolu da verin.

Doherty eşiği bu çerçevede 0,1 ile 1 saniye arasına düşer. Ben ikisini şöyle birleştiririm: 400 ms içinde bir tepki, 1 saniyeyi aşınca da bir gösterge.

Algılanan hız ve skeleton screen

Algılanan hız, kullanıcının bekleyişi ne kadar uzun hissettiğidir ve saatteki süreyle her zaman örtüşmez. Bu farkı kapatmanın ilk yolu sistem durumunu göstermektir. Bu, Nielsen'in ilk ilkesi olan sistem durumunun görünürlüğüdür.

NN/g'nin 2023 tarihli makalesine göre iskelet ekran, sayfanın tel çerçeve (wireframe) benzeri bir taslağıdır. Yalnızca tam sayfa yüklemede kullanılır ve açık gri kutularla sayfanın yerleşimini taklit eder. Makale bunun algılanan yükleme süresini azalttığını yazar.

Aynı makale hangi göstergenin ne zaman kullanılacağını da sıralar:

Bekleme	Ne gösterilir
1 saniyenin altı	Hiçbir şey. Hızla yanıp sönen ekran kullanıcıya yetişemiyormuş hissi verebilir.
2 ile 10 saniye, tek parça	Spinner, örneğin tek bir video ya da dashboard kartı için.
10 saniyenin altı, tam sayfa	İskelet ekran.
10 saniyenin üstü	İlerleme çubuğu ve açık bir süre tahmini.
Dosya yükleme, indirme, dönüştürme	İlerleme çubuğu. İskelet ekran burada uygun değildir.

NN/g iki uyarı da ekler. Parlayan ya da nabız gibi atan iskelet animasyonları dikkat dağıtabilir ve erişilebilirlik sorunu yaratabilir. Yalnızca başlığı, altlığı ve arka planı gösteren boş çerçeve ise bir spinner'dan farksızdır.

Bence makalenin en önemli uyarısı şu: iskelet ekran performans iyileştirmesinin yerini tutmaz. Sayfa yine aynı hızda yüklenir, iskelet yalnızca bekleyişi kolaylaştırır.

Arayüzde 400 ms'yi tutturmak

Sunucunun yanıtı 400 ms'yi geçse bile arayüzün tepkisi geçmek zorunda değil. Tepki ile sonuç ayrı şeylerdir. Ben ekranları incelerken bu ikisini ayrı ayrı ölçerim.

Basılan buton hemen değişsin. Bir bankacılık uygulamasında "Gönder"e basınca buton basılı hale geçmeli ve yazısı "Gönderiliyor" olmalı. Sonuç birkaç saniye sürse de kullanıcı isteğin alındığını bilir.

Riski düşük işlerde sonucu önden gösterin. Bir e-ticaret sitesinde favoriye eklenen ürünün kalbi hemen dolabilir. İstek başarısız olursa kalp geri boşalır ve kısa bir mesaj çıkar. Para transferinde bunu yapmam, orada gerçek sonucu beklerim.

Liste yenilenirken de ekranı boşaltmayın. Eski satırları yerinde bırakıp üstte küçük bir yenileniyor işareti gösterirseniz kullanıcı okumaya devam eder.

Benim notum

Audit'lerde en sık gördüğüm hata, butona basıldığında hiçbir şeyin değişmemesidir. Kullanıcı tekrar basar ve aynı ödeme ya da form iki kez gider. Butonun hemen basılı hale geçmesi ve tekrar basılamaz olması bu sorunu çoğu zaman çözer.

İkinci sırada, her yüklemeye spinner koyma alışkanlığı var. 300 ms süren bir filtre için ekranda bir an dönen bir halka, işi olduğundan yavaş gösterir. Ben 1 saniyenin altındaki işlerde göstergeyi kaldırırım.

Bir de iskelet ekranın gerçek içerikle uyuşmaması var. Üç satırlık iskelet gelir, sonra tek bir satır yüklenir ve sayfa zıplar. İskeleti gerçek bileşenlerin ölçüsüyle çizmek bu sorunu önler. Ben bunu tasarım sistemine bir bileşen olarak eklerim.

Ürününüzün bekleme anlarını ve geri bildirimlerini birlikte düzeltmek isterseniz Tasarla & Yayınla Sprinti tasarımı ve kodu birlikte teslim eder. Önce sorunları görmek isterseniz UX Audit ile başlayabilirsiniz.

İlgili sayfalar

Boş ekranın bir de kalıcı hali var. Henüz verisi olmayan ekranı boş durum kalıbında anlattım. Kartlarla dolu ekranlarda yükleme sırası için dashboard kalıbına bakabilirsiniz.

Diğer yasalar UX yasaları listesinde. Hedeflerin boyutu ve yeri için Fitts yasası iyi bir sonraki adım.