İş Akışını Bozan Tasarım: Sorun Kesinti Değil, Kaybolan Durum

İş akışındaki her kesinti kötü değildir. Ödemeyi onaylatan ekran da bir kesintidir, hesabı silmeden önce soran uyarı da; ikisi de kullanıcıyı bilerek durdurur ve iyi ederler. Sorun kesintinin varlığında değil, kesinti bittikten sonra kullanıcının nereye düştüğünde. Akış tasarımı tartışmalarının büyük kısmı yanlış yerde, adım sayısında dönüyor.

Kaybolan durum, kesintinin kendisinden pahalı

Klasik örnek iTunes'un sözleşme onayıdır. Güncellemeyi başlatırsın, araya kullanıcı anlaşması ekranı girer, onayı verdikten sonra işlem başa sarar ve aynı düğmeye ikinci kez basman gerekir. Buradaki onay ekranını kaldıramazsın, hukuk ekibi kaldırtmaz zaten. Kaldırabileceğin tek şey onaydan sonraki o boşluk: kullanıcının ne yapmak istediği bilgisi sistemde duruyordu, onay akışı onu attı.

Bir akışta adım sayısını kısaltmakla uğraşmaktansa, kesinti sonrası durumu geri yüklemeyi daha güvenilir bulurum. Adım azaltma her ekranda ayrı bir pazarlıktır, bir yerde de durur; yasal onay, iki faktörlü doğrulama, ödeme sağlayıcısına gidiş bir şekilde orada kalır. Durumu saklayıp geri yükleme ise bir kez doğru kurulduğunda bütün kesintiler için çalışır, tasarım aşamasında akla gelmeyenler için de.

Pratikte bu, "kullanıcı nereden geldi ve ne yapmak istiyordu" bilgisini kesintiye giren ekrana taşımak demek. Oturum açma ekranına yönlendirmeden önce hedef adresi saklamak, formu doğrulama hatasıyla geri gönderirken girilen değerleri korumak, ödeme sağlayıcısından dönüşte sepeti değil son adımı göstermek. Hiçbiri zor iş değil; sık atlanmasının sebebi zorluk değil, akışın mutlu senaryo üzerinden tasarlanıp kesinti senaryosunun sonradan yamanması.

Arayüz kusuru mu, altyapı arızası mı

İkisi kullanıcıya aynı hissi verir ama aynı şey değildir. Taşınmış bir eczane otomasyonuna birkaç gün giriş yapılamaması can sıkar, düzelince unutulur. Kontrolleri alışılmadık yere koymuş bir ekran ise her açılışta aynı gecikmeyi üretir, kullanıcı bunu öğrenir ve zamanla o bölümden kaçınmaya başlar. Kalıcı hasarı yapan ikincisidir.

Ayırmanın pratik yolu tekrarlanabilirlik: aynı adımları izleyen ikinci kişi aynı yere takılıyorsa elindeki tasarım sorunudur, altyapı değil. Sunucu logu bu ayrımı tek başına vermez, çünkü kullanıcının kafası karıştığında sistem bir hata üretmez; sadece o oturumda daha fazla tıklama ve daha uzun bekleme görürsün.

"Altyapı sağlam olsun, deneyim kendiliğinden düzelir" cümlesi de bu yüzden yarım doğru. Hızlı yüklenen bir sayfa, kullanıcıyı üç ekran geriye atan bir akışı kurtarmaz. Tersi de geçerli: temiz bir arayüzün altında her on istekten biri zaman aşımına düşüyorsa, kullanıcı arayüzü değil markayı hatırlar.

Aynı bilgiyi ikinci kez sormak

Akışı yoran şeylerin çoğu tek başına ufak. Yan yana gelince kullanıcının kısa süreli belleğini boşaltıyorlar, asıl maliyet orada. En sık rastladıklarım:

• Doğrulama kodu ekranında kodun hangi numaraya gittiğini göstermemek
• Form hatasında dolu alanları temizleyip kullanıcıya baştan yazdırmak
• Aynı işlemi iki farklı ekrana bölüp arada geri dönüşü kapatmak
• Hata mesajında ne olduğunu söyleyip ne yapılacağını söylememek

Bunların hepsi kullanıcıdan hafıza istiyor. Oysa ekranda duran bilgi bedava, hatırlanması istenen bilgi pahalı.

Kullanıcı testi diye yapılan şey çoğu zaman müşteri onayı

Siteyi geçici bir adrese kurup müşteriye "bir bakın" demek yaygın bir alışkanlık ve faydalı bir adım. Ama bu bir kullanıcı testi değil. Müşteri projeyi biliyor, akışı tasarlayan kişiyle haftalardır konuşuyor, hangi düğmenin nerede olduğunu duyduğu için biliyor. Onun sorunsuz tamamladığı bir akış, konuyu ilk kez gören birinin de tamamlayacağı anlamına gelmez. İkisi farklı aşamalardır: müşteri onayı sözleşmeye, test tasarıma bakar.

Gerçek test şuna benziyor: konuyu bilmeyen birine bir görev veriyorsun ("şu ürünü iade et"), ekranı izliyorsun ve susuyorsun. Yol gösterdiğin an test biter. Birkaç kişiyle yapılan böyle bir tur, aylarca fark edilmeyen tıkanmaları genellikle ilk yarım saatte çıkarır; Nielsen Norman Group'un küçük örneklemle test üzerine yazdıkları bu yüzden hâlâ okunuyor.

Testte çıkacak bulguların çoğu da yukarıdaki iki başlığa düşer: ya kullanıcı bir kesintiden sonra yolunu kaybetmiştir, ya da sistemin sessizce yuttuğu bir hatayı kendi hatası sanmıştır. Akışı düzeltmeye bu ikisinden başla, adım saymaya sonra dönersin.