Bir Ürün Arayüzü Neden Güzel Göründüğü Hâlde Kullanılamaz?

Bir tasarım sunumunda herkes memnun ayrılır. Ekranlar temiz, tipografi oturmuş, boşluklar tutarlı. Ürün yayına girer ve birkaç hafta içinde destek kutusuna aynı sorular düşmeye başlar: bunu nereden yapıyoruz, bu kaydedildi mi, o liste neden boş.

İki gözlem de doğrudur. Arayüz gerçekten iyi görünmektedir ve gerçekten zor kullanılmaktadır. Çelişki değildir, çünkü onaylanan şey ile kullanılan şey aynı durum değildir.

Statik bir ekran, kullanıcının nadiren bulunduğu bir anı gösterir: veri idealdir, isimler kısadır, hiçbir şey yüklenmiyordur, hata yoktur ve kullanıcı doğru sayfaya doğrudan gelmiştir. Tasarım o anda değerlendirilir; ürün ise diğer bütün anlarda kullanılır.

Görsel kararların hedefe göre nasıl alındığını görsellik ve kullanılabilirlik dengesi yazısında ele almıştık. Buradaki soru bir adım öteye bakıyor: görsel kararlar doğru alındığında bile bir arayüzü zorlaştıran şeyler nelerdir?

Tasarım, var olmayan bir veriyle onaylanır

Mockup'taki isimler tasarımcı tarafından seçilir ve genellikle güzel sığar. Gerçek veride bir müşteri adı kırk karakter olur, bir ürün başlığı üç satıra taşar, bir kullanıcı profil fotoğrafı yüklememiştir.

Daha önemlisi, mockup çoğu zaman dolu durumu gösterir. Oysa bir arayüzün en kritik anları genellikle boş olduğu andır: ilk giriş, henüz kayıt eklenmemiş liste, sonuç dönmeyen arama. Bu ekranlar tasarlanmadığında yerlerini kendiliğinden bir boşluk alır ve kullanıcı ne yapması gerektiğini anlamaz.

Hata durumları da aynı sebeple eksik kalır. "Bir şeyler ters gitti" metni, tasarım dosyasında bir kez görünür; gerçek üründe kullanıcının tek yol göstericisi olur.

Bunların hepsi tasarlanabilir. Tasarlanmadıklarında, en iyi ekranlara sahip bir ürün en kötü anlarında yalnız bırakır.

Bilgi mimarisi ekran görüntüsünde görünmez

Bir menüyü güzel gösterebilirsiniz. Yanlış gruplanmış bir menüyü de güzel gösterebilirsiniz; ikisi bir görselde birbirinden ayrılmaz.

Bilgi mimarisi, kullanıcı aradığı şeyin nerede olması gerektiğini tahmin etmeye çalıştığında ortaya çıkar. "Ayarlar" içinde mi, "Hesap" içinde mi, yoksa "Yönetim" içinde mi? Bu soruyu her seferinde yeniden sormak zorunda kalan bir kullanıcı, arayüzü güzel bulsa bile yorulur.

Sorun genellikle iki yerden gelir. Birincisi, gruplamanın kullanıcının zihnindeki değil şirketin organizasyon şemasındaki bölünmeyi yansıtmasıdır. İkincisi, isimlendirmenin iç jargonu taşımasıdır: ekip içinde herkesin bildiği bir kısaltma, dışarıdan gelen için anlamsız bir başlıktır.

Bunu görselde fark etmek zordur çünkü menüyü tasarlayan kişi zaten içeriğin nerede olduğunu bilmektedir.

Etiket, ne olacağını söylemiyor

Bir butonun ne yaptığı, üstündeki yazıdan anlaşılmalıdır. Uygulamada çoğu buton ne yaptığını değil, hangi kategoriye ait olduğunu söyler.

"Kaydet" ile "Yayınla" arasındaki fark kullanıcı için büyüktür; ikisi de "Tamam" yazan bir butonun arkasına gizlendiğinde kullanıcı denemek zorunda kalır. Denemenin bedeli düşükse sorun küçüktür. Geri alınamayan bir işlemse, güven bir anda kaybolur.

Aynı belirsizlik onay pencerelerinde de sık görülür. "Bu işlemi yapmak istediğinizden emin misiniz?" sorusu, ne olacağını söylemediği için gerçek bir onay üretmez; kullanıcı okumayı bırakır ve refleksle onaylar.

Daha iyi bir alışkanlık, etiketi sonuçla yazmaktır: "Siparişi iptal et", "Taslağı yayınla", "Üyeliği sonlandır". Bu, tasarım değil dil kararıdır ve genellikle en ucuz iyileştirmedir.

Bilişsel yük tek ekranda değil, adımlar arasında birikir

Tek bir ekran sade olabilir ve akış yine de yorucu olabilir.

Bunun en yaygın biçimi, kullanıcıdan bir şeyi akılda tutmasını istemektir. Üçüncü adımda sorulan soru, birinci adımda görülen bir bilgiye dayanıyorsa ve o bilgi artık ekranda değilse, kullanıcı geri gitmek zorunda kalır. Geri gittiğinde girdiği veriler kaybolursa, akış tamamlanmaz.

İkinci biçim, aynı anda çok fazla seçenek sunmaktır. Bir ekranda beş eşit ağırlıkta yol varsa, kullanıcı hangisinin kendi durumuna uyduğunu ayırt etmek için ekstra iş yapar.

Üçüncüsü, kararın erken sorulmasıdır. Kullanıcının henüz bilmediği bir şeyi seçmesi istendiğinde — örneğin kullanmadığı bir özelliğin ayarını — o karar tahmine dönüşür.

Ekran zamanla başka bir işin ekranı hâline gelir

Bir arayüzün ilk hâli genellikle nettir, çünkü tek bir iş için tasarlanmıştır. Zorluk sonradan gelir.

Ürün büyüdükçe her yeni özelliğin bir yere konması gerekir ve en uygun yer neredeyse her zaman mevcut, iyi çalışan bir ekrandır. Tek tek bakıldığında bu kararların hepsi makuldür. Toplamda, bir işi yapmak için tasarlanmış ekran altı işi birden taşımaya başlar.

Sonuç, kullanıcının birincil görevinin görsel olarak değil kavramsal olarak kaybolmasıdır. Ekran hâlâ düzenlidir; ama artık ne için var olduğunu söylemez. Yeni gelen bir kullanıcı, kendi işine ait olmayan beş şeyi eleyerek başlamak zorunda kalır.

Bunun tipik işareti, bir ekranın açıklamasının "ve" ile büyümesidir: burası siparişleri görüntüleme ve iade başlatma ve fatura indirme ve müşteri notu ekleme ekranıdır. Cümle uzadıkça ekranın odağı kısalır.

Çözüm her zaman ekranı bölmek değildir. Çoğu zaman yeterli olan, birincil görevi yeniden ilan etmek ve geri kalanı ikincil düzeye indirmektir. Bunun için önce sorunun sorulması gerekir: bu ekran bugün kimin, hangi işi için var?

Bu soru düzenli olarak sorulmadığında, arayüz kötüleşmez — yalnızca giderek daha fazla şeyin ortak alanı hâline gelir.

Aynı şey her ekranda aynı davranmıyor

Tutarsızlık, tek başına bakıldığında hiçbir ekranı kötü göstermez. Toplamda ise kullanıcının öğrendiğini boşa çıkarır.

Bir ürün içinde silme işlemi bir yerde onay isterken başka bir yerde istemiyorsa, kullanıcı hangisinin geçerli olduğunu bilemez. Bir liste bir ekranda otomatik kaydediyor, diğerinde kaydet butonu bekliyorsa, güven yerini dikkate bırakır — ve dikkat yorucudur.

Bu, tasarım kalitesinden çok üretim biçiminden kaynaklanır: ekranlar farklı zamanlarda, farklı kişiler tarafından, aradaki kararlar yazılı olmadan yapılmıştır. Mobil deneyimde sık yapılan hatalar da benzer bir kökten gelir.

Gerçek senaryoyla denemek

Bir arayüzü değerlendirmenin en güvenilir yolu, onu bir görev üzerinden çalıştırmaktır.

Bunun için laboratuvar gerekmez. Ürünü hiç görmemiş birine tek cümlelik bir görev verilir — "bu hesaba yeni bir kullanıcı ekleyin" — ve yalnızca izlenir. Yol gösterilmez, soru cevaplanmaz. Beş kişiyle yapılan böyle bir deneme, çoğu zaman aylardır tartışılan konuları birkaç dakikada çözer.

İkinci yararlı alışkanlık, ürünü kötü koşullarda denemektir: yavaş bağlantı, uzun isimler, boş hesap, yanlış girilen form. Bu koşullar egzotik değildir; yalnızca tasarım dosyasında bulunmazlar.

Denemeyi kimin izlediği de sonucu değiştirir. Ürünü yapan kişi bir kullanıcının tıkandığı anı kendi gözüyle gördüğünde, aynı bilginin rapor olarak iletilmesinden çok daha hızlı karar alır. Bulguyu aktarmak yerine paylaşmak, tartışmanın büyük kısmını baştan bitirir.

Sonuç

Güzel ama kullanılamayan arayüzlerin çoğu, kötü tasarımdan değil eksik tasarımdan çıkar. Tasarlanan şey ürünün en iyi hâlidir; kullanılan şey ise ortalama hâlidir.

Aradaki farkı kapatmak yeni bir görsel dil gerektirmez. Genellikle üç şey yeter: boş, hatalı ve yavaş durumları da tasarlamak, etiketleri sonuca göre yazmak ve akışı baştan sona bir kez gerçek bir insanla yürütmek.

Ürün ve arayüz tasarımı çalışmalarımızda bu üçü, sonda yapılacak bir kontrol listesi değil, tasarımın kendisinin parçasıdır.