Yükleme Durumu Ürünün Kendisidir

Ürününüzün bir yıl boyunca gösterdiği her yükleme durumunu toplayın. Her kullanıcı, her oturum, her yenileme. Kullanıcı saati cinsinden bu rakam, yayınladığınız en çok izlenen ekrandır. Çoğu ekip ise sanki kimse bakmıyormuş gibi davranır.

Dashboard tasarım incelemesinden geçer. Boş durum, eğer boş durumlar ürünün kendisidir yazısını okuduysanız, tasarım incelemesinden geçer. Yükleme durumu ise 2012'den kalma bir stil dosyasından gelen 16 piksellik bir spinner ve bir duayla yetinir. Kullanıcının her zaman gördüğü ama kimsenin tasarlamadığı tek ekran budur.

Yükleme durumu bir marka izlenimidir

Her yükleme durumu bir güven sözleşmesidir. Ürün kullanıcıya şunu söylüyor: "Çalışıyorum, çökmedim, bu bekleyiş bilerek." Ekranın bundan sonra söylediği şey, markanın baskı altında nasıl davrandığına dönüşür.

Linear'ın yükleme durumları Linear gibi hissettirir. Issue listesi şeklinde iskelet satırlar, sunucu onaylamadan önce kaydedilen satır içi oluşturma, kasıtlı bir ritimle markalı geçişler. Stripe'ınkiler Stripe gibi hissettirir. Ödeme butonundaki shimmer, dashboard'daki kart şeklinde iskeletler, nihai duruma dönüşen makbuz. İkisi de beklemeyi ürünün kendisi olarak ele alır.

Kötü versiyon, beyaz zemin üzerinde dönen eski bir gif'tir. İçerik şekli yok, ilerleme sinyali yok, marka yok. Kullanıcıya "yoğunlaştık ve senin burada olduğunu unuttuk" deniyor. Bu da bir marka izlenimi. Sadece ekibin yayınlamak istediği izlenim değil.

Yükleme durumunun beş arketipi

Çoğu ekip "yükleme durumu"nu tek bir tasarım problemi sayar. Aslında beş tanedir. Her biri farklı bir bekleyişe uyar ve farklı bir nedenle başarısız olur.

1. İskelet ekran

Nihai içeriğin şeklini yansıtan yer tutucu bir yerleşim. Satır olacak yerde satırlar, kart olacak yerde kartlar. Göz, içerik gelmeden önce yapıya kilitlenir ve bekleyiş başlıyor gibi değil, çözülüyor gibi okunur.

Linear'ın issue listesi, nihai listeyle piksel piksel eşleşen satır şeklinde iskeletler sunar. Stripe Dashboard, metrik bölümünde dolu kartlara dönüşen kart şeklinde iskeletler sunar. Notion, doküman yüklendiğinde gerçek bloklara dönüşen blok şeklinde yer tutucular sunar. Söz aynı: yükleme şekli nihai şekli öngörür.

Şu durumda kullanın: yapı biliniyorsa. Şu durumda geçin: yerleşim o kadar dinamikse ki iskelet sonraki adım hakkında yalan söyleyecekse.

2. İyimser UI

Kullanıcının eylemini sunucu onaylamadan önce hemen gösterin. Arka planda uzlaştırın. Sunucu kabul ederse UI titremez. Etmezse UI, görünür bir geri alma yoluyla eski haline döner.

Linear'ın satır içi issue oluşturması altın standarttır. C'ye bas, başlık yaz, enter'a vur, issue gidiş-dönüş tamamlanmadan listede. Figma'nın imleç ve seçim hareketleri tüm çok oyunculu oturum boyunca iyimserdir. Kullanıcı ağı hiç hissetmez.

Şu durumda kullanın: hata nadir ve geri alınabilirse. Şu durumda geçin: eylem yıkıcıysa veya kullanıcının devam etmeden önce sunucunun yanıtına ihtiyacı varsa.

3. Akışlı kısmi sonuç

İlk parçayı, geri kalanı hâlâ yoldayken gösterin. Kullanıcı sonucu zaten tükettiği için bekleyiş çıktının içinde kaybolur.

Claude'un token akışı, insan hızında okunan yumuşatılmış bir ritimle yayınlanmış en temiz örnektir. Cursor diff'i token token akıtır, böylece kullanıcı model yazmayı bitirmeden kodu okuyor olur. Vercel deploy logunu canlı akıtır, böylece kullanıcı build'i beklemez, izler. Yapay zeka gecikmesi için tasarım yazısı daha geniş gecikme stratejisini kapsar.

Şu durumda kullanın: sonucun doğal bir ritmi varsa. Şu durumda geçin: parçalar tek başına işe yaramıyorsa.

4. İçerik olarak ilerleme

Bekleyişin kendisi değerdir. Deploy logu, build hattı, ajanın akıl yürütme izi. Kullanıcı sonucu beklemiyor. Sonucu okuyor.

Vercel'in deploy görünümü kanonik örnektir. Deploy logu yükleme durumudur ve platformda en çok görüntülenen ekrandır. GitHub Actions adım adım çalışma çıktısıyla aynısını yapar. Cursor'ın ajan paneli çalışırken akıl yürütme izini gösterir, böylece dakikalarca süren bir görev tıkanmış değil, amaçlı hissettirir. v0 ve Lovable bunu prompt'tan uygulamaya yüzeylerinde sunar; orada build akışı yükleme durumu, önizleme ise ödüldür.

Şu durumda kullanın: bekleyiş değerin kendisiyse. Şu durumda geçin: yalnızca nihai durumu önemseyen bir kullanıcı için adımlar işe yaramıyorsa.

5. Markalı spinner

Mikro nabız, gradyan, shimmer. Ürünün bir kişilik jetonu kazandığı an. Stripe'ın ödeme butonu shimmer'ı, Vercel'in gradyan ilerleme çubuğu, Linear'ın geçiş beklemelerindeki mikro nabzı. Hiçbiri işi tek başına yapmıyor. İlk dört desenden birinin üstüne biniyor ve zaten yapısı olan bir bekleyişe marka cilası ekliyorlar.

Şu durumda kullanın: bekleyiş kısaysa ve yüzey yüksek riskliyse. Şu durumda geçin: arkasında iskelet veya akış yoksa. İlk dört desenden biri olmadan markalı spinner, 2026'dan bir hex koduyla 1996'dan kalma bir spinner'dır.

İskeletler neredeyse her zaman spinner'ları yener

İskelet, gelmekte olanın şeklini öngörür. Spinner yalnızca bir yerlerde bir şeyler olduğunu bildirir. Aynı bekleyiş, iki farklı deneyim.

Stripe'ın dashboard iskeleti saat açısından spinner versiyonundan zar zor daha hızlıdır, ama algılanan hız farkı çok daha büyüktür. Kullanıcı kart şeklinde bir yerleşim görür ve veri gelmeden yönünü bulmaya başlar. Metrikler çözüldüğünde göz zaten yerindedir. Spinner'da ise kullanıcı ekranın ortasına bakıp başka yere bakmak için izin bekler. Yerleşimi öngörebiliyorsanız iskelet yayınlayın. Öngöremiyorsanız durum satırı yayınlayın.

İyimser UI hile koddur

Eylem bekleyiş başlamadan önce kaydedildiği için bekleyiş görünmez olur.

Linear her yerde iyimser yayınladı. Issue oluşturma, durum değişikliği, atanan kişi değişimi, etiket ekleme, cycle taşıma. Her biri niyet anında yerel depoya yazar ve sunucu yanıt verdikten sonra uzlaştırır. Figma çok oyunculu modu imleç hareketlerinde, seçimde ve çoğu düzenlemede iyimserdir. Notion doküman düzenlemelerinde iyimserdir. Her ürün yerel yazılım gibi hissettirir çünkü ağ iyimser katmanın altına gizlenmiştir.

Bunun çalışması için iki şey gerekir. Hata nadir ve geri alınabilir olmalı, yoksa UI titrer ve kullanıcı ona güvenmeyi bırakır. Ve hatalar görünür olmalı. Sunucu hatasını sessizce yutan iyimser bir eylem, hiç iyimserlik olmamasından kötüdür, çünkü kullanıcıya işe yaramayan eylemin işe yaradığını öğretir. Her iyimser yazmanın bir geri alması, bir toast'ı veya kullanıcının görebileceği bir rollback'i olmalı.

Harika yükleme durumları için beş kural

Beşten dördünü tutturun, bekleyiş tasarlanmış gibi okunur. Üçünü tutturun, yükleme durumu sonradan akla gelmiş gibi hissettirmeye başlar.

1. Yükleme şekli nihai şekli öngörür. Satırlar için iskelet satırlar, kartlar için iskelet kartlar. İçerik çözüldüğünde yerleşim sıçraması yok.
2. Mümkün olduğunda bekleyişe içerik verilir. Token'ları akıtın, logu gösterin, kısmi sonucu render edin. Okuyan kullanıcı beklemiyordur.
3. 800ms'yi aşan her bekleyiş geri bildirim alır. 800ms altında temiz bir geçiş yeterli. 800ms üstünde kullanıcının sistemin canlı olduğuna dair bir sinyale ihtiyacı var; önce yapı, sonra içerik gelen bir aşamalı ifşa bile olsa.
4. İyimser eylemlerin görünür bir geri alma yolu olur. Bir toast, bir rollback, net bir hata durumu. Kurtarmasız iyimserlik gaslighting'dir.
5. Marka gerekçesi olmadan spinner yok. Markalı spinner'lar ilk dört desenden birinin üstüne biner, onların yerini asla almaz. Ekranda tek şey spinner ise tasarım bitmemiştir.

Daha derin bağlam, daha geniş web tasarım ilkeleri analizinde ve core web vitals'ın yerleşim kaymasını algılanan performans hatası olarak ele alış biçiminde yatar.

Yükleme durumlarını öldüren anti-desenler

Altı hata modu olması gerekenden sık yayınlanıyor. Her biri düzeltilebilir ve her biri şu an bir yerde canlıda.

İlerlemesi olmayan sonsuz spinner. Hiçbir sinyal vermeden on beş saniyedir dönen bir spinner. Kullanıcı isteğin canlı mı, ölü mü, takılı mı olduğunu bilmiyor. Yerine bir durum satırı, ilerleme çubuğu veya akış yüzeyi koyun.

Kapatılamayan sayfa kilitleyen modal. Tüm ekranı ele geçiren ve kullanıcının kaydırmasına, kopyalamasına veya ürünün geri kalanını okumasına izin vermeyen bir yükleme modalı. Bekleyiş rehine krizine döner.

İskelet çözüldüğünde sıçrayan yerleşim. Gerçek yerleşimle eşleşmeyen bir iskelet. Satırlar kayar, kartlar yeniden akar, başlık hareket eder. İskelet farklı bir tasarım değildir, içeriksiz aynı tasarımdır.

Sonsuza dek dönen "Yükleniyor..." metni. Dönen üç nokta, ilerleme yok, durum yok. Kullanıcı iki oturumda onu görmezden gelmeyi öğrenir; bu da yüzeyin sonra yayınlayacağı gerçek her durum için kanalı öldürür.

Hataları sessizce yutan iyimser UI. Eylem UI'da kaydedilir, sunucu başarısız olur, ürün kullanıcıya asla söylemez. Çözüm görünür bir toast, bir geri al butonu veya bir rollback.

100ms'lik bekleyişte markalı spinner'lar. Kullanıcı fark etmeden biten bir bekleyiş için shimmer. Saf yük. Hızlı yüzeyler fade hak eder. Yavaş yüzeyler yapı hak eder.

Bilerek sürtünme tasarlamak, bir bekleyişin kasıtlı olarak görünür olması gereken nadir durumları kapsar. Yükleme durumları onlar değildir. Onlar görünmez olması, tasarlanması veya içeriğe dönüştürülmesi gereken bekleyişlerdir.

Yükleme durumu denetimi

Altı soru. Bir sonraki sürümden önce her yükleme yüzeyini bunlardan geçirin.

1. Yükleme şekli nihai şekli öngörüyor mu? Öngörülebilir yerleşimler için iskeletler, öngörülemeyenler için durum satırları. Çözülürken yerleşim sıçraması yok.
2. Bekleyiş bilgi taşıyor mu? Bir iskelet, bir akış, bir ilerleme logu, bir durum satırı. Üzerinde hiçbir şey olmayan 800ms üstü her bekleyiş bir sızıntıdır.
3. Her bekleyiş için tek bir birincil mesaj var mı? "Dashboard yükleniyor", üst üste binen dört sinyalden iyidir. Tek sinyal, işi yapan görsel hiyerarşi.
4. Yükleme durumu marka sesiyle uyuşuyor mu? Yükleme metnini dolu ekranın yanında okuyun. Ton kayıyorsa yükleme durumu farklı bir marka giyiyordur.
5. İyimser eylemler başarısızlıkta geri alınabilir ve görünür mü? Her iyimser yazmanın bir geri alması, toast'ı veya rollback'i var. Sessiz başarısızlık yok.
6. Yükleme ekranı ürünü bir yabancıya satar mıydı? Gördükleri tek ekran yükleme durumu olsaydı, kaydoldukları ürün gibi hissettirir miydi? Hayırsa, uygulamanızdaki en çok izlenen ekran aynı zamanda en kötü tasarlanmış ekrandır.

Her yükleme durumunun bu altısından geçtiği bir ürün, yavaş bir ağda bile hızlı hissettirir.

Deseni seçin, sonra bekleyişi yayınlayın

Yükleme durumları cila katmanı değildir. Marka katmanı, güven katmanı ve algılanan performans katmanıdır; hepsi kullanıcının her şeyden çok gördüğü ekrana sıkıştırılmış. Ekip bilerek bir seçim yapsa da yapmasa da her bekleyiş bir tasarım kararıdır.

Yapının bilindiği yerde iskelet. Hatanın geri alınabildiği yerde iyimser. Sonucun ritmi olduğu yerde akış. Bekleyişin değer olduğu yerde içerik olarak ilerleme. Markalı spinner yalnızca ilk dördü işini zaten yapıyorsa. Landing page tasarım ilkeleri analizi bu disiplinin pazarlama sayfası versiyonudur.

Yükleme durumunu yavaş olmanın özrü gibi görmeyi bırakın. Toplamda, ürünün kendisidir. Bekleyişi onların zamanına değer kılın.

SSS

İskelet ekran ile yükleme spinner'ı arasındaki fark nedir?

İskelet, yer tutucu yerleşimle nihai içeriğin şeklini öngörür, böylece kullanıcı veri gelmeden yönünü bulmaya başlar. Spinner yalnızca bir şeylerin olduğunu bildirir; şekil yok, yapı yok, önizleme yok. İskeletler algılanan beklemeyi azaltır. Spinner'lar azaltmaz.

İyimser UI ile akışlı yanıt arasında hangisini ne zaman kullanmalıyım?

Kullanıcının eylemi işin kendisiyse, yani issue eklemek, durumu değiştirmek veya kartı taşımak gibi, iyimser UI. İşi sunucu yapıyorsa ve sonucun doğal bir ritmi varsa, yani metin üretimi, log çıktısı veya deploy hattı gibi, akış. İkisi birlikte çalışır.

Düz bir spinner yayınlamak hiç uygun mu?

Yalnızca bir saniyenin altında bir yedek olarak, yalnızca yerleşim gerçekten öngörülemezse ve yalnızca bir marka gerekçesiyle. İskelet, durum satırı veya akış yüzeyi, her algılanan performans metriğinde spinner'ı yener. Varsayılanınız spinner-en-son olsun.

Bekleyişi tasarlayın, ürünü yayınlayın

Bekleyiş, kullanıcının en çok gördüğü ekrandır. En sık edindikleri marka izlenimi, en sık okudukları güven sinyali ve her sayfa yüklemesinde yaptıkları algılanan performans testi. Dashboard'u altı hafta, yükleme durumunu bir öğleden sonra tasarlayan bir ekip, işin yanlış oranını kullanıcının gerçekten yaşadığı yere yayınlıyor demektir.

Yükleme durumlarını lansmandan önceki son sprint yerine ürünün parçası olarak tasarlayan bir ekip istiyorsanız, Brainy'yi tutun. Bekleyişin markanın parçası olduğu ve algılanan performansın gerçek performansı yendiği ürünler yayınlıyoruz.