Veri Tablolarınız İçin Tek Bir Genel Boş Durum (Empty State) Kullanmayın

Çoğu veri tablosu tek bir mesajla gelir: "Veri yok."

Tasarım incelemesinde iyi görünür. Ancak canlı ortamda (production) destek taleplerine (support tickets) yol açar.

Boş bir tablo üç farklı anlama gelir. Her durum için özel bir tasarım, özel bir metin ve özel bir eylem gerekir.

Ayrı ayrı tasarlamanız gereken üç durum şunlardır:

  1. İlk kullanım (Henüz veri mevcut değil) Kullanıcı yenidir. Bu tablonun ne işe yaradığını ve nasıl başlayacağını bilmek ister. • Hedef: Kullanıcıyı sisteme alıştırmak (onboarding). • Metin: Tablonun amacını açıklayın. • Eylem: İlk öğeyi oluşturmak veya veri içe aktarmak için bir buton sağlayın. • Kaçının: "Veri yok" gibi bir çıkmaz mesajdan.

  2. Filtrelenmiş boş durum (Veri var ancak filtreler gizliyor) Kullanıcı, sıfır sonuç döndüren filtreler uygulamıştır. Genellikle aracın bozuk olduğunu düşünürler. • Hedef: Kullanıcının verilerini bulmasına yardımcı olmak. • Metin: Hangi filtrelerin aktif olduğunu açıkça belirtin. • Eylem: Tüm filtreleri temizlemek veya düzenlemek için bir buton sağlayın. • Kaçının: Aktif filtreleri görmezden gelen genel bir mesajdan.

  3. Yükleme hatası (İstek başarısız oldu) Sunucu bir hata döndürdü veya ağ bağlantısı kesildi. • Hedef: Kullanıcının durumu düzeltmesine yardımcı olmak. • Metin: Yüklemenin başarısız olduğunu açıklayın ve bir zaman damgası veya hata kodu gösterin. • Eylem: Bir yeniden dene butonu sağlayın. • Kaçının: Sorun aslında teknik bir hata iken kullanıcıya "Veri yok" demekten.

Ekipler bu konuda neden başarısız olur:

  • Boş durumları sürecin çok geç bir aşamasında tasarlarlar.
  • Sadece demo verilerle test yaparlar, bu yüzden boş durumu asla görmezler.
  • Boş durumları uç durumlar (edge cases) olarak görürler.

Gerçekte, boş durumlar etkisi yüksek (high-leverage) anlardır. İyi bir boş durum, bir kullanıcıyı dakikalar içinde sıfırdan değere taşır. Kötü bir durum ise kullanıcıyı kafa karışıklığı ve hayal kırıklığı içinde bırakır.

Tablo bileşeninizi bu koşulları ayrı ayrı yönetecek şekilde oluşturun. Bunları şimdi tasarlamak çok az maliyetlidir ancak daha sonra büyük miktarda destek süresinden tasarruf sağlar.

Source: https://dev.to/137foundry/why-the-empty-states-in-a-data-table-deserve-three-separate-designs-instead-of-one-generic-message-1il4