Adımların Sırası: Kullanıcıdan Ne Zaman Ne İstemeli

Bir akışın adımları tek tek doğru olabilir, sıraları yanlış olduğu için yine de dağılır. Kullanıcıdan istenen şeyin kendisi kadar, ne zaman istendiği de bir tasarım kararıdır. Bildirim izni, üyelik formu, profil fotoğrafı: her birinin işe yaradığı bir an var, ama o an genellikle açılış ekranı değil.

Aynı talep, farklı anda farklı bedel

Bir uygulamayı yeni açan kişi henüz ne aldığını bilmiyor. Karşılığında ne vermeye razı olur? Neredeyse hiçbir şey. Bildirim iznini açılış ekranına koymam; oradan gelen “izin ver” penceresi kullanıcıya bir teklif değil, bir vergi gibi görünür ve reddedilen izin çoğu platformda kolay kolay geri gelmez. Aynı istek, kişi ilk siparişini verdikten sonra “kargo çıkınca haber verelim mi” biçiminde sorulduğunda tamamen başka bir şeye dönüşür.

Peki her durumda böyle mi? Değil. Kullanıcının zaten güvenlik beklentisiyle geldiği bir bankacılık uygulamasında işlem bildirimi açılışta sorulabilir, çünkü talebin gerekçesi kullanıcının kafasında hazır duruyor. Ayrım isteğin erken ya da geç olmasında değil: kullanıcı o anda gerekçeyi kendi başına kurabiliyor mu, kuramıyor mu.

Kademeli açıklama nereye kadar

Kullanıcıya bir seferde yalnızca ihtiyacı olanı göstermek iyi bir ilke, ama sınırsız değil ve bedeli çoğu yazıda atlanıyor. Her yeni ekran bir bırakma noktası ekler. Adım başına %90’ı devam ettiren bir akış kulağa gayet iyi geliyor; beş adım sonunda elde kalan oran 0,90’ın beşinci kuvveti, yani yaklaşık %59. Sekiz alanlı bir formu “yormayalım” diye beş ekrana bölmek, tek başına kaybı azaltmaz, sadece yeni yerlere dağıtır.

Bölme kararını alan sayısına göre değil, alanlar arasındaki bağa göre vermek gerekir. Alanların hepsi zorunlu ve birbirinden bağımsızsa tek sayfa daha iyi çalışır: kullanıcı ne kadar iş kaldığını görür, tarayıcı otomatik doldurur, geri dönmek bedava olur. Alanların bir kısmı önceki cevaba bağlıysa bölmek kazandırır, çünkü kimse kendisiyle ilgisi olmayan on beş alanı görmeden geçmiş olur. Kısacası kademeli açıklamanın kazandırdığı şey ekran sayısı değil, gösterilmeyen alan sayısı.

Geri dönüp düzeltmenin faturası

“Kullanıcı her aşamada geri dönüp cevabını değiştirebilmeli” cümlesi arayüzde küçük bir bağlantı gibi görünür. Uygulamada karşılığı başkadır. Her adımı sırayla kaydeden bir yapı yerine, akış tamamlanana kadar taşınan bir taslak durumu tutmanız gerekir; üstüne değişen bir cevabın sonraki adımlarda toplanmış veriyi geçersiz kılıp kılmadığını çözecek bir kural katmanı gelir. Kargo ülkesini değiştiren kullanıcının seçtiği teslimat yöntemi hâlâ geçerli mi sorusunun cevabı bir yerde yazılı olmak zorunda.

Bu maliyet gerçek, ama alternatifi daha pahalı. Düzeltilemeyen bir alanla karşılaşan kullanıcı ya süreci baştan başlatır ya da bırakır; ikisi de destek ekibine iş çıkarır. Karar verilmesi gereken şey “geri dönüş olsun mu” değil, hangi alanların geri dönülebilir olacağı. Üç alanı serbest bırakıp gerisini kilitlemek, hepsini kilitlemekten de hepsini açmaktan da daha iyi bir denge kuruyor.

Dönülemeyecek yeri önceden söylemek

Bir seçim sonradan değiştirilemeyecekse bunu kullanıcı seçim anında bilmeli, sonuç ekranında değil. Fatura tipi, kullanıcı adı, para birimi gibi alanlar buna girer. Uyarının yeri alanın hemen yanı; onay ekranındaki uzun bilgilendirme metni okunmuyor.

Aynı mantık özet ekranları için de geçerli. Kullanıcının önceki adımlarda ne girdiğini hatırlamak zorunda kalmaması, akışın kısa süreli bellek yükünü azaltmanın en ucuz yolu: girilen değerleri sonraki adımın üstünde küçük bir özet olarak göstermek çoğu zaman yetiyor.

Sırayı neye göre kurmalı

Akışı tasarlarken işe yarayan tek soru şu: kullanıcı bu adıma geldiğinde ne kazanmış oldu? Cevap yoksa istek erken demektir, geri alın. Cevap varsa istek doğru yerdedir, üstelik o kazanımı isteğin metninde hatırlatabilirsiniz. Zamanlama meselesi bir nezaket kuralı değil; hangi adımda ne kadar kredi biriktiğinin hesabı.