Görev Analizi: Özellik Listesinden İş Akışına

Özellik listesi bir yazılımın ne yapabildiğini söyler, kullanıcının işini nasıl bitirdiğini söylemez. Aradaki boşluğu görev analizi doldurur: kullanıcının bir işi tamamlamak için attığı adımlar sırayla çıkarılır, her adımda ekranda hangi bilginin bulunması gerektiği belirlenir. Menüde bir yerlerde duran özellik ile tam karar anında görünen özellik arasındaki fark, çoğu yazılımda memnuniyeti belirleyen farktır.

Özellik listesi neyi ölçmez

Bir listede "fatura görüntüleme" satırı işaretliyse özellik vardır. Listenin ölçmediği şey, o özelliğin nerede durduğudur. Masraf onayı yapan biri kalemi görür, tutarı görür, ama faturanın kendisine bakmak için satıra tıklayıp açılan panelde ikinci bir bağlantıya daha gitmek zorundaysa, elli kalemlik bir raporda yüz fazladan etkileşim birikir. Özellik tamdır, iş akışı bozuktur.

Bu yüzden analiz, "hangi ekranda ne olacak" sorusundan değil, "kullanıcı bu adımda hangi kararı veriyor" sorusundan başlar. Karar belliyse, o kararı vermek için gereken veri de bellidir. Ekranda kalması gereken tam olarak odur.

Analizi çıkarmanın adımları

Önce izle, sonra sor

Anket, insanların yaptıklarını değil yaptıklarını sandıklarını verir. Contextual inquiry burada işe yarıyor: kullanıcı kendi masasında, kendi verisiyle çalışırken izlenir. Bakılacak şeyler basit. Kaç sekme açık, hangi bilgiyi kağıda not alıyor, hangi adımda durup birine soruyor. Yan ekranda açık duran bir Excel dosyası, o verinin yazılımda yanlış yerde durduğunun en net işaretidir.

Adımları yaz, her adıma veri iliştir

Gözlemi sıralı bir akışa dökerken wireflow gibi bir gösterim yeterli: kutular adımları, oklar geçişleri taşır. Her kutunun altına iki satır düşülür. Bu adımda ne karar veriliyor, bu kararı vermek için hangi alanlar gerekiyor. Analizin asıl çıktısı çizim değil, bu ikili listedir.

Sıklığa göre yerleştir

Aynı akış içinde her adım eşit sıklıkta değildir. Yüz onaydan doksanında sadece tutar ve kategori bakılıyorsa, o iki alan ana görünümde kalır; nadiren açılan denetim geçmişi bir tık geriye çekilir. Buradaki karar sezgiyle değil, gözlemde tuttuğun sayıyla verilir.

Yarım kalmayı tasarla

Gerçek kullanımda akışlar tamamlanmaz. Telefon çalar, eksik belge beklenir, kullanıcı ertesi güne bırakır. Bir adımın kesilip sonra kaldığı yerden sürdürülebilmesi, akışın kendisi kadar tasarım konusudur.

Alternatif akışların maliyeti

Kullanıcıların farklı sıralarla çalıştığı doğru. Biri önce belgeleri yüklüyor, diğeri önce kalemleri giriyor. Buradan "her sıraya izin verelim" sonucu çıkarılınca iş büyür: birbirinden bağımsız beş adımın sıralanma biçimi 5! yani 120 farklı yol demektir. Bunların hepsini ayrı ayrı düşünmek, test etmek ve dokümante etmek mümkün değil.

Pratikte tek bir varsayılan sıra seçilir ve o sıra kusursuz çalışacak biçimde tasarlanır. Geri kalan sıralar tasarlanmaz, sadece kırılmaz: kullanıcı beklenmedik bir yerden girdiğinde ekran hata vermez, girdiği veri kaybolmaz.

Bunun bedeli arayüzde değil veri modelinde ödenir. Serbest sıra, kaydın yarım haliyle saklanabilmesi demektir; zorunlu alanları olan bir tabloya yarım kayıt yazamazsın. Taslak durumunu baştan tanımlar, doğrulamayı kaydetme anından ayırıp gönderme anına taşırsan bu esnekliği ayrı bir akış motoruna ihtiyaç duymadan alırsın. Sonradan eklenmeye kalkıldığında ise migration, mevcut kayıtların geriye dönük doldurulması ve her formda ikinci bir doğrulama katmanı çıkar.

Analiz nerede biter

Görev analizinin bitiş noktası, akış şemasının bütün ihtimalleri kapsaması değil. Doksan kullanımda tekrarlanan tek bir yolu bulup onu adım adım sağlamlaştırmak, kalan onu için sadece veri kaybını önlemek yeterli. Her iki uca eşit emek harcayan ekipler genelde ikisini de yarım bırakıyor.