İdeal ekran neden tek başına yeterli değildir?
Bir ekranın gerçek kullanım süresinin önemli bir bölümü ideal durumda geçmez. Bağlantı yavaşlar, arama sonuç vermez, kullanıcı henüz veri eklememiştir veya servis isteği başarısız olur. Tasarım yalnızca dolu ekranı gösteriyorsa kullanıcı deneyiminin en kırılgan anları tanımsız bırakılmış olur.
Bir ekranın durumu, o ekranın süsü değil davranışıdır. Durum tanımlanmadan akış tamamlanmış sayılmaz.
Her akışta tasarlanması gereken 6 durum
| Durum | Kullanıcının sorusu | Tasarımın cevabı |
|---|---|---|
| İlk kullanım | Burada ne yapacağım? | Kısa açıklama ve tek bir başlangıç eylemi |
| Yükleniyor | Sistem çalışıyor mu? | İlerlemenin sürdüğünü gösteren uygun geri bildirim |
| Boş sonuç | Neden hiçbir şey yok? | Nedeni açıklayan metin ve mümkünse sonraki adım |
| Kısmi veri | Eksik olan ne? | Mevcut içeriği koruyan, eksik kısmı belirten yerel durum |
| Hata | Ne oldu, şimdi ne yapabilirim? | Anlaşılır neden, tekrar deneme veya alternatif yol |
| Başarı | İşlem tamamlandı mı? | Sonucu doğrulayan geri bildirim ve sonraki mantıklı adım |
Boş durum yalnızca boş bir kutu değildir
Boş durum iki farklı nedenle oluşabilir: kullanıcı henüz içerik üretmemiştir ya da yaptığı filtre ve arama hiçbir sonuç döndürmemiştir. İlkinde kullanıcıyı içerik eklemeye yönlendirmek gerekir; ikincisinde filtreyi temizlemek veya sorguyu değiştirmek gerekir. Aynı görseli ve aynı mesajı iki durumda kullanmak, sorunun nedenini kullanıcıdan saklar.
- Durumun neden boş olduğunu tek cümlede söyleyin.
- Kullanıcının yapabileceği tek bir birincil eylem gösterin.
- Eylem mümkün değilse sahte bir buton eklemek yerine beklentiyi açıklayın.
- Arama ve filtre sonucundaki boşluğu, ilk kullanım boşluğundan ayırın.
Yüklenme geri bildirimi süreye göre seçilir
Her bekleme için aynı yüklenme göstergesi kullanılmamalı. Çok kısa işlemlerde gösterge ekranda parlamaya neden olabilir; içeriğin yapısı belliyse iskelet ekran yerleşimin sıçramasını engeller; birkaç saniyeyi aşan işlemlerde ise kullanıcının işlemin sürdüğünü ve ekrandan ayrılıp ayrılamayacağını bilmesi gerekir.
| Tahmini süre | Uygun yaklaşım | Kaçınılması gereken |
|---|---|---|
| 0-300 ms | Çoğu durumda gösterge göstermemek | Kısa süreli görsel yanıp sönme |
| 300 ms-2 sn | İskelet ekran veya yerel gösterge | Tüm ekranı gereksiz yere kilitlemek |
| 2-10 sn | Açık durum metni ve ilerleme geri bildirimi | Belirsiz, sonsuz dönen gösterge |
| 10 sn + | Arka plan işlemi, bildirim veya gerçek ilerleme | Kullanıcıyı açıklamasız bekletmek |
Hata mesajı üç soruyu cevaplamalıdır
- Ne oldu? Teknik hata kodu yerine kullanıcı açısından sonucu söyleyin.
- Verilerim güvende mi? İşlemin tamamlanıp tamamlanmadığını belirsiz bırakmayın.
- Şimdi ne yapabilirim? Tekrar deneme, bilgiyi düzeltme veya destek alma yolunu gösterin.
Hata tüm ekranı ilgilendirmiyorsa tüm ekranı kapatmamalıdır. Örneğin profil fotoğrafı yüklenemediğinde kullanıcının geri kalan profil bilgilerini görmesini engellemek yerine, hatayı fotoğraf alanında göstermek daha doğru bir kurtarma yolu sağlar.
Geliştirmeye hazır tasarım teslimatı
Figma'da tek bir ideal ekran teslim etmek, davranış kararlarını geliştirme aşamasına ertelemektir. Her kritik ekran için durum matrisi hazırlanmalı; içerik, eylem, bileşen varyantı ve geçiş kuralı aynı yerde tanımlanmalıdır.
- Bileşen varyantları: varsayılan, odak, devre dışı, yükleniyor, hata ve başarı
- Gerçekçi uzunlukta örnek içerik ve metin taşması senaryoları
- Mobil ve masaüstü için kırılma davranışları
- Ekranlar arası geçişleri gösteren tıklanabilir prototip
- Hangi hatanın yerel, hangisinin sayfa seviyesinde gösterileceğini belirten notlar