Aktivite Odaklı Tasarım ve Görev Analizi: Ağaç Nerede Kesilir

Kullanıcı bir hedefe ulaşmak için ekranda tam olarak ne yapıyor? Aktivite odaklı tasarım bu soruyu merkeze alır, görev analizi de cevabı çıkarma yöntemidir. Zor kısmı yöntemi öğrenmek değil, çözümlemeyi nerede keseceğine karar vermek.

Hedef, aktivite, görev

Üçünü ayırmadan analiz yürümez. Hedef, kullanıcının bitirmek istediği şeydir: siparişi tamamlamak. Aktivite, o hedefe götüren tekrarlı davranış kümesidir; ürün seçmek, sepeti düzenlemek, ödemeye geçmek. Görev ise aktivitenin içindeki tek tek adım, mesela kart numarasını girmek.

Ayrımın pratik faydası şu: tasarım kararlarının çoğu aktivite seviyesinde alınır, ölçüm ise görev seviyesinde yapılır. Aktiviteyi değiştirmeden görev sayısını azaltmaya çalışırsan ekranı sıkıştırmaktan başka bir şey yapmış olmazsın.

Analizi çıkarmanın kısa yolu

Hedefi tek cümleyle yaz. Cümle iki hedef birden içeriyorsa aslında iki ayrı analiz yapıyorsun demektir, ikiye böl.

Sonra insanların gerçekte ne yaptığını topla:

• Sesli düşünme oturumu: kullanıcı işi yaparken ne beklediğini anlatır, nerede duraksadığını sen görürsün.
• Bağlamsal gözlem: kişiyi kendi masasında, kendi verisiyle izlemek. Laboratuvarda ortaya çıkmayan kısayollar burada çıkar.
• Var olan sistemin kayıtları: hangi adım kaç kez tekrarlanıyor, nereden geri dönülüyor.

Üçünü birden yapmaya gerek yok. Sistem yayındaysa kayıtla başla, şaşırtıcı bir şey görürsen üstüne bir oturum koy.

Ağaç nerede kesilir

Görev analizinin asıl zorluğu burada. Her görevi ortalama üç alt adıma bölersen dördüncü seviyede 81, beşincide 243 yaprak olur. Kimse 243 satırlık bir ağacı okuyup tasarım kararı vermez; o doküman yazıldığı gün ölür.

Basit bir kesme ölçütü var: bir adımı ikiye bölmek hiçbir tasarım kararını değiştirmiyorsa bölme. ‘Formu doldur’ ile ‘ad alanına tıkla’ arasındaki fark tam olarak budur. İkincisi ancak alanların sırası gerçekten tartışma konusuysa anlamlı.

Ben ağacı genelde iki seviyede kesip geri kalanını olay kayıtlarına bırakırım: kullanıcının hangi tıklamada takıldığını masa başında tahmin etmeye çalışmaktansa arayüze birkaç satır log koyup okumak hem daha ucuz hem daha doğru.

Arayüzden bağımsız yazmak

Yaygın tavsiye, görevleri arayüzden bağımsız tanımlamaktır: ‘ara’ de, ‘arama kutusuna yaz’ deme. Tavsiye yerinde ama uygulama sırası çoğu metinde ters veriliyor. Veriyi mevcut arayüzden toplarsın, çünkü insanlar ancak somut bir şey yaparken izlenebilir. Bağımsızlaştırma sonradan gelen bir temizlik adımıdır; ağacı yazarken arayüze özgü fiilleri atar, niyeti bırakırsın.

Sıfırdan bir ürün kuruyorsan izleyecek arayüz de yok. O durumda analiz yok denecek kadar azdır: kaba bir hedef listesi çıkarıp prototipe geçmek, masada görev ağacı büyütmekten çok daha hızlı sonuç verir.

Yöntem neyi kaçırır

Görev analizi var olan süreci çok iyi tarif eder, zayıflığı da bu. Çıktı hep mevcut akışın sadeleşmiş hali olur; adım silmeyi önerir, adımı büsbütün gereksiz kılacak farklı bir modeli önermez.

İkinci boşluk motivasyon tarafında. Ağaç, kullanıcının işi neden yarıda bıraktığını göstermez. Güvenmemek, acele etmek, karar verecek bilgiye sahip olmamak ağaçta bir kutu olarak durmaz. Terk oranı yüksek bir akışta görev sayısını düşürmek çoğu zaman hiçbir şeyi değiştirmez, çünkü sorun adımların uzunluğunda değildir. Yöntemi kullan, ama çıktısını süreç haritası olarak gör, ürün stratejisi olarak değil.