UX'te Use Case Yazımı: Ana Akış, İstisnalar ve Son Koşul
Use case, bir kullanıcının hedefine giderken attığı adımları ve sistemin her adıma verdiği yanıtı yan yana yazma işidir. Tarifi basit, uygulaması nadiren öyle: ekiplerin çoğunda ya hiç yazılmıyor ya da kimsenin açmadığı kırk sayfalık bir dosyaya dönüşüyor. Aradaki farkı belirleyen şey, belgeye neyin girmeyeceğine karar verebilmek.
Use case nereden çıktı
Use case'i UX'e ait bir empati aracı sanmak yaygın, oysa kökeni yazılım mühendisliği. Ivar Jacobson 1980'lerin sonunda telekom sistemlerini tarif etmek için kullandı, Alistair Cockburn 2000'lerin başında yayımladığı kitapta hedef seviyeleri fikrini oturttu. Bu köken, belgenin neye iyi geldiğini de açıklıyor: use case sistemin sınırını çizer. İçeride ne var, dışarıda kim var, ikisi arasında hangi mesajlar gidip geliyor.
UX tarafında işe yaramasının sebebi de bu. Araştırmadan çıkan niyet ile ekranların davranışı arasında çeviri yapan tek belge çoğu zaman use case oluyor. Persona kullanıcının kim olduğunu söyler, use case sistemin ona ne cevap verdiğini.
Senaryo, user story ve use case
Üçü birbirinin yerine kullanılıyor ama farklı işler yapıyorlar. User story bir planlama birimi, sprint'e sığsın diye kısa yazılır ve asıl amacı konuşmayı başlatmaktır. Senaryo tek bir yolu hikâye gibi anlatır: adı olan bir kişi, bir bağlam, baştan sona giden tek bir patika. Use case ise aynı hedefe giden yolların hepsini, sistemin yanıtlarıyla birlikte tutar.
Peki her akış için use case yazmalı mı? Hayır. Basit bir içerik sayfasında senaryo fazlasıyla yeterli. Use case'in maliyetini geri ödediği yerler dar: para, izin ve durum değişikliği olan akışlar. Ödeme, iade, üyelik iptali, yetki devri. Buralarda "kullanıcı ortada vazgeçerse ne olur" sorusunun cevabı hem tasarımı hem veritabanını ilgilendirir, o yüzden yazılı olması gerekir.
İyi bir use case'in iskeleti
Başlık aktörün hedefidir, sistemin işlemi değil. "Kullanıcı biletini iade eder" doğru bir başlık, "iade servisi çağrılır" değil. Hedefi bu seviyede tutmak belgenin nerede biteceğini de belirler.
Altına tetikleyici ve ön koşul gelir: akış neyle başlıyor, başlayabilmesi için sistemde neyin doğru olması gerekiyor. Ana akış numaralı adımlarla ilerler ve beş ila dokuz adımı geçmemesi iyi bir işaret. Daha uzunsa büyük ihtimalle iki ayrı hedefi tek belgeye sıkıştırmışsınızdır.
En çok atlanan parça son koşul. Akış başarıyla bittiğinde sistemde ne doğru olmalı? Bilet iptal işaretlenmiş, koltuk envantere dönmüş, iade kaydı açılmış olmalı. Bu satır yazılmadığında ekranlar doğru görünür ama arkada yarım kalmış durumlar birikir. Testi yazacak kişinin aradığı satır da tam olarak budur.
İstisnaları tek tek yazmak neden tıkanır
"Tüm istisnai durumları önceden düşünün" tavsiyesi kulağa doğru geliyor, ama sayınca ters çalıştığı yer hemen görünüyor. Bir ödeme akışında altı ikili karar noktası olsun: kullanıcı giriş yapmış mı, kayıtlı kartı var mı, adresi tanımlı mı, kupon giriyor mu, teslimat slotu seçiyor mu, sözleşmeyi onaylıyor mu. Her kombinasyonu ayrı bir yol olarak yazarsanız 2 üzeri 6, yani 64 patika çıkar. Yedinci karar bunu 128'e taşır. Aynı belgeye hem "modüler ve sade yaz" hem "hiçbir istisnayı atlama" demek bu yüzden kendi içinde çelişiyor.
Çıkış yolu, patikaları değil hata sınıflarını yazmak: girdi geçersiz, dış servis yanıt vermiyor, yetki yok, akış ortasında durum değişti (koltuğu başkası aldı). Dört beş sınıf 64 kombinasyonun tamamını karşılar, çünkü her kombinasyon eninde sonunda bunlardan birine düşer. Ben istisnaları ana akışın numaralı adımlarının arasına serpiştirmem; ana akış tek sütun halinde okunabilir kalsın, istisnalar 3a, 3b diye altta toplansın.
Yarım sayfaya sığan örnek
Hedef: Kullanıcı biletini iade eder.
Ön koşul: Bilet kullanıcının hesabına bağlı, kalkışa 24 saatten fazla var.
Ana akış: Kullanıcı biletlerim listesinden bileti seçer, iade tutarını ve kesintiyi görür, onaylar. Sistem iade kaydını açar, koltuğu serbest bırakır, kullanıcıya referans numarası gösterir.
İstisnalar: 2a tarife servisi yanıt vermediği için kesinti hesaplanamıyor, 3a koltuk aynı anda değiştirilmiş, 3b banka iadesi beklemede.
Son koşul: Bilet iptal, koltuk envanterde, iade kaydı referansıyla izlenebilir.
Bunun "kullanıcı ilgi alanını seçer, favorilere ekler, paylaşır" tarzı özetlerden farkı, her satırın bir karara ya da bir sistem durumuna karşılık gelmesi. Karar üretmeyen cümle use case'de yer kaplıyor demektir.
Belge nerede durursa yaşar
Use case'in ölmesinin en yaygın sebebi içeriği değil, yeri. Tasarım dosyalarından ayrı bir sürücüde duran belge ikinci sprint'te güncelliğini kaybediyor. İşe yarayanı onu tüketen yere yakın tutmak: ilgili görev kaydına ya da akışın kod deposundaki testine bağlamak. Akış değiştiğinde belgeyi güncellemeyen kişi zaten testi de kırar, ikisi yan yana durduğunda güncelleme kendiliğinden gelir.
Peki hiç use case yazmadan iyi ürün çıkar mı? Çıkar. Ama para veya durum değiştiren akışlarda yazmayan ekipler aynı soruları her toplantıda baştan konuşuyor. Belge, o konuşmanın kalıcı hali.