Kullanıcı Akışı (User Flow) Nasıl Çizilir?

Ekran tasarımına doğrudan geçen ekipler, akışı ekranları çizerken keşfeder. Sonuç tanıdıktır: ödeme reddedildiğinde kullanıcının nereye döneceği, oturum süresi dolduğunda girilen bilgilerin ne olacağı, aynı saate iki kişi aynı anda randevu almaya çalışırsa ne olacağı geliştirme sırasında sorulur. Kullanıcı akışı bu soruları ekran çizilmeden önce sormanızı sağlar. Bu yazı akışın ne olduğunu, benzer belgelerden farkını, hangi sembollerle çizileceğini ve bir randevu alma örneği üzerinden hata dallarının nasıl ekleneceğini anlatıyor.

Kullanıcı akışı, görev akışı ve yolculuk haritası

NN/g kullanıcı akışını, bir ürünle yapılan yaygın bir görevi tamamlamak için gereken tipik ya da ideal adımları tarif eden etkileşimler dizisi olarak tanımlar 1. Yolculuk haritası ise bir kişinin bir hedefe ulaşmak için geçtiği sürecin görselleştirilmesidir ve kullanıcının eylemlerinin yanında düşüncelerini ve duygularını da içerir 2.

"Görev akışı" terimi kaynaklarda tutarlı biçimde tanımlanmaz. Sektörde genellikle tek bir görevin, kullanıcı tipine göre dallanmayan, doğrusal adımlarını anlatmak için kullanılır. Görevlerin yapısını çözmek için NN/g'nin anlattığı hiyerarşik görev analizi daha sistematik bir yoldur: kullanıcının hedefi ana görevlere, ana görevler de alt görevlere bölünür 3.

NN/g'ye göre süreç birden çok kanala yayılıyorsa ya da günler ve haftalar sürüyorsa yolculuk haritası, etkileşim tek bir ürün içinde dakikalar ya da saatler içinde tamamlanıyorsa kullanıcı akışı daha uygun araçtır 1.

Çizmeden önce yazılması gerekenler

Bir akışı çizmeye başlamadan önce şu dört bilgiyi tek bir paragrafta yazın. Bu paragraf, akışı okuyan herkes için bağlamı sabitler:

1. Kullanıcı ve hedef: Kim, neyi başarmak istiyor? Örnek: "Kliniğe ilk kez gelecek bir hasta, bu hafta içinde diş kontrolü için randevu almak istiyor."
2. Giriş noktası: Kullanıcı akışa nereden giriyor? Ana sayfa, bir bildirim, bir SMS bağlantısı ya da arama sonucu farklı akış başlangıçlarıdır.
3. Başarı koşulu: Akış ne zaman başarılı biter? "Randevu kaydedildi ve onay mesajı gönderildi" gibi ölçülebilir bir cümle yazın.
4. Kısıtlar: Üyelik zorunlu mu, ödeme alınıyor mu, aynı anda kaç randevu tutulabilir, hangi bilgiler yasal olarak gerekli?

Bu bilgileri araştırmadan topladıysanız akış gerçek davranışa dayanır. Görev analizi, kullanıcıların farklı tiplerinin (örneğin ilk kez gelen ve düzenli gelen hasta) aynı hedefe farklı yollardan gidebildiğini gösterir 3.

Hangi sembollerle çizilir?

Akış şemaları için uluslararası bir standart vardır: ISO 5807, veri, program ve sistem akış şemalarında kullanılacak sembolleri ve kuralları tanımlar ve 2019'da gözden geçirilerek geçerliliği teyit edilmiştir 5. Ürün tasarımında ise genellikle bu sembollerin sadeleştirilmiş bir alt kümesi kullanılır. Ekip içinde anlaşılır olması, standarda birebir uymasından daha önemlidir. Aşağıdaki küme çoğu akış için yeterlidir:

İki kural akışın okunabilirliğini belirgin biçimde artırır: her karar düğümünden çıkan okların üzerine yanıtı yazın ("Evet", "Hayır", "Süre doldu") ve mutlu yolu ana eksende düz bir çizgi olarak tutup hata dallarını yanlara açın.

Örnek: klinik randevu alma akışı

Aşağıdaki örnek kurgusaldır ve herhangi bir gerçek ürünü anlatmaz. Önce mutlu yol, yani her şeyin yolunda gittiği senaryo çizilir:

[Başla: "Randevu al" düğmesi]
  → Hizmet seçimi ("Diş kontrolü")
  → Şube seçimi ("Kadıköy")
  → Tarih ve saat seçimi ("Perşembe 14:30")
  ◇ Kullanıcı giriş yapmış mı?
      Evet → Bilgileri kontrol et
      Hayır → Telefon numarası + SMS kodu → Bilgileri kontrol et
  → Bilgileri kontrol et (hizmet, şube, saat, ad, telefon)
  → "Randevuyu onayla"
  ◇ Saat hâlâ boş mu?
      Evet → Onay ekranı + SMS
      Hayır → "Bu saat az önce doldu. Size en yakın boş saatler:" → Tarih ve saat seçimi
[Bitiş: Onay ekranı]

Bu taslakta iki şey dikkat çeker. Birincisi, giriş yapma adımı akışın başına değil, kullanıcının randevuya değer verdiği noktaya, saat seçiminden sonraya konmuştur. İkincisi, "Bilgileri kontrol et" adımı GOV.UK Design System'deki cevapları kontrol etme kalıbına dayanır: kullanıcı bir bilgiyi değiştirmek için geri gittiğinde, işlemi baştan yapmak zorunda kalmadan yeniden kontrol sayfasına döner 7. Aynı kalıp, işlemin kullanıcı onaylayana kadar tamamlanmadığını açıkça belirtmeyi önerir 7.

Birden çok rol varsa: kulvarlı akış

SaaS ürünlerinde görevler çoğu zaman tek kişiyle bitmez. Randevu örneğinde hasta randevuyu alır, ama klinikteki resepsiyon görevlisi randevuyu onaylayabilir, erteleyebilir ya da iptal edebilir. Bu durumda akışı yatay kulvarlara bölmek okumayı kolaylaştırır: üstte hasta, ortada sistem, altta klinik personeli. Bir rolün eylemi diğer rolün ekranında bir değişiklik yaratıyorsa (örneğin personel randevuyu ertelediğinde hastaya bildirim gitmesi), ok bir kulvardan diğerine geçer.

Kulvarlı çizim, ekran tasarımında sık unutulan soruları da görünür kılar: Hasta, personelin yaptığı değişikliği nerede görecek? Personel aynı anda iki hastanın aynı saate yazıldığını fark ederse ne yapacak? Bildirim gitmezse kim sorumlu? Bu sorular ürün ekibi, destek ekibi ve geliştiricilerle birlikte yanıtlanmalıdır; çünkü yanıtlar çoğu zaman ekranı değil, iş kuralını değiştirir.

Hata ve kenar durumlarını eklemek

Mutlu yol çizildikten sonra her adımda "burada ne ters gidebilir?" sorusunu sorun. Randevu örneği için tipik dallar şunlardır:

• Doğrulama hatası: Telefon numarası eksik ya da hatalı. GOV.UK Design System, hata mesajının ilgili alanın yanında ve sayfanın üstündeki hata özetinde gösterilmesini, kullanıcının girdiği bilgilerin silinmemesini önerir 8.
• Seçilen saatin dolması: Kullanıcı saati seçtikten sonra başka biri aynı saati almış. Akış kullanıcıyı başa değil, saat seçimine ve en yakın alternatiflere döndürmelidir.
• SMS kodunun gelmemesi ya da süresinin dolması: "Kodu yeniden gönder" dalı ve bir bekleme süresi.
• Bağlantının kopması: Onay düğmesine basıldı ama yanıt gelmedi. Kullanıcı iki kez basarsa iki randevu mu oluşur? Bu soru akışta yanıtlanmalıdır.
• Uygun saat olmaması: Seçilen şubede o hafta boş saat yok. Boş bir liste yerine başka şube ya da tarih öneren bir durum tasarlanmalıdır.
• Kullanıcının zaten randevusu olması: Aynı hizmet için ikinci randevuya izin veriliyor mu?
• Geri dönme: Kullanıcı tarayıcının geri düğmesine basarsa seçimler korunuyor mu? GOV.UK, bazı kullanıcıların veri girerken tarayıcı geri düğmesine güvenmediğini, bu yüzden soru sayfalarının üstüne bir geri bağlantısı konmasını önerir 6.

Uygunluk ya da yetki sorunlarını doğrulama hatasıyla karıştırmayın. GOV.UK, kullanıcının uygun olmadığını ya da bir işlem için izni olmadığını söylemek için hata mesajı bileşeninin kullanılmamasını önerir 8; bu durumlar akışta ayrı bir sayfa olarak gösterilmelidir. Hata ve boş durum metinlerinin nasıl yazılacağını boş durum ve hata mesajları yazısında ayrıca ele aldık.

Akıştan ekranlara geçiş

Akış onaylandığında her dikdörtgen bir ekran adayıdır. Bu noktada iki yaklaşım işe yarar. Birincisi, GOV.UK'nin "her sayfada tek soru" ile başlama önerisidir: tek soru sormak, kullanıcının ne istendiğini anlamasına ve o soruya odaklanmasına yardım eder 6. Aynı kaynak, araştırma destekliyorsa ilişkili soruların gruplanabileceğini de belirtir 6; örneğin hizmet ve şube seçimi tek ekranda birleşebilir.

İkincisi, akışı wireflow'a dönüştürmektir. Wireflow, tel kafes düzeyindeki ekran tasarımlarını akış şemasına benzer sade bir etkileşim gösterimiyle birleştirir ve özellikle az sayıda ekranın içeriğinin dinamik olarak değiştiği mobil uygulamalarda işe yarar 4. Tel kafes, prototip ve mockup arasındaki farkları wireframe, mockup ve prototip farkı yazısında anlattık.

Sık yapılan hatalar

• Yalnız mutlu yolu çizmek: Geliştirme sırasında en çok soru doğuran şey, akışta olmayan hata dallarıdır.
• Ekranı ve eylemi karıştırmak: "Kaydet" bir eylemdir, ekran değildir. İkisi aynı şekille çizilirse akış okunmaz hâle gelir.
• Sistem yanıtını atlamak: Kullanıcı düğmeye bastıktan sonra ne görüyor? Yükleniyor durumu, onay ya da hata da akışın parçasıdır.
• Tek akışa her şeyi sığdırmak: Randevu alma, iptal ve erteleme ayrı görevlerdir; ayrı akışlarda daha anlaşılır olurlar.
• Akışı test etmemek: Akış bir hipotezdir. Prototipe dökülüp gerçek kullanıcılarla denenmeden kesinleşmiş sayılmamalıdır; testin nasıl kurulacağı için kullanılabilirlik testi nasıl yapılır yazısına bakabilirsiniz.

Karmaşık rol ve izin yapısına sahip bir SaaS ürününde akışları birlikte kurmak isterseniz SaaS ürün tasarımı hizmetimizin kapsamına göz atabilirsiniz.