Ekranın ters gittiği anı tasarlamak: boş durum, hata ve kenar senaryoları
Beceri rehberi

Ekranın ters gittiği anı tasarlamak: boş durum, hata ve kenar senaryoları

Hazırlayan: Mindset Institute EditörlüğüGüncellendi: 5 dk okuma

Boş durum, hata durumu ve kenar senaryolarının tasarımı: durum envanteri, hata mesajı yazımı, kurtarma yolları ve standartlaştırma yöntemi.

Mutlu yol dışında kalan ekranlar neden önemlidir?

Ürün tasarımında sıklıkla veriyle dolu, hatasız, hızlı çalışan ekran çizilir; bu mutlu yol (happy path) olarak adlandırılır. Oysa kullanıcı ürünle ilk karşılaştığında liste boştur, ağ bağlantısı zayıflayabilir, form eksik doldurulur, yetkisi olmayan bir sayfaya gider. Bu anlar tasarlanmamışsa kullanıcı boş beyaz bir ekran, anlaşılmaz bir hata kodu ya da hiçbir geri bildirim vermeyen bir düğme ile karşılaşır.

Bu ekranlar ürünün olgunluğunu gösterir. Kullanıcı güveni, her şey yolundayken değil sorun çıktığında oluşur. İyi tasarlanmış boş durum yeni kullanıcıyı ilk adıma yönlendirir; iyi tasarlanmış hata ekranı kullanıcıya neyin yanlış gittiğini söyler ve nasıl devam edeceğini gösterir.

Bu durumların tasarımı ayrı bir iş kalemidir ve geliştirme sırasında geride bırakıldığında sıklıkla yazılımcının geçici metniyle yayına çıkar. Tasarım sürecine baştan eklenmeleri hem kullanıcı deneyimini hem de ekip içi tutarlılığı iyileştirir.

Durum envanteri: hangi durumlar var?

Tasarımın ilk adımı, bir ekranın alabileceği tüm durumları listelemektir. Buna durum envanteri denir. Tipik bir veri ekranının durumları şunlardır: • Yükleniyor: veri henüz gelmedi. • Boş: veri yok, çünkü hiç oluşturulmadı ya da henüz gelmedi. • Sonuç yok: arama ya da filtre hiçbir kayıt döndürmedi. • Kısmi: veri var ama bir bölümü yüklenemedi. • Hata: istek başarısız oldu; geçici mi, kalıcı mı, kullanıcı kaynaklı mı? • Yetki yok: kullanıcının bu içeriği görme izni yok. • Çevrimdışı: bağlantı kesildi. • Başarı: işlem tamamlandı.

Envanter, tasarımcı, yazılımcı ve ürün sorumlusunun ortak bir listede buluşmasını sağlar. Hangi durumun hangi koşulda tetiklendiği ve kullanıcıya ne gösterileceği tabloya yazılır. Böylece ekranın kapsamı baştan netleşir ve unutulan durum son anda kodlayıcının tahminiyle doldurulmaz.

Boş durum tasarımı

Boş durum, aslında bir fırsattır. Farklı boş durum türleri ayırt edilmelidir, çünkü her birine farklı yaklaşılır.

İlk kullanım boşluğu: Kullanıcı henüz hiçbir şey oluşturmamıştır, örneğin ilk proje, ilk müşteri. Burada ekranın görevi ürünün ne işe yaradığını açıklamak ve ilk adıma net bir eylem düğmesi sunmaktır.

Kullanıcı temizledi boşluğu: Kullanıcı tüm gelen kutusunu işlemiş ya da tüm görevleri bitirmiştir. Burada kısa ve olumlu bir geri bildirim yeterlidir; fazla süs gerekmez.

Sonuç yok boşluğu: Arama ya da filtre hiçbir kayıt bulamamıştır. Burada filtreyi temizleme, yazımı kontrol etme ya da farklı terimler deneme önerisi yardımcı olur.

Boş durumun metni kısa, somut ve eyleme dönük olmalıdır. Güzel bir illüstrasyon tek başına yetmez; kullanıcı ne olduğunu ve ne yapabileceğini anlamalıdır. Marka sesi burada devreye girebilir ama bilgi önde kalmalıdır. Aşırı sevimli dil, ciddi bir iş aracında kullanıcıyı rahatsız edebilir.

Hata durumları ve kurtarma yolları

İyi bir hata mesajı kullanıcının şu soruları yanıtlamasını sağlar: ne oldu, neden oldu ve şimdi ne yapabilirim? Teknik hata kodu ya da sunucu mesajı tek başına bu soruları yanıtlamaz. Kod destek ekibi için faydalı olabilir, ama kullanıcıya gösterilen ana metin sade bir dille yazılmalıdır.

Hata türlerini ayırmak gerekir: • Kullanıcı hatası: Yanlış biçimde girilen bilgi. Hata alanın yanında gösterilmeli, nasıl düzeltileceği söylenmelidir. • Sistem hatası: Sunucu ya da ağ sorunu. Kullanıcıyı suçlamayan, yeniden deneme ya da sonra tekrar bakma seçeneği sunan metin gerekir. • Yetki hatası: Kullanıcının erişim izni yoktur. Kime başvurması gerektiğini söylemek yardımcı olur. • Kalıcı hata: Aranan sayfa ya da kayıt artık yok. Ana sayfaya ya da ilgili listeye dönüş yolu verilmelidir.

Kurtarma yolu, hata ekranının en önemli parçasıdır. Çıkmaz sokak yaratmayın: her hata ekranında kullanıcının atabileceği en az bir adım olmalıdır. Form hatasında girilen verinin korunması, kullanıcının baştan yazmak zorunda kalmaması önemlidir.

Hata mesajı yazımı: örnek bir dönüşüm

Örneğin ödeme formunda kullanıcı yanlış kart bilgisi girdiğinde sistemin gösterdiği ilk metin şudur: Hata, işlem başarısız. Bu mesaj ne olduğunu, nedenini ve çözümü söylemez. Aynı durum şöyle yazılabilir: Kart bilgileri doğrulanamadı. Kart numarasını ve son kullanma tarihini kontrol edip tekrar deneyin. Burada kullanıcı suçlanmaz, sorunun nerede olabileceği belirtilir ve devam yolu verilir.

Mesaj yazarken şu ilkeler işe yarar. Kullanıcının diliyle yazın, dahili terimlerden kaçının. Kullanıcıyı suçlayan ifadelerden (geçersiz giriş yaptınız gibi) kaçının, durumu nötr anlatın. Sorunun yerini gösterin; satır içi hata, sayfa üstündeki genel uyarıdan daha etkilidir. Çözümü söyleyin. Üzgünüz gibi aşırı özür ifadelerini ve mizahı yalnızca durum ciddi değilse kullanın; veri kaybı gibi durumlarda mizah güveni zedeler.

Hata mesajı erişilebilir de olmalıdır: yalnızca renkle belirtilmemeli, ekran okuyucuya duyurulmalı ve odak, hataya taşınmalıdır.

Kenar senaryoları ve standartlaştırma

Kenar senaryoları, beklenen akıştan uzaklaşan nadir ama gerçek durumlardır: çok uzun bir isim, hiç görseli olmayan kayıt, aynı anda farklı kişilerin aynı kaydı düzenlemesi, kullanıcının işlemi yarıda bırakması, çok büyük bir veri listesi, yavaş bağlantı, oturumun işlem sırasında süresinin dolması. Her biri tasarlanmazsa ürün bozulmuş görünür.

Kenar senaryolarını bulmak için sistematik sorular sorulur: Veri hiç olmazsa ne olur? Çok fazla olursa ne olur? Beklenmedik biçimde gelirse? İşlem yarıda kesilirse? Aynı anda birden çok kullanıcı varsa? Bu sorular durum envanterine eklenir.

Standartlaştırma, bu çalışmanın kalıcı kazanımıdır. Boş durum, hata ve yükleme düzenleri tasarım sisteminde bileşen olarak tanımlanır, metin tonu ve yapısı için yazım kuralı belirlenir. Böylece her ekip aynı sorunu yeniden çözmez ve ürün boyunca tutarlı bir deneyim oluşur. Standart, katı bir kalıp değil bir başlangıç noktasıdır; bağlama göre uyarlanır ama sebepsiz sapılmaz.

Sık yapılan hatalar

  • Boş durumu tasarlamamak; kullanıcı ilk girişte boş bir tablo ile baş başa kalır.
  • Hata mesajında yalnızca teknik kod göstermek.
  • Kullanıcıyı suçlayan ya da belirsiz dil kullanmak.
  • Hata ekranında çıkış yolu bırakmamak.
  • Form hatasında girilen veriyi silmek.
  • Tüm hata türlerini aynı genel mesajla karşılamak.
  • Yükleme durumunu atlayıp boş durumla karıştırmak; veri gelmeden önce boş ekran göstermek kullanıcıyı yanıltır.
  • Hata durumlarını yalnızca geliştirme sonunda eklemek; tasarım ile kod arasında uyumsuzluk çıkar.
  • Kenar senaryolarını gerçek veriyle sınamamak; örnek verilerle her şey düzgün görünür.

Mindset programlarında nerede çalışılır?

Boş Durum, Hata Durumu ve Kenar Senaryosu Tasarımı eğitimi, durum envanteri ve kapsam, boş durum tasarımı, hata durumları ve kurtarma ile kenar senaryoları ve standartlaştırma modüllerinden oluşur.

İlgili Mindset programı

Boş Durum, Hata Durumu ve Kenar Senaryosu Tasarımı

Sık sorulanlar

Sık sorulan sorular

Boş durum ekranında neler bulunmalıdır?

Durumun ne olduğunu açıklayan kısa bir metin, ürünün değerini ya da sonraki adımı gösteren cümle ve net bir eylem düğmesi bulunmalıdır. İllüstrasyon destekleyicidir ama tek başına yetmez. Boşluğun türüne göre ilk kullanım, temizlenmiş liste ya da sonuç yok mesajı değişir.

İyi bir hata mesajı nasıl yazılır?

Kullanıcının diliyle, suçlamadan ve şu sorulara cevap vererek yazılır: ne oldu, neden oldu, şimdi ne yapılabilir. Hatayı ilgili alanın yanında göstermek, çözümü açıkça söylemek ve gerekirse teknik kodu ikincil bilgi olarak vermek iyi bir yaklaşımdır.

Durum envanteri neden gerekir?

Bir ekranın tüm durumlarını önceden listelemek, unutulan durumların son anda geliştiricinin tahminiyle doldurulmasını önler. Tasarımcı, yazılımcı ve ürün sorumlusu ortak bir tablo üzerinde hangi durumun hangi koşulda tetiklendiğini ve ne gösterileceğini netleştirir.

Hata mesajında mizah kullanılmalı mı?

Yalnızca sonucu ciddi olmayan durumlarda ve markanın sesiyle uyumluysa. Sayfa bulunamadı gibi zararsız bir durumda hafif bir ton kabul görür. Veri kaybı, ödeme ya da güvenlik hatasında mizah, kullanıcının endişesini küçümsüyormuş gibi algılanır ve güveni azaltır.

Kenar senaryoları nasıl bulunur?

Veri hiç yoksa, çok fazlaysa, beklenmedik biçimdeyse, işlem yarıda kesilirse ya da birden çok kullanıcı aynı anda işlem yaparsa ne olacağı sistematik sorulur. Gerçek ve uç veriyle prototipi denemek, örnek verilerle görünmeyen sorunları ortaya çıkarır.

Boş Durum ve Hata Ekranları Nasıl Tasarlanır